@jakkrichm/create-nexus-devflow 2.0.13 → 2.0.15

package/template/{.claude/skills/40-implement → .agents/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/.agents/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.

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

@@ -1,6 +1,6 @@
----name: 60-report
-
-description: "[Devflow] Report stage in DevFlow 2.0 - produce standardized markdown and HTML summary report for the completed run."
+---
+name: 60-report
+description: "[Devflow] Report stage in DevFlow 2.0 - produce standardized markdown summary report for the completed run."
 argument-hint: "{running-id or workspace path}"
 ---
 
@@ -8,7 +8,7 @@ argument-hint: "{running-id or workspace path}"
 
 $ARGUMENTS
 
-Produce the final human-friendly summary of the full running flow in both Markdown and HTML so the outcome is easy to communicate every time.
+Produce the final human-friendly summary of the full running flow in Markdown (`60-report.md`) so the outcome is easy to communicate every time.
 
 ## Usage
 
@@ -16,19 +16,12 @@ Produce the final human-friendly summary of the full running flow in both Markdo
 60-report {running-id or workspace path}
 ```
 
-Use this when:
-
-- verification is complete and the run is ready for a final standardized summary before release
-- the team needs a standardized summary for communication
-- non-technical readers should be able to understand what happened
-
 ## Markdown-First Contract
 
-Write the primary stage artifacts to:
+Write the primary stage artifact to:
 
 ```text
-devflow/runs/{ID}-{slug}60-report.md
-devflow/runs/{ID}-{slug}60-report.html
+devflow/runs/{ID}-{slug}/60-report.md
 ```
 
 using:
@@ -39,6 +32,9 @@ using:
 
 Before writing `60-report.md`, read `artifact_language` from `report.template.md` and produce the markdown artifact in that language.
 
+> [!IMPORTANT]
+> **No Auto-Generated HTML**: ยกเลิกการสร้างไฟล์ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้! ระบบจะสร้างเฉพาะ `60-report.md` เท่านั้น หากผู้ใช้หรือทีมต้องการสร้าง HTML Report สวยงาม ให้เรียกคำสั่งแยกต่างหาก: `/report:html` หรือ `npm run report:html`
+
 ## Required Section Content
 
 Before completing any generated artifact:
@@ -57,13 +53,13 @@ Before completing any generated artifact:
 
 Run reporting as an outcome-evidence loop, not as a dump of prior artifacts.
 
-- **Intent**: produce a final markdown and HTML summary that lets a reader understand the outcome, evidence, decisions, risks, and next actions without replaying the whole run.
+- **Intent**: produce a final markdown summary that lets a reader understand the outcome, evidence, decisions, risks, and next actions without replaying the whole run.
 - **Context**: read all relevant stage artifacts, checklist files, verify impact notes, release notes, validation output, and supporting artifacts that materially explain the result.
-- **Action**: summarize the problem, direction, completed work, validation outcome, checklist progress, final decision, open risks, and next actions, then render the HTML report.
+- **Action**: summarize the problem, direction, completed work, validation outcome, checklist progress, final decision, open risks, and next actions.
 - **Observation**: use concrete evidence such as checklist completion, blocked or skipped items, validation results, release state, impact notes, and unresolved follow-ups.
 - **Adjustment**: if evidence is missing, return to the owning stage; if the report must support continuation, use `handoff`; if the run produced reusable lessons, use `insight-capture` or `Wiki`.
-- **Stop Condition**: stop when `70-report.md` and `70-report.html` both exist, summarize the outcome accurately, include checklist and evidence snapshots, and name any remaining follow-up work.
-- **Handoff**: `70-report.md` must close the mainline run or tell the next reader exactly where follow-up work should continue.
+- **Stop Condition**: stop when `60-report.md` exists, summarizes the outcome accurately, includes checklist and evidence snapshots, and names any remaining follow-up work.
+- **Handoff**: `60-report.md` must close the mainline run or tell the next reader exactly where follow-up work should continue.
 
 ### 1. Gather Full Run Context
 
@@ -73,7 +69,7 @@ Read all relevant stage artifacts:
 - `10-define.md`
 - `20-spec.md`
 - `30-plan.md`
-- `40-implement.md`
+- `40-execute.md`
 - `50-verify.md`
 - `checklists/implementation-checklist.md` when present
 - `checklists/verification-checklist.md` when present
@@ -98,19 +94,9 @@ Explain:
 
 Write:
 
-- a readable Markdown report for contributors
-- a consistent HTML report for stakeholder sharing
-
-In phase 1, `artifact_language` governs the markdown report text. HTML output is derived directly from `60-report.md` through the shared markdown-to-html renderer.
+- a readable Markdown report (`60-report.md`) for contributors
 
-To render the HTML consistently from the markdown report, use one of:
-
-```text
-npm run report:html -- <workspace-path-or-running-id>
-npm run render:html -- --stage 60-report <workspace-path-or-running-id>
-```
-
-Keep checklist summaries and follow-up status inside `60-report.md` so they carry through into the rendered HTML.
+Keep checklist summaries and follow-up status inside `60-report.md`.
 
 Both outputs should summarize checklist state when checklist artifacts exist, including:
 
@@ -120,27 +106,6 @@ Both outputs should summarize checklist state when checklist artifacts exist, in
 - approval status, review blockers, and next allowed command when they still matter
 - remaining follow-up work
 
-The HTML should stay visually consistent across runs while preserving the report markdown as the source of truth.
-
-### 4. Keep The Audience In Mind
-
-Prefer clarity over internal detail.
-
-Do not bury the outcome inside implementation trivia. The report should help a reader understand the run without replaying the whole workflow.
-
-When checklists exist, use them as the most human-readable operational record of what actually happened.
-Use `handoff` when the report must support continued work, and `insight-capture` when the run produced lessons that should become reusable knowledge.
-
-### 5. Manual Review Soft Gate
-
-Use the report as the final visibility checkpoint before release.
-If any stage still shows unresolved approval, blockers, or deferred work:
-
-- surface that state clearly in `60-report.md`
-- pull the relevant signal forward from checklist approval sections when they exist
-- do not imply the phase is fully closed when review is still open
-- recommend the real next action, even if that means returning to an earlier stage
-
 ## Output
 
 Report:
@@ -148,37 +113,18 @@ Report:
 - what the run accomplished
 - checklist completion status and remaining items
 - important remaining follow-ups
-- where `60-report.md` and `60-report.html` were written
-- render command used or recommended:
-
-```text
-npm run report:html -- <workspace-path-or-running-id>
-```
+- where `60-report.md` was written
+- standalone HTML command tip: `/report:html` (if HTML view is desired)
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline workflow
 - Previous state: `50-verify`
 - Next state: `70-release` when the summary is aligned and release can proceed
-- Common companion commands: `Wiki` for durable knowledge capture, `Help` for routing or explanation
-- Support skills: `handoff`, `insight-capture`, and writing skills when final reporting must support continuation or reusable learning
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/report.template.md`
-- Related commands: `50-verify`, `70-release`, `Wiki`, `Help`
+- Common companion commands: `/report:html` for standalone HTML dashboard, `Wiki` for durable knowledge capture, `Help` for routing or explanation
 
 ## Next Workflow Recommendation
 
-- **Primary**: `70-release {ID}` after `60-report.md` and `60-report.html` reflect the verified state clearly.
-- **Render HTML**: `npm run report:html -- {ID}` after `60-report.md` is finalized so the standardized stakeholder HTML stays in sync
-- **Alternative**: `Wiki` when the completed run should be promoted into durable reusable knowledge before release packaging continues
-- **Additional Alternative**: `handoff` when another session or agent must continue from the completed run.
-
-## Nexus Event
-
-- Use `Wiki` when the final summary should become durable project or framework knowledge.
-- Use `Help` when approval signals, ownership, or route timing still feel ambiguous.
-- Return to `50-verify` when unresolved evidence, blockers, or review state mean the report should not advance yet.
+- **Primary**: `70-release {ID}` after `60-report.md` reflects the verified state clearly.
+- **Optional Standalone HTML**: `/report:html` (or `npm run report:html -- {ID}`) if an interactive HTML report is desired for stakeholder presentation.
+- **Alternative**: `Wiki` when the completed run should be promoted into durable reusable knowledge before release packaging continues.

package/template/.agents/skills/70-release/SKILL.md

@@ -57,10 +57,10 @@ Before completing any generated artifact:
 Run release as a readiness-packaging loop, not as a celebratory summary.
 
 - **Intent**: convert verified work into a clear release, PR, merge, deploy, or handoff packet without hiding unresolved risk.
-- **Context**: read `50-verify.md`, `50-verify-impact.md` when present, `40-implement.md`, `20-spec.md`, checklist state, and any PR, deploy, merge, or handoff notes.
+- **Context**: read `50-verify.md`, `50-verify-impact.md` when present, `40-execute.md`, `20-spec.md`, checklist state, and any PR, deploy, merge, or handoff notes.
 - **Action**: summarize delivered scope, user/system impact, readiness state, validation evidence, rollback or mitigation notes, and follow-up items.
 - **Observation**: use concrete evidence such as verify verdict, failed or skipped checks, impact notes, residual risks, merge/deploy constraints, and checklist status.
-- **Adjustment**: if release readiness becomes uncertain, return to `50-verify`; if fixes are required, return to `40-implement`; if context must transfer, use `handoff`.
+- **Adjustment**: if release readiness becomes uncertain, return to `50-verify`; if fixes are required, return to `40-execute`; if context must transfer, use `handoff`.
 - **Stop Condition**: stop when the release state is explicit, evidence supports readiness, residual risks and follow-ups are named, and the next delivery or reporting route is clear.
 - **Handoff**: `70-release.md` must close the mainline run or tell the next reader what shipped, what did not ship, what evidence supports readiness, and what follow-ups remain.
 
@@ -86,7 +86,7 @@ Read:
 
 - `60-report.md`
 - `50-verify.md`
-- `40-implement.md`
+- `40-execute.md`
 - `20-spec.md`
 - `devflow/context/findings.md`
 - any PR, deploy, merge, or handoff notes already captured
@@ -118,7 +118,7 @@ Prefer clear release-note style wording:
 
 If release readiness changes because unresolved issues are found:
 
-- route back to `50-verify` or `40-implement`
+- route back to `50-verify` or `40-execute`
 
 Do not package unfinished work as release-ready through wording tricks.
 When executing git operations:
@@ -148,7 +148,7 @@ Report:
 - Classification: Mainline workflow
 - Previous state: `60-report`
 - Next state: End of the mainline run when release packaging or handoff is complete
-- Common companion commands: `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
+- Common companion commands: `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`, `overview`
 - Support skills: `resolving-merge-conflicts`, `handoff`, and `setup-pre-commit` when release packaging needs conflict resolution, transfer notes, or local quality gates
 
 ## Sources
@@ -156,21 +156,22 @@ Report:
 - `AGENTS.md`
 - `docs/workspace-artifacts.md`
 - `.agent/resources/schemas/release.template.md`
-- Related commands: `60-report`, `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
+- Related commands: `60-report`, `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`, `overview`
 
 ## Next Workflow Recommendation
 
-- **Primary**: End of Timeline flow
+- **Primary**: End of Timeline flow (or run `/overview` to sync living project context)
 - **Why**: The report is already complete, and this phase is the final release-facing execution step.
 - **Alternatives**:
+  - `overview` - choose this to immediately sync newly shipped capabilities into `devflow/context/project-overview.md`.
   - `60-report` - choose this when the release package diverges from the approved report and the summary must be refreshed first.
   - `50-verify` - choose this when release readiness becomes uncertain.
-  - `40-implement` - choose this when additional fixes are needed before release can proceed.
+  - `40-execute` - choose this when additional fixes are needed before release can proceed.
   - `handoff` - choose this when release-ready context must move to another session, agent, or stakeholder packet.
 
 ## Nexus Event
 
-- Use `Commit`, `PR`, `Deploy`, `Merge`, or `Changelog` when release execution still needs a concrete lane.
+- Use `Commit`, `PR`, `Deploy`, `Merge`, `Changelog`, or `overview` when release execution still needs a concrete lane.
 - Return to `60-report` when release notes, scope, or handoff wording diverge from the approved summary.
-- Return to `50-verify` or `40-implement` when release readiness changes because unresolved issues are discovered.
+- Return to `50-verify` or `40-execute` when release readiness changes because unresolved issues are discovered.
 

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

@@ -92,7 +92,7 @@ The following former narrow agents are now skills. Invoke them through the respo
 
 Specialist agents must use the DevFlow 2.0 stage-first contract:
 
-- Prefer `00-discover.md`, `10-define.md`, `20-spec.md`, `30-plan.md`, `40-implement.md`, `50-verify.md`, `70-release.md`, and `60-report.md` as the primary artifacts.
+- Prefer `00-discover.md`, `10-define.md`, `20-spec.md`, `30-plan.md`, `40-execute.md`, `50-verify.md`, `70-release.md`, and `60-report.md` as the primary artifacts.
 - Do not silently rewrite legacy JSON artifacts.
 - If migration work still requires JSON, prefer CLI-backed minimal updates instead of full-file rewrites.
 - If the specialist is only reviewing, recommend exact commands instead of mutating artifacts.
@@ -145,7 +145,7 @@ Short reports can be returned directly in chat.
 - Classification: Companion command
 - Mainline status: Specialist invocation command, not a numbered stage
 - Typical entry points: any stage that needs focused specialist judgment
-- Typical handoff targets: return to the owning workflow such as `10-define`, `20-spec`, `30-plan`, `40-implement`, `50-verify`, `60-report`, `70-release`
+- Typical handoff targets: return to the owning workflow such as `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`
 
 ## Sources
 
@@ -156,7 +156,7 @@ Short reports can be returned directly in chat.
 
 ## Next Workflow Recommendation
 
-- **Primary**: the workflow that owns the target's lifecycle, such as `10-define`, `20-spec`, `30-plan`, `40-implement`, `50-verify`, `60-report`, `70-release`, or `PR-Review`.
+- **Primary**: the workflow that owns the target's lifecycle, such as `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`, or `PR-Review`.
 - **Why**: `Agent` supplies specialist judgment; the owning workflow should execute the next lifecycle step.
 - **Alternatives**:
   - `Research` when the specialist work uncovered unresolved external uncertainty

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

@@ -14,9 +14,9 @@ devflow  ->  [autopilot]  ->  review packet  ->  70-release
                report)
 ```
 
-Autopilot is an explicit opt-in execution skill for Nexus-DevFlow 2.0. It runs a single bounded loop across the delivery lifecycle (**`20-spec` -> `30-plan` -> `40-implement` -> `50-verify` -> `60-report`**) without requiring human confirmation between every sub-step.
+Autopilot is an explicit opt-in execution skill for Nexus-DevFlow 2.0. It runs a single bounded loop across the delivery lifecycle (**`20-spec` -> `30-plan` -> `40-execute` -> `50-verify` -> `60-report`**) without requiring human confirmation between every sub-step.
 
-It does **not** replace the normal step-by-step workflow. Mainline commands (`20-spec`, `30-plan`, `40-implement`, `50-verify`, `60-report`, `70-release`) remain the conservative default.
+It does **not** replace the normal step-by-step workflow. Mainline commands (`20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`) remain the conservative default.
 
 Do not suggest Autopilot as the default next action. Use it only when the user explicitly asks for it.
 
@@ -34,7 +34,7 @@ Common forms:
 If the requested target conflicts with a run already in progress, stop and ask which one should win. Do not overwrite active stage artifacts silently.
 
 > [!IMPORTANT]
-> Rollback is intentionally excluded from Autopilot. If the request is a rollback or the stage is marked Rollback, stop and direct the user to `rollback` and reviewed `40-implement`. Reversing completed work requires explicit dependency and human review gates.
+> Rollback is intentionally excluded from Autopilot. If the request is a rollback or the stage is marked Rollback, stop and direct the user to `rollback` and reviewed `40-execute`. Reversing completed work requires explicit dependency and human review gates.
 
 ---
 
@@ -82,7 +82,7 @@ Stop before changing files when:
 
 ---
 
-## Step 4 - Implement in Small Increments (`40-implement`)
+## Step 4 - Implement in Small Increments (`40-execute`)
 
 Work through the implementation checklist in order. Each step must remain reviewable.
 
@@ -99,7 +99,7 @@ For every subtask:
    git add <modified-files> devflow/runs/{running-id}-{slug}/checklists/implementation-checklist.md
    git commit -m "feat({running-id}): checkpoint <concise step description>"
    ```
