codeforge-dev 1.10.0 → 1.12.0

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/spec-build/SKILL.md

@@ -0,0 +1,353 @@
+---
+name: spec-build
+description: >-
+  This skill should be used when the user asks to "implement the spec",
+  "build from spec", "start building the feature", "spec-build",
+  "implement this feature from the spec", "build what the spec describes",
+  or needs to orchestrate full implementation of an approved specification
+  through a phased workflow of planning, building, reviewing, and closing.
+version: 0.1.0
+---
+
+# Spec-Driven Implementation
+
+## Mental Model
+
+An approved spec is a contract — it defines exactly what to build, what to skip, and how to verify success. This skill takes a `user-approved` spec and orchestrates the full implementation lifecycle: plan the work, build it, review everything against the spec, and close the loop. No separate `/spec-update` run is needed afterward — Phase 5 performs full as-built closure.
+
+The workflow is five phases executed in strict order. Each phase has a clear gate before the next can begin.
+
+```
+/spec-new  ->  /spec-refine  ->  /spec-build
+                                    |
+                                    +-> Phase 1: Discovery & Gate Check
+                                    +-> Phase 2: Implementation Planning
+                                    +-> Phase 3: Implementation
+                                    +-> Phase 4: Comprehensive Review
+                                    +-> Phase 5: Spec Closure
+```
+
+> **Note:** Phase 4's review functionality is also available standalone via `/spec-review` for features implemented outside of `/spec-build`.
+
+---
+
+## Acceptance Criteria Markers
+
+During implementation, acceptance criteria use three states:
+
+| Marker | Meaning |
+|--------|---------|
+| `[ ]` | Not started |
+| `[~]` | Implemented, not yet verified — code written, tests not confirmed |
+| `[x]` | Verified — tests pass, behavior confirmed |
+
+Phase 3 flips `[ ]` to `[~]` as criteria are addressed in code. Phase 4 upgrades `[~]` to `[x]` after verification. This convention is the only spec edit during active implementation.
+
+---
+
+## CRITICAL: Planning Before Implementation
+
+Phase 2 generates an implementation plan. This plan MUST be created and approved before any code changes begin in Phase 3. Use `EnterPlanMode` to create the plan. The plan MUST include Phases 3, 4, and 5 instructions verbatim — these phases run after plan approval, and the instructions must be preserved so they execute correctly even across context boundaries.
+
+Do NOT skip planning. Do NOT begin writing code during Phase 2. The plan is a contract with the user — get approval first.
+
+---
+
+## Complexity Assessment
+
+Before planning, assess the spec's complexity to determine whether team spawning would benefit the implementation.
+
+**Complexity indicators** — if two or more apply, the spec is complex:
+- 8+ functional requirements (FR-*)
+- Cross-layer work (backend + frontend + tests spanning different frameworks)
+- 3+ independent workstreams that could run in parallel
+- Multiple services or modules affected
+
+### When Complexity is High: Recommend Team Spawning
+
+Decompose work into parallel workstreams and recommend team composition using the project's existing custom agents. These agents carry frontloaded skills, safety hooks, and tailored instructions — always prefer them over generalist agents.
+
+**Recommended compositions by spec type:**
+
+| Spec Type | Teammates |
+|-----------|-----------|
+| Full-stack feature | researcher + test-writer + doc-writer |
+| Backend-heavy | researcher + test-writer |
+| Security-sensitive | security-auditor + test-writer |
+| Refactoring work | refactorer + test-writer |
+| Multi-service | researcher per service + test-writer |
+
+**Available specialist agents:** `architect`, `bash-exec`, `claude-guide`, `debug-logs`, `dependency-analyst`, `doc-writer`, `explorer`, `generalist`, `git-archaeologist`, `migrator`, `perf-profiler`, `refactorer`, `researcher`, `security-auditor`, `spec-writer`, `statusline-config`, `test-writer`
+
+Use `generalist` only when no specialist matches the workstream. Hard limit: 3-5 active teammates maximum.
+
+**When complexity is low** (< 8 requirements, single layer, sequential work): skip team spawning, implement directly in the main thread. Still follow all 5 phases.
+
+The user can override the team recommendation in either direction.
+
+---
+
+## Phase 1: Discovery & Gate Check
+
+### Step 1: Find the Spec
+
+```
+Glob: .specs/**/*.md
+```
+
+Match by `$ARGUMENTS` — the user provides a feature name or path. If ambiguous, list matching specs and ask which one to implement.
+
+### Step 2: Read the Full Spec
+
+Read every line. Extract structured data:
+
+- **All `[user-approved]` requirements** — every FR-* and NFR-* with their EARS-format text
+- **All acceptance criteria** — every `[ ]` checkbox item
+- **Key Files** — existing files to read for implementation context
+- **Dependencies** — prerequisite features, systems, or libraries
+- **Out of Scope** — explicit exclusions that define boundaries to respect
+
+### Step 3: Gate Check
+
+**Hard gate**: Verify the spec has `**Approval:** user-approved`.
+
+- If `user-approved` -> proceed to Step 4
+- If `draft` or missing -> **STOP**. Print: "This spec is not approved for implementation. Run `/spec-refine <feature>` first to validate assumptions and get user approval." Do not continue.
+
+This gate is non-negotiable. Draft specs contain unvalidated assumptions — building against them risks wasted work.
+
+### Step 4: Build Context
+
+Read every file listed in the spec's `## Key Files` section. These are the files the spec author identified as most relevant to implementation. Understanding them is prerequisite to planning.
+
+After reading, note:
+- Which key files exist vs. which are new (to be created)
+- Patterns, conventions, and interfaces in existing files
+- Any dependencies or constraints discovered in the code
+
+### Step 5: Assess Complexity
+
+Apply the complexity indicators from the assessment section above. Note the result for Phase 2 — it determines whether to recommend team spawning.
+
+---
+
+## Phase 2: Implementation Planning
+
+**Do NOT write any code in this phase.** This phase produces a plan only.
+
+Use `EnterPlanMode` to enter plan mode. Create a structured implementation plan covering:
+
+### Plan Structure
+
+1. **Spec Reference** — path to the spec file, domain, feature name
+2. **Complexity Assessment** — indicators found, team recommendation (if applicable)
+3. **Requirement-to-File Mapping** — each FR-*/NFR-* mapped to specific file changes
+4. **Implementation Steps** — ordered by dependency, grouped by related requirements:
+   - For each step: files to create/modify, requirements addressed, acceptance criteria to verify
+   - Mark which steps depend on others completing first
+5. **Out-of-Scope Boundaries** — items from the spec's Out of Scope section, noted as "do not touch"
+6. **Verification Checkpoints** — acceptance criteria listed as checkpoints after each logical group of steps
+
+### Preserving Phase Instructions
+
+The plan MUST include the following phases verbatim so they survive context across the implementation session. Include them as a "Post-Implementation Phases" section in the plan:
+
+**Phase 3 instructions**: Execute steps, flip `[ ]` to `[~]` after addressing each criterion in code.
+
+**Phase 4 instructions**: Run comprehensive review using the Spec Implementation Review Checklist at `skills/spec-build/references/review-checklist.md`. Walk every requirement, verify every criterion, audit code quality, check spec consistency. Produce a summary report.
+
+**Phase 5 instructions**: Update spec status, add Implementation Notes, update Key Files, add Discrepancies, set Last Updated date.
+
+### Team Plan (if applicable)
+
+If complexity assessment recommends team spawning, the plan should additionally include:
+- Workstream decomposition with clear boundaries
+- Teammate assignments by specialist type
+- Task dependencies between workstreams
+- Integration points where workstreams converge
+
+Present the plan via `ExitPlanMode` and wait for explicit user approval before proceeding.
+
+---
+
+## Phase 3: Implementation
+
+Execute the approved plan step by step. This is where code gets written.
+
+### Execution Rules
+
+1. **Follow the plan order** — implement steps in the sequence approved by the user
+2. **Live spec updates** — after completing work on an acceptance criterion, immediately edit the spec file:
+   - Flip `[ ]` to `[~]` for criteria addressed in code
+   - This is the ONLY spec edit during Phase 3 — no structural changes to the spec
+3. **Track requirement coverage** — mentally track which FR-*/NFR-* requirements have been addressed as you work through the steps
+4. **Note deviations** — if the implementation must deviate from the plan (unexpected constraint, better approach discovered, missing dependency), note the deviation for Phase 4. Do not silently diverge.
+5. **Respect boundaries** — do not implement anything listed in the spec's Out of Scope section
+
+### If Using a Team
+
+If team spawning was approved in Phase 2:
+
+1. Create the team using `TeamCreate`
+2. Create tasks in the team task list mapped to spec requirements
+3. Spawn teammates using the recommended specialist agent types
+4. Assign tasks by domain match
+5. Coordinate integration points as workstreams converge
+6. Collect results and ensure all `[ ]` criteria are flipped to `[~]`
+
+### Progress Tracking
+
+The spec file itself is the progress tracker. At any point during Phase 3:
+- `[ ]` criteria = not yet addressed
+- `[~]` criteria = addressed in code, awaiting verification
+- Count of `[~]` vs total criteria shows implementation progress
+
+---
+
+## Phase 4: Comprehensive Review
+
+The most critical phase. Audit everything built against the spec. Use the Spec Implementation Review Checklist at `skills/spec-build/references/review-checklist.md` as the authoritative guide.
+
+### 4A: Requirement Coverage Audit
+
+Walk through every FR-* and NFR-* requirement from the spec:
+
+1. For each requirement: identify the specific files and functions that address it
+2. Verify the implementation matches the EARS-format requirement text
+3. Flag requirements that were missed entirely
+4. Flag requirements only partially addressed
+5. Flag code written outside the spec's scope (scope creep)
+
+### 4B: Acceptance Criteria Verification
+
+For each `[~]` criterion in the spec:
+
+1. Find or write the corresponding test
+2. Run the test and confirm it passes
+3. If the test passes -> upgrade `[~]` to `[x]` in the spec
+4. If the test fails -> note the failure, do not upgrade
+5. For criteria without tests: write the test, run it, then decide
+
+Report any criteria that cannot be verified and explain why.
+
+### 4C: Code Quality Review
+
+Check the implementation against code quality standards:
+
+- Error handling at appropriate boundaries
+- No hardcoded values that should be configurable
+- Function sizes within limits (short, single-purpose)
+- Nesting depth within limits
+- Test coverage for new code paths
+- No regressions in existing tests
+
+### 4D: Spec Consistency Check
+
+Compare implemented behavior against each EARS requirement:
+
+- Does the code actually do what each requirement says?
+- Are there behavioral differences between spec intent and actual implementation?
+- Are Key Files in the spec still accurate? Any new files missing from the list?
+- Are there files created during implementation that should be added?
+
+### 4E: Summary Report
+
+Present a structured summary to the user:
+
+```
+## Implementation Review Summary
+
+**Requirements:** N/M addressed (list any gaps)
+**Acceptance Criteria:** N verified [x], M in progress [~], K not started [ ]
+**Deviations from Plan:** (list any, or "None")
+**Discrepancies Found:** (spec vs reality gaps, or "None")
+**Code Quality Issues:** (list any, or "None")
+
+**Recommendation:** Proceed to Phase 5 / Fix issues first (with specific list)
+```
+
+If issues are found, address them before moving to Phase 5. If issues require user input, present them and wait for direction.
+
+---
+
+## Phase 5: Spec Closure
+
+The final phase. Update the spec to reflect what was actually built. This replaces the need for a separate `/spec-update` run.
+
+### Step 1: Update Status
+
+Set `**Status:**` to:
+- `implemented` — if all acceptance criteria are `[x]`
+- `partial` — if any criteria remain `[ ]` or `[~]`
+
+### Step 2: Update Metadata
+
+- Set `**Last Updated:**` to today's date (YYYY-MM-DD)
+- Preserve `**Approval:** user-approved` — never downgrade
+
+### Step 3: Add Implementation Notes
+
+In the `## Implementation Notes` section, document:
+
+- **Deviations from the original spec** — what changed and why
+- **Key design decisions** — choices made during implementation not in the original spec
+- **Trade-offs accepted** — what was sacrificed and the reasoning
+- **Surprising findings** — edge cases, performance characteristics, limitations discovered
+
+Reference file paths, not code. Keep notes concise.
+
+### Step 4: Update Key Files
+
+In `## Key Files`:
+- Add files created during implementation
+- Remove files that no longer exist
+- Update paths that changed
+- Verify every path listed actually exists
+
+### Step 5: Add Discrepancies
+
+In `## Discrepancies`, document any gaps between spec intent and actual build:
+- Requirements that were met differently than specified
+- Behavioral differences from the original EARS requirements
+- Scope adjustments that happened during implementation
+
+If no discrepancies exist, leave the section empty or note "None."
+
+### Step 6: Final Message
+
+Print: "Implementation complete. Spec updated to `[status]`. Run `/spec-check` to verify spec health."
+
+---
+
+## Persistence Policy
+
+Complete all five phases. Stop only when:
+- Gate check fails in Phase 1 (spec not approved) — hard stop
+- User explicitly requests stop
+- A genuine blocker requires user input that cannot be resolved
+
+If interrupted mid-phase, resume from the last completed step. Phase 3 progress is tracked via acceptance criteria markers in the spec — `[~]` markers show exactly where implementation left off.
+
+Do not skip phases. Do not combine phases. Each phase exists because it surfaces different types of issues. Phase 4 in particular catches problems that are invisible during Phase 3.
+
+---
+
+## Ambiguity Policy
+
+- If `$ARGUMENTS` matches multiple specs, list them and ask the user which to implement.
+- If a spec has no acceptance criteria, warn the user and suggest adding criteria before implementation. Offer to proceed anyway if the user confirms.
+- If Key Files reference paths that don't exist, note this in Phase 1 and proceed — they may be files to create.
+- If the spec has both `[assumed]` and `[user-approved]` requirements, the gate check still fails — all requirements must be `[user-approved]` before implementation begins.
+- If Phase 4 reveals significant gaps, do not silently proceed to Phase 5. Present the gaps and get user direction on whether to fix them first or document them as discrepancies.
+- If the spec is already `implemented`, ask: is this a re-implementation, an update, or an error?
+
+---
+
+## Anti-Patterns
+
+- **Skipping the plan**: Jumping from Phase 1 to Phase 3 without a plan leads to unstructured work and missed requirements. Always plan first.
+- **Optimistic verification**: Marking `[~]` as `[x]` without running the actual test. Every `[x]` must be backed by a passing test or confirmed behavior.
+- **Scope creep during implementation**: Building features not in the spec because they "seem useful." Respect Out of Scope boundaries.
+- **Deferring Phase 4**: "I'll review later" means "I won't review." Phase 4 runs immediately after Phase 3.
+- **Silent deviations**: Changing the implementation approach without noting it. Every deviation gets documented in Phase 4/5.
+- **Skipping Phase 5**: The spec-reminder hook will catch this, but it's better to close the loop immediately. Phase 5 is not optional.

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/spec-build/references/review-checklist.md

