@jakkrichm/create-nexus-devflow 2.0.13 → 2.0.15

package/template/.agents/skills/implement/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: implement
+description: "[Devflow] Fast-Track Implement stage in DevFlow (Blueprint Mode) - execute checklist tasks incrementally with TDD and update spec.md."
+argument-hint: "{running-id or workspace path}"
+---
+
+# Fast-Track: Implement (Blueprint Mode)
+
+$ARGUMENTS
+
+Incremental code execution stage in Fast-Track. Reads the Single Living Spec (`spec.md`), executes checklist tasks, implements tests (TDD), and updates the implementation record.
+
+## Invocations & Aliases
+
+- `/implement`: Run implementation on current active run
+- `/implement {running-id}`: Run implementation on specified running ID
+- `$implement`: Codex CLI invocation
+
+## Fast-Track Mainline Workflow
+
+```text
+/spec ──▶ /implement ──▶ /check ──▶ /complete
+```
+
+## Behavior & Contract
+
+When invoked:
+
+### 1. Load Active Context
+1. Identify active Running ID from `devflow/context/current-stage.md` or argument.
+2. Read `devflow/runs/{RUNNING_ID}/spec.md`.
+3. Locate `## 2. Plan & Test Strategy` and `## 3. Implementation Checklist`.
+
+### 2. Incremental Execution with TDD
+1. Select unchecked items `- [ ]` from the checklist in order.
+2. For each task:
+   - **TDD (Red-Green-Refactor)**: When `Test Decision: Required`, create or update unit tests first.
+   - Implement the minimal, clean code change satisfying the task.
+   - Run localized verification (e.g. `npm test`, linter).
+   - Mark the item as `- [x]` in `spec.md`.
+
+### 3. Update Living Spec (`spec.md`)
+Append or update `## 4. Implementation Record` in `spec.md` with:
+- Summary of completed tasks and modified files
+- Key architectural observations or notes
+- Status of checklist items
+
+Example:
+```markdown
+## 4. Implementation Record
+- **[Task 1.1]**: Implemented JWT auth middleware in `src/middleware/auth.ts`
+- **[Task 1.2]**: Added unit tests in `test/auth.test.ts` (All 6 tests passing)
+- **[Task 1.3]**: Registered auth route in `src/server.ts`
+```
+
+### 4. Update Workspace Status
+Update `devflow/context/current-stage.md`:
+- `Current Stage`: `implement (Fast-Track -> Checklist Completed -> Ready for /check)`
+
+### 5. Output Summary & Next Step
+Report to the user:
+- Completed checklist items and modified files
+- Local verification results
+- **Next Command**: `/check` (or `/check {RUNNING_ID}`)

package/template/.agents/skills/insight/SKILL.md

@@ -27,7 +27,7 @@ What Broke ➔ Business Impact ➔ Root Cause ➔ Fix Evidence ➔ Prevention &
 
 ## 2. Process & Recording Destinations
 
-1. **Load Evidence**: Review `git diff`, `40-implement.md`, `50-verify.md`, or test logs.
+1. **Load Evidence**: Review `git diff`, `40-execute.md`, `50-verify.md`, or test logs.
 2. **Distill Insights**: Formulate clear, actionable, non-generic takeaways.
 3. **Save to Persistent Memory**:
    - Save project-wide engineering lessons to `devflow/context/lessons.md` (or `knowledge/lessons.md`).

