@jakkrichm/create-nexus-devflow 2.2.1 → 2.5.0

package/template/.claude/skills/40-execute/SKILL.md

@@ -1,161 +0,0 @@
----
-name: 40-execute
-description: "[devflow][D] Execute stage in DevFlow 2.0 - execute planned tasks incrementally with evidence and unit tests."
----
-# Phase 40: Execute Code
-
-Implement and execute the approved plan incrementally. Source code edits are allowed in this phase.
-
-## Usage
-
-```text
-40-execute {ID}
-```
-
-## Markdown-First Contract
-
-Use `40-execute.md` as the primary execution artifact.
-Before writing `40-execute.md`, produce the artifact in Thai (`th`).
-
-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
-
-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 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.
-- **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-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
-
-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. Execute 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-execute.md`
-- update checklist item status, timestamps, and evidence links as work progresses
-
-If tests are `Required`:
-
-1. **TDD Cycle (RED)**: ออกแบบและเขียนตัวเทสต์ให้พังก่อน (หรือเขียนโครงสร้างเทสต์ที่คาดหวังผลลัพธ์ที่ถูกต้อง) ตามแนวทางใน [coding-standards.md](file:///devflow/context/coding-standards.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 Execution
-
-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
-- make sure checklist statuses match the actual state of the code and tests
-- make sure `40-execute.md` is ready for Verify
-
-### 5. Manual Review Soft Gate
-
-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`
-- 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 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`
-- 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 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.
-
-## 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 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-execute.md`

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

@@ -1,55 +0,0 @@
----
-name: 50-verify
-description: "[devflow][D] Verify stage 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 multi-lane 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.
-
-## Process & Quality Gates
-
-### 1. Senior QA Review & Multi-Lane Verification
-
-Execute verification across all essential quality dimensions:
-
-1. **Lane 1: Typecheck & Static Code Quality**:
-   - Run typecheck and static analysis (`tsc --noEmit`, `npm run lint`).
-2. **Lane 2: Automated Test Suites (TDD Gate)**:
-   - Run automated unit and integration tests (`npm test`).
-   - Confirm 100% test pass rate with zero disabled or skipped tests.
-3. **Lane 3: Scrutinize QA & Edge Cases Review**:
-   - **Boundary Conditions**: Check empty inputs, 0/1 counts, off-by-one errors.
-   - **Null / Undefined Safety**: Verify nullish handling and strict type invariants.
-   - **Error Handling & Propagation**: Verify errors provide actionable diagnostics without swallowing.
-4. **Lane 4: Security & Hygiene Audit**:
-   - **Secrets Check**: Ensure no hardcoded credentials or API keys exist.
-   - **Input Sanitization**: Ensure parameterized queries and validated inputs.
-5. **Lane 5: Findings Ledger State Machine (`findings.md`)**:
-   - Inspect `devflow/context/findings.md`.
-   - **P0/P1 HARD GATE**: Any Finding of severity `P0` or `P1` in `open` or `fixed` status unconditionally blocks pass.
-6. **Lane 6: Manual Scenario Proof**:
-   - Provide clear manual verification instructions: "Where to go", "What to run/click", "What to expect".
-
-### 2. Decision & Route
-
-- **Pass**: Route to `60-report {ID}`.
-- **Fail**: Route back to `40-execute {ID}` with exact failure evidence and remediation steps.
-
-## Output
-
-Report:
-- QA verdict across all verification lanes
-- Evidence commands and outputs
-- Next command: `60-report {ID}` (if pass) or `40-execute {ID}` (if fail)

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