@@ -0,0 +1,175 @@
+# Spec Implementation Review Checklist
+
+Comprehensive checklist for spec implementation reviews. Used by `/spec-build` Phase 4 and `/spec-review`. Walk through every section methodically. Do not skip sections — each catches different categories of issues.
+
+---
+
+## 4A: Requirement Coverage Audit
+
+For each FR-* requirement in the spec:
+
+- [ ] Identify the file(s) and function(s) that implement this requirement
+- [ ] Verify the implementation matches the EARS-format requirement text
+- [ ] Confirm the requirement is fully addressed (not partially)
+- [ ] Note if the requirement was met through a different approach than planned
+
+For each NFR-* requirement in the spec:
+
+- [ ] Identify how the non-functional requirement is enforced (e.g., timeout config, index, validation)
+- [ ] Verify measurable NFRs have been tested or measured (response time, throughput, size limits)
+- [ ] Confirm the NFR is met under expected conditions, not just ideal conditions
+
+Cross-checks:
+
+- [ ] Every FR-* has corresponding code — no requirements were skipped
+- [ ] Every NFR-* has corresponding enforcement — no hand-waving
+- [ ] No code was written that doesn't map to a requirement (scope creep check)
+- [ ] Out of Scope items from the spec were NOT implemented
+
+---
+
+## 4B: Acceptance Criteria Verification
+
+For each criterion currently marked `[~]` (implemented, not yet verified):
+
+- [ ] Locate the corresponding test (unit, integration, or manual verification)
+- [ ] If no test exists: write one
+- [ ] Run the test
+- [ ] If test passes: upgrade `[~]` to `[x]` in the spec
+- [ ] If test fails: note the failure, keep as `[~]`, document the issue
+
+Summary checks:
+
+- [ ] Count total criteria vs. verified `[x]` — report the ratio
+- [ ] Any criteria still `[ ]` (not started)? Flag as missed
+- [ ] Any criteria that cannot be tested? Document why and note as discrepancy
+- [ ] Do the tests actually verify the criterion, or just exercise the code path?
+
+---
+
+## 4C: Code Quality Review
+
+### Error Handling
+
+- [ ] Errors are caught at appropriate boundaries (not swallowed, not over-caught)
+- [ ] Error messages are informative (include context, not just "error occurred")
+- [ ] External call failures (I/O, network, subprocess) have explicit handling
+- [ ] No bare except/catch-all that hides real errors
+
+### Code Structure
+
+- [ ] Functions are short and single-purpose
+- [ ] Nesting depth is within limits (2-3 for Python, 3-4 for other languages)
+- [ ] No duplicated logic that should be extracted
+- [ ] Names are descriptive (functions, variables, parameters)
+
+### Hardcoded Values
+
+- [ ] No magic numbers without explanation
+- [ ] Configuration values that may change are externalized (not inline)
+- [ ] File paths, URLs, and credentials are not hardcoded
+
+### Test Quality
+
+- [ ] New code has corresponding tests
+- [ ] Tests verify behavior, not implementation details
+- [ ] Tests cover happy path, error cases, and key edge cases
+- [ ] No over-mocking that makes tests trivially pass
+- [ ] Existing tests still pass (no regressions introduced)
+
+### Dependencies
+
+- [ ] New imports/dependencies are necessary (no unused imports)
+- [ ] No circular dependencies introduced
+- [ ] Third-party dependencies are justified (not added for trivial functionality)
+
+---
+
+## 4D: Spec Consistency Check
+
+### Requirement-to-Implementation Fidelity
+
+- [ ] Re-read each EARS requirement and compare against the actual implementation
+- [ ] For "When [event], the system shall [action]" — does the code handle that event and perform that action?
+- [ ] For "If [unwanted condition], the system shall [action]" — is the unwanted condition detected and handled?
+- [ ] For ubiquitous requirements ("The system shall...") — is the behavior always active?
+
+### Key Files Accuracy
+
+- [ ] Every file in the spec's Key Files section still exists at that path
+- [ ] New files created during implementation are listed in Key Files
+- [ ] Deleted or moved files have been removed/updated in Key Files
+- [ ] File descriptions in Key Files are still accurate
+
+### Schema and API Consistency
+
+- [ ] If the spec has a Schema/Data Model section, verify referenced files are current
+- [ ] If the spec has API Endpoints, verify routes match the implementation
+- [ ] Any new endpoints or schema changes are reflected in the spec
+
+### Behavioral Alignment
+
+- [ ] Edge cases discovered during implementation are documented
+- [ ] Performance characteristics match NFR expectations
+- [ ] Integration points work as the spec describes
+- [ ] Default values and fallback behaviors match spec intent
+
+---
+
+## 4E: Summary Report Template
+
+After completing sections 4A through 4D, compile findings into this format:
+
+```
+## Implementation Review Summary
+
+**Spec:** [feature name] ([spec file path])
+**Date:** YYYY-MM-DD
+
+### Requirement Coverage
+- Functional: N/M addressed
+- Non-Functional: N/M addressed
+- Gaps: [list or "None"]
+
+### Acceptance Criteria
+- [x] Verified: N
+- [~] Implemented, pending verification: N
+- [ ] Not started: N
+- Failures: [list or "None"]
+
+### Code Quality
+- Issues found: [list or "None"]
+- Regressions: [list or "None"]
+
+### Spec Consistency
+- Key Files updates needed: [list or "None"]
+- Discrepancies: [list or "None"]
+
+### Deviations from Plan
+[list or "None"]
+
+### Recommendation
+[ ] Proceed to Phase 5 — all clear
+[ ] Fix issues first: [specific list]
+[ ] Requires user input: [specific questions]
+```
+
+---
+
+## When to Fail the Review
+
+The review should recommend "fix issues first" when:
+
+- Any FR-* requirement has no corresponding implementation
+- Any acceptance criterion test fails
+- Existing tests regress (new code broke something)
+- Code was written outside the spec's scope without user approval
+- Critical error handling is missing (crashes on expected error conditions)
+
+The review should recommend "proceed to Phase 5" when:
+
+- All requirements have corresponding implementations
+- All acceptance criteria are `[x]` (or `[~]` with documented reason)
+- No test regressions
+- Code quality is acceptable (no critical issues)
+- Discrepancies are documented, not hidden

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/spec-check/SKILL.md

