aw-spec-cli 0.1.0 → 0.1.2

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

@@ -0,0 +1,279 @@
+---
+name: "aw-spec-implement"
+description: "Execute the implementation plan by processing and executing all tasks defined in tasks.md"
+argument-hint: "Optional implementation guidance or task filter"
+compatibility: "Requires aw-spec project structure with .aw-spec/ directory"
+metadata:
+  author: "github-aw-spec"
+  source: "templates/commands/implement.md"
+user-invocable: true
+disable-model-invocation: false
+---
+
+
+## User Input
+
+```text
+$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:
+
+- Read each file below **before** starting the Pre-Execution Checks / Outline. Treat their contents as authoritative engineering standards for this command, second only to `.aw-spec/memory/constitution.md`.
+- If a listed file does not exist, skip it silently and continue — do **not** error and do **not** ask the user to provide it.
+- This is the **domain-agnostic technical** set, so the framework is reusable across domains. Domain-specific rule files (e.g. healthcare FHIR/HL7/PHI) are **not** part of this set — they are offered separately in the **Domain Rule-File Selection** section below (sourced from `comandrulemap.md`). You can also add any extra file directly with an `@` mention.
+
+Standards for `/aw-spec-implement`:
+- docs/architecture/folder-structure.md
+- docs/architecture/vertical-slices.md
+- docs/architecture/cqrs.md
+- docs/architecture/persistence.md
+- docs/architecture/testing.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/security/zero-trust.md
+- docs/governance/coding-standards.md
+- docs/governance/dependency-policy.md
+- docs/governance/api-versioning.md
+- docs/glossary/ai-rules.md
+
+## Domain Rule-File Selection (interactive)
+
+After the technical standards above are loaded, and **before** the Pre-Execution Checks, resolve the active domain and ask the user which **domain** rule files to load for this command:
+
+1. **Resolve the active domain.** Read `.aw-spec/domain.json` and take its `domain` value — the active domain-specs folder name. The candidate domain rule files are the bullet list under the `## /aw-spec-implement` heading in `docs/domainspecs/<domain>/comandrulemap.md`.
+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:
+   - Ask one single-select question with the AskUserQuestion tool — *"Domain is not set or its rule files are missing (state which: no domain set / domain '<domain>' has no comandrulemap.md). Continue without domain rules?"* — with options **"Continue (technical only)"** and **"Exit"**.
+   - **Continue (technical only)** → skip steps 3-5 and proceed with only the auto-loaded technical standards (plus any `@`-mentioned files).
+   - **Exit** → stop the command **immediately** with no side effects: do **not** run the Pre-Execution Checks, hooks, Outline, or any later step, and create/modify nothing. Tell the user to run `/aw-spec-select-domain` (or fix the domain folder) and re-run.
+   - If interactive questions cannot be asked (non-interactive/automated run), default to **Continue (technical only)**.
+   - Exception: if `comandrulemap.md` exists but has **no entries under this command's heading**, this is **not** a gate trigger — load no domain files for this command and continue normally to the Pre-Execution Checks.
+3. **Show a selection box** using the AskUserQuestion tool:
+   - Ask one single-select question — *"Domain rule files for /aw-spec-implement:"* — with options **"Select all (recommended)"**, **"Pick a subset"**, and **"None (technical only)"**.
+   - If the user chooses **"Pick a subset"**, follow up with **multi-select** questions whose options are the individual candidate files so the user can tick the ones they want. AskUserQuestion allows ≤4 options per question and ≤4 questions per call, so split the candidates into groups of ≤4 (by category: architecture overlays, clinical domain, security overlays, governance overlays, glossary) across as many calls as needed.
+   - If interactive questions cannot be asked (non-interactive or automated run), skip the prompt and default to **Select all**.
+4. **Load the selection.** Read every file the user selected (the full list for "Select all"; nothing extra for "None"). If any selected file does not exist on disk, skip it silently and continue — do not error.
+5. **Final context set** = the always-loaded technical standards (section above) **＋** the domain files selected here **＋** any files the user passed via `@` mention in their command. The `@`-mentioned files are always loaded in addition, whether or not they appear in the candidate list, and are never removed by a "None"/subset choice.
+6. Proceed to the Pre-Execution Checks only after the selected files are loaded.
+
+## Pre-Execution Checks
+
+**Check for extension hooks (before implementation)**:
+- Check if `.aw-spec/extensions.yml` exists in the project root.
+- If it exists, read it and look for entries under the `hooks.before_implement` key
+- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
+- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
+- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
+  - If the hook has no `condition` field, or it is null/empty, treat the hook as executable
+  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
+- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `aw-spec.git.commit` → `/aw-spec-git-commit`.
+- For each executable hook, output the following based on its `optional` flag:
+  - **Optional hook** (`optional: true`):
+    ```
+    ## Extension Hooks
+
+    **Optional Pre-Hook**: {extension}
+    Command: `/{command}`
+    Description: {description}
+
+    Prompt: {prompt}
+    To execute: `/{command}`
+    ```
+  - **Mandatory hook** (`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.
+    ```
+- If no hooks are registered or `.aw-spec/extensions.yml` does not exist, skip silently
+
+## Outline
+
+1. Run `.aw-spec/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. **Check checklists status** (if FEATURE_DIR/checklists/ exists):
+   - Scan all checklist files in the checklists/ directory
+   - For each checklist, count:
+     - Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`
+     - Completed items: Lines matching `- [X]` or `- [x]`
+     - Incomplete items: Lines matching `- [ ]`
+   - Create a status table:
+
+     ```text
+     | Checklist | Total | Completed | Incomplete | Status |
+     |-----------|-------|-----------|------------|--------|
+     | ux.md     | 12    | 12        | 0          | ✓ PASS |
+     | test.md   | 8     | 5         | 3          | ✗ FAIL |
+     | security.md | 6   | 6         | 0          | ✓ PASS |
+     ```
+
+   - Calculate overall status:
+     - **PASS**: All checklists have 0 incomplete items
+     - **FAIL**: One or more checklists have incomplete items
+
+   - **If any checklist is incomplete**:
+     - Display the table with incomplete item counts
+     - **STOP** and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
+     - Wait for user response before continuing
+     - If user says "no" or "wait" or "stop", halt execution
+     - If user says "yes" or "proceed" or "continue", proceed to step 3
+
+   - **If all checklists are complete**:
+     - Display the table showing all checklists passed
+     - Automatically proceed to step 3
+
+3. Load and analyze the implementation context:
+   - **REQUIRED**: Read tasks.md for the complete task list and execution plan
+   - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
+   - **IF EXISTS**: Read data-model.md for entities and relationships
+   - **IF EXISTS**: Read contracts/ for API specifications and test requirements
+   - **IF EXISTS**: Read research.md for technical decisions and constraints
+   - **IF EXISTS**: Read .aw-spec/memory/constitution.md for governance constraints
+   - **IF EXISTS**: Read quickstart.md for integration scenarios
+
+4. **Project Setup Verification**:
+   - **REQUIRED**: Create/verify ignore files based on actual project setup:
+
+   **Detection & Creation Logic**:
+   - Check if the following command succeeds to determine if the repository is a git repo (create/verify .gitignore if so):
+
+     ```sh
+     git rev-parse --git-dir 2>/dev/null
+     ```
+
+   - Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore
+   - Check if .eslintrc* exists → create/verify .eslintignore
+   - Check if eslint.config.* exists → ensure the config's `ignores` entries cover required patterns
+   - Check if .prettierrc* exists → create/verify .prettierignore
+   - Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)
+   - Check if terraform files (*.tf) exist → create/verify .terraformignore
+   - Check if .helmignore needed (helm charts present) → create/verify .helmignore
+
+   **If ignore file already exists**: Verify it contains essential patterns, append missing critical patterns only
+   **If ignore file missing**: Create with full pattern set for detected technology
+
+   **Common Patterns by Technology** (from plan.md tech stack):
+   - **Node.js/JavaScript/TypeScript**: `node_modules/`, `dist/`, `build/`, `*.log`, `.env*`
+   - **Python**: `__pycache__/`, `*.pyc`, `.venv/`, `venv/`, `dist/`, `*.egg-info/`
+   - **Java**: `target/`, `*.class`, `*.jar`, `.gradle/`, `build/`
+   - **C#/.NET**: `bin/`, `obj/`, `*.user`, `*.suo`, `packages/`
+   - **Go**: `*.exe`, `*.test`, `vendor/`, `*.out`
+   - **Ruby**: `.bundle/`, `log/`, `tmp/`, `*.gem`, `vendor/bundle/`
+   - **PHP**: `vendor/`, `*.log`, `*.cache`, `*.env`
+   - **Rust**: `target/`, `debug/`, `release/`, `*.rs.bk`, `*.rlib`, `*.prof*`, `.idea/`, `*.log`, `.env*`
+   - **Kotlin**: `build/`, `out/`, `.gradle/`, `.idea/`, `*.class`, `*.jar`, `*.iml`, `*.log`, `.env*`
+   - **C++**: `build/`, `bin/`, `obj/`, `out/`, `*.o`, `*.so`, `*.a`, `*.exe`, `*.dll`, `.idea/`, `*.log`, `.env*`
+   - **C**: `build/`, `bin/`, `obj/`, `out/`, `*.o`, `*.a`, `*.so`, `*.exe`, `*.dll`, `autom4te.cache/`, `config.status`, `config.log`, `.idea/`, `*.log`, `.env*`
+   - **Swift**: `.build/`, `DerivedData/`, `*.swiftpm/`, `Packages/`
+   - **R**: `.Rproj.user/`, `.Rhistory`, `.RData`, `.Ruserdata`, `*.Rproj`, `packrat/`, `renv/`
+   - **Universal**: `.DS_Store`, `Thumbs.db`, `*.tmp`, `*.swp`, `.vscode/`, `.idea/`
+
+   **Tool-Specific Patterns**:
+   - **Docker**: `node_modules/`, `.git/`, `Dockerfile*`, `.dockerignore`, `*.log*`, `.env*`, `coverage/`
+   - **ESLint**: `node_modules/`, `dist/`, `build/`, `coverage/`, `*.min.js`
+   - **Prettier**: `node_modules/`, `dist/`, `build/`, `coverage/`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`
+   - **Terraform**: `.terraform/`, `*.tfstate*`, `*.tfvars`, `.terraform.lock.hcl`
+   - **Kubernetes/k8s**: `*.secret.yaml`, `secrets/`, `.kube/`, `kubeconfig*`, `*.key`, `*.crt`
+
+5. Parse tasks.md structure and extract:
+   - **Task phases**: Setup, Tests, Core, Integration, Polish
+   - **Task dependencies**: Sequential vs parallel execution rules
+   - **Task details**: ID, description, file paths, parallel markers [P]
+   - **Execution flow**: Order and dependency requirements
+
+6. Execute implementation following the task plan:
+   - **Phase-by-phase execution**: Complete each phase before moving to the next
+   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
+   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
+   - **File-based coordination**: Tasks affecting the same files must run sequentially
+   - **Validation checkpoints**: Verify each phase completion before proceeding
+
+7. Implementation execution rules:
+   - **Setup first**: Initialize project structure, dependencies, configuration
+   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
+   - **Core development**: Implement models, services, CLI commands, endpoints
+   - **Integration work**: Database connections, middleware, logging, external services
+   - **Polish and validation**: Unit tests, performance optimization, documentation
+
+8. Progress tracking and error handling:
+   - Report progress after each completed task
+   - Halt execution if any non-parallel task fails
+   - For parallel tasks [P], continue with successful tasks, report failed ones
+   - Provide clear error messages with context for debugging
+   - Suggest next steps if implementation cannot proceed
+   - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
+
+9. Completion validation:
+   - Verify all required tasks are completed
+   - Check that implemented features match the original specification
+   - Validate that tests pass and coverage meets requirements
+   - Confirm the implementation follows the technical plan
+
+Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/aw-spec-tasks` first to regenerate the task list.
+
+## Mandatory Post-Execution Hooks
+
+**You MUST complete this section before reporting completion to the user.**
+
+Check if `.aw-spec/extensions.yml` exists in the project root.
+- If it does not exist, or no hooks are registered under `hooks.after_implement`, skip to the Completion Report.
+- If it exists, read it and look for entries under the `hooks.after_implement` key.
+- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue to the Completion Report.
+- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
+- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
+  - If the hook has no `condition` field, or it is null/empty, treat the hook as executable
+  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
+- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `aw-spec.git.commit` → `/aw-spec-git-commit`.
+- For each executable hook, output the following based on its `optional` flag:
+  - **Mandatory hook** (`optional: false`) — **You MUST emit `EXECUTE_COMMAND:` for each mandatory hook**:
+    ```
+    ## Extension Hooks
+
+    **Automatic Hook**: {extension}
+    Executing: `/{command}`
+    EXECUTE_COMMAND: {command}
+    ```
+  - **Optional hook** (`optional: true`):
+    ```
+    ## Extension Hooks
+
+    **Optional Hook**: {extension}
+    Command: `/{command}`
+    Description: {description}
+
+    Prompt: {prompt}
+    To execute: `/{command}`
+    ```
+
+## Completion Report
+
+Report final status with summary of completed work.
+
+## Done When
+
+- [ ] All tasks in tasks.md completed and marked `[X]`
+- [ ] Implementation validated against specification, plan, and test coverage
+- [ ] Extension hooks dispatched or skipped according to the rules in Mandatory Post-Execution Hooks above
+- [ ] Completion reported to user with summary of completed work

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