-8. Write `devflow/runs/{running-id}-{slug}40-implement.md`.
+8. Write `devflow/runs/{running-id}-{slug}40-execute.md`.
 
 ---
 
@@ -161,7 +161,7 @@ When Autopilot finishes successfully, output a scannable review packet:
 - **Artifacts Generated**:
   - Spec: `devflow/runs/{id}20-spec.md`
   - Plan: `devflow/runs/{id}30-plan.md`
-  - Implement Evidence: `devflow/runs/{id}40-implement.md`
+  - Implement Evidence: `devflow/runs/{id}40-execute.md`
   - QA Verify Report: `devflow/runs/{id}50-verify.md`
   - Digest Report: `devflow/runs/{id}60-report.md`
   - HTML Dashboard: `devflow/runs/{id}60-report.html`

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

@@ -145,7 +145,7 @@ Brainstorm caching strategy
 - Honest tradeoffs over fake confidence
 - Multiple viable paths before recommending one
 - Persistent output saved to disk
-- Mainline remains: `00-discover -> 10-define -> 20-spec -> 30-plan -> 40-implement -> 50-verify -> 60-report -> 70-release`
+- Mainline remains: `00-discover -> 10-define -> 20-spec -> 30-plan -> 40-execute -> 50-verify -> 60-report -> 70-release`
 
 ## Relationship To DevFlow 2.0
 

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

