@jakkrichm/create-nexus-devflow 2.0.8 → 2.0.10

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

@@ -1,6 +1,6 @@
 ---name: 20-spec
 
-description: Spec stage in DevFlow 2.0 - write the formal markdown-first specification from a stable definition.
+description: "[Devflow] Spec stage in DevFlow 2.0 - write the formal markdown-first specification from a stable definition."
 argument-hint: "{running-id or workspace path}"
 ---
 
@@ -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/.claude/skills/30-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---name: 30-plan
 
-description: Plan implementation in DevFlow 2.0 - transform `20-spec.md` into a markdown-first executable plan.
+description: "[Devflow] Plan stage in DevFlow 2.0 - transform 20-spec.md into an executable task breakdown with test decisions."
 ---
 # Phase 30: Plan Implementation
 
@@ -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/.claude/skills/40-implement/SKILL.md

@@ -1,6 +1,6 @@
 ---name: 40-implement
 
-description: Implement code in DevFlow 2.0 - execute one planned unit at a time with markdown-first implementation evidence.
+description: "[Devflow] Implement stage in DevFlow 2.0 - execute planned tasks incrementally with evidence and unit tests."
 ---
 # Phase 40: Implement Code
 
@@ -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/.claude/skills/50-verify/SKILL.md

@@ -1,6 +1,6 @@
 ---name: 50-verify
 
-description: Verify quality in DevFlow 2.0 - perform senior QA review, record evidence, and decide pass or return-to-implement.
+description: "[Devflow] Verify stage in DevFlow 2.0 - perform senior QA review, record evidence, and decide pass or return-to-implement."
 ---
 # Phase 50: Verify Quality
 
@@ -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
 
@@ -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/.claude/skills/60-report/SKILL.md

@@ -1,6 +1,6 @@
 ---name: 60-report
 
-description: Report stage in DevFlow 2.0 - produce the final standardized markdown and HTML summary for the full running flow.
+description: "[Devflow] Report stage in DevFlow 2.0 - produce standardized markdown and HTML summary report for the completed run."
 argument-hint: "{running-id or workspace path}"
 ---
 
@@ -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:
@@ -157,8 +157,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 +167,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 +180,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.

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

@@ -1,6 +1,6 @@
 ---name: 70-release
 
-description: Release stage in DevFlow 2.0 - package verified work for delivery, merge, PR, deployment, or handoff.
+description: "[Devflow] Release stage in DevFlow 2.0 - package verified work for delivery, git merge, PR, or deployment."
 argument-hint: "{running-id or workspace path}"
 ---
 
@@ -13,12 +13,12 @@ Package approved work for delivery after the report stage has captured the final
 ## Usage
 
 ```text
-/70-Release {running-id or workspace path}
+70-release {running-id or workspace path}
 ```
 
 Use this when:
 
-- `/60-Report` is complete
+- `60-report` is complete
 - the work needs release execution or a release-facing handoff packet
 - downstream stakeholders need delivery notes instead of raw implementation detail
 
@@ -27,7 +27,7 @@ Use this when:
 Write the primary stage artifact to:
 
 ```text
-devflow/runs/{ID}-{slug}/70-release.md
+devflow/runs/{ID}-{slug}70-release.md
 ```
 
 using:
@@ -60,7 +60,7 @@ Run release as a readiness-packaging loop, not as a celebratory summary.
 - **Context**: read `50-verify.md`, `50-verify-impact.md` when present, `40-implement.md`, `20-spec.md`, checklist state, and any PR, deploy, merge, or handoff notes.
 - **Action**: summarize delivered scope, user/system impact, readiness state, validation evidence, rollback or mitigation notes, and follow-up items.
 - **Observation**: use concrete evidence such as verify verdict, failed or skipped checks, impact notes, residual risks, merge/deploy constraints, and checklist status.