@@ -25,23 +25,22 @@ Glob: .specs/**/*.md
 If `.specs/` does not exist, report: "No specification directory found. Use `/spec-new` to create your first spec."
 
 Exclude non-spec files:
-- `ROADMAP.md`
+- `MILESTONES.md`
 - `BACKLOG.md`
 - `LESSONS_LEARNED.md`
 - Files in `archive/`
-- `_overview.md` files (report them separately as parent specs)
 
 ### Step 2: Read Each Spec
 
 For each spec file, extract:
 - **Feature name** from the `# Feature: [Name]` header
-- **Version** from the `**Version:**` field
+- **Domain** from the `**Domain:**` field
 - **Status** from the `**Status:**` field
 - **Last Updated** from the `**Last Updated:**` field
 - **Approval** from the `**Approval:**` field (default `draft` if missing)
 - **Line count** (wc -l)
 - **Sections present** — check for each required section header
-- **Acceptance criteria** — count total, count checked `[x]`
+- **Acceptance criteria** — count total, count checked `[x]`, count in-progress `[~]`
 - **Requirements** — count total, count `[assumed]`, count `[user-approved]`
 - **Discrepancies** — check if section has content
 
@@ -62,6 +61,7 @@ For each spec, check these conditions:
 | **Stale paths** | Key Files references paths that don't exist | Low |
 | **Draft + implemented** | Status is `implemented` but Approval is `draft` — approval gate was bypassed | High |
 | **Inconsistent approval** | Approval is `user-approved` but spec has `[assumed]` requirements | High |
