@jakkrichm/create-nexus-devflow 2.0.0 → 2.0.1

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

@@ -1,26 +1,26 @@
 ---name: 40-implement
-
-description: Implement code in DevFlow 2.0 - execute one planned unit at a time with markdown-first implementation evidence.
----
-# Phase 40: Implement Code
-
-Implement the approved plan incrementally. Source code edits are allowed in this phase.
-
-## Usage
-
-```text
-/40-Implement {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 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.
-
+
+description: Implement code in DevFlow 2.0 - execute one planned unit at a time with markdown-first implementation evidence.
+---
+# Phase 40: Implement Code
+
+Implement the approved plan incrementally. Source code edits are allowed in this phase.
+
+## Usage
+
+```text
+/40-Implement {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 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.
+
 ## Required Section Content
 
 Before completing any generated artifact:
@@ -34,133 +34,133 @@ Before completing any generated artifact:
 - re-read the saved artifact and verify every heading satisfies this rule
 
 ## Process
-
-### Loop Contract
-
-Run implementation 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.
-- **Action**: make the smallest useful change for the current unit, update or create tests when required, run the planned verification, and record the result.
-- **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.
-
-### 1. Get Bearings
-
-Read:
-
-- `30-plan.md`
-- `20-spec.md`
-- `checklists/implementation-checklist.md` when present
-- referenced pattern files
-- `10-define.md` when the intent needs a quick reminder
-
-Confirm the current Git branch with `git branch --show-current` and use that branch as the user's chosen working branch. Do not create, switch, or checkout branches automatically.
-
-Select one scoped unit of work at a time. Do not implement the whole plan as one blob.
-
-### 2. Implement One Scoped Unit
-
-Use the original coder discipline, adapted to 2.0:
-
-- **STRICT MANDATE (กฎเหล็ก Unit Test)**: ต้องสร้าง/แก้ไข Unit Test ควบคู่กับการแก้ไขโค้ดเสมอ โดยห้ามแก้ไขเฉพาะไฟล์โค้ดหลัก (Production Code) โดยไม่แก้ไขหรือสร้างไฟล์เทสต์ควบคู่กัน
-- start each scoped unit by naming its intent, context, expected observation, adjustment route, and stop condition
-- read referenced pattern files before editing
-- read the test decision from `30-plan.md`
-- confirm assumptions, target files, and success criteria before editing
-- 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`
-- update checklist item status, timestamps, and evidence links as work progresses
-
-If tests are `Required`:
-
-1. **TDD Cycle (RED)**: ออกแบบและเขียนตัวเทสต์ให้พังก่อน (หรือเขียนโครงสร้างเทสต์ที่คาดหวังผลลัพธ์ที่ถูกต้อง) ตามแนวทางของ [test-driven-development](file:///.agents/skills/test-driven-development/SKILL.md)
-2. **GREEN**: เขียนโค้ดระบบจริงให้สอดคล้องเพื่อให้เทสต์ผ่าน
-3. **REFACTOR**: ปรับปรุงโครงสร้างโค้ดโดยยังคงรันเทสต์ผ่านอย่างต่อเนื่อง
-
-### 3. Recovery
-
-Use the old recovery discipline when blocked:
-
-- capture the blocker with evidence
-- mark failure only when the current unit truly cannot continue
-- recommend `Debug` when root cause analysis is needed
-- return to Plan when the work no longer matches the plan
-
-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
-
-When the scoped work is complete:
-
-- summarize the completed units
-- list changed files
-- 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
-
-### 5. Manual Review Soft Gate
-
-If the plan was not clearly approved, warn that implementation proceeded under review risk.
-When finishing `40-implement.md`:
-
-- record any deviation from the approved plan explicitly
-- set reviewer expectations before `/50-Verify`
-- keep `/50-Verify` as the next soft recommendation rather than an unconditional jump
-
-## Output
-
-Report:
-
-- scoped units completed
-- files changed
-- verification commands run
-- test decisions followed or changed, with reasons
-- loop evidence and handoff notes for Verify
-- blocked items or manual checks
-- next command: `/50-Verify {ID}`
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `/30-Plan`
-- Next state: `/50-Verify` when scoped implementation 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
-
-- **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.
-  - `/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.
-
-## Nexus Event
-
-- 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.
-
-## 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`
-
+
+### Loop Contract
+
+Run implementation 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.
+- **Action**: make the smallest useful change for the current unit, update or create tests when required, run the planned verification, and record the result.
+- **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.
+
+### 1. Get Bearings
+
+Read:
+
+- `30-plan.md`
+- `20-spec.md`
+- `checklists/implementation-checklist.md` when present
+- referenced pattern files
+- `10-define.md` when the intent needs a quick reminder
+
+Confirm the current Git branch with `git branch --show-current` and use that branch as the user's chosen working branch. Do not create, switch, or checkout branches automatically.
+
+Select one scoped unit of work at a time. Do not implement the whole plan as one blob.
+
+### 2. Implement One Scoped Unit
+
+Use the original coder discipline, adapted to 2.0:
+
+- **STRICT MANDATE (กฎเหล็ก Unit Test)**: ต้องสร้าง/แก้ไข Unit Test ควบคู่กับการแก้ไขโค้ดเสมอ โดยห้ามแก้ไขเฉพาะไฟล์โค้ดหลัก (Production Code) โดยไม่แก้ไขหรือสร้างไฟล์เทสต์ควบคู่กัน
+- start each scoped unit by naming its intent, context, expected observation, adjustment route, and stop condition
+- read referenced pattern files before editing
+- read the test decision from `30-plan.md`
+- confirm assumptions, target files, and success criteria before editing
+- 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`
+- update checklist item status, timestamps, and evidence links as work progresses
+
+If tests are `Required`:
+
+1. **TDD Cycle (RED)**: ออกแบบและเขียนตัวเทสต์ให้พังก่อน (หรือเขียนโครงสร้างเทสต์ที่คาดหวังผลลัพธ์ที่ถูกต้อง) ตามแนวทางของ [test-driven-development](file:///.agents/skills/test-driven-development/SKILL.md)
+2. **GREEN**: เขียนโค้ดระบบจริงให้สอดคล้องเพื่อให้เทสต์ผ่าน
+3. **REFACTOR**: ปรับปรุงโครงสร้างโค้ดโดยยังคงรันเทสต์ผ่านอย่างต่อเนื่อง
+
+### 3. Recovery
+
+Use the old recovery discipline when blocked:
+
+- capture the blocker with evidence
+- mark failure only when the current unit truly cannot continue
+- recommend `Debug` when root cause analysis is needed
+- return to Plan when the work no longer matches the plan
+
+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
+
+When the scoped work is complete:
+
+- summarize the completed units
+- list changed files
+- 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
+
+### 5. Manual Review Soft Gate
+
+If the plan was not clearly approved, warn that implementation proceeded under review risk.
+When finishing `40-implement.md`:
+
+- record any deviation from the approved plan explicitly
+- set reviewer expectations before `/50-Verify`
+- keep `/50-Verify` as the next soft recommendation rather than an unconditional jump
+
+## Output
+
+Report:
+
+- scoped units completed
+- files changed
+- verification commands run
+- test decisions followed or changed, with reasons
+- loop evidence and handoff notes for Verify
+- blocked items or manual checks
+- next command: `/50-Verify {ID}`
+
+## Relationship To DevFlow 2.0
+
+- Classification: Mainline workflow
+- Previous state: `/30-Plan`
+- Next state: `/50-Verify` when scoped implementation 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
+
+- **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.
+  - `/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.
+
+## Nexus Event
+
+- 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.
+
+## 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`
+