-- **Adjustment**: if release readiness becomes uncertain, return to `/50-Verify`; if fixes are required, return to `/40-Implement`; if context must transfer, use `handoff`.
+- **Adjustment**: if release readiness becomes uncertain, return to `50-verify`; if fixes are required, return to `40-implement`; if context must transfer, use `handoff`.
 - **Stop Condition**: stop when the release state is explicit, evidence supports readiness, residual risks and follow-ups are named, and the next delivery or reporting route is clear.
 - **Handoff**: `70-release.md` must close the mainline run or tell the next reader what shipped, what did not ship, what evidence supports readiness, and what follow-ups remain.
 
@@ -99,7 +99,7 @@ Prefer clear release-note style wording:
 
 If release readiness changes because unresolved issues are found:
 
-- route back to `/50-Verify` or `/40-Implement`
+- route back to `50-verify` or `40-implement`
 
 Do not package unfinished work as release-ready through wording tricks.
 Use `resolving-merge-conflicts` when merge or rebase conflicts block packaging. Use `handoff` when release output must transfer to another agent or session without duplicating artifacts.
@@ -125,7 +125,7 @@ Report:
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline workflow
-- Previous state: `/60-Report`
+- Previous state: `60-report`
 - Next state: End of the mainline run when release packaging or handoff is complete
 - Common companion commands: `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
 - Support skills: `resolving-merge-conflicts`, `handoff`, and `setup-pre-commit` when release packaging needs conflict resolution, transfer notes, or local quality gates
@@ -135,21 +135,21 @@ Report:
 - `AGENTS.md`
 - `docs/workspace-artifacts.md`
 - `.agent/resources/schemas/release.template.md`
-- Related commands: `/60-Report`, `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
+- Related commands: `60-report`, `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
 
 ## Next Workflow Recommendation
 
 - **Primary**: End of Timeline flow
 - **Why**: The report is already complete, and this phase is the final release-facing execution step.
 - **Alternatives**:
-  - `/60-Report` - choose this when the release package diverges from the approved report and the summary must be refreshed first.
-  - `/50-Verify` - choose this when release readiness becomes uncertain.
-  - `/40-Implement` - choose this when additional fixes are needed before release can proceed.
+  - `60-report` - choose this when the release package diverges from the approved report and the summary must be refreshed first.
+  - `50-verify` - choose this when release readiness becomes uncertain.
+  - `40-implement` - choose this when additional fixes are needed before release can proceed.
   - `handoff` - choose this when release-ready context must move to another session, agent, or stakeholder packet.
 
 ## Nexus Event
 
 - Use `Commit`, `PR`, `Deploy`, `Merge`, or `Changelog` when release execution still needs a concrete lane.
-- Return to `/60-Report` when release notes, scope, or handoff wording diverge from the approved summary.
-- Return to `/50-Verify` or `/40-Implement` when release readiness changes because unresolved issues are discovered.
+- Return to `60-report` when release notes, scope, or handoff wording diverge from the approved summary.
+- Return to `50-verify` or `40-implement` when release readiness changes because unresolved issues are discovered.
 

package/template/.claude/skills/adopt/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: adopt
-description: Bootstrap Nexus-DevFlow into an existing (brownfield) codebase. Surveys the real repository (read-only), interviews the user for intent, generates project-overview.md and coding-standards.md from existing code, tunes AGENTS.md commands, and seeds the initial Discovery or Run map. Use when the user runs adopt, /adopt, $adopt, is overlaying DevFlow onto an app that already has meaningful code, or asks to adopt DevFlow into an existing project. For freshly scaffolded or early projects, use onboard instead.
+description: "[Devflow] Survey existing brownfield codebase and bootstrap DevFlow context files."
 ---
 
 # adopt - Bootstrap Nexus-DevFlow from an Existing Codebase
@@ -8,14 +8,14 @@ description: Bootstrap Nexus-DevFlow into an existing (brownfield) codebase. Sur
 Where this sits in the workflow:
 
 ```text
