@jakkrichm/create-nexus-devflow 2.2.1 → 2.5.0

package/template/.agents/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/.agents/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}`

package/template/.claude/skills/10-define/SKILL.md

@@ -1,54 +0,0 @@
----
-name: 10-define
-description: "[devflow][D] Define stage in DevFlow 2.0 - turn an approved discovery into a bounded delivery run in context/current-run with stable scope."
-argument-hint: "{approved discovery-id, discovery path, running-id, or run path}"
----
-
-# Phase 10: Define
-
-$ARGUMENTS
-
-Convert an approved `Proceed` discovery into a bounded delivery run. Checks the Single Active Run Guardrail, allocates a sequential ID without prefix (`xxx-slug`), and writes `devflow/context/current-run/10-define.md`.
-
-## Usage
-
-```text
-10-define {discovery-id or discovery path}
-10-define {id or run path}
-```
-
-## Markdown-First Contract
-
-For the active delivery run, write:
-
-```text
-devflow/context/current-run/10-define.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/define.template.md
-```
-
-## Process & Quality Gates
-
-### 1. Single Active Run Guardrail (One Thing at a Time)
-1. Inspect `devflow/context/current-stage.md`, `devflow/context/current-feature.md`, and `devflow/context/current-run/`.
-2. If an active uncompleted run exists:
-   - **HALT and reject opening a new define stage**.
-   - Warn the user to complete or close the active run with `/complete` or `70-deliver` first.
-
-### 2. Validate The Discovery Gate
-Require:
-- `Decision: Proceed`
-- `Approval Status: Approved`
-- A resolvable Discovery ID and `discovery.md` (or legacy `00-explore.md`)
-
-### 3. Allocate Sequential ID
-- Inspect `devflow/history/HISTORY.md` and allocate sequential ID without prefix (e.g. `022-{slug}`).
-- Create directory `devflow/context/current-run/` if it does not exist.
-- Write `devflow/context/current-run/10-define.md`.
-- Update `devflow/context/current-stage.md`:
-  - `Active Running ID`: `{ID}`
-  - `Current Stage`: `10-define (Completed -> Ready for 20-spec)`

package/template/.claude/skills/20-spec/SKILL.md

@@ -1,155 +0,0 @@
----
-name: 20-spec
-description: "[devflow][D] Spec stage in DevFlow 2.0 - write the formal markdown-first specification from a stable definition."
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 20: Spec
-
-$ARGUMENTS
-
-Turn the defined work into a specification that is concrete enough for planning and explicit enough to serve as the delivery contract.
-
-## Usage
-
-```text
-20-spec {running-id or workspace path}
-```
-
-Use this when:
-
-- the goal and scope are stable
-- the team needs testable or reviewable requirements
-- planning should not start until the contract is explicit
-
-## Markdown-First Contract
-
-Write the primary stage artifact to:
-
-```text
-devflow/runs/{ID}-{slug}20-spec.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/spec.template.md
-```
-
-Before writing `20-spec.md`, read `artifact_language` from `spec.template.md` and produce the 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 specification as a contract-hardening loop, not as a prose expansion of the definition.
-
-- **Intent**: produce requirements and acceptance criteria that are concrete enough for planning and review.
-- **Context**: read the run's `10-define.md`, follow its `source_discovery` link when original framing matters, and read relevant research, hard constraints, and domain or codebase decisions that shape this run's delivery contract.
-- **Action**: write requirements, acceptance criteria, constraints, and out-of-scope items, then inspect whether each requirement is testable and unambiguous.
-- **Observation**: use concrete evidence such as ambiguous wording, unchecked assumptions, edge cases, missing acceptance criteria, conflicting constraints, and implementation details that are not true constraints.
-- **Adjustment**: if facts are missing, route to `Research`; if requirements need stress-testing, use `grill-with-docs`; if module or interface boundaries affect the contract, use `codebase-design`; if scope is unstable or still contains multiple independently deliverable contracts, return to `10-define` and split the run before continuing.
-- **Stop Condition**: stop when every requirement has checkable acceptance criteria, hard constraints are explicit, out-of-scope items are visible, and `30-plan` can break the work down without inventing intent.
-- **Handoff**: `20-spec.md` must tell `30-plan` what must be delivered, how success will be checked, what constraints cannot move, and what is intentionally excluded.
-
-### 1. Read Definition Artifacts
-
-Read:
-
-- `10-define.md`
-- the shared `00-explore.md` referenced by `source_discovery` when the original framing still matters
-- research notes if they impose real constraints
-
-### 2. Write The Specification
-
-Define:
-
-- core requirements
-- acceptance criteria
-- hard constraints
-- explicit out-of-scope items
-
-The spec should be strong enough that planning can break it into executable units without guessing intent.
-
-### 3. Handle Missing Certainty
-
-If the spec cannot be written confidently:
-
-- call `Research` when facts are missing
-- use `grill-with-docs` when requirements, acceptance criteria, constraints, or out-of-scope items need to be stress-tested against scenarios and domain language
-- use `codebase-design` when requirements imply module boundaries, interface contracts, seams, or testability constraints
-- record assumptions explicitly when they are unavoidable
-
-Do not hide uncertainty inside vague requirement text.
-
-Do not combine sibling Running IDs into one spec. If this run still contains multiple independent acceptance, release, ownership, or context boundaries, stop and return to `10-define {running_id}` for an explicit split.
-
-### 4. Finalize `20-spec.md`
-
-- preserve the template headings
-- follow the `artifact_language` configured in `spec.template.md`
-- replace all placeholders
-- keep implementation details out unless they are true constraints
-- make sure the acceptance criteria can actually be checked
-
-### 5. Manual Review Soft Gate
-
-Before recommending `30-plan`, check whether the delivery contract has been human-reviewed.
-If `Approval Status` is not approved yet:
-
-- warn that planning may drift if the spec is still under review
-- recommend review of requirements, exclusions, and acceptance criteria first
-- keep `30-plan` as a soft recommendation only
-
-## Output
-
-Report:
-
-- core requirements
-- acceptance criteria
-- hard constraints
-- out-of-scope items
-- manual review warnings when the contract is still pending
-- recommended next step
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `10-define`
-- Next state: `30-plan` when the contract is implementation-ready
-- Common companion commands: `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate` when product or integration context is still incomplete; support skills: `grill-with-docs`, `domain-modeling`, and `codebase-design` when the spec depends on precise domain language, durable decisions, or module/interface constraints
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/spec.template.md`
-- Related commands: `10-define`, `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate`, `30-plan`
-
-## Next Workflow Recommendation
-
-- **Primary**: `30-plan`
-- **Why**: The specification is now concrete enough to break into executable work.
-- **Alternatives**:
-  - `Research` - choose this when the spec still depends on missing facts.
-  - `grill-with-docs` - choose this when the spec is readable but not yet tough enough to plan from.
-  - `codebase-design` - choose this when interface shape or testability constraints must be settled before planning.
-  - `10-define` - choose this when the scope itself is still unstable.
-
-## Nexus Event
-
-- Use `Research` when a requirement, rule, or integration constraint still lacks evidence.
-- Use `Spec-Research`, `Competitor`, or `PRD` when the contract needs stronger external, product, or market framing before planning.
-- Use `grill-with-docs` when available if clarification could materially change acceptance criteria, edge cases, exclusions, or rules.

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

