@jakkrichm/create-nexus-devflow 2.0.9 → 2.0.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jakkrichm/create-nexus-devflow",
-  "version": "2.0.9",
+  "version": "2.0.11",
   "description": "Installer package for Nexus-DevFlow agentic workflow layer.",
   "license": "MIT",
   "author": "Jakkrich",

package/template/.agents/skills/00-discover/SKILL.md

@@ -13,8 +13,8 @@ Explore a request before delivery commitment. Create or resume a Discovery ID, c
 ## Usage
 
 ```text
-/00-Discover {title or request}
-/00-Discover {discovery-id}
+00-discover {title or request}
+00-discover {discovery-id}
 ```
 
 Use this when:
@@ -28,7 +28,7 @@ Use this when:
 Write the primary discovery artifact to:
 
 ```text
-devflow/discoveries/{DISCOVERY_ID}-{slug}/00-discover.md
+devflow/discoveries/{DISCOVERY_ID}-{slug}00-discover.md
 ```
 
 using:
@@ -65,7 +65,7 @@ Run discovery as a decision-and-routing loop, not as task initialization.
 - **Observation**: use concrete evidence such as option tradeoffs, product framing, research results, root cause, stakeholder constraints, open questions, and visible risk.
 - **Adjustment**: invoke only the companion route needed to resolve the current uncertainty; every companion invoked by Discover must return to this Discovery ID for synthesis.
 - **Stop Condition**: stop when the selected route and evidence are recorded, open questions are visible, and the decision is `Proceed`, `Defer`, or `Reject`.
-- **Handoff**: only an approved `Proceed` discovery may hand off to `/10-Define {discovery_id}`. `Defer` and `Reject` end without allocating a Running ID.
+- **Handoff**: only an approved `Proceed` discovery may hand off to `10-define {discovery_id}`. `Defer` and `Reject` end without allocating a Running ID.
 
 ### 1. Create Or Resume The Discovery
 
@@ -99,7 +99,7 @@ After each companion route:
 
 - update `00-discover.md` with the durable findings and source path
 - reassess whether another route is materially necessary
-- return to the Discover decision rather than jumping directly to `/10-Define`
+- return to the Discover decision rather than jumping directly to `10-define`
 
 ### 5. Decide
 
@@ -109,7 +109,7 @@ Set one decision:
 - `Defer`: the idea remains relevant but timing, evidence, or ownership is not ready
 - `Reject`: the idea should not proceed under the current framing
 
-Candidate delivery slices may be suggested, but they remain provisional and unnumbered until `/10-Define`.
+Candidate delivery slices may be suggested, but they remain provisional and unnumbered until `10-define`.
 
 ### 6. Write `00-discover.md`
 
@@ -117,11 +117,11 @@ Candidate delivery slices may be suggested, but they remain provisional and unnu
 - follow the configured `artifact_language`
 - replace placeholders with concrete context
 - record selected routes, returned findings, open questions, decision, and rationale
-- keep `related_runs` empty until `/10-Define` materializes approved slices
+- keep `related_runs` empty until `10-define` materializes approved slices
 
 ### 7. Manual Review Gate
 
-Before `/10-Define`:
+Before `10-define`:
 
 - confirm the selected route and evidence are sufficient
 - confirm the decision is `Proceed`
@@ -138,15 +138,15 @@ Report:
 - selected support route and why
 - important findings and open questions
 - `Proceed`, `Defer`, or `Reject` decision
-- recommended next step, including `/10-Define {discovery_id}` only when Proceed is approved
+- recommended next step, including `10-define {discovery_id}` only when Proceed is approved
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline discovery stage
 - Previous state: request intake
-- Next state: `/10-Define {discovery_id}` only after approved Proceed
+- Next state: `10-define {discovery_id}` only after approved Proceed
 - Common companion routes: `Brainstorm`, `PRD`, `Research`, `Debug`
-- Running ID lifecycle: begins in `/10-Define`, not in Discover
+- Running ID lifecycle: begins in `10-define`, not in Discover
 
 ## Sources
 
@@ -156,7 +156,7 @@ Report:
 
 ## Next Workflow Recommendation
 