+| **In-progress criteria** | Has acceptance criteria marked `[~]` (implemented, not yet verified) | Info |
 
 ### Step 4: Report
 
@@ -70,24 +70,25 @@ Output a summary table:
 ```
 ## Spec Health Report
 
-| Feature | Version | Status | Approval | Updated | Lines | Issues |
-|---------|---------|--------|----------|---------|-------|--------|
-| Session History | v0.2.0 | implemented | user-approved | 2026-02-08 | 74 | None |
-| Auth Flow | v0.3.0 | planned | draft | 2026-01-15 | 45 | Unapproved, Stale (26 days) |
-| Settings Page | v0.2.0 | partial | draft | 2026-02-05 | 210 | Unapproved, Long spec |
+| Feature | Domain | Status | Approval | Updated | Lines | Issues |
+|---------|--------|--------|----------|---------|-------|--------|
+| Session History | sessions | implemented | user-approved | 2026-02-08 | 74 | None |
+| Auth Flow | auth | planned | draft | 2026-01-15 | 45 | Unapproved, Stale (26 days) |
+| Settings Page | ui | partial | draft | 2026-02-05 | 210 | Unapproved, Long spec |
 
 ## Issues Found
 
 ### High Priority
-- **Auth Flow** (`.specs/v0.3.0/auth-flow.md`): Status is `planned` but last updated 26 days ago. Either implementation is stalled or the spec needs an as-built update.
+- **Auth Flow** (`.specs/auth/auth-flow.md`): Status is `planned` but last updated 26 days ago. Either implementation is stalled or the spec needs an as-built update.
 
 ### Medium Priority
-- **Settings Page** (`.specs/v0.2.0/settings-page.md`): 210 lines — consider splitting into sub-specs for easier consumption.
+- **Settings Page** (`.specs/ui/settings-page.md`): 210 lines — consider splitting into separate specs in the domain folder.
 
 ### Suggested Actions
 1. Run `/spec-refine auth-flow` to validate assumptions and get user approval
-2. Run `/spec-update auth-flow` to update the auth flow spec
-3. Split settings-page.md into sub-specs
+2. Run `/spec-review auth-flow` to verify implementation against the spec
+3. Run `/spec-update auth-flow` to update the auth flow spec
+4. Split settings-page.md into sub-specs
 
 ### Approval Summary
 - **User-approved:** 1 spec
@@ -95,4 +96,4 @@ Output a summary table:
 - **Assumed requirements across all specs:** 8
 ```
 
