@jakkrichm/create-nexus-devflow 2.0.9 → 2.0.10

package/template/.claude/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/.claude/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/.claude/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/.claude/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/.claude/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
 
@@ -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

@@ -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

@@ -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

@@ -8,14 +8,14 @@ description: "[Devflow] Survey existing brownfield codebase and bootstrap DevFlo
 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

@@ -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