-- **Primary**: the selected companion route, or `/10-Define {discovery_id}` after approved Proceed
+- **Primary**: the selected companion route, or `10-define {discovery_id}` after approved Proceed
 - **Alternatives**:
   - `Brainstorm {discovery_id}` for unresolved options
   - `PRD {discovery_id}` for product framing

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

@@ -13,8 +13,8 @@ Convert an approved `Proceed` discovery into bounded delivery slices. Allocate o
 ## Usage
 
 ```text
-/10-Define {discovery-id or discovery path}
-/10-Define {running-id or run path}
+10-define {discovery-id or discovery path}
+10-define {running-id or run path}
 ```
 
 Use a Discovery ID to materialize new delivery runs. Use an existing Running ID only to revise or split a definition that already exists.
@@ -24,7 +24,7 @@ Use a Discovery ID to materialize new delivery runs. Use an existing Running ID
 For every approved delivery slice, write:
 
 ```text
-devflow/runs/{ID}-{slug}/10-define.md
+devflow/runs/{ID}-{slug}10-define.md
 ```
 
 using:
@@ -57,8 +57,8 @@ Run definition as a scope-stabilization and run-allocation loop.
 - **Context**: read the approved `00-discover.md`, linked Brainstorm/PRD/Research/Debug outputs, project-wide rules, existing run IDs, and dependencies between candidate slices.
 - **Action**: lock initiative and scope boundaries, decompose delivery slices, review the run map, allocate collision-free Running IDs, and write one `10-define.md` per slice.
 - **Observation**: use independent acceptance boundaries, release boundaries, ownership, dependencies, context size, cross-domain coupling, and reviewability as evidence for splitting or combining slices.
-- **Adjustment**: merge slices that are only implementation tasks; split slices that require separate specs, releases, ownership, or large independent context; return to `/00-Discover` if the decision or product direction is still unstable.
-- **Stop Condition**: stop when the run map is approved, IDs are materialized without collision, each run has stable in/out scope, and every generated run can proceed independently to `/20-Spec {running_id}`.
+- **Adjustment**: merge slices that are only implementation tasks; split slices that require separate specs, releases, ownership, or large independent context; return to `00-discover` if the decision or product direction is still unstable.
+- **Stop Condition**: stop when the run map is approved, IDs are materialized without collision, each run has stable in/out scope, and every generated run can proceed independently to `20-spec {running_id}`.
 - **Handoff**: each `10-define.md` must identify its source Discovery ID, sibling runs, dependencies, scope, non-goals, and exact next command.
 
 ### 1. Validate The Discovery Gate
@@ -69,7 +69,7 @@ For new delivery work, require:
 - `Approval Status: Approved`
 - a resolvable Discovery ID and `00-discover.md`
 
-If either gate is missing, do not create a Running ID. Return to `/00-Discover {discovery_id}`.
+If either gate is missing, do not create a Running ID. Return to `00-discover {discovery_id}`.
 
 ### 2. Build The Delivery Run Map
 
@@ -83,7 +83,7 @@ Create separate runs when work has materially independent:
 - dependency sequencing
 - implementation context large enough to threaten reliable planning or review
 
-Keep ordinary subtasks inside `/30-Plan` and checklists.
+Keep ordinary subtasks inside `30-plan` and checklists.
 
 For every slice record:
 
@@ -126,11 +126,11 @@ If an existing definition is too broad:
 - preserve traceability to the original run and discovery
 - allocate new IDs only after approval
 - mark the old definition as `Superseded` and list its replacement runs
-- do not silently fork scope during `/20-Spec`
+- do not silently fork scope during `20-spec`
 
 ### 7. Manual Review Gate
 
-Before recommending `/20-Spec`, confirm each generated definition independently. Approval of one run must not imply approval of every sibling run.
+Before recommending `20-spec`, confirm each generated definition independently. Approval of one run must not imply approval of every sibling run.
 
 ## Output
 
@@ -141,13 +141,13 @@ Report:
 - workspace path for every generated run
 - scope and dependency summary per run
 - any superseded run