@@ -1,220 +0,0 @@
----
-name: 30-plan
-description: "[devflow][D] Plan stage in DevFlow 2.0 - transform 20-spec.md into an executable task breakdown with test decisions."
----
-# Phase 30: Plan Implementation
-
-**Strict mode: planning only. Do not edit source code in this phase.**
-
-Create a codebase-informed implementation plan using `30-plan.md` as the primary artifact in DevFlow 2.0.
-
-## Usage
-
-```text
-30-plan {ID}
-```
-
-## Markdown-First Contract
-
-Use `30-plan.md` as the main planning artifact.
-
-Use controlled task-engine commands when plan status or subtask tracking must be synchronized:
-
-Record complexity, context, phases, subtasks, and validation notes directly in the stage markdown files for this running ID. Treat `30-plan.md` as the source of truth.
-
-**MANDATORY RULE:** If you create temporary script files (e.g. `.ps1`, `.sh`) to execute multiple compatibility commands in batch, save them inside the task workspace, never in the central `scripts/` directory.
-
-## 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 planning as an evidence loop, not as a one-shot outline.
-
-- **Intent**: produce a plan that lets implementation proceed without guessing scope, files, risks, or verification.
-- **Context**: read the spec, prior stage artifacts, relevant code/docs, existing commands, and any research that constrains execution.
-- **Action**: draft the smallest useful plan, then inspect whether every phase has files, dependencies, risks, verification, and a test decision.
-- **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-execute` enough context to select one scoped unit and execute it without inventing intent.
-
-### 1. Read Task Artifacts
-
-Read:
-
-- `devflow/runs/{ID}-*20-spec.md`
-- `10-define.md` and the shared `00-explore.md` referenced by `source_discovery` when they help clarify intent
-
-### 2. Assess Complexity
-
-Use the old planning discipline:
-
-- `simple`: 1 phase, 1-3 subtasks
-- `standard`: multiple ordered phases with clear verification
-- `complex`: deeper codebase exploration, possibly specialist help
-
-If architecture or data flow is still unclear, recommend `Research` or `Agent codebase-explorer` before pretending the plan is stable.
-If domain terms, boundaries, or hard-to-reverse design choices are still questionable, use `grill-with-docs` before locking the plan.
-Use `codebase-design` when phases depend on seam placement or module interfaces. Use `tdd` when behavior-change subtasks need red-green-refactor test cases.
-
-### 3. Explore Codebase Patterns
-
-Use fast searches (`rg`, file reads) to find:
-
-- similar implementations
-- entry points
-- config and test commands
-- files likely to change
-- patterns that implementation should mirror
-
-Record important findings in `30-plan.md`. Use legacy context updates only when compatibility tooling still needs them.
-
-### 4. Build The Plan
-
-Use the old planner discipline, but keep `30-plan.md` as the main contract:
-
-- record the planning loop evidence: context read, observations, adjustments made, stop condition, and handoff notes
-- add phases in dependency order
-- add subtasks that are small, verifiable units
-- include explicit files to modify or create
-- include patterns to follow
-- include verification command or manual check
-- include a test decision for every subtask
-- record assumptions, scope boundaries, and risks explicitly
-
-Each subtask should answer:
-
-- what to change
-- where to change it
-- which pattern to follow
-- how to verify it
-- whether automated tests are required, manual, or not required
-
-### 4.1 Test Decision Gate
-
-**STRICT MANDATE (กฎเหล็ก Unit Test)**: สำหรับทุก subtask ที่มีการเพิ่ม แก้ไข หรือเปลี่ยนแปลงการทำงานของโค้ด (Behavior Change) **ต้องระบุเป็น `Required` เสมอ** ห้ามละเว้นเด็ดขาด ยกเว้นงานประเภทเอกสารหรือแก้ไข Configuration เท่านั้น
-
-For every subtask, decide one of:
-
-- `Required`: automated tests must be created or updated (Mandatory for all behavior changes)
-- `Manual/Command Only`: verification is non-test but still explicit (Only for configuration/infrastructure tasks)
-- `Not Required`: no new automated test is needed because there is no meaningful behavior surface (Only for documentation/comments)
-
-Record:
-
-- reason
-- planned cases when tests are required (using AAA pattern: Arrange-Act-Assert)
-- verification command or manual check
-- expected result
-
-Do not use "too simple" as the only reason for skipping tests.
-
-### 5. Create Human-Readable Plan
-
-Create `30-plan.md` in the task workspace and base its structure on:
-
-```text
-.agent/resources/schemas/plan.template.md
-```
-
-Before writing `30-plan.md`, read `artifact_language` from `plan.template.md` and produce the artifact in that language.
-
-Before reporting completion:
-
-Review `{plan_md_path}` against `plan.template.md`, keep the required headings, and remove placeholder text before completion.
-
-Replace every placeholder with concrete phases, files, commands, dependencies, and verification evidence.
-Follow the `artifact_language` configured in `plan.template.md` for all plan narrative text.
-
-Create the checklist directory when detailed execution tracking is needed:
-
-```text
-devflow/runs/{ID}-*/checklists/
-```
-
-Seed at least:
-
-- `implementation-checklist.md`
-- `verification-checklist.md`
-
-Use the schema templates under `.agent/resources/schemas/` and turn approved phases/subtasks into live markdown checklist items using task markers such as `- [ ]`, `- [/]`, `- [!]`, and `- [-]` so humans can follow the run without reading the full planning narrative.
-
-### 6. Validate And Close Planning
-
-Run:
-
-Run `npm run validate` after changing the framework, templates, or shared references. For task work, manually verify that `30-plan.md` still matches the required template contract.
-
-If validation fails, repair only what is necessary and keep `30-plan.md` aligned with the corrected state.
-
-### 7. Manual Review Soft Gate
-
-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-execute` as a soft recommendation only
-
-## Output Checklist
-
-- complexity is clear
-- loop evidence is recorded: intent, context, observation, adjustment, stop condition, and handoff
-- phases are ordered by dependency
-- every subtask is scoped and verifiable
-- every subtask has a test decision
-- `30-plan.md` is written and reviewable
-- validation passes
-- manual review warning is explicit when approval is still pending
-- next command is ready
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `20-spec`
-- 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
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/plan.template.md`
-- Related commands: `20-spec`, `Research`, `Agent`, `40-execute`
-
-## Next Workflow Recommendation
-
-- **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.
-  - `Agent codebase-explorer devflow/runs/{ID}-*/` - choose this when architecture or data flow is unclear.
-  - `grill-with-docs` - choose this when plan assumptions or design boundaries need one last adversarial pass.
-  - `codebase-design` - choose this when a plan needs clearer seams, interfaces, or test surfaces.
-  - `20-spec {ID}` - choose this when the spec itself is not strong enough for planning.
-
-## Nexus Event
-
-- Use `Research` when architecture, sequencing, or rollout decisions still depend on missing evidence.
-- Use `Agent codebase-explorer` or another specialist lane when the codebase shape or integration boundary is still unclear.
-- Use `grill-with-docs` when available if a short clarification pass could materially change sequencing, dependency order, rollout risk, or verification strategy.
-
-## Wiki Update Recommendation
-
-- **Needed**: `yes` when planning records a reusable architecture decision, project pattern, or context-loading lesson.
-- **Scope**: `project` unless the planning lesson changes DevFlow framework behavior.
-- **Reason**: Plans often discover stable patterns that future sessions should reuse.
-- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*30-plan.md`
-