dflow-sdd-ddd 0.3.0 → 0.5.0

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

@@ -29,7 +29,7 @@ keeps every project's `CLAUDE.md` scannable for AI in the same shape.
 ## Snippet to merge into `CLAUDE.md`
 
 ```markdown
-# Project: {系統名稱} — ASP.NET Core + DDD
+# Project: {系統名稱} — Clean Architecture + DDD
 
 **重要：所有開發工作都必須遵循本文件定義的流程。**
 
@@ -45,8 +45,8 @@ keeps every project's `CLAUDE.md` scannable for AI in the same shape.
 - **Users / Customers**: {使用者 / 客戶描述}
 - **Team**: {團隊組成；e.g. "全端工程團隊，3-5 人；DDD 經驗中等"}
 - **Dflow Adoption Context**: {新專案 greenfield / 既有系統導入 / 遷移等}
-- **Tech Stack**: ASP.NET Core {版本}；EF Core / MediatR / {其他};
-  .NET {版本}
+- **Tech Stack**: {Framework} {Framework version}；{ORM / persistence} {ORM version} / {Mediator} / {其他};
+  {Language}
 
 ### Architecture (Clean Architecture)
 
@@ -60,7 +60,7 @@ Presentation → Application → Domain ← Infrastructure
 |---|---|---|
 | Domain | 業務規則、Aggregate、Value Object、Domain Event | 依賴外部套件、存取資料庫、處理 HTTP |
 | Application | 編排領域操作、CQRS、驗證、DTO | 包含業務邏輯、直接存取資料庫 |
-| Infrastructure | EF Core、外部 API、檔案存取 | 包含業務邏輯 |
+| Infrastructure | {ORM / persistence}、外部 API、檔案存取 | 包含業務邏輯 |
 | Presentation | HTTP 端點、Request/Response | 包含業務邏輯、直接操作 Domain 物件 |
 
 ### Project Structure
@@ -109,6 +109,7 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 - `/dflow:finish-feature` — Feature 收尾 + 整合摘要
 - `/dflow:pr-review` — PR 審查檢查點
 - `/dflow:report-dflow-feedback` — 草擬給 Dflow upstream 的已清理回饋，不自動送出
+- `/dflow:status` / `/dflow:next` / `/dflow:cancel` — 狀態管理
 
 ### Core Principles (Project Reaffirmed)
 
@@ -120,7 +121,7 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 
 ### Domain Layer Rules (Hard Invariants)
 
-- ❌ 不可有任何 NuGet 套件依賴（純 .NET 類型）
+- ❌ 不可有任何外部套件依賴（語言純粹 types）
 - ❌ 不可有 ORM 屬性（`[Table]`、`[Column]` 等）
 - ❌ 不可有序列化屬性（`[JsonProperty]` 等）
 - ❌ 不可有 `DbContext`、`IConfiguration`、`HttpClient`
@@ -133,7 +134,7 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 
 {此段由專案自行填入。例如：}
 
-- **本專案使用 MediatR 做 Command / Query dispatch**，Application 層
+- **本專案使用 {Mediator} 做 Command / Query dispatch（若適用）**，Application 層
   Command / Query Handler 命名為 `{Name}CommandHandler` /
   `{Name}QueryHandler`
 - **整合測試使用 {Testcontainers / WebApplicationFactory / 其他}**；

package/templates/greenfield/scaffolding/Git-principles-gitflow.md

@@ -174,7 +174,7 @@ Before making key Git operations:
       `context-map.md` reflect the feature's net changes
 - [ ] `dflow/specs/domain/glossary.md` updated with any new terms
 - [ ] `dflow/specs/architecture/tech-debt.md` updated with any debt discovered
-- [ ] Domain project has zero external NuGet dependencies
+- [ ] Domain project has zero external package dependencies
 - [ ] No ORM / serialization attributes on Domain entities
 - [ ] Domain unit tests pass (invariants + value object equality)
 
@@ -334,7 +334,7 @@ exists, e.g. `.github/workflows/ci.yml` or `azure-pipelines.yml`.}
 
 ### Suggested CI gates for Clean Architecture
 
-- Verify Domain project has zero (or allow-listed) NuGet deps
+- Verify Domain project has zero (or allow-listed) external package deps
 - Run Domain unit tests + Application tests on every PR
 - Run Integration tests on `develop` and `release/*` branches
 - Verify EF migrations build cleanly

package/templates/greenfield/scaffolding/Git-principles-trunk.md

@@ -249,7 +249,7 @@ Before making key Git operations:
       `context-map.md` reflect the feature's net changes
 - [ ] `dflow/specs/domain/glossary.md` updated with any new terms
 - [ ] `dflow/specs/architecture/tech-debt.md` updated with any debt discovered
-- [ ] Domain project has zero external NuGet dependencies
+- [ ] Domain project has zero external package dependencies
 - [ ] No ORM / serialization attributes on Domain entities
 - [ ] Domain unit tests pass (invariants + value object equality)
 - [ ] CI is green (all required checks passing)
@@ -359,7 +359,7 @@ exists, e.g. `.github/workflows/ci.yml` or `azure-pipelines.yml`.}
 
 ### Suggested CI gates for Clean Architecture
 
-- Verify Domain project has zero (or allow-listed) NuGet deps
+- Verify Domain project has zero (or allow-listed) external package deps
 - Run Domain unit tests + Application tests on every PR
 - Run Integration tests on `main` and pre-deploy
 - Verify EF migrations build cleanly

package/templates/greenfield/scaffolding/_overview.md

@@ -30,19 +30,18 @@ delivers. Keep it non-technical enough that a new hire can skim it in
 
 ## Technical Architecture
 
-This project is an ASP.NET Core application built with **Clean
-Architecture** and **Domain-Driven Design (DDD)**. Dependencies flow
-inward only — the Domain layer is the core and depends on nothing.
+This project follows **Clean Architecture** and **Domain-Driven Design
+(DDD)**. Dependencies flow inward only — the Domain layer is the core
+and depends on nothing.
 
 ### Stack
 
 | Item | Choice |
 |------|--------|
-| Runtime | .NET {version, e.g. 8} |
-| Language | C# {version, e.g. 12} |
-| Web framework | ASP.NET Core (Web API / Minimal API — {which}) |
-| ORM | Entity Framework Core {version} |
-| Mediator | {e.g. MediatR, internal CQRS dispatcher, or none} |
+| Language | {Language} |
+| Framework | {Framework} {Framework version} |
+| ORM / persistence | {ORM / persistence} {ORM version} |
+| Mediator | {Mediator} (or none) |
 | Validation | {e.g. FluentValidation} |
 | Database | {e.g. PostgreSQL 16, SQL Server 2022} |
 | Auth | {e.g. JWT bearer, OIDC via Azure AD, cookie auth} |
@@ -57,13 +56,32 @@ Presentation  →  Application  →  Domain  ←  Infrastructure
 
 | Layer | Responsibilities | Must NOT |
 |-------|------------------|----------|
-| Domain | Aggregates, Entities, Value Objects, Domain Events, Domain Services, repository interfaces | Depend on any NuGet package outside allowed list; know about EF Core, HTTP, DI containers |
+| Domain | Aggregates, Entities, Value Objects, Domain Events, Domain Services, repository interfaces | Depend on package-manager libraries outside the project's allow-list; know about ORM/persistence frameworks, HTTP, DI containers |
 | Application | Commands / Queries (CQRS), Validators, DTOs, Event Handlers, orchestration | Contain business logic; access database directly |
-| Infrastructure | EF Core `DbContext` + configurations, repository implementations, external API clients | Contain business logic |
+| Infrastructure | ORM / persistence configuration, repository implementations, external API clients | Contain business logic |
 | Presentation | HTTP endpoints, Request / Response mapping, auth + middleware | Contain business logic; expose Domain objects directly |
 
 ### Project Layout
 
+> **Note**: The project layout below uses .NET/C# conventions —
+> project-level namespaces like `{Project}.Domain` and a separate `.csproj`
+> per layer. This is shown as a concrete example so you can see "what a
+> real Clean Architecture layout looks like".
+>
+> If this project's stack is **not** .NET, this layout does **not**
+> literally apply — translate to the conventions of your stack:
+>
+> - Java/Spring: `com.example.domain` / `com.example.application` packages, often a multi-module Maven/Gradle build
+> - Node/TypeScript: `src/domain/` / `src/application/` folders, monorepo workspaces optional
+> - Python: `domain/` / `application/` packages
+> - Go: `internal/domain/` / `internal/application/`
+> - PHP/Laravel: `app/Domain/` / `app/Application/`
+>
+> For full per-stack examples, see `docs/examples-by-stack.md`. If the
+> convention for your stack is unclear, consult authoritative sources
+> for the stack (e.g., its official project structure guide) or ask the
+> developer before placing code.
+
 ```
 src/
 ├── {Project}.Domain/
@@ -147,7 +165,7 @@ format / MADR / other}.
 Initial ADRs that typically exist:
 
 - **ADR-0001** — Choice of ORM / persistence approach
-- **ADR-0002** — CQRS + MediatR vs direct handlers
+- **ADR-0002** — CQRS + mediator/dispatcher vs direct handlers
 - **ADR-0003** — Auth strategy
 
 ---

package/templates/greenfield/templates/CLAUDE.md

@@ -1,4 +1,4 @@
-# Project: {系統名稱} — ASP.NET Core + DDD
+# Project: {系統名稱} — Clean Architecture + DDD
 
 **重要：所有開發工作都必須遵循本文件定義的流程。**
 
@@ -10,7 +10,7 @@
 
 ### Background
 
-這是一個使用 Clean Architecture 和 Domain-Driven Design 的 ASP.NET Core 系統。
+這是一個遵循 Clean Architecture 與 Domain-Driven Design 的新建專案；具體 stack 詳見 `dflow/specs/shared/_overview.md`。
 採用 SDD 流程，所有開發工作必須遵循本文件定義的流程。
 
 ### Architecture (Clean Architecture)
@@ -27,7 +27,7 @@ Presentation → Application → Domain ← Infrastructure
 |---|---|---|
 | Domain | 業務規則、Aggregate、Value Object、Domain Event | 依賴外部套件、存取資料庫、處理 HTTP |
 | Application | 編排領域操作、CQRS、驗證、DTO | 包含業務邏輯、直接存取資料庫 |
-| Infrastructure | EF Core、外部 API、檔案存取 | 包含業務邏輯 |
+| Infrastructure | {ORM / persistence}、外部 API、檔案存取 | 包含業務邏輯 |
 | Presentation | HTTP 端點、Request/Response | 包含業務邏輯、直接操作 Domain 物件 |
 
 ### Project Structure
@@ -35,7 +35,7 @@ Presentation → Application → Domain ← Infrastructure
 ```
 dflow/specs/
 ├── shared/                   # 專案級治理文件（由 dflow init 寫入）
-│   ├── _overview.md          # 系統現況與遷移策略
+│   ├── _overview.md          # 系統概覽與架構方向
 │   └── _conventions.md       # 規格撰寫慣例
 ├── domain/
 │   ├── glossary.md
@@ -154,7 +154,7 @@ bugfix/{BUG-ID}-{short-description}      # Bug 修復（SDD 必須）
 
 ### Domain Layer Rules
 
-- ❌ 不可有任何 NuGet 套件依賴（純 .NET 類型）
+- ❌ 不可有任何外部套件依賴（語言純粹 types）
 - ❌ 不可有 ORM 屬性（[Table], [Column] 等）
 - ❌ 不可有序列化屬性（[JsonProperty] 等）
 - ❌ 不可有 DbContext、IConfiguration、HttpClient

package/docs/using-with-gemini-cli.en.md

@@ -1,200 +0,0 @@
-# Using Dflow with Gemini CLI
-
-> [繁體中文](using-with-gemini-cli.md) | **English**
-
-A walk-through of what Dflow looks like when your AI coding agent is
-[Gemini CLI](https://github.com/google/gemini-cli). About 10 minutes to read.
-
-This guide focuses on the Gemini CLI experience specifically. For the
-tool-neutral evaluation flow, see
-[`docs/evaluating-dflow.en.md`](evaluating-dflow.en.md). For the full Get Started
-and feature list, see [`README.md`](../README.en.md).
-
-## Who This Guide Is For
-
-You are using or evaluating Dflow with Gemini CLI as your AI coding agent.
-This guide covers what Gemini CLI sees after `init`, how Dflow's slash
-commands are recognized, and the Gemini-CLI-specific patterns worth knowing.
-
-You do not need to read this before running `init`. It is most useful after
-you have run `init` once and want to understand what Gemini CLI is actually
-loading.
-
-## Prerequisites
-
-- Gemini CLI installed (see [github.com/google/gemini-cli](https://github.com/google/gemini-cli)).
-- Node.js / npm available (Dflow ships through npm). Install globally with
-  `npm install -g dflow-sdd-ddd`, or use `npx dflow-sdd-ddd` for the no-install path.
-- A project directory you are comfortable initializing in. A branch or a
-  disposable sample project is recommended for first contact; see the
-  [evaluator guide playbook](evaluating-dflow.en.md#a-30-minute-evaluation-playbook).
-
-You do not need a separate Dflow service or API key. The workflows are
-text-based and use Gemini CLI's existing capabilities.
-
-## What Gemini CLI Sees After `init`
-
-Running `dflow init` (or `npx dflow-sdd-ddd init` on the no-install path) and
-selecting Gemini CLI as a target tool creates a thin shim at the project root:
-
-```markdown
-# GEMINI.md - Dflow Project Instructions
-
-This project uses Dflow for spec-first AI-assisted development.
-
-Before planning or editing code, read and follow:
-
-- `dflow/specs/shared/AI-AGENT-GUIDE.md`
-
-Keep tool-specific instruction files small. The Dflow guide above is the
-single source of truth for project workflow rules, slash-command behavior,
-spec locations, and SDD/DDD constraints.
-
-If your tool supports Markdown imports, the canonical guide is imported below:
-
-@dflow/specs/shared/AI-AGENT-GUIDE.md
-```
-
-Two things happen when Gemini CLI starts in this project:
-
-1. Gemini CLI automatically loads `GEMINI.md` from the project root into
-   its context. This is Gemini CLI's standard project instructions
-   mechanism.
-2. The trailing `@dflow/specs/shared/AI-AGENT-GUIDE.md` line uses Gemini
-   CLI's Markdown import syntax to inline the canonical Dflow guide. So
-   Gemini CLI effectively reads both files as one set of instructions.
-
-The canonical guide (`dflow/specs/shared/AI-AGENT-GUIDE.md`) is where the
-real workflow rules live: project context (track, tech stack, prose
-language), the `/dflow:*` workflow table, source-of-truth file paths, and
-core SDD/DDD rules. The `GEMINI.md` shim stays small precisely so the
-canonical guide can evolve without Gemini-CLI-specific edits.
-
-If a `GEMINI.md` already existed in the project, `init` does not overwrite
-it. Instead it writes a merge snippet under `dflow/specs/shared/` that you
-can paste into your existing `GEMINI.md` manually.
-
-## Using Dflow Workflow Commands in Gemini CLI
-
-Dflow's `/dflow:*` slash commands are workflow names recognized by the AI
-through the workflow table in `AI-AGENT-GUIDE.md`, not Gemini CLI's
-built-in tool commands. You type them as plain chat:
-
-```text
-/dflow:new-feature
-```
-
-Gemini CLI treats this as input. Because it has the workflow table loaded
-via `GEMINI.md` import, it recognizes the prefix and enters the matching
-workflow. A typical conversation looks like:
-
-```text
-User: /dflow:new-feature
-
-Gemini CLI: Entering new-feature workflow. Please describe the user-facing
-capability or business behavior you want to add.
-
-User: Allow expense submitters to attach a receipt image when filing an
-expense.
-
-Gemini CLI: I'll start by drafting a feature spec under
-dflow/specs/features/active/. Before I do, I need a short answer on:
-[clarifying questions about scope, owner, priority]
-```
-
-The workflow then walks you through spec drafting, behavior examples,
-implementation planning, and finish-feature drift checks. The exact
-sequence depends on which workflow you entered (`/dflow:new-feature`,
-`/dflow:modify-existing`, `/dflow:bug-fix`, etc.). All workflow definitions
-live under the Dflow skill source; Gemini CLI follows them by reading the
-skill files when needed.
-
-Available workflow entry points:
-
-| Command | Use when |
-|---|---|
-| `/dflow:new-feature` | A new user-visible capability or business behavior is requested. |
-| `/dflow:modify-existing` | Existing behavior needs to change. |
-| `/dflow:bug-fix` | A defect can be described with expected vs actual behavior. |
-| `/dflow:new-phase` | An active feature needs another implementation slice. |
-| `/dflow:finish-feature` | Implementation is complete and needs drift closure. |
-| `/dflow:verify` | Specs, domain docs, implementation, and tests need consistency checks. |
-| `/dflow:pr-review` | A change is ready for SDD/DDD review. |
-| `/dflow:report-dflow-feedback` | You found a Dflow issue or improvement and want a sanitized upstream feedback draft. |
-
-If you forget a command name, ask Gemini CLI "what dflow workflows are
-available?" — the answer comes from the workflow table it already has
-loaded.
-
-## Differences vs Other AI Tools
-
-The canonical guide (`dflow/specs/shared/AI-AGENT-GUIDE.md`) is identical
-across tools. Only the root-level shim differs:
-
-| Tool | Generated shim | Loads canonical guide via |
-|---|---|---|
-| Gemini CLI | `GEMINI.md` | `@dflow/specs/shared/AI-AGENT-GUIDE.md` Markdown import |
-| Claude Code | `CLAUDE.md` | `@dflow/specs/shared/AI-AGENT-GUIDE.md` Markdown import |
-| Codex / Copilot coding agent | `AGENTS.md` | Reads file content directly when starting |
-| GitHub Copilot | `.github/copilot-instructions.md` | Reads file content directly |
-
-You can run `dflow configure-agents` later to add another tool's shim
-without re-running `init`. Multiple tools can be active in the same project
-and stay synchronized via the canonical guide.
-
-## Common Patterns and Gotchas
-
-**Keep `GEMINI.md` thin.** If you find yourself adding workflow rules,
-spec locations, or SDD constraints to `GEMINI.md`, those belong in
-`dflow/specs/shared/AI-AGENT-GUIDE.md` instead. The shim stays small so
-that other tools' shims don't drift away from it.
-
-**`/dflow:*` is not a Gemini CLI tool.** The slash commands are plain text
-patterns the AI recognizes from the workflow table. You can use them
-immediately after `init` without any Gemini CLI configuration.
-
-**Permission gates and Dflow workflow gates are separate.** Gemini CLI may
-ask for confirmation before executing a shell command or modifying a file.
-Dflow's workflows have their own approval gates (e.g., "I drafted the spec —
-do you want me to proceed to implementation?"). Both can fire on the same
-action; this is expected and not a sign of misconfiguration.
-
-**The `@` import is not recursive.** `GEMINI.md` imports
-`AI-AGENT-GUIDE.md`, but if `AI-AGENT-GUIDE.md` references other files
-(e.g., feature specs), those are not auto-loaded — Gemini CLI reads them
-on demand when entering the relevant workflow. This keeps context usage
-proportional to active work.
-
-**A pre-existing `GEMINI.md` is preserved.** `init` will not overwrite your
-existing project instructions. Look under `dflow/specs/shared/` for the
-merge snippet `init` wrote and paste the relevant sections into your
-existing `GEMINI.md` manually.
-
-**Cross-machine projects work.** `dflow/specs/` is plain Markdown checked
-into your repo. Anyone cloning the repo and using Gemini CLI in it will
-see the same Dflow setup automatically through the committed `GEMINI.md`
-shim and the canonical guide.
-
-## Where to Go Next
-
-If you have not run `init` yet:
-
-- Follow the [evaluator guide playbook](evaluating-dflow.en.md#a-30-minute-evaluation-playbook)
-  to try it on a disposable sample project.
-
-If you have run `init` and want to see end-to-end workflow examples:
-
-- Read [`tutorial/01-greenfield/`](../tutorial/01-greenfield/walkthrough-00-setup.md) or
-  [`tutorial/02-brownfield/`](../tutorial/02-brownfield/walkthrough-00-setup.md). The
-  tutorial walk-throughs show conversation flows and the resulting
-  `dflow/specs/` outputs.
-
-If you want to understand the design rationale:
-
-- Read [`docs/why-ddd-for-ai.en.md`](why-ddd-for-ai.en.md).
-
-If something does not work as described:
-
-- File a docs feedback issue (see [`CONTRIBUTING.md`](../CONTRIBUTING.md)).
-  Per-tool documentation is new and feedback specifically about Gemini CLI
-  behavior is valuable.

package/docs/using-with-gemini-cli.md

@@ -1,184 +0,0 @@
-# 在 Gemini CLI 中使用 Dflow
-
-> **繁體中文** | [English](using-with-gemini-cli.en.md)
-
-當你的 AI 程式設計助理是 [Gemini CLI](https://github.com/google/gemini-cli) 時，Dflow 的使用體驗 walk-through。閱讀約需 10 分鐘。
-
-本指南專注於 Gemini CLI 的具體使用體驗。工具中立的評估流程請見
-[`docs/evaluating-dflow.md`](evaluating-dflow.md)。完整的 Get Started
-與功能列表請見 [`README.md`](../README.md)。
-
-## 本指南的適用對象
-
-你正在使用或評估以 Gemini CLI 作為 AI 程式設計助理的 Dflow。
-本指南說明 `init` 之後 Gemini CLI 看到了什麼、Dflow 的 slash
-commands 是如何被識別的，以及幾個值得了解的 Gemini CLI 專屬使用模式。
-
-你不需要在執行 `init` 之前先讀本指南。它最適合在你執行過一次 `init` 之後、
-想了解 Gemini CLI 實際載入什麼內容時閱讀。
-
-## 前置條件
-
-- 已安裝 Gemini CLI（見 [github.com/google/gemini-cli](https://github.com/google/gemini-cli)）。
-- 已具備 Node.js / npm 環境（Dflow 透過 npm 發佈）。以
-  `npm install -g dflow-sdd-ddd` 全域安裝，或用 `npx dflow-sdd-ddd` 走免安裝路徑。
-- 有一個你願意在其中執行 init 的專案目錄。首次嘗試建議先用 branch 或
-  可拋棄的範例專案；見
-  [評估者指南 Playbook](evaluating-dflow.md#30-分鐘評估-playbook)。
-
-你不需要獨立的 Dflow 服務或 API 金鑰。這些 workflow 是文字形式，使用
-Gemini CLI 本身既有的功能。
-
-## `init` 之後 Gemini CLI 看到了什麼
-
-執行 `dflow init`（或免安裝路徑的 `npx dflow-sdd-ddd init`）並選擇 Gemini CLI
-作為目標工具後，會在專案根目錄建立一個薄 shim：
-
-```markdown
-# GEMINI.md - Dflow Project Instructions
-
-This project uses Dflow for spec-first AI-assisted development.
-
-Before planning or editing code, read and follow:
-
-- `dflow/specs/shared/AI-AGENT-GUIDE.md`
-
-Keep tool-specific instruction files small. The Dflow guide above is the
-single source of truth for project workflow rules, slash-command behavior,
-spec locations, and SDD/DDD constraints.
-
-If your tool supports Markdown imports, the canonical guide is imported below:
-
-@dflow/specs/shared/AI-AGENT-GUIDE.md
-```
-
-Gemini CLI 在這個專案中啟動時，會發生兩件事：
-
-1. Gemini CLI 自動從專案根目錄載入 `GEMINI.md` 到它的 context 中。
-   這是 Gemini CLI 的標準專案指示機制。
-2. 末尾的 `@dflow/specs/shared/AI-AGENT-GUIDE.md` 這行使用 Gemini
-   CLI 的 Markdown import 語法，將 canonical Dflow 指南 inline 嵌入。因此 Gemini CLI
-   等效於把兩個檔案當成一組指示來讀取。
-
-canonical 指南（`dflow/specs/shared/AI-AGENT-GUIDE.md`）是實際 workflow
-規則的所在：專案上下文（track、技術棧、文章語言）、`/dflow:*` workflow 表、
-source-of-truth 檔案路徑，以及核心 SDD/DDD 規則。`GEMINI.md` shim 刻意保持精簡，
-這樣 canonical 指南就能在不需要 Gemini CLI 專屬修改的情況下持續演進。
-
-如果專案中已有 `GEMINI.md`，`init` 不會覆蓋它。它改為在
-`dflow/specs/shared/` 下寫入 merge snippet，讓你手動貼入現有的 `GEMINI.md`。
-
-## 在 Gemini CLI 中使用 Dflow Workflow 指令
-
-Dflow 的 `/dflow:*` slash commands 是 AI 透過 `AI-AGENT-GUIDE.md` 中的
-workflow 表識別的 workflow 名稱，不是 Gemini CLI 的內建工具指令。
-你以普通對話方式輸入它們：
-
-```text
-/dflow:new-feature
-```
-
-Gemini CLI 將此視為輸入。由於它已透過 `GEMINI.md` import 載入了 workflow 表，
-它會識別這個前綴並進入對應的 workflow。一次典型的對話如下：
-
-```text
-User: /dflow:new-feature
-
-Gemini CLI: Entering new-feature workflow. Please describe the user-facing
-capability or business behavior you want to add.
-
-User: Allow expense submitters to attach a receipt image when filing an
-expense.
-
-Gemini CLI: I'll start by drafting a feature spec under
-dflow/specs/features/active/. Before I do, I need a short answer on:
-[clarifying questions about scope, owner, priority]
-```
-
-接著這個 workflow 會引導你完成 spec 起草、行為範例、實作計畫，以及
-finish-feature 漂移（drift）檢查。確切的流程取決於你進入的是哪個 workflow
-（`/dflow:new-feature`、`/dflow:modify-existing`、`/dflow:bug-fix` 等）。
-所有 workflow 定義都存放在 Dflow skill source 中；Gemini CLI 在需要時讀取
-skill 檔案來執行它們。
-
-可用的 workflow 入口：
-
-| 指令 | 適用情境 |
-|---|---|
-| `/dflow:new-feature` | 需要新增一個使用者可見的功能或業務行為。 |
-| `/dflow:modify-existing` | 需要修改現有行為。 |
-| `/dflow:bug-fix` | 可以用預期行為 vs 實際行為描述的缺陷。 |
-| `/dflow:new-phase` | 進行中的 feature 需要另一個實作 slice。 |
-| `/dflow:finish-feature` | 實作完成後需要進行漂移（drift）收尾。 |
-| `/dflow:verify` | 需要對 spec、領域文件、實作與測試進行一致性檢查。 |
-| `/dflow:pr-review` | 變更已準備好進行 SDD/DDD review。 |
-| `/dflow:report-dflow-feedback` | 你發現了 Dflow 的問題或改進點，想要一份清理過的上游回饋草稿。 |
-
-如果你忘了指令名稱，問 Gemini CLI「what dflow workflows are available?」
-即可 —— 答案會從它已載入的 workflow 表中給出。
-
-## 與其他 AI 工具的差異
-
-canonical 指南（`dflow/specs/shared/AI-AGENT-GUIDE.md`）在各工具之間是相同的。
-只有根目錄層的 shim 有所不同：
-
-| 工具 | 產生的 shim | 載入 canonical 指南的方式 |
-|---|---|---|
-| Gemini CLI | `GEMINI.md` | `@dflow/specs/shared/AI-AGENT-GUIDE.md` Markdown import |
-| Claude Code | `CLAUDE.md` | `@dflow/specs/shared/AI-AGENT-GUIDE.md` Markdown import |
-| Codex / Copilot coding agent | `AGENTS.md` | 啟動時直接讀取檔案內容 |
-| GitHub Copilot | `.github/copilot-instructions.md` | 直接讀取檔案內容 |
-
-你可以之後執行 `dflow configure-agents` 來新增另一個工具的 shim，而不需要重跑
-`init`。同一個專案可以同時啟用多個工具，並透過 canonical 指南保持同步。
-
-## 常見模式與注意事項
-
-**保持 `GEMINI.md` 精簡。** 如果你發現自己在把 workflow 規則、spec 路徑或
-SDD 約束加入 `GEMINI.md`，這些內容應該放到
-`dflow/specs/shared/AI-AGENT-GUIDE.md`。shim 保持精簡，其他工具的 shim 才不會
-與它產生漂移（drift）。
-
-**`/dflow:*` 不是 Gemini CLI 的工具指令。** Slash commands 是 AI 從 workflow
-表識別的純文字模式。你在 `init` 之後就可以立即使用它們，不需要任何 Gemini CLI
-設定。
-
-**Permission gates 與 Dflow workflow gates 是分開的。** Gemini CLI 可能會在執行
-shell 指令或修改檔案前要求確認。Dflow 的 workflow 有自己的審核關卡（例如「我已起草
-spec —— 你要我繼續進入實作嗎？」）。兩者可能在同一個動作上同時觸發；這是預期行為，
-不代表設定有誤。
-
-**`@` import 不是遞迴的。** `GEMINI.md` import 了 `AI-AGENT-GUIDE.md`，但如果
-`AI-AGENT-GUIDE.md` 引用了其他檔案（例如 feature spec），那些檔案不會被自動
-載入 —— Gemini CLI 會在進入對應 workflow 時按需讀取它們。這樣可以讓 context
-用量與正在進行的工作保持比例。
-
-**既有的 `GEMINI.md` 會被保留。** `init` 不會覆蓋你現有的專案指示。請到
-`dflow/specs/shared/` 下找 `init` 寫入的 merge snippet，並手動將相關段落貼入
-你現有的 `GEMINI.md`。
-
-**跨機器專案可正常運作。** `dflow/specs/` 是純 Markdown，已 check in 到你的
-repo。任何人 clone 該 repo 並在其中使用 Gemini CLI，都會透過已 commit 的
-`GEMINI.md` shim 與 canonical 指南自動看到相同的 Dflow 設定。
-
-## 下一步
-
-如果你還沒有執行 `init`：
-
-- 按照[評估者指南 Playbook](evaluating-dflow.md#30-分鐘評估-playbook)
-  在可拋棄的範例專案中試用。
-
-如果你已執行 `init` 且想查看端到端的 workflow 範例：
-
-- 閱讀 [`tutorial/01-greenfield/`](../tutorial/01-greenfield/walkthrough-00-setup.md) 或
-  [`tutorial/02-brownfield/`](../tutorial/02-brownfield/walkthrough-00-setup.md)。
-  tutorial walk-through 展示了對話流程與產生的 `dflow/specs/` 輸出。
-
-如果你想了解設計理念：
-
-- 閱讀[為什麼 AI 時代 DDD 更重要](why-ddd-for-ai.md)。
-
-如果有任何行為與描述不符：
-
-- 開一個 docs feedback issue（見 [`CONTRIBUTING.md`](../CONTRIBUTING.md)）。
-  Per-tool 文件是新內容，有關 Gemini CLI 行為的具體回饋非常有價值。