aw-spec-cli 0.1.1 → 0.1.2

package/assets/.claude/skills/aw-spec-implement/SKILL.md

@@ -19,6 +19,17 @@ $ARGUMENTS
 
 You **MUST** consider the user input before proceeding (if not empty).
 
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
+## Project Structure Gate (run before loading standards)
+
+**Before loading standards or writing code, confirm a scaffolded app exists** — the output of `/aw-spec-foundation`, not just `.aw-spec/`/`docs/`/`specs/` framework files. Check the repo root (Glob/Bash) for a real build entrypoint, ignoring matches only inside `.aw-spec/`/`docs/`/`specs/`: `*.sln` or `*.csproj` under `src/` (.NET/AppWeaver), else `package.json`/`pom.xml`/`build.gradle`/`go.mod`/`Cargo.toml`/`pyproject.toml` etc.
+
+- **None found → STOP, no side effects** (don't load standards, run hooks, or write anything): tell the developer *"No scaffolded project found — run `/aw-spec-foundation ModularMonolith <AppName>` (or `VerticalSlice <AppName>`) first, then re-run."*
+- **Found →** use its solution/host-project path as the implementation target and continue.
+
 ## Auto-Loaded Engineering Standards (Required Context)
 
 **Before doing anything else in this command, load the project engineering-standards files listed below into context using the Read tool.** These were previously supplied manually as `@docs/...` mentions; they are now loaded automatically so the user does not need to pass them. Rules:

package/assets/.claude/skills/aw-spec-minimal-implementation/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: "aw-spec-minimal-implementation"
+description: "Single-step implementation tier: takes a requirement DIRECTLY as the argument (an `Aggregate/Feature` token + free-text requirement) and implements it in one load-and-execute pass — no /aw-spec-specify, no spec.md, no plan.md/tasks.md, no analysis report. Loads a curated technical + domain rule set once, builds a structurally complete vertical slice (implementing what the loaded rules support, stubbing only genuinely-external runtime services), emits a final execution note, then offers an opt-in breakdown of unclear areas. For audited/traceable work use /aw-spec-fast-implement or the full plan→tasks→analyze→implement flow instead."
+argument-hint: "<Aggregate>/<Feature> then the requirement text — e.g. MedicinalProduct/RegisterMedicinalProduct  Allow an authorized user to register a new medicinal product..."
+compatibility: "Requires a scaffolded application project (output of /aw-spec-foundation) and the .aw-spec/ directory. Does NOT require a spec.md or /aw-spec-specify."
+metadata:
+  author: "github-aw-spec"
+  source: "templates/commands/minimal-implementation.md"
+user-invocable: true
+disable-model-invocation: false
+---
+
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+**The argument IS the requirement — this is a single-step command.** `$ARGUMENTS` contains an `Aggregate/Feature` token (two PascalCase segments separated by `/`, e.g. `MedicinalProduct/RegisterMedicinalProduct`) followed by the free-text requirement (the feature description + acceptance criteria). There is **no** `/aw-spec-specify` step and **no** `spec.md`: parse the requirement straight from this argument and implement it in one pass. If `$ARGUMENTS` is empty, or carries an `Aggregate/Feature` token but no requirement text, STOP and show usage: `/aw-spec-minimal-implementation <Aggregate>/<Feature> <requirement text>`.
+
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
+## When to use this command
+
+**Single-step tier.** Takes the requirement directly from the argument and implements it in one pass — **no** `/aw-spec-specify`, **no** `spec.md`/`plan.md`/`tasks.md`/research/contracts/analysis — loading a curated rule set (technical standards + the domain's single-step set) once, ending with a final note + an opt-in unclear-areas breakdown. It implements what the loaded rules support; only a **genuinely-external runtime service** (live terminology server, external FHIR endpoint) is left as an injectable fixture port, recorded as a deferral.
+
+**Non-negotiable:** scaffolded project present (gate below), requirement supplied, constitution MUST principles honored, architecture patterns (vertical slices, CQRS, folder structure) + the aggregate's in-aggregate invariants (NDC format, ≥1 ingredient, ≥1 packaging, Draft guard) implemented, and an in-memory coverage check before writing code. **Escalate to `/aw-spec-fast-implement`** (or the full flow) if you need the heavy integrations actually built, traceable artifacts, or the work is audited/complex.
+
+## Project Structure Gate (run before loading standards)
+
+**Before loading standards or writing code, confirm a scaffolded app exists** — the output of `/aw-spec-foundation`, not just `.aw-spec/`/`docs/`/`specs/` framework files. Check the repo root (Glob/Bash) for a real build entrypoint, ignoring matches only inside `.aw-spec/`/`docs/`/`specs/`: `*.sln` or `*.csproj` under `src/` (.NET/AppWeaver), else `package.json`/`pom.xml`/`build.gradle`/`go.mod`/`Cargo.toml`/`pyproject.toml` etc.
+
+- **None found → STOP, no side effects** (don't load standards, run hooks, or write anything): tell the developer *"No scaffolded project found — run `/aw-spec-foundation ModularMonolith <AppName>` (or `VerticalSlice <AppName>`) first, then re-run."*
+- **Found →** use its solution/host-project path as the implementation target and continue.
+
+## Auto-Loaded Engineering Standards (Required Context)
+
+**Load these files once with the Read tool, before the Pre-Execution Checks.** Treat them as authoritative (second only to `.aw-spec/memory/constitution.md`); skip any that don't exist. This list is the domain-agnostic **technical knob** (the domain knob is the `## /aw-spec-minimal-implementation` heading in `comandrulemap.md`); edit it to tune richness, or add a file with an `@` mention.
+
+Technical standards for `/aw-spec-minimal-implementation`:
+- docs/architecture/folder-structure.md
+- docs/architecture/vertical-slices.md
+- docs/architecture/cqrs.md
+- docs/architecture/persistence.md
+- docs/architecture/eventing.md
+- docs/domain/domain-driven-design.md
+- docs/security/authorization.md
+- docs/security/auditing.md
+- docs/security/data-classification.md
+- docs/governance/coding-standards.md
+- docs/governance/dependency-policy.md
+- docs/glossary/ai-rules.md
+
+## Domain Rule-File Selection (once)
+
+After the technical standards are loaded, resolve the active domain and load the domain's curated rule set — once.
+
+1. **Resolve the active domain.** Read `.aw-spec/domain.json`'s `domain`. Load **exactly the files listed** under the **`## /aw-spec-minimal-implementation`** heading in `docs/domainspecs/<domain>/comandrulemap.md` (the per-domain knob; the set varies by domain).
+   - **Fallback:** if that heading is absent, load `domain-driven-design.domain.md` + the domain's terms file (`pharma-terms.md`/`clinical-terms.md`) + lifecycle file (`product-lifecycle.domain.md`) if present. A missing heading is **not** an error.
+2. **Domain gate (missing domain or rules).** If `.aw-spec/domain.json` is absent or its `domain` is empty, **or** `docs/domainspecs/<domain>/comandrulemap.md` does not exist:
+   - If no domain is set, do **not** hard-block. Note "no domain set / domain rules unavailable — running technical-only" and continue with just the technical standards (plus any `@`-mentioned files).
+   - Exception: if the user explicitly asked to enforce a domain and none is set, tell them to run `/aw-spec-select-domain` and stop.
+3. **Load the minimal set.** Because the set is already small, default to loading **all** of it (no selection prompt needed). Read each file once; skip missing files silently. In an interactive session you MAY offer a one-line confirm, but the default is "load all of the minimal set".
+4. **Final context set** = technical standards ＋ the domain's rule set ＋ any `@`-mentioned files (always loaded in addition).
+5. Proceed to the Pre-Execution Checks only after these are loaded.
+
+## Pre-Execution Checks
+
+**Check for collapsed pre-hooks**:
+- Check if `.aw-spec/extensions.yml` exists. If not, skip silently.
+- If it exists, read it and collect enabled hook entries under `hooks.before_implement` (the only pre-point relevant to an implementation-only tier). Treat hooks without `enabled` as enabled; skip `enabled: false`.
+- Do **not** evaluate `condition` expressions: run a hook only if it has no non-empty `condition`; otherwise leave it to the HookExecutor.
+- When building slash commands from hook command names, replace dots with hyphens (`aw-spec.git.commit` → `/aw-spec-git-commit`).
+- For each executable hook, emit:
+  - **Optional** (`optional: true`):
+    ```
+    ## Extension Hooks
+
+    **Optional Pre-Hook**: {extension}
+    Command: `/{command}`
+    Description: {description}
+
+    Prompt: {prompt}
+    To execute: `/{command}`
+    ```
+  - **Mandatory** (`optional: false`):
+    ```
+    ## Extension Hooks
+
+    **Automatic Pre-Hook**: {extension}
+    Executing: `/{command}`
+    EXECUTE_COMMAND: {command}
+
+    Wait for the result of the hook command before proceeding to the Outline.
+    ```
+
+## Outline
+
+This is a **single-step** flow: parse the requirement from the argument, derive the design in your
+head, and implement — all in one pass. No scripts seed artifacts; nothing is read from or written to
+`specs/`.
+
+### 1. Parse the requirement (from the argument — no spec.md)
+
+- From `$ARGUMENTS`, take the leading **`Aggregate/Feature`** token (two PascalCase segments split by `/`, e.g. `MedicinalProduct/RegisterMedicinalProduct`) and treat the remaining text as the **requirement** (description + acceptance criteria). If no `Aggregate/Feature` token is given, derive `<Feature>` from the requirement and `<Aggregate>` from its primary domain entity.
+- If the argument is empty, or carries an `Aggregate/Feature` token but no requirement text, **STOP** with usage (see the User Input section). Do **not** invent a requirement.
+- The **implementation target** is the scaffolded application source tree located by the Project Structure Gate above (its solution/host project). You will place the slice under that app for `<Aggregate>/<Feature>`.
+
+### 2. Build the internal model (in your head — collapses specify+plan+tasks)
+
+Derive, **without writing any files**:
+- **User story + acceptance criteria** from the requirement (what success looks like).
+- **Functional requirements** — give them working `FR-###` keys for the coverage check and the note.
+- **Key entities / aggregate shape**: the aggregate root, its value objects and child entities, and the **in-aggregate invariants** the acceptance criteria imply (e.g. NDC format + uniqueness, ≥1 ingredient, ≥1 packaging, Draft on create).
+- **Constitution**: IF `.aw-spec/memory/constitution.md` exists, load it; its MUST principles are authoritative even here.
+- Track every **ambiguity / missing detail / assumption** as you go — these feed the opt-in part of the Final Execution Note.
+- Do **not** create `spec.md`, `plan.md`, `tasks.md`, `research.md`, `data-model.md`, `contracts/`, or `quickstart.md`.
+
+### 3. Resolve unclear areas without blocking
+
+For each ambiguity or missing detail in the requirement, choose a **documented reasonable assumption** and proceed — this is single-step, so do **not** stop to ask mid-way. Keep a running list of (a) assumptions made and (b) genuinely unclear/under-specified items; both surface in the opt-in section of the Final Execution Note.
+
+### 4. Implement directly from the requirement
+
+Implement straight into the scaffolded app's source tree (no design files):
+- **Structure**: follow `docs/architecture/folder-structure.md` and `vertical-slices.md` — place the feature as a vertical slice under `<Aggregate>/<Feature>` inside the app located by the Project Structure Gate.
+- **Behavior**: apply CQRS command/query separation per `cqrs.md`; model the entities derived in step 2; implement each Functional Requirement and the primary user-story/acceptance flow.
+- **Conventions**: follow `coding-standards.md` and `ai-rules.md` (loaded in the technical set), the loaded domain rules, and the domain's ubiquitous-language/terms glossary for correct vocabulary in names/labels.
+- **Implement what the loaded rules support; stub only genuinely-external services**: implement the aggregate, value objects, entities, and **in-aggregate invariants** for real, and honor whatever domain rules are in this domain's set (e.g. NDC format/structure, ATC/identifier shape, FHIR mapping shape where those files are loaded). Stub **only** a genuinely-external runtime dependency that can't exist in a self-contained build — e.g. a live terminology server or external FHIR endpoint — behind an **injectable port** with a fixture implementation (e.g. an `INdcValidator` / `ITerminologyValidator`). Never invent real coded values; use a clearly-named sentinel. Record each stub/port as a deferral in the Final Execution Note.
+- **Coverage (in-memory)**: before finishing, confirm every Functional Requirement and the acceptance flow is addressed, the aggregate's structural invariants hold, and nothing violates a constitution MUST. **STOP** and recommend `/aw-spec-fast-implement` only if the *structure itself* can't be expressed simply or a constitution MUST is at stake — not merely because an integration is stubbed.
+- **Tests**: only if the requirement explicitly requests them (this tier defaults to no tests).
+- **Ignore files**: ensure `.gitignore` covers the stack (this is a .NET/C# project by default: `bin/`, `obj/`, `*.user`); append only missing critical patterns.
+
+### 5. Build check
+
+Build/compile the affected project. Report the result in the final note. If it fails, fix obvious issues; if the failure indicates the task is more complex than "minimal," say so and recommend escalating to `/aw-spec-fast-implement`.
+
+## Mandatory Post-Execution Hooks
+
+**Complete this before the Final Execution Note.**
+
+- Check if `.aw-spec/extensions.yml` exists; if not, skip to the Final Execution Note.
+- Read enabled hook entries under `hooks.after_implement` (the only post-point relevant to an implementation-only tier — this tier produces no plan, so plan/agent-context hooks do not apply). Treat missing `enabled` as enabled; skip `enabled: false`; do not evaluate `condition` expressions.
+- Convert command names dots→hyphens. For each executable hook, emit:
+  - **Mandatory** (`optional: false`) — **emit `EXECUTE_COMMAND:`**:
+    ```
+    ## Extension Hooks
+
+    **Automatic Hook**: {extension}
+    Executing: `/{command}`
+    EXECUTE_COMMAND: {command}
+    ```
+  - **Optional** (`optional: true`):
+    ```
+    ## Extension Hooks
+
+    **Optional Hook**: {extension}
+    Command: `/{command}`
+    Description: {description}
+
+    Prompt: {prompt}
+    To execute: `/{command}`
+    ```
+
+## Final Execution Note
+
+This is the **only** output record for this tier — there are no spec.md/plan.md/tasks.md files. After the build check, emit a concise note in chat:
+
+- **Feature**: `<Aggregate>/<Feature>` (parsed from the argument).
+- **Files created/changed**: each path with a one-line purpose.
+- **Requirement coverage**: a short `FR-### → file(s)` map and the user-story/acceptance flow implemented.
+- **Stubbed / deferred integrations (option "B")**: each heavy integration stubbed behind a port (terminology/NDC/ATC validation, FHIR projection, audit/lifecycle depth, etc.) with its fixture/sentinel name — so the reader knows what is NOT production-grade and must be built (e.g. via `/aw-spec-fast-implement`) before release.
+- **Standards applied**: "technical standards + <domain> single-step rule set" (or "technical-only").
+- **Build status**: pass/fail (and what was fixed).
+
+### Then offer the unclear-areas breakdown (opt-in)
+
+After the note above, **ask the developer one question** (single-select, e.g. via AskUserQuestion):
+
+> *"Want a breakdown of the unclear/ambiguous areas and the assumptions I made, so you can refine them one by one?"* — options **"Yes — list them"** / **"No — leave it"**.
+
+- **If the developer says yes** (and in a non-interactive run, default to yes): append an **"⚠️ Unclear Areas & Assumptions to Refine"** section — an **itemized, numbered** list where each entry states: *what was unclear or missing in the requirement*, *the assumption / default chosen*, *where it shows up in the code* (file/symbol), and *how to firm it up*. Order them so the developer can fix them one at a time, and include the stubbed integrations here too (each is a thing to finish).
+- **If the developer says no**: end with just the concise note plus the reminder below.
+
+End with: *no design artifacts were persisted — re-run with `/aw-spec-fast-implement` if you need a traceable `plan.md`/`tasks.md` or the heavy integrations fully built.*
+
+## Key rules
+
+- **Single step**: the requirement comes from the argument — never call `/aw-spec-specify` and never read or create a `spec.md`.
+- Load each rule file **once**; never re-read context you already hold.
+- **Never** create `spec.md`, `plan.md`, `tasks.md`, or Phase-1 design files in this tier — the whole point is no persisted artifacts, just the final note.
+- The constitution and the loaded standards are authoritative. **STOP** on an unjustified constitution MUST violation or a requirement that cannot be met simply — escalate to `/aw-spec-fast-implement` rather than shipping partial/incorrect code.
+- Do **not** block mid-way to clarify: make documented assumptions, finish, then offer the unclear-areas breakdown at the end.
+- This is the tier for **simple, non-domain-rich** tasks. If the work turns out domain-rich or complex, stop and recommend `/aw-spec-fast-implement`.
+
+## Done When
+
+- [ ] Project Structure Gate passed (scaffolded app present); requirement parsed from the argument
+- [ ] Technical standards and the domain rule set loaded **once** (or technical-only); constitution MUST principles honored
+- [ ] Internal model derived in-head (no spec.md/plan.md/tasks.md/design files created)
+- [ ] Feature implemented as a vertical slice (CQRS, correct folder structure, domain vocabulary) into the scaffolded app
+- [ ] In-memory coverage check passed (every FR + the acceptance flow addressed)
+- [ ] Build checked; extension hooks dispatched or skipped per the rules above
+- [ ] **Final Execution Note** emitted, and the developer asked whether to include the itemized unclear-areas / assumptions breakdown

package/assets/.claude/skills/aw-spec-plan/SKILL.md

@@ -19,6 +19,10 @@ $ARGUMENTS
 
 You **MUST** consider the user input before proceeding (if not empty).
 
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
 ## Auto-Loaded Engineering Standards (Required Context)
 
 **Before doing anything else in this command, load the project engineering-standards files listed below into context using the Read tool.** These were previously supplied manually as `@docs/...` mentions; they are now loaded automatically so the user does not need to pass them. Rules:

package/assets/.claude/skills/aw-spec-specify/SKILL.md

@@ -19,6 +19,10 @@ $ARGUMENTS
 
 You **MUST** consider the user input before proceeding (if not empty).
 
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
 ## Auto-Loaded Engineering Standards (Required Context)
 
 **Before doing anything else in this command, load the project engineering-standards files listed below into context using the Read tool.** These were previously supplied manually as `@docs/...` mentions; they are now loaded automatically so the user does not need to pass them. Rules:

package/assets/.claude/skills/aw-spec-tasks/SKILL.md

@@ -19,6 +19,10 @@ $ARGUMENTS
 
 You **MUST** consider the user input before proceeding (if not empty).
 
+## Context Reuse (cross-command dedup)
+
+**Skip Read-ing any file already in this conversation.** Before loading a standards/domain/template/spec file this command names, check whether it is already in context (loaded earlier here or by a prior `/aw-spec-*` command). If present and unchanged, reuse it and **skip the Read** — only Read files not yet loaded. A file already in context still counts as loaded; this just avoids the redundant re-read.
+
 ## Auto-Loaded Engineering Standards (Required Context)
 
 **Before doing anything else in this command, load the project engineering-standards files listed below into context using the Read tool.** These were previously supplied manually as `@docs/...` mentions; they are now loaded automatically so the user does not need to pass them. Rules:

package/assets/.kilocode/rules/specify-rules.md

@@ -0,0 +1,4 @@
+<!-- AW-SPEC START -->
+For additional context about technologies to be used, project structure,
+shell commands, and other important information, read the current plan
+<!-- AW-SPEC END -->

package/assets/.kilocode/workflows/aw-spec-addcomponent.md

@@ -0,0 +1,129 @@
+---
+name: "aw-spec-addcomponent"
+description: "Add an opt-in AppWeaver framework component to the project: pick a component from docs/components/, choose one or more implementations from its integration.md catalog, and wire the matching code in."
+argument-hint: "Optional component folder name to select directly (e.g. Email)"
+compatibility: "Requires aw-spec project structure with a docs/components/ directory whose subfolders each contain an integration.md runbook"
+metadata:
+  author: "github-aw-spec"
+  source: "local"
+user-invocable: true
+disable-model-invocation: false
+---
+
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+The text the user typed after `/aw-spec-addcomponent` (if any) is an optional component folder name
+to select directly (e.g. `Email`). If it matches a folder under `docs/components/`, skip the
+component-selection prompt; otherwise fall through to interactive selection.
+
+## Purpose
+
+Add an **opt-in AppWeaver framework component** (Email, Jobs, QrGenerator, …) to the current
+project. Each component lives in its own folder under `docs/components/` and ships two
+agent-readable files: `README.md` (the contract) and `integration.md` (an **ordered agent
+runbook**). This command discovers the available components, lets the developer pick **one**, then
+lets them pick **one or more implementations** from that component's catalog, and finally executes
+the component's own `integration.md` runbook to add the required code.
+
+This command is the entry point; the per-component `integration.md` is the authority on *what code
+to add*. Always defer to the selected component's runbook for the actual edits, package versions,
+registration scaffold, and verification steps — do not invent integration steps from memory.
+
+## Outline
+
+1. **Discover candidate components.** List the immediate **subdirectories** of `docs/components/`
+   (directories only — ignore loose files such as `README.md`). This is the set of selectable
+   components.
+   - If `docs/components/` does not exist or has **no** subdirectories, report that no components
+     are available, point the user at `docs/components/README.md` for the expected layout, and
+     **stop** without changing anything.
+   - A component folder is only valid if it contains an `integration.md`. Skip (and note) any
+     subfolder missing one.
+
+2. **Direct argument (optional).** If the user passed an argument:
+   - If it exactly matches one of the discovered folder names, treat that as the chosen component
+     and skip to step 4.
+   - If it does not match any folder, note the mismatch, list the available names, and fall through
+     to the interactive selection in step 3.
+
+3. **Select the component (single-select).** Present the candidate components with the
+   `AskUserQuestion` tool (single-select, `multiSelect: false`). Use each folder name as the option
+   label and, if cheaply available, the one-line "Use when…" summary from
+   `docs/components/README.md` as the option description.
+   - If **more than 4** components exist, split across multiple `AskUserQuestion` questions/calls
+     (≤4 options per question).
+   - If **exactly one** component exists, ask a confirmation — *"Add component '<name>'?"* with
+     options **"Add '<name>'"** and **"Cancel"**.
+   - If the user cancels (or interactive questions cannot be asked and no valid argument was given),
+     **stop** without changing anything.
+
+4. **Load the component runbook.** Read `docs/components/<chosen>/integration.md` and, when it
+   references it, `docs/components/<chosen>/README.md`. Locate the **"Implementation catalog
+   (selection list)"** section — its table rows are the selectable implementations. Each row's
+   `Key` is the implementation identifier; capture each Key plus its human description for the
+   prompt.
+   - If `integration.md` is missing or has no implementation catalog, report that the component is
+     not integrable via this command and **stop**.
+
+5. **Select implementation(s) (multi-select).** Present the catalog rows with `AskUserQuestion`,
+   `multiSelect: true`. Use the `Key` as the option label and the row's "Implementation"/"Best for"
+   text as the description.
+   - If the catalog has a **single** row, tell the user it is the only available implementation and
+     ask them to confirm it (do not invent others).
+   - Honor any **grouping / selection rules** the component's `integration.md` states for reading
+     the answer (e.g. Jobs: pick exactly one Group A store, optionally one Group B status store).
+     If more rows exist than fit one prompt, split across multiple `AskUserQuestion` calls.
+
+6. **Empty selection → exit cleanly.** If the user submits with **nothing selected** (or cancels
+   the implementation prompt), do **not** modify the project. Report that no implementation was
+   chosen, name the component, and tell them they can re-run `/aw-spec-addcomponent` any time. Then
+   **stop**.
+
+7. **Add the code (one or more selected).** Execute the chosen component's `integration.md` runbook
+   **in order** for the selected implementation(s):
+   - Resolve the **host/startup project** the runbook targets — the single project that owns
+     `Program.cs` + the ASP.NET Core web SDK (`<App>.Service` for the Vertical Slice foundation,
+     `<App>.API` for the Modular Monolith foundation, or another name in a future template). **Find it
+     by locating `Program.cs`, not by assuming a fixed name.** These foundations have **no** separate
+     `…Application` / `…Infrastructure` project — package references, registration, and
+     `appsettings.json` all target this one project.
+   - Apply the runbook's **"Common steps"** once.
+   - Apply each selected implementation's **block** (package version in
+     `Directory.Packages.props`, `PackageReference` without `Version=`, registration line, config).
+   - Set `options.Provider` per the runbook (when multiple implementations are selected, follow the
+     runbook's rule for choosing the default/active provider — ask a single-select follow-up if it
+     requires one).
+   - Honor the cross-cutting rules in `docs/components/README.md` (R0.1–R0.5, incl. R0.2a): versions
+     only in `Directory.Packages.props`; register in the host/startup project resolved via `Program.cs`
+     (R0.2 — its `Extensions/InfrastructureServiceRegistration.cs`/`AddInfrastructure` if present,
+     else `Program.cs`); inject the abstraction; always set `options.Provider`; never commit secrets.
+   - **Register in both startup paths when they exist (R0.2a).** If the host project splits
+     registration into `AddInfrastructure` (`Extensions/InfrastructureServiceRegistration.cs`) **and**
+     `AddAspireInfrastructure` (`Extensions/AspireInfrastructureExtensions.cs`) — the
+     `if (isAspire) AddAspireInfrastructure(...) else AddInfrastructure(...)` switch in `Program.cs` —
+     add the component's registration to **both** methods, not just `AddInfrastructure`. The block is
+     the same in each, differing only in provider-specific calls (connection strings, `UseSqlite` vs
+     `UseNpgsql`) that must match that method's existing provider. Registering in only one leaves the
+     component missing whenever the app runs in the other mode.
+   - Run any optional usage/feature-slice and schema steps only if the runbook calls for them or the
+     user asks.
+
+8. **Verify and report.** Run the component runbook's **Verification** checklist (at minimum
+   `dotnet build`). Then report:
+   - the component added and which implementation key(s) were wired,
+   - the active provider,
+   - the files changed,
+   - any follow-ups the developer must do out-of-band (secrets, migrations, DDL).
+
+## Done When
+
+- [ ] A component was chosen, or nothing was changed (no components available, or the user
+      cancelled).
+- [ ] If implementations were selected, the component's `integration.md` runbook was executed for
+      each, the project builds, and the changes were reported.
+- [ ] If **no** implementation was selected, the project was left untouched and the user was told so.

package/assets/.kilocode/workflows/aw-spec-agent-context.update.md

@@ -0,0 +1,31 @@
+---
+name: aw-spec-agent-context-update
+description: Refresh the managed AW-Spec section in the coding agent context file
+compatibility: Requires aw-spec project structure with .aw-spec/ directory
+metadata:
+  author: github-aw-spec
+  source: agent-context:commands/aw-spec.agent-context.update.md
+---
+
+# Update Coding Agent Context
+
+Refresh the managed AW-Spec section inside the active coding agent's context/instruction file (e.g. `CLAUDE.md`, `.github/copilot-instructions.md`, `AGENTS.md`).
+
+## Behavior
+
+The script reads the agent-context extension config at
+`.aw-spec/extensions/agent-context/agent-context-config.yml` to discover:
+
+- `context_file` — the path of the coding agent context file to manage.
+- `context_markers.start` / `.end` — the delimiters surrounding the managed section. Defaults to `<!-- AW-SPEC START -->` and `<!-- AW-SPEC END -->` when the field is missing.
+
+It then creates, replaces, or appends the managed block so that the section points at the most recent plan path when one can be discovered (`specs/<feature>/plan.md`).
+
+If `context_file` is empty or the file cannot be located, the command reports nothing to do and exits successfully.
+
+## Execution
+
+- **Bash**: `.aw-spec/extensions/agent-context/scripts/bash/update-agent-context.sh [plan_path]`
+- **PowerShell**: `.aw-spec/extensions/agent-context/scripts/powershell/update-agent-context.ps1 [plan_path]`
+
+When `plan_path` is omitted, the script auto-detects the most recently modified `specs/*/plan.md`.