@jakkrichm/create-nexus-devflow 2.0.0

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

@@ -0,0 +1,166 @@
+---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.
+
+## Required Section Content
+
+Before completing any generated artifact:
+
+- preserve every heading required by the selected template
+- write concrete information under every heading
+- when no information exists or the section does not apply, write exactly `-`
+- never leave a heading immediately followed by another heading with no body content
+- remove template placeholders from the final artifact
+- do not invent facts merely to avoid using `-`
+- 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`
+

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

@@ -0,0 +1,188 @@
+---name: 50-verify
+
+description: Verify quality in DevFlow 2.0 - perform senior QA review, record evidence, and decide pass or return-to-implement.
+---
+# Phase 50: Verify Quality
+
+Review implementation quality, run validation, produce a verification report, and route the task forward or back to implementation.
+
+## Usage
+
+```text
+/50-Verify {ID}
+```
+
+## Markdown-First Contract
+
+Use `50-verify.md` as the primary verification artifact.
+Use `50-verify-impact.md` as an optional companion artifact when the run changes behavior, touches core logic, crosses integration boundaries, or needs explicit rollback and client impact analysis.
+Before writing either verification artifact, read `artifact_language` from the matching template and produce the markdown output in that language.
+
+Use these commands only to keep workflow status aligned with the task engine:
+
+Record verification start, results, open issues, and approval direction directly in `50-verify.md`. Use the stage markdown itself to indicate whether the work is ready for human review or needs to return to implementation.
+If an impact report is needed, create it in the same task directory and summarize its conclusions from `50-verify.md`.
+Keep the verification checklist aligned with the same soft-gate state so downstream report and release stages can see the current approval direction without re-reading the full verify narrative.
+
+## Required Section Content
+
+Before completing any generated artifact:
+
+- preserve every heading required by the selected template
+- write concrete information under every heading
+- when no information exists or the section does not apply, write exactly `-`
+- never leave a heading immediately followed by another heading with no body content
+- remove template placeholders from the final artifact
+- do not invent facts merely to avoid using `-`
+- re-read the saved artifact and verify every heading satisfies this rule
+
+## Process
+
+### Loop Contract
+
+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.
+- **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.
+- **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.
+
+### 1. Context Gathering
+
+Read:
+
+- `20-spec.md`
+- `30-plan.md`
+- `40-implement.md`
+- `checklists/verification-checklist.md` when present
+- changed files
+- test output, command output, screenshots, or manual-check evidence
+
+### 2. Artifact Gate
+
+Run the necessary validation for the current state before doing the full review.
+
+### 3. QA Review
+
+Use the old QA reviewer discipline, adapted to 2.0:
+
+- **STRICT MANDATE (กฎเหล็ก Unit Test)**: ตรวจสอบว่าโค้ดใหม่หรือการแก้ไข Bug (ที่มี behavior change) มีการสร้างหรืออัปเดต Unit Test คู่กันมาด้วยหรือไม่ หากไม่มีให้ทำเครื่องหมายว่า FAIL ทันที
+- compare claimed implementation evidence against the spec, plan, diff, and test decisions before forming a verdict
+- correctness
+- readability
+- architecture (DIP, SRP, Loose Coupling)
+- security
+- performance
+- test coverage (และตรวจสอบว่าไม่มีการ skip หรือ disable เทสต์)
+- test decision alignment
+- manual verification gaps
+- assumptions and scope discipline
+
+Run project validation commands when available: lint, tests, typecheck, build, or targeted commands from the plan.
+
+For test-decision alignment, verify that planned verification was actually executed and that the evidence matches the claimed result.
+Use `review` for a two-axis standards/spec review, `diagnosing-bugs` when a failure needs root cause analysis, and `silent-failure-audit` when the risk is false-positive success.
+
+### 4. Verification Report
+
+Create or update `50-verify.md` in the task directory.
+Create or update `50-verify-impact.md` when the run includes behavior changes, client-facing flow changes, integration risk, or rollback considerations worth reviewing separately.
+
+Base the structure on:
+
+```text
+.agent/resources/schemas/verify.template.md
+.agent/resources/schemas/verify-impact.template.md
+```
+
+Before reporting completion, validate the markdown and replace all placeholders with concrete command output, manual checks, failures, screenshots, and residual risks.
+Follow the `artifact_language` configured in the selected template for both `50-verify.md` and `50-verify-impact.md`.
+
+Include:
+
+- verdict: pass or fail
+- evidence: commands and results
+- loop observation, adjustment, stop condition, and handoff notes
+- test-decision alignment
+- checklist alignment and any stale status corrections
+- approval gate summary copied into the verification checklist when relevant
+- findings grouped by severity
+- manual checks required
+- recommended next action
+- impact report summary or explicit note that no impact report was needed
+
+### 5. Decision
+
+**STRICT GATING (CRITICAL FAIL)**: หากพบว่าไม่มีการสร้าง/แก้ไข Unit Test ตามกฎ Unit Test Mandate หรือรันเทสต์แล้วไม่ผ่านทั้งหมด **บังคับให้ตัดสินเป็น FAIL ทันที**
+
+If pass:
+
+- route to `/60-Report`
+
+If fail:
+
+- route back to `/40-Implement` with exact failed evidence, missing checks, or required changes
+
+Use `Debug` when investigation is needed before implementation can resume.
+
+### 6. Manual Review Soft Gate
+
+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`
+- keep `/60-Report` as a soft recommendation only
+
+## Output
+
+Report:
+
+- QA verdict
+- key findings
+- 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
+
+## Relationship To DevFlow 2.0
+
+- Classification: Mainline workflow
+- Previous state: `/40-Implement`
+- 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
+
+## Sources
+
+- `AGENTS.md`
+- `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`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/60-Report {ID}` when verification passes, or `/40-Implement {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.
+  - `review` - choose this when changed work needs standards and spec review as separate axes.
+  - `Wiki project ingest devflow/runs/{ID}-*/50-verify.md` - choose this when verification reveals reusable project knowledge.
+
+## Nexus Event
+
+- Use `Debug` when failures need deeper investigation before rework.
+- Use `PR-Review`, `QA-Orchestrate`, or `Agent code-reviewer` when a narrower review lane would change the verification decision quality.
+- Use `Wiki` when verified findings should become reusable project knowledge before the run continues.
+
+## Wiki Update Recommendation
+
+- **Needed**: `yes` when QA confirms a reusable lesson, regression pattern, manual check, or validation command.
+- **Scope**: `project` unless QA reveals a DevFlow framework rule.
+- **Reason**: Verified QA evidence is one of the safest sources for project wiki updates.
+- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*/50-verify.md`
+

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

@@ -0,0 +1,183 @@
+---name: 60-report
+
+description: Report stage in DevFlow 2.0 - produce the final standardized markdown and HTML summary for the full running flow.
+argument-hint: "{running-id or workspace path}"
+---
+
+# Phase 60: Report
+
+$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.
+
+## Usage
+
+```text
+/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:
+
+```text
+devflow/runs/{ID}-{slug}/60-report.md
+devflow/runs/{ID}-{slug}/60-report.html
+```
+
+using:
+
+```text
+.agent/resources/schemas/report.template.md
+```
+
+Before writing `60-report.md`, read `artifact_language` from `report.template.md` and produce the markdown artifact in that language.
+
+## Required Section Content
+
+Before completing any generated artifact:
+
+- preserve every heading required by the selected template
+- write concrete information under every heading
+- when no information exists or the section does not apply, write exactly `-`
+- never leave a heading immediately followed by another heading with no body content
+- remove template placeholders from the final artifact
+- do not invent facts merely to avoid using `-`
+- re-read the saved artifact and verify every heading satisfies this rule
+
+## Process
+
+### Loop Contract
+
+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.
+- **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.
+- **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.
+
+### 1. Gather Full Run Context
+
+Read all relevant stage artifacts:
+
+- the shared `00-discover.md` referenced by `source_discovery` when it materially explains the delivery decision
+- `10-define.md`
+- `20-spec.md`
+- `30-plan.md`
+- `40-implement.md`
+- `50-verify.md`
+- `checklists/implementation-checklist.md` when present
+- `checklists/verification-checklist.md` when present
+
+Include supporting artifacts only when they add real context.
+
+### 2. Summarize The Run
+
+Explain:
+
+- what problem was addressed
+- what direction was chosen
+- what was implemented
+- how it was verified
+- how checklist progress moved across the run
+- what approval or review state remained at each important gate
+- what the release recommendation is
+- what follow-up items still exist
+
+### 3. Produce Standardized Outputs
+
+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.
+
+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.
+
+Both outputs should summarize checklist state when checklist artifacts exist, including:
+
+- completion progress
+- blocked or skipped items
+- notable evidence snapshots
+- 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:
+
+- 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>
+```
+
+## 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`
+
+## 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.