-- exact `/20-Spec {running_id}` commands for approved runs
+- exact `20-spec {running_id}` commands for approved runs
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline workflow and Running ID creation boundary
-- Previous state: approved `/00-Discover`
-- Next state: `/20-Spec {running_id}` per generated run
+- Previous state: approved `00-discover`
+- Next state: `20-spec {running_id}` per generated run
 - Running ID lifecycle: starts here
 
 ## Sources
@@ -158,13 +158,13 @@ Report:
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/20-Spec {running_id}` for each approved run
+- **Primary**: `20-spec {running_id}` for each approved run
 - **Alternatives**:
-  - `/00-Discover {discovery_id}` when the go/no-go decision or direction is unstable
+  - `00-discover {discovery_id}` when the go/no-go decision or direction is unstable
   - `Research {discovery_id}` when evidence still blocks a reliable split
   - `grill-with-docs` when boundaries or terminology remain ambiguous
 
 ## Nexus Event
 
 - Use `domain-modeling` when sibling runs need shared language or durable architectural decisions.
-- Use `planning-and-task-breakdown` only after the delivery boundary is stable; small tasks belong in `/30-Plan`, not separate Running IDs.
+- Use `planning-and-task-breakdown` only after the delivery boundary is stable; small tasks belong in `30-plan`, not separate Running IDs.

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

@@ -13,7 +13,7 @@ Turn the defined work into a specification that is concrete enough for planning
 ## Usage
 
 ```text
-/20-Spec {running-id or workspace path}
+20-spec {running-id or workspace path}
 ```
 
 Use this when:
@@ -27,7 +27,7 @@ Use this when:
 Write the primary stage artifact to:
 
 ```text
-devflow/runs/{ID}-{slug}/20-spec.md
+devflow/runs/{ID}-{slug}20-spec.md
 ```
 
 using:
@@ -60,9 +60,9 @@ Run specification as a contract-hardening loop, not as a prose expansion of the
 - **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.
+- **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
 
@@ -94,7 +94,7 @@ If the spec cannot be written confidently:
 
 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.
+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`
 
@@ -106,12 +106,12 @@ Do not combine sibling Running IDs into one spec. If this run still contains mul
 
 ### 5. Manual Review Soft Gate
 
-Before recommending `/30-Plan`, check whether the delivery contract has been human-reviewed.
+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
+- keep `30-plan` as a soft recommendation only
 
 ## Output
 
@@ -127,8 +127,8 @@ Report:
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline workflow
-- Previous state: `/10-Define`
-- Next state: `/30-Plan` when the contract is implementation-ready
+- 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
@@ -136,17 +136,17 @@ Report:
 - `AGENTS.md`
 - `docs/workspace-artifacts.md`
 - `.agent/resources/schemas/spec.template.md`
-- Related commands: `/10-Define`, `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate`, `/30-Plan`
+- Related commands: `10-define`, `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate`, `30-plan`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/30-Plan`
+- **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.
+  - `10-define` - choose this when the scope itself is still unstable.
 
 ## Nexus Event
 

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

@@ -11,7 +11,7 @@ Create a codebase-informed implementation plan using `30-plan.md` as the primary
 ## Usage
 
 ```text
-/30-Plan {ID}
+30-plan {ID}
 ```
 
 ## Markdown-First Contract
@@ -46,15 +46,15 @@ Run planning as an evidence loop, not as a one-shot outline.
 - **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.
+- **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-Implement` enough context to select one scoped unit and execute it without inventing intent.
+- **Handoff**: `30-plan.md` must give `40-implement` enough context to select one scoped unit and execute it without inventing intent.
 
 ### 1. Read Task Artifacts
 
 Read:
 
-- `devflow/runs/{ID}-*/20-spec.md`
+- `devflow/runs/{ID}-*20-spec.md`
 - `10-define.md` and the shared `00-discover.md` referenced by `source_discovery` when they help clarify intent
 
 ### 2. Assess Complexity
@@ -161,12 +161,12 @@ If validation fails, repair only what is necessary and keep `30-plan.md` aligned
 
 ### 7. Manual Review Soft Gate
 