package/template/.agents/skills/overview/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: overview
+description: "[Devflow] Scan codebase architecture, data models, and shipped history to synthesize or refresh devflow/context/project-overview.md as the living source of truth."
+---
+
+# overview - Living Context Synthesis & Sync
+
+Where this sits in the workflow:
+
+```text
+codebase + devflow/history/HISTORY.md  ->  [overview]  ->  devflow/context/project-overview.md  ->  00-discover / 10-define / 20-spec
+(reality & shipped runs)                    (sync &         (living source of truth)             (informed planning)
+                                             synthesize)
+```
+
+`overview` is the context synchronization and synthesis engine for Nexus-DevFlow. It inspects the actual codebase (manifest, dependencies, directory layout, models/schemas, entry points) along with the completed delivery history (`devflow/history/HISTORY.md` and `devflow/runs/`) to build or refresh `devflow/context/project-overview.md`.
+
+It ensures that `project-overview.md` remains a **Living Source of Truth** that evolves alongside your software, rather than a stale artifact left behind after onboarding.
+
+## Usage
+
+```text
+/overview
+$overview
+overview
+```
+
+Use this when:
+- Multiple delivery runs (`RUN-xxx`) have shipped and `project-overview.md` needs to reflect newly added capabilities.
+- New database schemas, ORM models, or API boundaries were introduced.
+- Major dependencies or architectural patterns were added or modified.
+- After completing `70-release` to keep project context perfectly aligned.
+- Preparing for a new initiative or discovery pass.
+
+---
+
+## Process
+
+### Step 1 - Scan Reality (Codebase Survey)
+
+Inspect the actual codebase to establish hard facts:
+
+1. **Manifest & Tooling**:
+   - Read `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `pom.xml`, or `Gemfile`.
+   - Identify language versions, primary framework, state management, and build tools.
+2. **Directory Architecture**:
+   - Map high-level directory layout (`src/`, `app/`, `api/`, `lib/`, `components/`, etc.).
+   - Identify major modules, entry points, and routing conventions.
+3. **Concrete Data Models & Schemas**:
+   - Search for ORM schemas (`schema.prisma`, Drizzle schemas, TypeORM entities, SQLAlchemy models, Zod schemas, or core TypeScript types).
+   - Extract entity names, core fields, relationships, and invariants.
+4. **Verified Commands**:
+   - Inspect package scripts (`dev`, `build`, `test`, `lint`, `check`, `verify`).
+
+---
+
+### Step 2 - Scan History (Delivered Capabilities)
+
+Inspect DevFlow history records:
+
+1. Read `devflow/history/HISTORY.md` for completed and released milestones.
+2. Scan completed delivery runs in `devflow/runs/` to extract shipped user-visible capabilities and core system features.
+
+---
+
+### Step 3 - Synthesize `project-overview.md`
+
+Write or update `devflow/context/project-overview.md` following standard structure:
+
+```markdown
+# Project Overview & Source of Truth
+
+> Living context artifact automatically synchronized with codebase reality and DevFlow delivery history.
+
+## 1. Project Purpose & Target Users
+- High-level summary of what the system does, who it serves, and the core problem it solves.
+
+## 2. Architecture & Directory Layout
+- Visual directory layout tree with short descriptions for major modules and boundaries.
+
+## 3. Technology Stack & Key Tooling
+- Frontend, Backend, Database, ORM, Testing frameworks, CI/CD, and Package Manager.
+
+## 4. Concrete Data Models & Entities
+- Field-level definitions of major entities, types, and relationships.
+
+## 5. Shipped Capabilities & Key Modules
+- Consolidated list of active features and subsystems verified in the codebase.
+
+## 6. Verified Commands & Developer Workflow
+- Exact commands for Dev, Build, Test, Lint, and Verify.
+
+## 7. Known Architectural Focus Areas
+- Known technical debt, active migrations, or upcoming architectural focus points.
+```
+
+---
+
+### Step 4 - Review & Report
+
+Present a concise summary of the sync:
+- Models or entities detected and added
+- Shipped capabilities refreshed from history
+- Stack and tooling updates
+- Any inconsistencies or gaps found between code and documentation
+
+---
+
+## Rules & Guardrails
+
+1. **Grounded in Reality**: Never invent non-existent packages, fictional data models, or unverified endpoints. Everything in `project-overview.md` must be traceable to real code or recorded history.
+2. **Preserve User Intent**: Do not erase custom business rules or user-written notes. Integrate new facts smoothly around existing intent.
+3. **Concrete Over Vague**: Provide actual model names, field types, and route paths rather than vague one-line summaries.
+4. **Non-Destructive**: `overview` only writes to `devflow/context/project-overview.md`. It never modifies source code, runs migrations, or touches git history.

package/template/.agents/skills/pr/SKILL.md

@@ -40,7 +40,7 @@ You are an orchestrator. Your goal is to call the specialized Git PR Maker agent
 - Prefer markdown-first stage artifacts as the source narrative:
   - `20-spec.md`
   - `30-plan.md`
-  - `40-implement.md`
+  - `40-execute.md`
   - `50-verify.md`
   - `60-report.md` when the final summary already exists
   - `70-release.md` when release execution notes already exist

package/template/.agents/skills/preview/SKILL.md

@@ -38,5 +38,5 @@ This is the preview master skill for Nexus-DevFlow. It manages local development
 ## Relationship To DevFlow 2.0
 
 - **Classification**: Companion command & Runtime support
-- **Mainline stages**: `40-implement` (interactive visual check), `50-verify` (smoke test check)
+- **Mainline stages**: `40-execute` (interactive visual check), `50-verify` (smoke test check)
 - **Handoff**: `50-verify`

package/template/.agents/skills/report-html/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: report-html
+description: "[Devflow] Standalone HTML Report Generator - render an interactive standalone HTML dashboard from spec.md or 60-report.md on demand."
+argument-hint: "{running-id or workspace path}"
+---
+
+# Standalone: Report HTML
+
+$ARGUMENTS
+
+Standalone companion command to generate an interactive, self-contained HTML report dashboard on demand from either a Fast-Track `spec.md` or a Deep-Track `60-report.md`.
+
+> [!NOTE]
+> HTML reports are **never automatically generated** during normal mainline stages (`/complete` or `60-report`). Use this command whenever you or stakeholders wish to view or share an interactive web report.
+
+## Invocations & Aliases
+
+- `/report:html`: Generate HTML report for the active or most recent run
+- `/report:html {running-id}`: Generate HTML report for the specified running ID
+- `npm run report:html -- {running-id}`: CLI npm script invocation
+- `$report:html`: Codex CLI invocation
+
+## Behavior & Contract
+
+When invoked:
+
+### 1. Identify Target Run
+1. Locate target run directory in `devflow/runs/{running-id}` from argument or `devflow/context/current-stage.md`.
+2. Check for either:
+   - Fast-Track Living Spec: `devflow/runs/{RUNNING_ID}/spec.md` (or `blueprint.md`)
+   - Deep-Track Report Digest: `devflow/runs/{RUNNING_ID}/60-report.md`
+
+### 2. Render Interactive HTML Dashboard
+Execute the HTML generation engine:
+```bash
+npm run report:html -- {RUNNING_ID}
+```
+Or execute the renderer to transform Markdown into a styled, standalone HTML document:
+- Path: `devflow/runs/{RUNNING_ID}/report.html`
+
+### 3. Output
+Provide:
+- Generated HTML file path: `file:///devflow/runs/{RUNNING_ID}/report.html`
+- Summary of sections rendered (Spec, Plan, Progress, QA Evidence, Release Notes)
+- Instructions to open the file in any browser

