dflow-sdd-ddd 0.9.0 → 0.10.0

package/templates/brownfield/scaffolding/CLAUDE-md-snippet.md

@@ -11,10 +11,9 @@
 > - Use this legacy snippet only if you intentionally want the older
 >   Claude-specific two-H2 layout in your project's root `CLAUDE.md`.
 
-The snippet follows the Dflow `templates/CLAUDE.md` H2 segmentation:
-**System Context** (what the system is) and **Development Workflow**
-(how we work). Keep those two H2 sections as the backbone when merging
-into an existing `CLAUDE.md`.
+The snippet uses a two-H2 segmentation: **System Context** (what the
+system is) and **Development Workflow** (how we work). Keep those two H2
+sections as the backbone when merging into an existing `CLAUDE.md`.
 
 ---
 
@@ -159,9 +158,7 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 When merging this snippet into an existing `CLAUDE.md`:
 
 1. **Keep the two H2 sections** (`System Context` / `Development Workflow`) as the
-   backbone. This alignment with the Dflow skill's
-   `templates/CLAUDE.md` is important — AI assistants navigate by
-   these headings.
+   backbone — AI assistants navigate by these headings.
 2. **Under `System Context`**: merge the background paragraph and the
    directory tree. If your project already documents directory
    structure elsewhere, keep the tree pointing to `dflow/specs/` and
@@ -172,7 +169,7 @@ When merging this snippet into an existing `CLAUDE.md`:
    cross-referenced from the scaffolding `Git-principles-*.md`.
 4. **Avoid duplication**: do not re-inline the Dflow skill's decision
    tree, Workflow Transparency rules, or Ceremony Scaling criteria
-   into `CLAUDE.md`. Let `CLAUDE.md` point to the skill, not
+   into `CLAUDE.md`. Let `CLAUDE.md` point to `AI-AGENT-GUIDE.md` and the workflow bundle, not
    duplicate it.
 
 If you are starting from scratch (no existing `CLAUDE.md`), the

package/templates/brownfield/scaffolding/_conventions.md

@@ -8,16 +8,17 @@
 > Audience: engineers writing specs; AI assistants producing spec drafts.
 
 This file captures **project-level** conventions only. Template shapes
-and Ceremony criteria are defined by the Dflow skill; here we just
-record how *this* project fills them in.
+and Ceremony criteria are defined by Dflow itself (the Ceremony tier criteria
+live in `AI-AGENT-GUIDE.md` § Ceremony Scaling; template shapes live in the
+workflow bundle); here we just record how *this* project fills them in.
 
 ---
 
 ## Where Specs Live
 
 All spec documents live under `dflow/specs/`. The feature directory pattern