-Before recommending `/40-Implement`, check whether the plan still shows pending review.
+Before recommending `40-implement`, 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-Implement` as a soft recommendation only
+- keep `40-implement` as a soft recommendation only
 
 ## Output Checklist
 
@@ -183,8 +183,8 @@ If `Approval Status` is still pending or major dependencies remain unresolved:
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline workflow
-- Previous state: `/20-Spec`
-- Next state: `/40-Implement` when execution steps and verification are clear
+- Previous state: `20-spec`
+- Next state: `40-implement` 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
@@ -192,18 +192,18 @@ If `Approval Status` is still pending or major dependencies remain unresolved:
 - `AGENTS.md`
 - `docs/workspace-artifacts.md`
 - `.agent/resources/schemas/plan.template.md`
-- Related commands: `/20-Spec`, `Research`, `Agent`, `/40-Implement`
+- Related commands: `20-spec`, `Research`, `Agent`, `40-implement`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/40-Implement {ID}`
+- **Primary**: `40-implement {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.
+  - `20-spec {ID}` - choose this when the spec itself is not strong enough for planning.
 
 ## Nexus Event
 
@@ -216,6 +216,6 @@ If `Approval Status` is still pending or major dependencies remain unresolved:
 - **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`
+- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*30-plan.md`
 
 

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

@@ -9,7 +9,7 @@ Implement the approved plan incrementally. Source code edits are allowed in this
 ## Usage
 
 ```text
-/40-Implement {ID}
+40-implement {ID}
 ```
 
 ## Markdown-First Contract
@@ -43,9 +43,9 @@ Run implementation as scoped execution loops, one unit at a time.
 - **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.
+- **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-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
 
@@ -112,8 +112,8 @@ If the plan was not clearly approved, warn that implementation proceeded under r
 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
+- set reviewer expectations before `50-verify`
+- keep `50-verify` as the next soft recommendation rather than an unconditional jump
 
 ## Output
 
@@ -125,13 +125,13 @@ Report:
 - test decisions followed or changed, with reasons
 - loop evidence and handoff notes for Verify
 - blocked items or manual checks
-- next command: `/50-Verify {ID}`
+- 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
+- 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
@@ -139,15 +139,15 @@ Report:
 - `AGENTS.md`
 - `docs/workspace-artifacts.md`
 - `.agent/resources/schemas/implement.template.md`
-- Related commands: `/30-Plan`, `Debug`, `Preview`, `/50-Verify`
+- Related commands: `30-plan`, `Debug`, `Preview`, `50-verify`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/50-Verify {ID}` when the planned work is complete.
+- **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.
+  - `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 +155,12 @@ 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 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`
+- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*40-implement.md`
 

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

@@ -9,7 +9,7 @@ Review implementation quality, run validation, produce a verification report, an
 ## Usage
 
 ```text