@@ -1,57 +0,0 @@
----
-name: 60-report
-description: "[devflow][D] Report stage in DevFlow 2.0 - produce standardized markdown summary report with retrospective lessons learned."
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 60: Report
-
-$ARGUMENTS
-
-Produce the final human-friendly summary of the full running flow in Markdown (`60-report.md`) with retrospective lessons learned, findings summary, and release digest.
-
-## Usage
-
-```text
-60-report {running-id or workspace path}
-```
-
-## Markdown-First Contract
-
-Write the primary stage artifact to:
-
-```text
-devflow/context/current-run/60-report.md
-```
-
-> [!IMPORTANT]
-> **No Auto-Generated HTML**: ห้ามสร้างไฟล์ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้! ระบบจะสร้างเฉพาะ `60-report.md` เท่านั้น หากต้องการดู HTML Report ให้เรียกคำสั่งแยก: `/report:html`
-
-## Process
-
-### 1. Gather Full Run Context & Verification Evidence
-Read all relevant stage artifacts:
-- `10-define.md`
-- `20-spec.md`
-- `30-plan.md`
-- `40-execute.md`
-- `50-verify.md`
-
-### 2. Retrospective Lessons Learned & Gotchas (Insight Extraction)
-Extract durable insights from the completed run:
-- **Reusable Patterns**: Design choices or implementations that future runs should mirror.
-- **Gotchas & Pitfalls**: Unforeseen issues or quirks encountered during execution.
-- **Unresolved Follow-ups**: Route any residual out-of-scope ideas to `devflow/ideas.md`.
-
-### 3. Produce Standardized Report (`60-report.md`)
-Structure the report in **Thai (`th`)**:
-1. **Executive Summary**: ปัญหาและแนวทางแก้ไข
-2. **Delivery Scope**: รายการฟีเจอร์และคอมโพเนนต์ที่ส่งมอบ
-3. **Verification Evidence Snapshot**: ผลการทดสอบทุก Lane
-4. **Retrospective & Lessons Learned**: บทเรียนและข้อควรระวัง
-5. **Manual Try Guide**: ขั้นตอนสำหรับมนุษย์ทดสอบระบบ
-
-## Next Workflow Recommendation
-
-- **Primary**: `70-deliver {ID}`
-- **Optional Standalone HTML**: `/report:html`

package/template/.claude/skills/70-deliver/SKILL.md

@@ -1,72 +0,0 @@
----
-name: 70-deliver
-description: "[devflow][D] Deliver stage in DevFlow 2.0 - package verified work for delivery, archive run to categorized history, git merge, PR, or deployment."
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 70: Deliver
-
-$ARGUMENTS
-
-Package approved work for delivery after the report stage has captured the final verified story. Archives the active run from `devflow/context/current-run/` to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}/`, updates `HISTORY.md` and `CHANGELOG.md`, executes pre-flight smoke checks, performs conventional git commit & merge, and closes the run.
-
-## Usage
-
-```text
-70-deliver {id or workspace path}
-```
-
-## Markdown-First Contract
-
-Write the primary stage artifact to:
-
-```text
-devflow/context/current-run/70-deliver.md
-```
-
-## Process & Quality Gates
-
-### 0. Step 0 Safety Pass & Findings Ledger Gate
-
-Before packaging, merging, or delivering:
-
-1. **Findings Ledger Blockers**:
-   - Inspect `devflow/context/findings.md`.
-   - No Finding of severity `P0` or `P1` in `open` or `fixed` status is permitted.
-   - `fixed` still blocks release until reviewed and closed in `50-verify`.
-2. **Pre-flight & Deployment Smoke Validation**:
-   - Verify environment variables and configuration parameters.
-   - Run production build or package smoke check (`npm run build` or `npm run test:package`).
-   - Validate that clean state exists with no untracked experimental files.
-3. **2-Stage Approval Separation**:
-   - Consent to merge into `main` is strictly separate from consent to `git push` to remote or deploy.
-
-### 1. Changelog & SemVer Version Bump
-
-1. Calculate next version according to **Semantic Versioning (SemVer)**:
-   - `Major`: Breaking architectural changes, removed public APIs
-   - `Minor`: New backward-compatible features added
-   - `Patch`: Bug fixes, optimizations, documentation
-2. Append new release entry to `CHANGELOG.md` in [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format (`Added`, `Changed`, `Fixed`, `Removed`, `Security`).
-
-### 2. Conventional Commit & Git Merge
-
-1. Stage all release and tracking files.
-2. Commit with conventional format: `chore(release): release {version}` or `feat({scope}): {summary}`.
-3. Squash-merge to base branch (`main`) with explicit user approval.
-
-### 3. Archive Run Folder to Categorized History
-
-1. Determine Category (`features`, `fixes`, `rollbacks`).
-2. Move directory `devflow/context/current-run/` ➔ `devflow/history/{category}/{xxx-slug}/`.
-3. Clean resolved findings (`closed`, `accepted`, `invalid`) from `devflow/context/findings.md` and append to the release notes.
-4. Append entry to `devflow/history/HISTORY.md` linking to `history/{category}/{xxx-slug}/60-report.md`.
-
-### 4. Update Workspace State
-
-Set `devflow/context/current-stage.md` to:
-- `Active Discovery ID`: `None`
-- `Active Running ID`: `None (Idle)`
-- `Current Stage`: `Idle (Ready for new run)`
-- `Last Completed Run`: `{ID} ({YYYY-MM-DD})`
-- `Last Updated`: `{YYYY-MM-DD}`