package/template/.agents/skills/review/SKILL.md

@@ -68,4 +68,4 @@ Categorize all findings into actionable severities:
 
 - **Classification**: Companion command & Verification support
 - **Mainline stages**: `50-verify` (QA & Code Review lane), `70-release` (Pre-merge review)
-- **Handoff**: `40-implement` (for fixes), `50-verify`, `70-release`
+- **Handoff**: `40-execute` (for fixes), `50-verify`, `70-release`

package/template/.agents/skills/rollback/SKILL.md

@@ -8,7 +8,7 @@ description: "[Devflow] Plan safe feature or run reversal with dependency and co
 Where this sits in the workflow:
 
 ```text
-completed run + git history  ->  [rollback]  ->  40-implement (or fix run)  ->  50-verify  ->  70-release
+completed run + git history  ->  [rollback]  ->  40-execute (or fix run)  ->  50-verify  ->  70-release
 (run archive + commits)          (risk review    (reverse product diff)          (prove)      (log & finalize)
                                   + plan)
 ```
@@ -51,7 +51,7 @@ Identify:
 
 - Exact commit SHA(s) introducing the feature.
 - Parent commit before the feature was introduced.
-- Associated stage artifacts (`20-spec.md`, `40-implement.md`, `70-release.md`).
+- Associated stage artifacts (`20-spec.md`, `40-execute.md`, `70-release.md`).
 
 ## Step 2 - Separate Product Changes From DevFlow History
 