-If no issues are found, report: "All specs healthy. N specs across M versions. All user-approved."
+If no issues are found, report: "All specs healthy. N specs across M domains. All user-approved."

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/spec-init/SKILL.md

@@ -5,14 +5,14 @@ description: >-
   "set up specs", "bootstrap specs", "start using specs", "create spec
   directory", "init specs for this project", or needs to set up the
   .specs/ directory structure for a project that doesn't have one yet.
-version: 0.1.0
+version: 0.2.0
 ---
 
 # Initialize Specification Directory
 
 ## Mental Model
 
-Before any spec can be created, the project needs a `.specs/` directory with its supporting files: a ROADMAP (what each version delivers) and a BACKLOG (deferred items). This skill bootstraps that structure so `/spec-new` has a home.
+Before any spec can be created, the project needs a `.specs/` directory with its supporting files: a MILESTONES tracker (what each milestone delivers) and a BACKLOG (deferred items). This skill bootstraps that structure so `/spec-new` has a home.
 
 ---
 
@@ -25,7 +25,7 @@ Glob: .specs/**/*.md
 ```
 
 **If `.specs/` already exists:**
-- Report current state: how many specs, versions, whether ROADMAP.md and BACKLOG.md exist
+- Report current state: how many specs, domains, whether MILESTONES.md and BACKLOG.md exist
 - Suggest `/spec-check` to audit health instead
 - Do NOT recreate or overwrite anything
 - Stop here
@@ -36,9 +36,9 @@ Glob: .specs/**/*.md
 
 Create the `.specs/` directory at the project root.
 
-### Step 3: Create ROADMAP.md
+### Step 3: Create MILESTONES.md
 
-Write `.specs/ROADMAP.md` using the template from `references/roadmap-template.md`.
+Write `.specs/MILESTONES.md` using the template from `references/milestones-template.md`.
 
 ### Step 4: Create BACKLOG.md
 
@@ -63,15 +63,16 @@ Summarize what was created:
 
 Created:
 - `.specs/` directory
-- `.specs/ROADMAP.md` — version tracking table
+- `.specs/MILESTONES.md` — milestone tracker
 - `.specs/BACKLOG.md` — deferred items list
 
 Next steps:
 - Add features to `BACKLOG.md` with priority grades (P0–P3)
-- Pull features into a version in `ROADMAP.md` when ready to scope
-- Use `/spec-new <feature-name> <version>` to create a spec
+- Pull features into a milestone in `MILESTONES.md` when ready to scope
+- Use `/spec-new <feature-name>` to create a spec (domain is inferred)
 - Use `/spec-refine <feature-name>` to validate before implementation
-- After implementing, use `/spec-update` to close the loop
+- After implementing, use `/spec-review <feature-name>` to verify against the spec
+- Then use `/spec-update` to close the loop
 - Use `/spec-check` to audit spec health at any time
 ```
 
@@ -87,7 +88,7 @@ Next steps:
 ## Ambiguity Policy
 
 - If the user runs this in a workspace root with multiple projects, ask which project to initialize.
-- If `.specs/` exists but is missing ROADMAP.md or BACKLOG.md, offer to create only the missing files.
+- If `.specs/` exists but is missing MILESTONES.md or BACKLOG.md, offer to create only the missing files.
 
 ---
 
@@ -95,5 +96,5 @@ Next steps:
 
 | File | Contents |
 |------|----------|
-| `references/roadmap-template.md` | Starter ROADMAP with version table format |
+| `references/milestones-template.md` | Starter MILESTONES with milestone table format |
 | `references/backlog-template.md` | Starter BACKLOG with item format |

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/spec-init/references/backlog-template.md

@@ -1,6 +1,6 @@
 # Backlog
 
-Priority-graded feature and infrastructure backlog. Items are pulled into versions when ready to scope and spec. See `ROADMAP.md` for the versioning workflow.
+Priority-graded feature and infrastructure backlog. Items are pulled into milestones when ready to scope and spec. See `MILESTONES.md` for the milestone workflow.
 
 ## P0 — High Priority