@@ -8,7 +8,7 @@ description: "[Devflow] Read-only scope, dependency, and risk pre-briefing befor
 Where this sits in the workflow:
 
 ```text
-10-define or project-overview.md  ->  [brief]  ->  20-spec  ->  30-plan  ->  40-implement
+10-define or project-overview.md  ->  [brief]  ->  20-spec  ->  30-plan  ->  40-execute
 (proposed scope & context)            (read-only   (write        (break down)  (build it)
                                       explainer)    contract)
 ```

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

@@ -0,0 +1,68 @@
+---
+name: check
+description: "[Devflow] Fast-Track Check stage in DevFlow (Blueprint Mode) - perform senior QA review, run multi-lane verification, and record evidence in spec.md."
+argument-hint: "{running-id or workspace path}"
+---
+
+# Fast-Track: Check (Blueprint Mode)
+
+$ARGUMENTS
+
+Quality assurance and multi-lane verification stage in Fast-Track. Validates the implementation against Acceptance Criteria, runs test suites, checks for regressions, and records evidence in the Single Living Spec (`spec.md`).
+
+## Invocations & Aliases
+
+- `/check`: Run verification on current active run
+- `/check {running-id}`: Run verification on specified running ID
+- `$check`: 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 `## 1. Specification & Scope` (Acceptance Criteria) and `## 3. Implementation Checklist`.
+
+### 2. Multi-lane Verification Execution
+Execute the verification gates across all lanes:
+1. **Lane 1 (Type & Syntax Safety)**:
+   - Run typecheck and linting (e.g. `npm run typecheck`, `npm run lint`).
+2. **Lane 2 (Test Suites & Coverage)**:
+   - Run automated unit and integration tests (e.g. `npm test`).
+3. **Lane 3 (Manual / Scenario Proof)**:
+   - Verify specific scenarios against Acceptance Criteria (`AC-1`, `AC-2`).
+   - Summarize "Where to go", "What to click/call", and "What to expect".
+
+### 3. Update Living Spec (`spec.md`)
+Append or update `## 5. Verification Evidence` in `spec.md` in **Thai (`th`)**:
+
+```markdown
+## 5. Verification Evidence
+- **Typecheck & Linter**: Passed (0 errors, 0 warnings)
+- **Automated Test Suites**: All tests passed (e.g. 12/12 passed, 0 failed)
+- **Acceptance Criteria Verification**:
+  - [x] AC-1: {ผลการตรวจสอบเงื่อนไขที่ 1 ผ่าน 100%}
+  - [x] AC-2: {ผลการตรวจสอบเงื่อนไขที่ 2 ผ่าน 100%}
+- **Manual Verification Guide**:
+  - *Where to go*: `http://localhost:3000/api/auth`
+  - *Action*: Send POST request with test credentials
+  - *Expected Result*: Received HTTP 200 with valid JWT token
+```
+
+### 4. Update Workspace Status
+Update `devflow/context/current-stage.md`:
+- `Current Stage`: `check (Fast-Track -> Verification Passed -> Ready for /complete)`
+
+### 5. Output Summary & Next Step
+Report to the user:
+- Summary of verification results across all lanes
+- Evidence recorded in `spec.md`
+- **Next Command**: `/complete` (or `/complete {RUNNING_ID}`)

package/template/.agents/skills/codebase-design/SKILL.md

@@ -5,7 +5,7 @@ description: "[Devflow] Shared vocabulary for designing deep modules. Use when a
 
 # Codebase Design
 
-Use this support skill when `20-spec`, `30-plan`, `40-implement`, or `50-verify` needs better module shape.
+Use this support skill when `20-spec`, `30-plan`, `40-execute`, or `50-verify` needs better module shape.
 
 Design deep modules: a lot of behavior behind a small interface, placed at a clean seam, and testable through that interface. The aim is leverage for callers, locality for maintainers, and behavior-focused tests.
 
@@ -13,7 +13,7 @@ Design deep modules: a lot of behavior behind a small interface, placed at a cle
 
 - `20-spec`: use when requirements depend on a stable module or interface contract.
 - `30-plan`: use when planning needs file-level architecture, seams, or dependency strategy.
-- `40-implement`: use when implementation reveals shallow modules or awkward test seams.
+- `40-execute`: use when implementation reveals shallow modules or awkward test seams.
 - `50-verify`: use when review finds code that is hard to test, hard to change, or too spread out.
 
 ## Vocabulary

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

@@ -55,5 +55,5 @@ Each commit should represent one atomic, self-contained change:
 ## Relationship To DevFlow 2.0
 
 - **Classification**: Companion command & Version control support
-- **Mainline integration**: Used during `40-implement` (checkpoint commits), `70-release` (final release commit).
+- **Mainline integration**: Used during `40-execute` (checkpoint commits), `70-release` (final release commit).
 - **Handoff**: `pr`, `merge`, `70-release`