@@ -98,7 +98,7 @@ Draft the rollback plan containing:
 Present the rollback plan to the user:
 
 - Summarize affected files and dependency risks.
-- If approved, route to `40-implement` (or allocate a dedicated Fixrollback Run) to safely execute the reversal steps behind review gates.
+- If approved, route to `40-execute` (or allocate a dedicated Fixrollback Run) to safely execute the reversal steps behind review gates.
 
 ## Rules
 

package/template/.agents/skills/security-review/SKILL.md

@@ -59,5 +59,5 @@ This is the comprehensive security master skill for Nexus-DevFlow. It combines s
 ## Relationship To DevFlow 2.0
 
 - **Classification**: Companion command & Safety gate
-- **Mainline integration**: Run during `40-implement` or `50-verify` before `70-release`.
-- **Handoff**: P0/P1 security findings block release and return to `40-implement` for immediate remediation.
+- **Mainline integration**: Run during `40-execute` or `50-verify` before `70-release`.
+- **Handoff**: P0/P1 security findings block release and return to `40-execute` for immediate remediation.

package/template/.agents/skills/simplify/SKILL.md

@@ -66,5 +66,5 @@ Delete commented-out code blocks, `// removed` notes, and unused variables (`_un
 ## Relationship To DevFlow 2.0
 
 - **Classification**: Companion command & Refactoring support
-- **Mainline integration**: Used during `40-implement` (Refactor step of TDD) or `50-verify`.
+- **Mainline integration**: Used during `40-execute` (Refactor step of TDD) or `50-verify`.
 - **Handoff**: `50-verify` (proves zero regressions).

package/template/.agents/skills/spec/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: spec
+description: "[Devflow] Fast-Track Spec router in DevFlow (Blueprint Mode) - aliases and routes to /feature or /fix to create the single living spec.md contract."
+argument-hint: "{feature title, bug description, IDEA-xxx, or running-id}"
+---
+
+# Fast-Track: Spec Router (Blueprint Mode)
+
+$ARGUMENTS
+
+Unified Fast-Track entry point that routes to `/feature` or `/fix` to create and maintain the **Single Living Spec (`spec.md`)**.
+
+> [!TIP]
+> **Preferred Commands**:
+> - ใช้ **`/feature <title>`** สำหรับฟีเจอร์ใหม่หรืองานพัฒนาทั่วไป
+> - ใช้ **`/fix <bug-description>`** สำหรับแก้บั๊กหรือ hotfix
+
+## Invocations & Aliases
+
+- `/feature <title>`: Fast-Track feature workflow (แนะนำ)
+- `/fix <bug-description>`: Fast-Track ad-hoc bugfix workflow (แนะนำ)
+- `/spec <title>` or `/spec IDEA-xxx`: Generic Fast-Track specification
+- `$feature`, `$fix`, `$spec`: Codex CLI invocation
+
+## Fast-Track Mainline Workflow
+
+```text
+/feature (หรือ /fix) ──▶ /implement ──▶ /check ──▶ /complete
+```
+
+## Behavior & Contract
+
+When invoked:
+
+1. If the input describes a bug or hotfix, routes to `/fix` behavior.
+2. Otherwise, routes to `/feature` behavior.
+3. Allocates sequential Running ID (`RUN-xxx`), creates directory `devflow/runs/{RUNNING_ID}/`, and generates `spec.md` in **Thai (`th`)**.
+4. Updates `devflow/context/current-stage.md` and reports next step: `/implement`.

package/template/.agents/skills/test/SKILL.md

@@ -81,7 +81,7 @@ For browser and UI features, unit tests alone are insufficient:
 
 ## 6. Test Generation & Persistent Execution Reports
 
-When generating or logging test runs during `40-implement` or `50-verify`:
+When generating or logging test runs during `40-execute` or `50-verify`:
 - Save summary reports to `devflow/reports/{date}-test-report-{slug}.md`
 - Include: Target, Test Cases (Happy Path, Error, Edge Cases), Pass/Fail statistics, and gaps/risks.
 
@@ -90,5 +90,5 @@ When generating or logging test runs during `40-implement` or `50-verify`:
 ## Relationship To DevFlow 2.0
 
 - **Classification**: Companion command & Engineering standard
-- **Mainline stages**: `30-plan` (TDD decisions), `40-implement` (TDD execution), `50-verify` (QA gate)
+- **Mainline stages**: `30-plan` (TDD decisions), `40-execute` (TDD execution), `50-verify` (QA gate)
 - **Handoff**: `50-verify`, `Debug`, `autopilot`

package/template/.agents/skills/try/SKILL.md

@@ -8,7 +8,7 @@ description: "[Devflow] Generate human manual QA review walkthrough guide (where
 Where this sits in the workflow:
 
 ```text
-40-implement or 50-verify or 60-report  ->  [try]  ->  human review & verification
+40-execute or 50-verify or 60-report  ->  [try]  ->  human review & verification
 (work implemented / verified)                  (manual    (where to go,
                                                steps)     what to click)
 ```
@@ -36,7 +36,7 @@ Read:
 - `devflow/context/current-stage.md`
 - `devflow/context/project-overview.md`
 - `devflow/context/coding-standards.md`
-- Active run artifacts: `20-spec.md`, `30-plan.md`, `40-implement.md`, `50-verify.md` (or archived run artifacts)
+- Active run artifacts: `20-spec.md`, `30-plan.md`, `40-execute.md`, `50-verify.md` (or archived run artifacts)
 - Current git branch and status
 
 Do not dump the full spec. Extract only the concrete routes, screens, CLI commands, API endpoints, test data, and expected outcomes that a human needs to verify the feature.

package/template/.claude/skills/00-discover/SKILL.md

@@ -14,12 +14,14 @@ Explore a request before delivery commitment. Create or resume a Discovery ID, c
 
 ```text
 00-discover {title or request}
+00-discover IDEA-xxx
 00-discover {discovery-id}
 ```
 
 Use this when:
 
 - a new request needs discussion before the team commits to delivery
+- exploring a pending idea from `devflow/ideas.md` (`00-discover IDEA-xxx`)
 - the best route may be `Brainstorm`, `PRD`, `Research`, or `Debug`
 - supporting findings need to be synthesized into a go/no-go decision
 

package/template/.claude/skills/30-plan/SKILL.md

@@ -48,7 +48,7 @@ Run planning as an evidence loop, not as a one-shot outline.
 - **Observation**: use concrete evidence such as file paths, existing patterns, package scripts, validation commands, and unresolved assumptions.
 - **Adjustment**: if evidence is missing, search/read more, recommend `Research` or `Agent codebase-explorer`, split the work, or route back to `20-spec` when the contract is not plan-ready.
 - **Stop Condition**: stop only when phases are ordered, subtasks are scoped, verification is explicit, test decisions are recorded, and any blockers are visible.
-- **Handoff**: `30-plan.md` must give `40-implement` enough context to select one scoped unit and execute it without inventing intent.
+- **Handoff**: `30-plan.md` must give `40-execute` enough context to select one scoped unit and execute it without inventing intent.
 
 ### 1. Read Task Artifacts
 
@@ -161,12 +161,12 @@ If validation fails, repair only what is necessary and keep `30-plan.md` aligned
 
 ### 7. Manual Review Soft Gate
 
-Before recommending `40-implement`, check whether the plan still shows pending review.
+Before recommending `40-execute`, check whether the plan still shows pending review.
 If `Approval Status` is still pending or major dependencies remain unresolved:
 
 - warn that implementation should wait for review
 - recommend human confirmation of sequencing, scope, and verification strategy
-- keep `40-implement` as a soft recommendation only
+- keep `40-execute` as a soft recommendation only
 
 ## Output Checklist
 
@@ -184,7 +184,7 @@ If `Approval Status` is still pending or major dependencies remain unresolved:
 
 - Classification: Mainline workflow
 - Previous state: `20-spec`
-- Next state: `40-implement` when execution steps and verification are clear
+- Next state: `40-execute` when execution steps and verification are clear
 - Common companion commands: `Research` or `Agent` when architecture, data flow, or external constraints still need investigation; support skills: `grill-with-docs`, `domain-modeling`, `codebase-design`, `tdd`, and `to-issues` for final design stress-testing, durable terminology capture, test planning, and issue packaging
 
 ## Sources
@@ -192,11 +192,11 @@ If `Approval Status` is still pending or major dependencies remain unresolved:
 - `AGENTS.md`
 - `docs/workspace-artifacts.md`
 - `.agent/resources/schemas/plan.template.md`
-- Related commands: `20-spec`, `Research`, `Agent`, `40-implement`
+- Related commands: `20-spec`, `Research`, `Agent`, `40-execute`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `40-implement {ID}`
+- **Primary**: `40-execute {ID}`
 - **Why**: Approved planning is the gate before implementation in DevFlow 2.0.
 - **Alternatives**:
   - `Research` - choose this when the plan still depends on missing evidence.

package/template/{.agents/skills/40-implement → .claude/skills/40-execute}/SKILL.md

@@ -1,25 +1,23 @@
----name: 40-implement
-
-description: "[Devflow] Implement stage in DevFlow 2.0 - execute planned tasks incrementally with evidence and unit tests."
 ---
-# Phase 40: Implement Code
+name: 40-execute
+description: "[Devflow] Execute stage in DevFlow 2.0 - execute planned tasks incrementally with evidence and unit tests."
+---
+# Phase 40: Execute Code
 
-Implement the approved plan incrementally. Source code edits are allowed in this phase.
+Implement and execute the approved plan incrementally. Source code edits are allowed in this phase.
 
 ## Usage
 
 ```text
-40-implement {ID}
+40-execute {ID}
 ```
 
 ## Markdown-First Contract
 
-Use `40-implement.md` as the primary implementation artifact.
-Before writing `40-implement.md`, read `artifact_language` from `.agent/resources/schemas/implement.template.md` and produce the artifact in that language.
+Use `40-execute.md` as the primary execution artifact.
+Before writing `40-execute.md`, produce the artifact in Thai (`th`).
 
-Use controlled task-engine commands when progress state must be synchronized:
-
-Before implementation, confirm the plan is approved in the stage artifacts. Track subtask progress, implementation notes, and completion evidence directly in `40-implement.md` and related stage markdown files.
+Before execution, confirm the plan is approved in the stage artifacts. Track subtask progress, execution notes, and completion evidence directly in `40-execute.md` and related stage markdown files.
 
 ## Required Section Content
 
@@ -37,7 +35,7 @@ Before completing any generated artifact:
 
 ### Loop Contract
 
-Run implementation as scoped execution loops, one unit at a time.
+Run execution as scoped execution loops, one unit at a time.
 
 - **Intent**: complete the selected planned unit while preserving the spec, plan, and repository conventions.
 - **Context**: read `30-plan.md`, `20-spec.md`, relevant checklist items, target files, pattern files, and test decisions before editing.
@@ -45,7 +43,7 @@ Run implementation as scoped execution loops, one unit at a time.
 - **Observation**: inspect concrete evidence from diffs, command output, tests, manual checks, and checklist status before claiming progress.
 - **Adjustment**: if evidence does not match intent, fix within the current unit, capture the blocker, use `Debug`, or return to `30-plan` or `20-spec` when the work no longer matches the contract.
 - **Stop Condition**: stop the unit when the planned change is complete, verification evidence is recorded, deviations are explained, and the next unit or handoff is clear.
-- **Handoff**: `40-implement.md` must tell `50-verify` what changed, why it changed, which checks ran, what failed or was skipped, and what residual risk remains.
+- **Handoff**: `40-execute.md` must tell `50-verify` what changed, why it changed, which checks ran, what failed or was skipped, and what residual risk remains.
 
 ### 1. Get Bearings
 
@@ -61,7 +59,7 @@ Confirm the current Git branch with `git branch --show-current` and use that bra
 
 Select one scoped unit of work at a time. Do not implement the whole plan as one blob.
 
-### 2. Implement One Scoped Unit
+### 2. Execute One Scoped Unit
 
 Use the original coder discipline, adapted to 2.0:
 
@@ -73,7 +71,7 @@ Use the original coder discipline, adapted to 2.0:
 - make the smallest useful code change
 - preserve project style
 - run the planned verification
-- record observation, adjustment, stop condition status, and the result in `40-implement.md`
+- record observation, adjustment, stop condition status, and the result in `40-execute.md`
 - update checklist item status, timestamps, and evidence links as work progresses
 
 If tests are `Required`:
@@ -93,7 +91,7 @@ Use the old recovery discipline when blocked:
 
 Use `tdd` for behavior-change implementation loops, `diagnosing-bugs` when a tight repro is needed before a fix, and `codebase-design` when implementation exposes an awkward seam or shallow module.
 
-### 4. Finalize Implementation
+### 4. Finalize Execution
 
 When the scoped work is complete:
 
@@ -102,14 +100,13 @@ When the scoped work is complete:
 - record verification performed
 - record loop evidence for each completed unit: intent, observation, adjustment, and stop condition
 - record deviations, blockers, and manual checks
-- follow the `artifact_language` configured in `implement.template.md`
 - make sure checklist statuses match the actual state of the code and tests
-- make sure `40-implement.md` is ready for Verify
+- make sure `40-execute.md` is ready for Verify
 
 ### 5. Manual Review Soft Gate
 
-If the plan was not clearly approved, warn that implementation proceeded under review risk.
-When finishing `40-implement.md`:
+If the plan was not clearly approved, warn that execution proceeded under review risk.
+When finishing `40-execute.md`:
 
 - record any deviation from the approved plan explicitly
 - set reviewer expectations before `50-verify`
@@ -131,14 +128,13 @@ Report:
 
 - Classification: Mainline workflow
 - Previous state: `30-plan`
-- Next state: `50-verify` when scoped implementation is complete
+- Next state: `50-verify` when scoped execution is complete
 - Common companion commands: `Debug` for blockers, `Preview` for local checks; support skills: `tdd`, `diagnosing-bugs`, and `codebase-design` for behavior changes, root-cause loops, and implementation-time design pressure
 
 ## Sources
 
 - `AGENTS.md`
 - `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/implement.template.md`
 - Related commands: `30-plan`, `Debug`, `Preview`, `50-verify`
 
 ## Next Workflow Recommendation
@@ -146,7 +142,7 @@ Report:
 - **Primary**: `50-verify {ID}` when the planned work is complete.
 - **Why**: Implementation needs independent verification before release or human acceptance.
 - **Alternatives**:
-  - `Debug "{blocker}"` - choose this when implementation is blocked by an unexplained failure.
+  - `Debug "{blocker}"` - choose this when execution is blocked by an unexplained failure.
   - `30-plan {ID}` - choose this when the plan is incomplete or no longer matches the work.
   - `Preview` - choose this when a local runtime or visual check is useful before formal verification.
   - `codebase-design` - choose this when the implementation cannot be tested cleanly because the module shape is wrong.
@@ -155,12 +151,11 @@ Report:
 
 - Use `Debug` when the conversation reveals an unexplained blocker, flaky behavior, or root-cause gap.
 - Use `Preview` when a runtime, UI, or local interaction check would reduce verification risk.
-- Return to `30-plan` when implementation drift shows the plan no longer matches reality.
+- Return to `30-plan` when execution drift shows the plan no longer matches reality.
 
 ## Wiki Update Recommendation
 
 - **Needed**: `yes` when coding discovers a reusable implementation pattern, gotcha, or context optimization.
 - **Scope**: `project` unless the discovery is about DevFlow itself.
 - **Reason**: Coding findings are useful only when they are stable enough to help future tasks.
-- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*40-implement.md`
-
+- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*40-execute.md`

package/template/.claude/skills/50-verify/SKILL.md

@@ -43,12 +43,12 @@ Before completing any generated artifact:
 Run verification as an evidence review loop, not as a single pass/fail guess.
 
 - **Intent**: decide whether the implementation satisfies the spec and plan without introducing unacceptable regression risk.
-- **Context**: read `20-spec.md`, `30-plan.md`, `40-implement.md`, checklist state, changed files, test decisions, and available command/manual evidence.
+- **Context**: read `20-spec.md`, `30-plan.md`, `40-execute.md`, checklist state, changed files, test decisions, and available command/manual evidence.
 - **Action**: run or inspect validation, compare implementation evidence against the contract, review risk areas, and record findings by severity.
 - **Observation**: use concrete evidence from test output, validation output, diff review, manual checks, skipped checks, and impact notes.
-- **Adjustment**: if evidence is missing or failing, request targeted implementation follow-up, route to `Debug`, or return to `40-implement` with the exact evidence gap.
+- **Adjustment**: if evidence is missing or failing, request targeted implementation follow-up, route to `Debug`, or return to `40-execute` with the exact evidence gap.
 - **Stop Condition**: stop only with a clear verdict: pass, fail, or blocked; include the evidence, residual risks, and next route.
-- **Handoff**: `50-verify.md` must tell `60-report` why the work is ready, or tell `40-implement` exactly what must change before verification resumes.
+- **Handoff**: `50-verify.md` must tell `60-report` why the work is ready, or tell `40-execute` exactly what must change before verification resumes.
 
 ### 1. Context Gathering
 
@@ -56,7 +56,7 @@ Read:
 
 - `20-spec.md`
 - `30-plan.md`
-- `40-implement.md`
+- `40-execute.md`
 - `checklists/verification-checklist.md` when present
 - changed files
 - test output, command output, screenshots, or manual-check evidence
@@ -124,7 +124,7 @@ If pass:
 
 If fail:
 
-- route back to `40-implement` with exact failed evidence, missing checks, or required changes
+- route back to `40-execute` with exact failed evidence, missing checks, or required changes
 
 Use `Debug` when investigation is needed before implementation can resume.
 
@@ -134,7 +134,7 @@ Verification is the main human review checkpoint for implemented work.
 If the evidence is incomplete or `Approval Status` remains pending:
 
 - warn that release is not yet ready for confident handoff
-- recommend additional review or a return to `40-implement`
+- recommend additional review or a return to `40-execute`
 - keep `60-report` as a soft recommendation only
 
 ## Output
@@ -146,12 +146,12 @@ Report:
 - commands run
 - validation status
 - impact and rollback analysis when `50-verify-impact.md` is present
-- next command: `60-report {ID}` if pass, or `40-implement {ID}` if fail
+- next command: `60-report {ID}` if pass, or `40-execute {ID}` if fail
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline workflow
-- Previous state: `40-implement`
+- Previous state: `40-execute`
 - Next state: `60-report` when evidence is sufficient
 - Common companion commands: `Debug`, `Test`, `QA-Orchestrate`, `PR-Review`, `Agent`, `Wiki`
 - Support skills: `review`, `diagnosing-bugs`, `tdd`, and `silent-failure-audit` for focused verification lanes
@@ -162,11 +162,11 @@ Report:
 - `docs/workspace-artifacts.md`
 - `.agent/resources/schemas/verify.template.md`
 - `.agent/resources/schemas/verify-impact.template.md`
-- Related commands: `40-implement`, `Debug`, `Test`, `QA-Orchestrate`, `PR-Review`, `Agent`, `60-report`
+- Related commands: `40-execute`, `Debug`, `Test`, `QA-Orchestrate`, `PR-Review`, `Agent`, `60-report`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `60-report {ID}` when verification passes, or `40-implement {ID}` when verification fails.
+- **Primary**: `60-report {ID}` when verification passes, or `40-execute {ID}` when verification fails.
 - **Why**: Verification decides whether work moves forward to the final report stage or loops back for fixes.
 - **Alternatives**:
   - `Debug` - choose this when the failure needs root cause analysis before more implementation.