-and file names follow Dflow (see the Dflow skill § "Project Structure
-Reference" for the full tree):
+and file names follow Dflow (see `AI-AGENT-GUIDE.md` § Source of Truth
+for the full tree):
 
 ```
 dflow/specs/features/active/{SPEC-ID}-{slug}/
@@ -98,8 +99,8 @@ Project-specific guidance when filling these templates:
 
 ## Ceremony Scaling (Project Application)
 
-The Dflow skill defines three tiers — **T1 Heavy / T2 Light / T3
-Trivial**. See the Dflow skill § "Ceremony Scaling" for the full
+Dflow defines three tiers — **T1 Heavy / T2 Light / T3
+Trivial**. See `AI-AGENT-GUIDE.md` § Ceremony Scaling for the full
 criteria table. We do not re-define the tier criteria here; this
 section records how *this* project applies them in borderline
 situations.
@@ -111,8 +112,8 @@ situations.
 | {e.g. UI refresh across multiple entrypoints} | T1 (project convention) | We treat multi-entrypoint UI/API refresh as T1 for this project even though Dflow default would be T2, because these changes often leak into business logic embedded in delivery/entrypoint code (presentation/UI layer, controllers, handlers, jobs, message consumers, data pipelines, or stored procedures) |
 
 If the team disagrees on tier classification for a specific change,
-run through the T3 four-criteria checklist (in the Dflow skill) and
-record the decision here the first time it arises.
+run through the T3 four-criteria checklist (in `AI-AGENT-GUIDE.md` §
+Ceremony Scaling) and record the decision here the first time it arises.
 
 ---
 
@@ -136,5 +137,5 @@ and `/dflow:new-phase` flows; the project-level convention is simply
 - [System overview](_overview.md)
 - [Git principles](Git-principles-{gitflow|trunk}.md)
 - [Glossary](../domain/glossary.md)
-- Dflow skill SKILL.md — canonical source for Ceremony Scaling, flow
+- `AI-AGENT-GUIDE.md` — canonical source for Ceremony Scaling, flow
   selection, and template shapes.

package/templates/brownfield/templates/_index.md

@@ -81,7 +81,7 @@ Template note (for AI):
 > T3 行：inline 完整描述一句話 + 標籤（如 `[cosmetic]` / `[text]` /
 >        `[format]`）；T3 不產獨立 spec 檔
 >
-> Tier 判準見 SKILL.md § Ceremony Scaling 三層表。
+> Tier 判準見 AI-AGENT-GUIDE.md § Ceremony Scaling 三層表。
 
 | Date | Tier | Description | Commit |
 |---|---|---|---|

package/templates/brownfield/templates/lightweight-spec.md

@@ -11,7 +11,7 @@ branch: bugfix/BUG-{NUMBER}-{short-description}
 Template note (for AI):
   This is the **lightweight-spec** template — it corresponds to T2 Light
   ceremony in the three-tier Ceremony Scaling (T1 Heavy / T2 Light /
-  T3 Trivial; see SKILL.md § Ceremony Scaling for the tier criteria).
+  T3 Trivial; see AI-AGENT-GUIDE.md § Ceremony Scaling for the tier criteria).
 
   - T1 Heavy → use templates/phase-spec.md instead
   - T2 Light → THIS template; produces an independent file

package/templates/brownfield/templates/phase-spec.md

@@ -21,7 +21,7 @@ Template note (for AI):
 
   Each section below carries an HTML comment indicating its fill-in activity (Activity 1-4).
   These activity markers let /dflow:status and the completion checklist track progress.
-  Activities correspond to SKILL.md § Guiding Questions by Activity:
+  Activities correspond to AI-AGENT-GUIDE.md § Guiding Questions by Activity:
     Activity 1: Understanding (What & Why)
     Activity 2: Domain Analysis (Where does it live?)
     Activity 3: Spec Writing (Behavior + Rules + Edge Cases)

package/templates/common/skill/SKILL.md

@@ -5,12 +5,15 @@ description: >
   /dflow:* commands (/dflow:new-feature, /dflow:modify-existing, /dflow:bug-fix,
   /dflow:new-phase, /dflow:finish-feature, /dflow:pr-review, /dflow:verify,
   /dflow:report-dflow-feedback, /dflow:status, /dflow:next, /dflow:cancel).
-  SECONDARY (auto-trigger safety net) — engage ONLY for: adding or changing
-  product/domain behavior, new requirements, a feature or bug-fix workflow, or
-  spec-impacting architecture/domain-model decisions. Do NOT engage for pure
-  refactors, infrastructure chores, formatting, or general code questions.
-  When engaged by natural language, DO NOT auto-enter a workflow: judge the
-  intent, suggest the matching /dflow: command, and wait for confirmation.
+  SECONDARY — engage ONLY for adding or changing product/user-facing/domain
+  behavior, a new requirement, a feature or bug-fix workflow, or spec-impacting
+  architecture/domain-model decisions. Includes indirect phrasings, e.g. "I want
+  to build/add ...", "let's add the ability to ...", "we need to support ...",
+  "can you implement ...", "users should be able to ...", "the app should also
+  ...". Do NOT engage for pure refactors, renames, infra/build chores,
+  formatting, dep bumps, or general code questions ("how does X work", "explain
+  this"). When engaged by natural language, DO NOT auto-enter a workflow: judge
+  the intent, suggest the matching /dflow: command, and wait for confirmation.
 ---
 
 <!-- dflow-generated: skill-adapter -->

package/templates/greenfield/references/drift-verification.md

@@ -180,10 +180,7 @@ Recommended trigger points (not enforced — developer's judgment):
 This command operates entirely within `dflow/specs/domain/{context}/` files
 (`rules.md`, `behavior.md`, and the `events.md` bonus check). It does
 **not** read from `dflow/specs/features/active/{SPEC-ID}-{slug}/` directories
-— the feature directory layout is not part of verify's input. The only effect of feature directory layout on this
-command is ensuring `last-updated` dates in `behavior.md` are bumped at
-`/dflow:finish-feature` time (so verify's mechanical drift guard stays
-useful).
+— the feature directory layout is not part of verify's input.
 
 ## Interaction with Other Commands
 

package/templates/greenfield/references/finish-feature-flow.md

@@ -35,7 +35,7 @@ state, archives the feature directory, and emits a Git-strategy-neutral
 - Step 5 → Step 6 (Integration Summary emitted → optional follow-up reverse-link)
 
 All other step transitions are **step-internal**: announce "Step N complete,
-entering Step N+1" and proceed without waiting. See SKILL.md § Workflow
+entering Step N+1" and proceed without waiting. See AI-AGENT-GUIDE.md § Workflow
 Transparency for the full transparency protocol and confirmation signals.
 
 ## Step 1: Validate Phase Specs and `_index.md`
@@ -127,6 +127,8 @@ For each row in Current BR Snapshot where Status = `active`:
   `rules.md` (REMOVED rule)
 - For any RENAMED BR-ID → rename the BR-ID in `rules.md` and update
   `glossary.md` if the term itself changed
+- For every BR-ID added, modified, or renamed above, set its `Last updated`
+  date in `rules.md`'s Rule Index to today
 
 For `behavior.md`:
 
@@ -136,7 +138,6 @@ For `behavior.md`:
   transitions and Domain Events as appropriate
 - For REMOVED BR-IDs, delete the corresponding scenario section from
   `behavior.md`
-- Update the BR-ID anchor's `last-updated` date in `behavior.md` to today
 
 For `events.md`:
 - Add any new Domain Events introduced by phase-specs in this feature

package/templates/greenfield/references/git-integration.md

@@ -182,7 +182,6 @@ diff. That breaks:
 - `git blame` on lines that crossed the rename boundary
 - PR diff quality (reviewers see two unrelated big-blob changes
   instead of one rename + small content diff)
-- `/dflow:verify` and other tools that walk feature history
 
 This is a known weakness of OpenSpec's directory-rename pattern; Dflow
 deliberately avoids it by mandating `git mv`.

package/templates/greenfield/references/init-project-flow.md

@@ -54,8 +54,8 @@ Report findings plainly:
 >  - `src/`: contains `MyApp.Domain`, `MyApp.Application`,
 >    `MyApp.Infrastructure`, `MyApp.WebAPI` → Clean Architecture layout
 >    detected
->  - `CLAUDE.md`: present → will not overwrite; I'll offer a snippet
->    to merge into it"
+>  - `CLAUDE.md`: present → I'll append a marked Dflow block (shown in
+>    the preview); a merge snippet only if there's a marker conflict"
 
 Or:
 
@@ -173,9 +173,10 @@ Wait for answers.
 >
 > If you select any agent, Dflow will create
 > `dflow/specs/shared/AI-AGENT-GUIDE.md` as the canonical guide. Root-level
-> tool files stay thin and point back to that guide. Existing tool files are
-> never overwritten; Dflow writes merge snippets under `dflow/specs/shared/`
-> instead."
+> tool files stay thin and point back to that guide. Existing user content is
+> never overwritten; Dflow appends a marked Dflow block (shown in the preview)
+> and refreshes it in place on re-run. Merge snippets under
+> `dflow/specs/shared/` are used only if Dflow markers conflict."
 
 **→ Transition (step-internal)**: Step 2 complete. Announce
 > "Step 2 complete (project information captured). Entering Step 3:
@@ -246,16 +247,17 @@ vendored workflow bundle). Compute the destination path:
 | `scaffolding/Git-principles-trunk.md` | `dflow/specs/shared/Git-principles-trunk.md` |
 | `scaffolding/AI-AGENT-GUIDE.md` | `dflow/specs/shared/AI-AGENT-GUIDE.md` when at least one AI agent is selected |
 | generated tool shim | `AGENTS.md`, `CLAUDE.md`, or `.github/copilot-instructions.md` when selected and missing |
-| generated merge snippet | `dflow/specs/shared/*-snippet.md` when the selected tool file already exists |
+| marked Dflow block | appended to a selected existing tool file unless it already points to `AI-AGENT-GUIDE.md`; refreshed in place on re-run |
+| fallback merge snippet | `dflow/specs/shared/*-snippet.md` only when the selected tool file has conflicting or malformed Dflow markers |
 
 ### 3.3 Present the preview
 
-Present the complete file list as two tables, separating create vs
+Present the complete file list as two tables, separating create / update vs
 skip, and wait for developer confirmation:
 
 > "Based on Step 1 inventory + Step 2 answers, here is what I'll do:
 >
-> **Will create ({N} files):**
+> **Will create / update ({N} files):**
 >
 > | Path | Source |
 > |---|---|
@@ -270,7 +272,7 @@ skip, and wait for developer confirmation:
 > | `dflow/specs/shared/_overview.md` | optional (you picked it) |
 > | `dflow/specs/shared/Git-principles-trunk.md` | mandatory (selected Git policy) |
 > | `dflow/specs/shared/AI-AGENT-GUIDE.md` | selected AI agent guide |
-> | `CLAUDE.md` | selected tool shim because repo has no CLAUDE.md |
+> | `CLAUDE.md` | marked Dflow block appended to existing CLAUDE.md (shown in preview) |
 >
 > **Will skip ({M} files — already present):**
 >
@@ -346,11 +348,24 @@ guide.
 For each selected tool-specific file (`AGENTS.md`, `CLAUDE.md`,
 `.github/copilot-instructions.md`):
 
+(checked in this order — the first matching rule wins):
+
 - if the target file does not exist, create a small shim at the target
   path that points to `dflow/specs/shared/AI-AGENT-GUIDE.md`
-- if the target file already exists, do not overwrite it; write a merge
-  snippet under `dflow/specs/shared/` and report that the developer
-  should merge it manually
+- if the target file contains conflicting or malformed Dflow markers, do not
+  edit it; write a fallback merge snippet under `dflow/specs/shared/` and
+  report that the developer should merge it manually
+- if the target file already contains a single well-formed Dflow marked block,
+  replace that block in place (idempotent refresh) and keep the rest of the
+  file unchanged
+- if the target file is an existing whole-file Dflow-generated shim, refresh it
+  in place
+- if the target file already points to the guide through the developer's own
+  pointer (and has no Dflow marked block), leave it untouched
+- otherwise preserve the existing content and append a marked Dflow block at
+  the end of the file, keeping the file's dominant line ending; show that block
+  in the preview, and refresh that same block on re-run. If the developer later
+  deletes the block, a later `init` / `configure-agents` run appends it again
 
 ### 4.4 Directory-only entries
 
@@ -380,7 +395,7 @@ Summarise what actually happened and point at the next command.
 ```
 Init complete. Summary:
 
-  Created ({N} files):
+  Created / Updated ({N} files):
     ✓ dflow/specs/features/active/.gitkeep
     ✓ dflow/specs/features/completed/.gitkeep
     ✓ dflow/specs/features/backlog/.gitkeep
@@ -391,7 +406,7 @@ Init complete. Summary:
     ✓ dflow/specs/architecture/decisions/README.md
     ✓ dflow/specs/shared/_overview.md
     ✓ dflow/specs/shared/Git-principles-trunk.md
-    ✓ CLAUDE.md (seeded from scaffolding snippet)
+    ✓ CLAUDE.md (marked Dflow block appended)
 
   Skipped ({M} files already present):
     - (none this run)
@@ -445,10 +460,9 @@ Remind the developer to review files that have `{placeholder}` tokens
 still in them:
 
 > "A few files still have `{placeholder}` tokens that need your input:
->  - `dflow/specs/shared/_overview.md`: `{業務領域}`, `{團隊}`,
->    `{使用者規模}`
+>  - `dflow/specs/shared/_overview.md`: the Business Domain and Technical
+>    Architecture fields (e.g. primary domain, stakeholders, user scale, stack)
 >  - `dflow/specs/domain/context-map.md`: context list and relationships
->  - `CLAUDE.md`: `{業務領域}`
 >
 >  These are fine to leave for now; fill them in during your next
 >  review pass."

package/templates/greenfield/references/modify-existing-flow.md

@@ -2,14 +2,14 @@
 
 Step-by-step guide for changing or fixing existing functionality.
 
-Triggered by `/dflow:modify-existing` or `/dflow:bug-fix` (or natural language implying a modification task — see SKILL.md § Workflow Transparency for the auto-trigger safety net).
+Triggered by `/dflow:modify-existing` or `/dflow:bug-fix` (or natural language implying a modification task — see AI-AGENT-GUIDE.md § Workflow Transparency for the auto-trigger safety net).
 
 **Step Gates** in this flow (stop-and-confirm before proceeding):
 - Step 2 → Step 3 (baseline captured → assess DDD impact)
 - Step 3 → Step 4 (DDD impact decision → implement)
 - Step 4 → Step 5 (implementation done → update documentation)
 
-All other step transitions are **step-internal**: announce "Step N complete, entering Step N+1" and proceed without waiting. See SKILL.md § Workflow Transparency for the full transparency protocol and confirmation signals.
+All other step transitions are **step-internal**: announce "Step N complete, entering Step N+1" and proceed without waiting. See AI-AGENT-GUIDE.md § Workflow Transparency for the full transparency protocol and confirmation signals.
 
 **Note on step count**: Greenfield edition has 5 steps (Brownfield has
 6) because Clean Architecture's layered structure already separates
@@ -29,7 +29,7 @@ This step has three parallel concerns:
 
 **Part A — Determine the Ceremony Tier (T1 / T2 / T3)**
 
-Dflow runs three ceremony tiers (full table in SKILL.md § Ceremony Scaling).
+Dflow runs three ceremony tiers (full table in AI-AGENT-GUIDE.md § Ceremony Scaling).
 For a modification, AI judges which tier fits before deciding what to
 produce:
 
@@ -147,7 +147,7 @@ add a row:
 | {新 SPEC-ID} | {新 slug} | {today} | in-progress |
 ```
 
-This update is **part of the same change set** (the developer commits
+This update is **part of the same change set** (offer to commit
 both at once; commit message should mention "Add follow-up reference to
 `{新 SPEC-ID}`"). The reverse link is a derived index — the new
 feature's `follow-up-of` field is the authoritative source.
@@ -158,8 +158,6 @@ phase's content).
 
 ## Step 2: Check Documentation
 
-## Step 2: Check Documentation
-
 - Spec in `dflow/specs/features/completed/`?
 - Domain model in `dflow/specs/domain/{context}/models.md`?
 - Business rules in `rules.md`?
@@ -305,7 +303,7 @@ Items marked *(post-5.3)* are re-verified after the documentation merge in 5.3 l
 - [ ] ORM / persistence mapping is kept outside Domain entities (no persistence attributes/annotations on Domain entities)
 - [ ] `Implementation Tasks` section (`phase-spec.md` or `lightweight-spec.md`): all tasks checked, or unchecked items explicitly labelled as follow-up
 - [ ] *(post-5.3)* `dflow/specs/domain/{context}/behavior.md` has a section anchor for every `BR-*` in ADDED / MODIFIED entries; REMOVED entries' anchors have been deleted (mechanical input for `/dflow:verify`)
-- [ ] *(post-5.3)* `dflow/specs/domain/{context}/behavior.md` `last-updated` is later than this spec's `created` date (mechanical drift guard)
+- [ ] *(post-5.3)* every ADDED / MODIFIED / RENAMED BR's `Last updated` in `dflow/specs/domain/{context}/rules.md` is later than this spec's `created` date (mechanical drift guard)
 
 If any item fails, report the gap and pause — don't proceed to 5.2.
 

package/templates/greenfield/references/new-feature-flow.md

@@ -2,7 +2,7 @@
 
 Step-by-step guide for adding a new feature with full DDD and Clean Architecture.
 
-Triggered by `/dflow:new-feature` (or natural language implying a new-feature task — see SKILL.md § Workflow Transparency for the auto-trigger safety net behavior).
+Triggered by `/dflow:new-feature` (or natural language implying a new-feature task — see AI-AGENT-GUIDE.md § Workflow Transparency for the auto-trigger safety net behavior).
 
 **Step Gates** in this flow (stop-and-confirm before proceeding):
 - Step 3 → Step 3.5 (Aggregate / VO / Events identified → confirm slug + directory + branch names)
@@ -10,9 +10,9 @@ Triggered by `/dflow:new-feature` (or natural language implying a new-feature ta
 - Step 6 → Step 7 (branch ready → start implementation)
 - Step 7 → Step 8 (implementation done → completion)
 
-All other step transitions are **step-internal**: announce "Step N complete, entering Step N+1" and proceed without waiting. See SKILL.md § Workflow Transparency for the full transparency protocol and confirmation signals.
+All other step transitions are **step-internal**: announce "Step N complete, entering Step N+1" and proceed without waiting. See AI-AGENT-GUIDE.md § Workflow Transparency for the full transparency protocol and confirmation signals.
 
-**Ceremony**: this flow always defaults to **T1 Heavy** — the first phase of a brand-new feature is by definition a full SDD cycle. Tier judgement (T1 / T2 / T3) only applies to `/dflow:modify-existing` (see `references/modify-existing-flow.md` and SKILL.md § Ceremony Scaling).
+**Ceremony**: this flow always defaults to **T1 Heavy** — the first phase of a brand-new feature is by definition a full SDD cycle. Tier judgement (T1 / T2 / T3) only applies to `/dflow:modify-existing` (see `references/modify-existing-flow.md` and AI-AGENT-GUIDE.md § Ceremony Scaling).
 
 ## Step 1: Intake — Understand the Request
 
@@ -42,7 +42,7 @@ Check `dflow/specs/domain/context-map.md`:
 [Context] bounded context. Does that match your understanding?"
 ```
 
-If new context needed → use context-definition template.
+If a new context is needed → create `dflow/specs/domain/{new-context}/context.md` using the context-definition template (`templates/context-definition.md`).
 
 If it crosses contexts:
 ```
@@ -201,7 +201,7 @@ Scenario: Submit expense report
 Announce to developer:
 > "Spec is drafted — behavior scenarios, Aggregate state transitions, Domain Events, and CQRS split are captured. Ready to plan the layer-by-layer implementation (Domain → Application → Infrastructure → Presentation)? `/dflow:next` or reply 'OK' to continue, or tell me if the spec needs another iteration first."
 
-Wait for confirmation (`/dflow:next`, verbal OK, or implicit — see SKILL.md § Confirmation Signals) before entering Step 5.
+Wait for confirmation (`/dflow:next`, verbal OK, or implicit — see AI-AGENT-GUIDE.md § Confirmation Signals) before entering Step 5.
 
 ## Step 5: Plan the Implementation (Layer by Layer)
 
@@ -352,7 +352,7 @@ AI reports `✓` / `✗` for every item before touching docs. Items marked *(pos
 - [ ] Aggregate invariants still hold after the change (all state changes go through methods, no public setters)
 - [ ] ORM / persistence mapping is kept outside Domain entities (no persistence attributes/annotations on Domain entities)
 - [ ] *(post-8.3)* `dflow/specs/domain/{context}/behavior.md` contains a section anchor for every `BR-*` introduced by this spec (mechanical input for `/dflow:verify`)
-- [ ] *(post-8.3)* `dflow/specs/domain/{context}/behavior.md` `last-updated` is later than this spec's `created` date (mechanical drift guard)
+- [ ] *(post-8.3)* `dflow/specs/domain/{context}/rules.md` `last-updated` is later than this spec's `created` date (mechanical drift guard)
 
 If any item fails, report the gap and pause — don't proceed to 8.2.
 
@@ -384,12 +384,14 @@ Ask these one-by-one; do not dump all six at once.
 
 ### 8.4 Archival
 
-For a single-phase feature, this is the closeout point. For a multi-phase
-feature, the developer typically reaches this point at the end of the
-final phase — at which time `/dflow:finish-feature` is the recommended
-trigger (it bundles steps 8.1 / 8.2 verification, BC sync, and archival
-into one explicit ceremony). Either path is acceptable; pick the one
-that matches the developer's habit.
+For a single-phase feature, this is the closeout point. If the feature has
+later phases still ahead, this phase is complete but the feature is not —
+don't archive yet; run `/dflow:new-phase` to start the next phase, not
+`/dflow:finish-feature` yet. For a multi-phase feature, the developer
+typically reaches this point at the end of the final phase — at which time
+`/dflow:finish-feature` is the recommended trigger (it bundles steps 8.1 /
+8.2 verification, BC sync, and archival into one explicit ceremony). Either
+path is acceptable; pick the one that matches the developer's habit.
 
 - [ ] `_index.md` `status` field changed to `completed`
 - [ ] All `phase-spec-*.md` files in the feature directory have `status:

package/templates/greenfield/references/new-phase-flow.md

@@ -20,7 +20,7 @@ adds a new phase to an in-progress feature only.
 - Step 6 → Step 7 (implementation done → complete the phase)
 
 All other step transitions are **step-internal**: announce "Step N complete,
-entering Step N+1" and proceed without waiting. See SKILL.md § Workflow
+entering Step N+1" and proceed without waiting. See AI-AGENT-GUIDE.md § Workflow
 Transparency for the full transparency protocol and confirmation signals.
 
 ## Step 1: Read Active Feature Context