-existing codebase  ->  [adopt]  ->  project-overview + coding-standards  ->  /00-discover or /10-define
+existing codebase  ->  [adopt]  ->  project-overview + coding-standards  ->  00-discover or 10-define
 (already has code)     (survey +    (seeded from the real code;               (first feature / refactoring
                         interview)   shipped architecture documented)          delivery lifecycle)
 ```
 
 Standard onboarding assumes a freshly scaffolded, near-empty app. That does not fit a codebase that already has thousands of lines of working code.
 
-`/adopt` is the brownfield on-ramp for Nexus-DevFlow: it reads what is already there, asks only for what the code cannot reveal (the *intent*, the *why*, and the *upcoming roadmap*), and produces the exact context files the rest of the DevFlow lifecycle expects (`project-overview.md`, `coding-standards.md`, `AGENTS.md` commands).
+`adopt` is the brownfield on-ramp for Nexus-DevFlow: it reads what is already there, asks only for what the code cannot reveal (the *intent*, the *why*, and the *upcoming roadmap*), and produces the exact context files the rest of the DevFlow lifecycle expects (`project-overview.md`, `coding-standards.md`, `AGENTS.md` commands).
 
 ---
 
@@ -91,5 +91,5 @@ Present the adoption summary for review:
 - Inferred conventions and coding standards
 - Available verified commands in `AGENTS.md`
 - Recommended next step:
-  - Run `00-discover` (or `/00-discover`, `$00-discover`) to explore the next major initiative or feature
-  - Run `10-define` (or `/10-define`, `$10-define`) to immediately scope a delivery run for known roadmap items
+  - Run `00-discover` (or `00-discover`, `$00-discover`) to explore the next major initiative or feature
+  - Run `10-define` (or `10-define`, `$10-define`) to immediately scope a delivery run for known roadmap items

package/template/.claude/skills/agent/SKILL.md

@@ -1,6 +1,6 @@
 ---name: agent
 
-description: Invoke Agent - Run a specialist persona on a file, folder, stage artifact, or codebase concern.
+description: "[Devflow] Invoke specialist persona or role-based agent on a target file, folder, stage artifact, or concern."
 ---
 # Phase 90: Invoke Agent
 
@@ -17,7 +17,7 @@ Agent {AGENT_NAME} {TARGET}
 Examples:
 
 ```text
-Agent requirements-engineer devflow/runs/007-auth-refactor/20-spec.md
+Agent requirements-engineer devflow/runs/007-auth-refactor20-spec.md
 Agent codebase-explorer src/services/
 Agent code-reviewer devflow/runs/007-auth-refactor
 ```
@@ -145,7 +145,7 @@ Short reports can be returned directly in chat.
 - Classification: Companion command
 - Mainline status: Specialist invocation command, not a numbered stage
 - Typical entry points: any stage that needs focused specialist judgment
-- Typical handoff targets: return to the owning workflow such as `/10-Define`, `/20-Spec`, `/30-Plan`, `/40-Implement`, `/50-Verify`, `/60-Report`, `/70-Release`
+- Typical handoff targets: return to the owning workflow such as `10-define`, `20-spec`, `30-plan`, `40-implement`, `50-verify`, `60-report`, `70-release`
 
 ## Sources
 
@@ -156,7 +156,7 @@ Short reports can be returned directly in chat.
 
 ## Next Workflow Recommendation
 
-- **Primary**: the workflow that owns the target's lifecycle, such as `/10-Define`, `/20-Spec`, `/30-Plan`, `/40-Implement`, `/50-Verify`, `/60-Report`, `/70-Release`, or `PR-Review`.
+- **Primary**: the workflow that owns the target's lifecycle, such as `10-define`, `20-spec`, `30-plan`, `40-implement`, `50-verify`, `60-report`, `70-release`, or `PR-Review`.
 - **Why**: `Agent` supplies specialist judgment; the owning workflow should execute the next lifecycle step.
 - **Alternatives**:
   - `Research` when the specialist work uncovered unresolved external uncertainty

package/template/.claude/skills/api-and-interface-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: api-and-interface-design
-description: Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
+description: "[Devflow] Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend."
 ---
 
 # API and Interface Design

package/template/.claude/skills/app-builder/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: app-builder
-description: Main application building orchestrator. Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents.
+description: "[Devflow] Main application building orchestrator. Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents."
 allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent
 ---
 

package/template/.claude/skills/architecture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: architecture
-description: Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
+description: "[Devflow] Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design."
 allowed-tools: Read, Glob, Grep
 ---