code-anchored-context 0.1.0 → 0.2.0

package/.agents/skills/README.md

@@ -8,6 +8,6 @@ project.
 
 ## Repository-Wide Skills
 
-- `development-initiative-context` - use central `Development/` initiatives
+- `code-anchored-context` - use central `context/` initiatives
   for planning, implementation context, programs, planned initiatives, ADRs,
   backlog, and release-documentation notes.

package/.agents/skills/{development-initiative-context → code-anchored-context}/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: development-initiative-context
-description: Use central repository Development context for planning and implementation. Use when starting, changing, reviewing, or documenting behavior-changing work; when checking or updating Development/current.md, Development/releases/*/initiatives/*, Development/programs/*, Development/programs/*/planned-initiatives/*, Development/backlog/items/*, specs, plans, interface notes, architecture notes, testing notes, delivery notes, infrastructure notes, actionable operations notes, ADRs, backlog, release-doc-notes.md; when promoting planned initiatives during release transitions; or when deciding whether Documentation/ should be left untouched.
+name: code-anchored-context
+description: Use central repository context for planning and implementation. Use when starting, changing, reviewing, or documenting behavior-changing work; when checking or updating context/current.md, context/releases/*/initiatives/*, context/programs/*, context/programs/*/planned-initiatives/*, context/backlog/items/*, specs, plans, interface notes, architecture notes, testing notes, delivery notes, infrastructure notes, actionable operations notes, ADRs, backlog, release-doc-notes.md; when promoting planned initiatives during release transitions; or when deciding whether docs/ should be left untouched.
 ---
 
-# Development Initiative Context
+# Code-Anchored Context
 
 ## Overview
 
-Use this skill to connect code work back to the central development context
-under `Development/`. The goal is to keep initiative knowledge centralized,
+Use this skill to connect code work back to the central working context
+under `context/`. The goal is to keep initiative knowledge centralized,
 preserve durable multi-release context in programs, and keep deferred
-isolated work discoverable in the development backlog. Scoped future program
+isolated work discoverable in the context backlog. Scoped future program
 work belongs in planned initiatives until the target release becomes current.
-Development context should also cover delivery concerns such as testing,
+Working context should also cover delivery concerns such as testing,
 delivery pipelines, and infrastructure when they affect how the work is
 verified, shipped, deployed, or hosted.
 
@@ -23,33 +23,33 @@ verified, shipped, deployed, or hosted.
 Read the nearest `AGENTS.md` files for the workspace and area being changed.
 Respect area-specific engineering rules first.
 
-### 2) Find The Current Development Context
+### 2) Find The Current Context
 
-Open `Development/current.md` from the repository root. It points to the
+Open `context/current.md` from the repository root. It points to the
 active release folder.
 
-Use `Development/terminology.md` as the canonical vocabulary for programs,
+Use `context/terminology.md` as the canonical vocabulary for programs,
 planned initiatives, release initiatives, backlog items, statuses, and
 promotion.
 
 If the workspace starts inside a subfolder, navigate upward to the repository
-root when the environment allows it. If `Development/` is not available in
+root when the environment allows it. If `context/` is not available in
 the workspace, mention that limitation in the task summary.
 
 ### 3) Match Existing Context
 
 Search these places for matching context:
 
-- active release initiatives under `Development/releases/<current-release>/initiatives/`
-- durable programs under `Development/programs/`
-- scoped future program work under `Development/programs/<program>/planned-initiatives/`
-- deferred items under `Development/backlog/items/`
+- active release initiatives under `context/releases/<current-release>/initiatives/`
+- durable programs under `context/programs/`
+- scoped future program work under `context/programs/<program>/planned-initiatives/`
+- deferred items under `context/backlog/items/`
 
 Search for:
 
 - the feature or bug name
-- affected area names, such as frontend, API, shared library, deploy, or
-  automation
+- affected concern names, such as product code, APIs, contracts, tests,
+  delivery, CI/CD, infrastructure, config, generated artifacts, or automation
 - related domain terms, APIs, jobs, entities, routes, config names, or tickets
 
 Use an existing initiative when the work belongs to it, even if the code
@@ -62,10 +62,10 @@ Create a new initiative for non-trivial behavior changes, cross-project
 work, release-significant work, or anything likely to need future product
 documentation.
 
-Use `Development/_templates/initiative/` as the source. Copy it to:
+Use `context/_templates/initiative/` as the source. Copy it to:
 
 ```text
-Development/releases/<current-release>/initiatives/<initiative-slug>/
+context/releases/<current-release>/initiatives/<initiative-slug>/
 ```
 
 Update the copied `README.md` first so future agents can quickly understand
@@ -82,10 +82,10 @@ If future program work is known well enough to scope, split, or preserve
 implementation intent, create a planned initiative under the parent program:
 
 ```text
-Development/programs/<program-slug>/planned-initiatives/<initiative-slug>/
+context/programs/<program-slug>/planned-initiatives/<initiative-slug>/
 ```
 
-Use `Development/_templates/planned-initiative/` as the source.
+Use `context/_templates/planned-initiative/` as the source.
 
 Use a planned initiative when:
 
@@ -95,7 +95,7 @@ Use a planned initiative when:
 - capturing it only in `roadmap.md` or `releases/<version>.md` would lose
   useful scope or implementation context
 
-Do not create a future `Development/releases/<version>/` initiative just to
+Do not create a future `context/releases/<version>/` initiative just to
 hold planned work unless that release is being made current or release
 planning has explicitly begun.
 
@@ -104,14 +104,14 @@ planning has explicitly begun.
 Use the right outliving path when initiative context needs to survive beyond
 the current release:
 
-- `Development/programs/<program-slug>/`: multi-release efforts, phases,
+- `context/programs/<program-slug>/`: multi-release efforts, phases,
   roadmaps, durable decisions, and release-slice history
-- `Development/programs/<program-slug>/planned-initiatives/<initiative-slug>/`:
+- `context/programs/<program-slug>/planned-initiatives/<initiative-slug>/`:
   scoped future delivery slices that are not in the current release yet
-- `Development/backlog/items/<originating-initiative-slug>--<item-slug>.md`:
+- `context/backlog/items/<originating-initiative-slug>--<item-slug>.md`:
   isolated deferred work cut from an initiative
 
-When creating a backlog item, use `Development/_templates/backlog-item.md`
+When creating a backlog item, use `context/_templates/backlog-item.md`
 and link to the originating initiative and release.
 
 When picking up a backlog item later, keep the item as a historical record.
@@ -122,17 +122,17 @@ Mark it as promoted and link to the new release initiative.
 When asked to set a new current release, treat it as a release transition,
 not just a `current.md` edit.
 
-Use `Development/_templates/release-transition.md` as the checklist:
+Use `context/_templates/release-transition.md` as the checklist:
 
-1. Update `Development/current.md`.
-2. Create `Development/releases/<target-release>/` from
-   `Development/_templates/release-context/` if missing.
-3. Scan `Development/programs/*/planned-initiatives/*/README.md` for
+1. Update `context/current.md`.
+2. Create `context/releases/<target-release>/` from
+   `context/_templates/release-context/` if missing.
+3. Scan `context/programs/*/planned-initiatives/*/README.md` for
    `Target release: <target-release>`.
 4. Promote each match into:
 
 ```text
-Development/releases/<target-release>/initiatives/<initiative-slug>/
+context/releases/<target-release>/initiatives/<initiative-slug>/
 ```
 
 5. Update the planned initiative metadata to `Status: Promoted`, with
@@ -175,13 +175,13 @@ settled truth lives. Promote stable conclusions into `spec.md`,
 `infrastructure.md`, `operations.md` when actionable, `backlog.md`, ADRs, or
 `release-doc-notes.md` as appropriate.
 
-### 9) Preserve The Documentation Boundary
+### 9) Preserve The Docs Boundary
 
-Do not edit `Documentation/` as part of normal feature work, bug fixes,
+Do not edit `docs/` as part of normal feature work, bug fixes,
 refactors, or planning. Instead, update the initiative's
 `release-doc-notes.md`.
 
-Only update `Documentation/` when a human explicitly asks for release
+Only update `docs/` when a human explicitly asks for release
 documentation work, a specific page update, or a demonstrable documentation
 fix.
 
@@ -189,7 +189,7 @@ fix.
 
 Denormalize navigation, not knowledge.
 
-Local `AGENTS.md` files may point to `Development/`, but initiative specs,
+Local `AGENTS.md` files may point to `context/`, but initiative specs,
 plans, ADRs, and release-doc notes should live in the central initiative
 folder. Do not create area-local copies of initiative documents.
 
@@ -198,7 +198,7 @@ folder. Do not create area-local copies of initiative documents.
 Before finishing behavior-changing work:
 
 - The matching initiative was read or a reason was given for why none exists.
-- Matching programs or development backlog items were checked when the work
+- Matching programs or context backlog items were checked when the work
   appears phased, deferred, or multi-release.
 - Planned initiatives were checked or created when future program scope is
   already clear but outside the current release.
@@ -206,4 +206,4 @@ Before finishing behavior-changing work:
   infrastructure, actionable operations, or backlog state was reflected in the
   initiative when appropriate.
 - Future product-documentation impact was captured in `release-doc-notes.md`.
-- `Documentation/` was left untouched unless explicitly requested.
+- `docs/` was left untouched unless explicitly requested.

package/AGENTS.md

@@ -3,30 +3,32 @@
 This file applies to the whole repo. Area-specific `AGENTS.md` files in
 subfolders layer on top of it. Read those too when working in a given area.
 
-## Development Context
+## Working Context
 
 In-progress specs, plans, ADRs, backlog, implementation context, and
-release-documentation notes live under [`Development/`](Development/).
-Start with [`Development/current.md`](Development/current.md).
+release-documentation notes live under [`context/`](context/).
+Start with [`context/current.md`](context/current.md).
 
 For behavior-changing work, use the repo-wide skill at
-[`.agents/skills/development-initiative-context/SKILL.md`](.agents/skills/development-initiative-context/SKILL.md).
-Keep initiative knowledge centralized under `Development/`; area
+[`.agents/skills/code-anchored-context/SKILL.md`](.agents/skills/code-anchored-context/SKILL.md).
+Keep initiative knowledge centralized under `context/`; area
 `AGENTS.md` files should point there rather than copying active plans.
 
-## Documentation Authoring
+## Docs Authoring
 
-### When To Edit `Documentation/`
+### When To Edit `docs/`
 
-Do not edit `Documentation/` as a side effect of feature work, bug fixes,
+Do not edit `docs/` as a side effect of feature work, bug fixes,
 refactors, or other code changes. Docs in this model are release-anchored:
 they describe the behavior of a specific release tag, not the partial state of
 a working branch.
 
-Touch `Documentation/` only when:
+Touch `docs/` only when:
 
 - A human explicitly asks you to refresh the docs for a release, typically
   after a release tag is cut and QA has signed off.
+- A human explicitly asks you to create or refresh baseline documentation for
+  an existing project.
 - A human explicitly asks you to update a specific page.
 - A human asks you to fix a demonstrable error in an existing page, such as a
   broken link or factual inaccuracy.
@@ -35,16 +37,16 @@ If you are unsure whether the request is one of these, ask before editing.
 
 If a project has documentation that intentionally follows a different cadence,
 document that exception in the area's README and in
-`Documentation/_authoring/areas/`.
+`docs/_authoring/areas/`.
 
 ### Where The Authoring Guidance Lives
 
 All documentation workflow, per-area authoring guides, and domain terminology
-live under [`Documentation/_authoring/`](Documentation/_authoring/). Start
-with [`Documentation/_authoring/README.md`](Documentation/_authoring/README.md).
+live under [`docs/_authoring/`](docs/_authoring/). Start
+with [`docs/_authoring/README.md`](docs/_authoring/README.md).
 
 If you are refreshing docs, the per-area guides in
-[`Documentation/_authoring/areas/`](Documentation/_authoring/areas/) tell you
+[`docs/_authoring/areas/`](docs/_authoring/areas/) tell you
 what matters and what to ignore for each area.
 
 `AGENTS.md` files stay lean. They are for coding conventions and agent

package/README.md

@@ -1,15 +1,15 @@
 # Code-Anchored Context Template
 
 This repository is a reusable starting point for keeping repository-local
-development context and release-anchored product documentation close to the
+working context and release-anchored product documentation close to the
 code they describe.
 
 It separates two kinds of truth:
 
 | Folder | Meaning | Updated when |
 | --- | --- | --- |
-| `Development/` | What the team is planning, building, deciding, validating, shipping, hosting, deferring, and learning. | During normal development. |
-| `Documentation/` | What the product does as of a known release or tag. | Only during explicit documentation refresh work. |
+| `context/` | What the team is planning, building, deciding, validating, shipping, hosting, deferring, and learning. | During normal development. |
+| `docs/` | What the product does as of a known release or tag. | Only during explicit documentation refresh work. |
 
 The goal is to give humans and AI agents enough structured context to change a
 codebase without relying on chat history, tribal memory, or scattered planning
@@ -18,11 +18,11 @@ notes.
 ## What This Template Contains
 
 - `AGENTS.md` with repo-wide agent guidance.
-- `.agents/skills/development-initiative-context/SKILL.md` for the recurring
-  development-context workflow.
-- `Development/` with terminology, release context, backlog/program structure,
+- `.agents/skills/code-anchored-context/SKILL.md` for the recurring
+  working-context workflow.
+- `context/` with terminology, release context, backlog/program structure,
   initiative templates, and a human-readable article and brief.
-- `Documentation/` with a generic release-anchored documentation workflow,
+- `docs/` with a generic release-anchored documentation workflow,
   authoring guide structure, and area/page templates.
 
 ## Adopting This In A Project
@@ -39,23 +39,23 @@ Useful options:
 
 ```bash
 npx code-anchored-context init --dry-run
-npx code-anchored-context init --no-documentation
+npx code-anchored-context init --no-docs
 npx code-anchored-context init --target ../existing-project
 ```
 
 The initializer copies the repo-local agent context into the target project,
 adds or updates guidance in `AGENTS.md`, installs the
-`development-initiative-context` skill under `.agents/skills/`, and replaces
+`code-anchored-context` skill under `.agents/skills/`, and replaces
 basic placeholders such as `PROJECT_NAME` and the initial release slug.
 
 Manual adoption still works:
 
 1. Copy the files into a repository root.
 2. Replace `PROJECT_NAME` placeholders with the project name.
-3. Set the first active release in `Development/current.md`.
+3. Set the first active release in `context/current.md`.
 4. Add or revise area-specific `AGENTS.md` files so they point back to
-   `Development/` and `Documentation/_authoring/`.
-5. Create `Documentation/_authoring/areas/<area>.md` for each documented
+   `context/` and `docs/_authoring/`.
+5. Create `docs/_authoring/areas/<area>.md` for each documented
    product or code area.
 6. Keep product or domain-specific documentation out of this template repo.
 
@@ -78,8 +78,8 @@ npx @your-scope/code-anchored-context init
 
 ## Working Rule
 
-Development context can evolve with the branch. Product documentation should
+Working context can evolve with the branch. Product docs should
 stay stable and release-accurate. When behavior changes during development,
 record future documentation impact in the relevant initiative's
-`release-doc-notes.md`; refresh `Documentation/` only when that work is
+`release-doc-notes.md`; refresh `docs/` only when that work is
 explicitly requested.