-/50-Verify {ID}
+50-verify {ID}
 ```
 
 ## Markdown-First Contract
@@ -46,9 +46,9 @@ Run verification as an evidence review loop, not as a single pass/fail guess.
 - **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.
+- **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.
+- **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
 
@@ -65,21 +65,21 @@ Read:
 
 Run the necessary validation for the current state before doing the full review.
 
-### 3. QA Review
+### 3. QA Review & Findings Ledger Verification
 
-Use the old QA reviewer discipline, adapted to 2.0:
+Use the senior QA reviewer discipline, adapted to DevFlow 2.0 and Blueprint quality gates:
 
 - **STRICT MANDATE (กฎเหล็ก Unit Test)**: ตรวจสอบว่าโค้ดใหม่หรือการแก้ไข Bug (ที่มี behavior change) มีการสร้างหรืออัปเดต Unit Test คู่กันมาด้วยหรือไม่ หากไม่มีให้ทำเครื่องหมายว่า FAIL ทันที
+- **EMPIRICAL PROOF CONTRACT (หลักฐานเชิงประจักษ์)**: ห้ามเคลมว่า "ผ่าน" หรือ "ทำงานได้" โดยไม่มีหลักฐานรูปธรรม — ต้องระบุ Command, Test Output, Route, Screenshot, หรือ Log จริงที่พิสูจน์ผลลัพธ์
+- **FINDINGS LEDGER STATE MACHINE (`findings.md`)**:
+  - ตรวจสอบ `devflow/context/findings.md`
+  - ตรวจสอบสถานะ: `open` ➔ `fixed` ➔ `closed` (เฉพาะการตรวจซ้ำใน `50-verify` เท่านั้นที่สามารถเลื่อนสถานะ `fixed` เป็น `closed` ได้)
+  - **P0/P1 HARD GATE**: หากพบ Finding ระดับ P0 หรือ P1 ในสถานะ `open` หรือ `fixed` ที่ยังไม่ได้ถูกแก้ไข/ตรวจซ้ำ ให้ตัดสินเป็น FAIL ทันที
+- **MANUAL TRY GUIDE**: สรุปขั้นตอนการทดสอบด้วยมือสำหรับมนุษย์ (Where to go, What to click, What to expect) ไว้อย่างชัดเจน
 - 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
+- correctness, readability, architecture (DIP, SRP, Loose Coupling), security, and performance
 - test coverage (และตรวจสอบว่าไม่มีการ skip หรือ disable เทสต์)
-- test decision alignment
-- manual verification gaps
-- assumptions and scope discipline
+- test decision alignment and scope discipline
 
 Run project validation commands when available: lint, tests, typecheck, build, or targeted commands from the plan.
 
@@ -120,11 +120,11 @@ Include:
 
 If pass:
 
-- route to `/60-Report`
+- route to `60-report`
 
 If fail:
 
-- route back to `/40-Implement` with exact failed evidence, missing checks, or required changes
+- route back to `40-implement` with exact failed evidence, missing checks, or required changes
 
 Use `Debug` when investigation is needed before implementation can resume.
 
@@ -134,8 +134,8 @@ 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
+- recommend additional review or a return to `40-implement`
+- keep `60-report` as a soft recommendation only
 
 ## Output
 
@@ -146,13 +146,13 @@ 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-implement {ID}` if fail
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline workflow
-- Previous state: `/40-Implement`
-- Next state: `/60-Report` when evidence is sufficient
+- 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
 
@@ -162,16 +162,16 @@ 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-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.
+- **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.
+  - `Wiki project ingest devflow/runs/{ID}-*50-verify.md` - choose this when verification reveals reusable project knowledge.
 
 ## Nexus Event
 
@@ -184,5 +184,5 @@ Report:
 - **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`
+- **Suggested Command**: `Wiki project ingest devflow/runs/{ID}-*50-verify.md`
 

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

@@ -13,7 +13,7 @@ Produce the final human-friendly summary of the full running flow in both Markdo
 ## Usage
 
 ```text
-/60-Report {running-id or workspace path}
+60-report {running-id or workspace path}
 ```
 
 Use this when:
@@ -27,8 +27,8 @@ Use this when:
 Write the primary stage artifacts to:
 
 ```text
-devflow/runs/{ID}-{slug}/60-report.md
-devflow/runs/{ID}-{slug}/60-report.html
+devflow/runs/{ID}-{slug}60-report.md
+devflow/runs/{ID}-{slug}60-report.html
 ```
 
 using:
@@ -87,8 +87,9 @@ Explain:
 - what problem was addressed
 - what direction was chosen
 - what was implemented
-- how it was verified
+- how it was verified (พร้อมบันทึกสถานะ Findings Ledger ใน `devflow/context/findings.md`)
 - how checklist progress moved across the run
+- **Manual Try Guide**: สรุปขั้นตอนการทดสอบสำหรับมนุษย์ ("Where to go", "What to click", "What to expect")
 - what approval or review state remained at each important gate
 - what the release recommendation is
 - what follow-up items still exist
@@ -157,8 +158,8 @@ 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
+- 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
 
@@ -167,11 +168,11 @@ npm run report:html -- <workspace-path-or-running-id>
 - `AGENTS.md`
 - `docs/workspace-artifacts.md`
 - `.agent/resources/schemas/report.template.md`
-- Related commands: `/50-Verify`, `/70-Release`, `Wiki`, `Help`
+- 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.
+- **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.
@@ -180,4 +181,4 @@ npm run report:html -- <workspace-path-or-running-id>
 
 - 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.
+- Return to `50-verify` when unresolved evidence, blockers, or review state mean the report should not advance yet.