@jakkrichm/create-nexus-devflow 2.0.9 → 2.0.11

package/template/.agents/skills/pr/SKILL.md

@@ -16,7 +16,7 @@ Primary behavior now lives in:
 
 Treat this workflow file as a compatibility wrapper around that skill in `pr` mode.
 
-In DevFlow 2.0, this is a release-adjacent workflow. It usually follows `/60-Report` and pairs naturally with `/70-Release` once the final summary is aligned.
+In DevFlow 2.0, this is a release-adjacent workflow. It usually follows `60-report` and pairs naturally with `70-release` once the final summary is aligned.
 
 ---
 
@@ -31,7 +31,7 @@ You are an orchestrator. Your goal is to call the specialized Git PR Maker agent
 - Ensure the branch is not `main` or `master`.
 - Check for unpushed commits.
 - Verify the working directory is clean enough for PR submission.
-- Confirm the implementation has already passed the expected verification gate. If it has not, route back to `/50-Verify` first.
+- Confirm the implementation has already passed the expected verification gate. If it has not, route back to `50-verify` first.
 
 ### Phase 2: Context And Template
 
@@ -75,19 +75,19 @@ Verify that the workflow returns:
 
 - Classification: Companion command
 - Mainline status: Release support command, not a numbered stage
-- Typical entry points: `/70-Release`, `Commit`
-- Typical handoff targets: `PR-Review`, `PR-Followup`, `Merge`, `/70-Release`
+- Typical entry points: `70-release`, `Commit`
+- Typical handoff targets: `PR-Review`, `PR-Followup`, `Merge`, `70-release`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agents/skills/release-git-operations/SKILL.md`
 - `.agents/skills/git-workflow-and-versioning/SKILL.md`
-- Related commands: `Commit`, `PR-Review`, `PR-Followup`, `Merge`, `/60-Report`, `/70-Release`
+- Related commands: `Commit`, `PR-Review`, `PR-Followup`, `Merge`, `60-report`, `70-release`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/70-Release`
+- **Primary**: `70-release`
 - **Why**: after PR creation, release execution and handoff details should stay consistent with the approved report.
-- **Alternative**: `PR-Review` for structured review before broader sharing, or `/60-Report` when the final communication summary still needs to be refreshed first.
+- **Alternative**: `PR-Review` for structured review before broader sharing, or `60-report` when the final communication summary still needs to be refreshed first.
 

package/template/.agents/skills/pr-review/SKILL.md

@@ -9,7 +9,7 @@ description: "[Devflow] PR Review Addon - Review a pull request using GitHub rev
 
 Use this workflow when you need a structured PR review without creating or changing the PR. It can review a local diff, a PR URL or number, or a task-linked branch.
 
-In DevFlow 2.0, this remains a supporting review workflow. It should feed corrective work back into `/40-Implement` or clear the path toward `/60-Report` and then `/70-Release`.
+In DevFlow 2.0, this remains a supporting review workflow. It should feed corrective work back into `40-implement` or clear the path toward `60-report` and then `70-release`.
 
 Primary behavior now lives in the `pr-review-analysis` skill. Keep this workflow as the compatibility wrapper and user-facing review prompt surface.
 
@@ -123,21 +123,21 @@ devflow/runs/{ID}-*/pr_review.md
 
 - Classification: Companion command
 - Mainline status: Verification and release support command, not a numbered stage
-- Typical entry points: `/50-Verify`, `PR`, `Agent code-reviewer`
-- Typical handoff targets: `PR-Followup`, `/60-Report`, `/70-Release`, `Wiki`
+- Typical entry points: `50-verify`, `PR`, `Agent code-reviewer`
+- Typical handoff targets: `PR-Followup`, `60-report`, `70-release`, `Wiki`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agent/resources/schemas/pr_review.template.md`
-- Related commands: `/50-Verify`, `PR`, `PR-Followup`, `Agent`, `/60-Report`, `/70-Release`, `Wiki`
+- Related commands: `50-verify`, `PR`, `PR-Followup`, `Agent`, `60-report`, `70-release`, `Wiki`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/40-Implement {ID}` when review finds required fixes, or `/60-Report {ID}` when the review is clean and the run needs the final summary refreshed before release execution.
+- **Primary**: `40-implement {ID}` when review finds required fixes, or `60-report {ID}` when the review is clean and the run needs the final summary refreshed before release execution.
 - **Why**: PR review either creates corrective implementation work or clears the path toward final summary alignment and release-facing packaging.
 - **Alternatives**:
-  - `/70-Release` when the report is already aligned and only release execution remains
+  - `70-release` when the report is already aligned and only release execution remains
   - `Wiki` when the review establishes a durable convention or risk pattern
   - `PR-Followup {target}` when the PR already has comments that need classification and response
 

package/template/.agents/skills/pr-review-analysis/SKILL.md

@@ -20,7 +20,7 @@ This skill should reuse and align with:
 
 ## When to Use
 
-- after `/50-Verify` when the change needs structured review before `/60-Report` and `/70-Release`
+- after `50-verify` when the change needs structured review before `60-report` and `70-release`
 - when a local diff, branch, or pull request needs findings-first analysis
 - when the user wants review without directly editing code
 
@@ -86,4 +86,4 @@ Return:
 - open questions or assumptions
 - residual risks or test gaps
 - where the review report was saved
-- the recommended next route such as `/40-Implement`, `/70-Release`, or `PR-Followup`
+- the recommended next route such as `40-implement`, `70-release`, or `PR-Followup`

package/template/.agents/skills/prd/SKILL.md

@@ -12,9 +12,9 @@ description: Strategic PRD Generator (Orchestration) - Transform a product or fe
 
 Transform a product or feature idea into a problem-first, hypothesis-driven Product Requirements Document (PRD).
 
-In DevFlow 2.0, this is a supporting workflow, not part of the numbered mainline state path. Use it when the idea is still too product-shaped for `/10-Define` or `/20-Spec` to proceed cleanly.
+In DevFlow 2.0, this is a supporting workflow, not part of the numbered mainline state path. Use it when the idea is still too product-shaped for `10-define` or `20-spec` to proceed cleanly.
 Use `to-prd` when existing conversation, discovery, or codebase context is already sufficient and the job is synthesis rather than another interview.
-When invoked from `/00-Discover`, link the PRD to the Discovery ID and return to `/00-Discover {discovery_id}` for the final `Proceed`, `Defer`, or `Reject` decision. PRD does not create Running IDs.
+When invoked from `00-discover`, link the PRD to the Discovery ID and return to `00-discover {discovery_id}` for the final `Proceed`, `Defer`, or `Reject` decision. PRD does not create Running IDs.
 
 ---
 
@@ -56,7 +56,7 @@ You are an orchestrator. Your goal is to call the specialized PRD Architect agen
   - explicit assumptions
   - open questions
   - risks that should remain visible before delivery planning
-- Do not let the PRD silently drift into implementation detail that belongs in `/20-Spec` or `/30-Plan`.
+- Do not let the PRD silently drift into implementation detail that belongs in `20-spec` or `30-plan`.
 
 ### Phase 4: Output Generation
 
@@ -84,10 +84,10 @@ devflow/prds/{date}-{slug}.prd.md
 
 Convert the PRD into explicit next steps for the Timeline flow:
 
-- `/00-Discover {discovery_id}` when the PRD belongs to an active discovery
-- `/10-Define` when product framing was created outside Discover and delivery has already been approved
-- `/20-Spec` when the delivery contract is ready to be locked
-- `/30-Plan {ID}` only after the spec is execution-ready
+- `00-discover {discovery_id}` when the PRD belongs to an active discovery
+- `10-define` when product framing was created outside Discover and delivery has already been approved
+- `20-spec` when the delivery contract is ready to be locked
+- `30-plan {ID}` only after the spec is execution-ready
 
 The user should still approve the transition into execution work. Do not treat PRD generation as automatic task creation.
 
@@ -110,18 +110,18 @@ Return:
 - Classification: Companion command
 - Mainline status: Not a numbered stage
 - Typical entry points: product framing before implementation-ready scope exists
-- Typical handoff targets: `/00-Discover {discovery_id}`, `/10-Define`, `/20-Spec`, `Roadmap`, `Spec-Orchestrate`
+- Typical handoff targets: `00-discover {discovery_id}`, `10-define`, `20-spec`, `Roadmap`, `Spec-Orchestrate`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agent/resources/schemas/prd.template.md`
-- Related commands: `Brainstorm`, `Research`, `/10-Define`, `/20-Spec`, `Roadmap`, `Spec-Orchestrate`
+- Related commands: `Brainstorm`, `Research`, `10-define`, `20-spec`, `Roadmap`, `Spec-Orchestrate`
 - Support skills: `to-prd`, `grill-with-docs`, `domain-modeling`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/00-Discover {discovery_id}` when invoked from discovery; otherwise `/10-Define`
+- **Primary**: `00-discover {discovery_id}` when invoked from discovery; otherwise `10-define`
 - **Why**: PRD shapes product intent, while Discover owns the delivery decision and Define owns Running ID creation.
 - **Alternative**: `Research` when technical feasibility or external dependencies are still unresolved.
 

package/template/.agents/skills/preview/SKILL.md

@@ -42,8 +42,8 @@ Use it when:
 
 Preferred DevFlow 2.0 pairing:
 
-- from `/40-Implement`
-- from `/50-Verify`
+- from `40-implement`
+- from `50-verify`
 
 ---
 
@@ -105,17 +105,17 @@ Example summary:
 
 - Classification: Companion command
 - Mainline status: Not a numbered stage
-- Typical entry points: `/40-Implement`, `/50-Verify`, UI or runtime checking
-- Typical handoff targets: `/50-Verify`, `Debug`, `/40-Implement`
+- Typical entry points: `40-implement`, `50-verify`, UI or runtime checking
+- Typical handoff targets: `50-verify`, `Debug`, `40-implement`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agents/skills/preview-local-check/SKILL.md`
-- Related commands: `/40-Implement`, `/50-Verify`, `Debug`
+- Related commands: `40-implement`, `50-verify`, `Debug`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/50-Verify` when preview confirms the change is ready for formal checks
-- **Alternative**: `/40-Implement` when preview exposed implementation work
+- **Primary**: `50-verify` when preview confirms the change is ready for formal checks
+- **Alternative**: `40-implement` when preview exposed implementation work
 

package/template/.agents/skills/preview-local-check/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: preview-local-check
-description: "[Devflow] Manage local preview, smoke-check, and temporary runtime verification before formal verification. Use when implementation needs a quick visual or runtime check, when a reviewer needs a local URL, or when a change should be inspected before /50-Verify."
+description: "[Devflow] Manage local preview, smoke-check, and temporary runtime verification before formal verification. Use when implementation needs a quick visual or runtime check, when a reviewer needs a local URL, or when a change should be inspected before 50-verify."
 ---
 
 # Preview Local Check
@@ -18,8 +18,8 @@ Use it to:
 
 ## When to Use
 
-- During `/40-Implement` when a quick runtime check is useful
-- During `/50-Verify` when the change needs visual or interactive confirmation
+- During `40-implement` when a quick runtime check is useful
+- During `50-verify` when the change needs visual or interactive confirmation
 - When a reviewer asks for a local preview URL
 
 Do not use this skill as a replacement for test evidence, verification evidence, or release readiness.
@@ -50,8 +50,8 @@ Always report:
 
 ### 4. Route Back
 
-- return to `/50-Verify` when preview confirms the change is ready for formal checks
-- return to `/40-Implement` when preview reveals implementation issues
+- return to `50-verify` when preview confirms the change is ready for formal checks
+- return to `40-implement` when preview reveals implementation issues
 - use `Debug` when the preview failure needs RCA
 
 ## Output

package/template/.agents/skills/prototype/SKILL.md

@@ -8,7 +8,7 @@ disable-model-invocation: true
 
 A prototype is throwaway code that answers one question.
 
-Use this support skill behind `Research`, `Brainstorm`, `/00-Discover`, `/10-Define`, `/20-Spec`, or `/30-Plan` when conversation alone cannot settle the uncertainty.
+Use this support skill behind `Research`, `Brainstorm`, `00-discover`, `10-define`, `20-spec`, or `30-plan` when conversation alone cannot settle the uncertainty.
 
 ## Branches
 

package/template/.agents/skills/release-git-operations/SKILL.md

@@ -27,8 +27,8 @@ This skill should reuse and align with:
 
 ## When to Use
 
-- After `/50-Verify` when verified work is ready for packaging
-- During `/70-Release` when the team needs commit, PR, merge, deployment, or changelog support after the report is already aligned
+- After `50-verify` when verified work is ready for packaging
+- During `70-release` when the team needs commit, PR, merge, deployment, or changelog support after the report is already aligned
 - When release communication must be built from markdown-first stage artifacts
 
 ## Supported Modes
@@ -83,9 +83,9 @@ Read the minimum required artifacts:
 
 ### 3. Route Back
 
-- return to `/70-Release` when packaging is still in progress
-- return to `/60-Report` when communication is the remaining task
-- return to `/40-Implement`, `/50-Verify`, or `PR-Followup` if release blockers are discovered
+- return to `70-release` when packaging is still in progress
+- return to `60-report` when communication is the remaining task
+- return to `40-implement`, `50-verify`, or `PR-Followup` if release blockers are discovered
 
 ## Output
 

package/template/.agents/skills/research/SKILL.md

@@ -30,12 +30,12 @@ Use `prototype` when the fastest reliable evidence is a runnable throwaway exper
 
 Preferred DevFlow 2.0 pairing:
 
-- from `/00-Discover`
-- from `/10-Define`
-- from `/20-Spec`
-- from `/50-Verify` when validating a claim or implementation choice
+- from `00-discover`
+- from `10-define`
+- from `20-spec`
+- from `50-verify` when validating a claim or implementation choice
 
-When invoked with a Discovery ID, link the research report to that discovery and return to `/00-Discover {discovery_id}` so Discover can synthesize the evidence and make the decision. Research must not allocate a Running ID.
+When invoked with a Discovery ID, link the research report to that discovery and return to `00-discover {discovery_id}` so Discover can synthesize the evidence and make the decision. Research must not allocate a Running ID.
 
 ---
 
@@ -125,19 +125,19 @@ Research whether this API version is compatible
 
 - Classification: Companion command
 - Mainline status: Not a numbered stage
-- Typical entry points: `/00-Discover`, `/10-Define`, `/20-Spec`, `/30-Plan`
+- Typical entry points: `00-discover`, `10-define`, `20-spec`, `30-plan`
 - Typical handoff targets: return to the stage that asked for the evidence
 
 ## Sources
 
 - `AGENTS.md`
 - `.agent/resources/schemas/research.template.md`
-- Related commands: `/00-Discover`, `/10-Define`, `/20-Spec`, `/30-Plan`, `Spec-Research`, `Agent`
+- Related commands: `00-discover`, `10-define`, `20-spec`, `30-plan`, `Spec-Research`, `Agent`
 - Support skills: `prototype`, `spec-research`, `competitor-analysis`, `insight-capture`
 
 ## Next Workflow Recommendation
 
-- Default: return to the stage that asked for evidence; for discovery-owned research this is `/00-Discover {discovery_id}`
-- Common routes: `/10-Define`, `/20-Spec`, `/30-Plan`, or `/50-Verify`
+- Default: return to the stage that asked for evidence; for discovery-owned research this is `00-discover {discovery_id}`
+- Common routes: `10-define`, `20-spec`, `30-plan`, or `50-verify`
 - Alternate: `Brainstorm` if the research opens multiple strategic options
 

package/template/.agents/skills/review/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: review
-description: "[Devflow] Two-axis review for changed work. Use inside /50-Verify or /70-Release when a branch, PR, or work-in-progress diff needs standards and spec review."
+description: "[Devflow] Two-axis review for changed work. Use inside 50-verify or 70-release when a branch, PR, or work-in-progress diff needs standards and spec review."
 ---
 
 # Review
 
-Use this support skill as one verification lane. `/50-Verify` owns validation evidence; this skill reviews a diff from two separate angles.
+Use this support skill as one verification lane. `50-verify` owns validation evidence; this skill reviews a diff from two separate angles.
 
 ## Axes
 
@@ -22,7 +22,7 @@ Keep the axes separate so one does not hide the other.
    - Confirm the diff is non-empty.
 
 2. Identify the spec source.
-   - Prefer `devflow/runs/{ID}-*/20-spec.md`, `30-plan.md`, issue brief, PRD, or explicit user path.
+   - Prefer `devflow/runs/{ID}-*20-spec.md`, `30-plan.md`, issue brief, PRD, or explicit user path.
    - If no spec exists, mark the Spec axis as skipped.
 
 3. Identify standards sources.

package/template/.agents/skills/review-followup-routing/SKILL.md

@@ -83,9 +83,9 @@ For task follow-up, append the approved follow-up work directly into the relevan
 
 ### 5. Route Back
 
-- `/40-Implement` for immediate corrective work
-- `/50-Verify` when only verification needs another pass
-- `/10-Define` or `/20-Spec` when the follow-up becomes genuinely new scope
+- `40-implement` for immediate corrective work
+- `50-verify` when only verification needs another pass
+- `10-define` or `20-spec` when the follow-up becomes genuinely new scope
 
 ## Output
 

package/template/.agents/skills/roadmap-strategy/SKILL.md

@@ -23,7 +23,7 @@ This skill should reuse and align with:
 
 - when product direction, priority, or sequencing needs a dedicated roadmap pass
 - when competitor, PRD, research, or delivery insight should be consolidated into strategy
-- when roadmap work should stay outside the numbered mainline but still hand off cleanly into `PRD`, `/10-Define`, or `/20-Spec`
+- when roadmap work should stay outside the numbered mainline but still hand off cleanly into `PRD`, `10-define`, or `20-spec`
 
 ## Canonical Artifacts
 
@@ -79,8 +79,8 @@ Replace placeholder content fully and keep headings and tables intact so validat
 ### 5. Route Back
 
 - `PRD` when product framing needs to deepen
-- `/10-Define` when roadmap decisions should become bounded work
-- `/20-Spec` when one item is ready for delivery contract work
+- `10-define` when roadmap decisions should become bounded work
+- `20-spec` when one item is ready for delivery contract work
 - `Brainstorm` when strategy is still too fuzzy to lock
 
 ## Output

package/template/.agents/skills/rollback/SKILL.md

@@ -8,7 +8,7 @@ description: "[Devflow] Plan safe feature or run reversal with dependency and co
 Where this sits in the workflow:
 
 ```text
-completed run + git history  ->  [rollback]  ->  /40-implement (or fix run)  ->  /50-verify  ->  /70-release
+completed run + git history  ->  [rollback]  ->  40-implement (or fix run)  ->  50-verify  ->  70-release
 (run archive + commits)          (risk review    (reverse product diff)          (prove)      (log & finalize)
                                   + plan)
 ```
@@ -20,9 +20,9 @@ This skill **plans a rollback**. It does not silently alter product code, reset
 A completed run by Running ID, name, or run path, plus an optional reason. Examples:
 
 ```text
-/rollback RUN-002-add-onboard-adopt-doctor-skills
-/rollback "auth login" because OAuth provider changed
-/rollback devflow/runs/RUN-001-align-devflow-blueprint
+rollback RUN-002-add-onboard-adopt-doctor-skills
+rollback "auth login" because OAuth provider changed
+rollback devflow/runs/RUN-001-align-devflow-blueprint
 ```
 
 With no target, list recent completed runs from `devflow/runs/` and `devflow/context/current-stage.md` and ask the user to choose. Never silently guess the target. If the reason is missing, ask for one before finalizing the rollback plan.
@@ -98,7 +98,7 @@ Draft the rollback plan containing:
 Present the rollback plan to the user:
 
 - Summarize affected files and dependency risks.
-- If approved, route to `/40-implement` (or allocate a dedicated Fix/Rollback Run) to safely execute the reversal steps behind review gates.
+- If approved, route to `40-implement` (or allocate a dedicated Fixrollback Run) to safely execute the reversal steps behind review gates.
 
 ## Rules
 

package/template/.agents/skills/security-review/SKILL.md

@@ -107,8 +107,8 @@ related_files: []
 
 ## 8. Next Allowed Command
 
-- `/40-Implement {running_id}` (if fail, for code remediation)
-- `/50-Verify {running_id}` (if pass, to verify execution correctness)
+- `40-implement {running_id}` (if fail, for code remediation)
+- `50-verify {running_id}` (if pass, to verify execution correctness)
 
 ## 9. Nexus Event
 
@@ -157,7 +157,7 @@ Evaluate high-severity risks including:
 
 - **Classification**: Companion command
 - **Mainline Status**: Not part of the linear Timeline. Can be run at any stage.
-- **Typical Entry Points**: Any stage, especially before `/50-Verify` or `/70-Release` to verify security health.
+- **Typical Entry Points**: Any stage, especially before `50-verify` or `70-release` to verify security health.
 
 ## Sources
 

package/template/.agents/skills/shipping-and-launch/SKILL.md

@@ -17,7 +17,7 @@ Ship with confidence. The goal is not just to deploy — it's to deploy safely,
 - Opening a beta or early access program
 - Any deployment that carries risk (all of them)
 
-In DevFlow 2.0, this skill most often supports `/70-Release` and assumes `/60-Report` is already aligned as the communication baseline.
+In DevFlow 2.0, this skill most often supports `70-release` and assumes `60-report` is already aligned as the communication baseline.
 
 ## The Pre-Launch Checklist
 

package/template/.agents/skills/simplify/SKILL.md

@@ -21,7 +21,7 @@ Treat this workflow file as a wrapper around that skill.
 
 Use this workflow when the code works but has grown harder to read, harder to change, or more general than necessary.
 
-In DevFlow 2.0, `Simplify` is a supporting implementation workflow. It usually pairs with `/40-Implement` and should end in `/50-Verify`.
+In DevFlow 2.0, `Simplify` is a supporting implementation workflow. It usually pairs with `40-implement` and should end in `50-verify`.
 
 ## Process
 
@@ -61,19 +61,19 @@ Return:
 
 - Classification: Companion command
 - Mainline status: Not a numbered stage
-- Typical entry points: `/40-Implement`, `/50-Verify`, `PR-Review`, `Agent`
-- Typical handoff targets: `/40-Implement`, `/50-Verify`, `PR-Review`
+- Typical entry points: `40-implement`, `50-verify`, `PR-Review`, `Agent`
+- Typical handoff targets: `40-implement`, `50-verify`, `PR-Review`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agents/skills/code-simplification/SKILL.md`
 - `.agent/resources/schemas/refactoring.template.md`
-- Related commands: `/40-Implement`, `/50-Verify`, `PR-Review`, `Agent`
+- Related commands: `40-implement`, `50-verify`, `PR-Review`, `Agent`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/50-Verify`
+- **Primary**: `50-verify`
 - **Why**: simplification should finish with explicit proof that behavior did not regress
-- **Alternative**: `/40-Implement` when simplification exposed a deeper implementation change rather than a pure refactor
+- **Alternative**: `40-implement` when simplification exposed a deeper implementation change rather than a pure refactor
 

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

@@ -48,8 +48,8 @@ Route proportionally:
 - `Research` or `Spec-Research` for external or technical proof
 - `Competitor` for market context
 - `PRD` for product framing
-- `/10-Define` for scope and decision locking
-- `/20-Spec` for delivery contract writing
+- `10-define` for scope and decision locking
+- `20-spec` for delivery contract writing
 
 Do not stack every support surface by default.
 
@@ -76,9 +76,9 @@ Use `.agent/resources/schemas/spec_orchestration.template.md` and replace placeh
 
 ### 5. Route Back To Mainline
 
-- `/10-Define` when the idea still needs scope decisions
-- `/20-Spec` when enough evidence exists to write the delivery contract
-- `/30-Plan` only when the spec is already solid
+- `10-define` when the idea still needs scope decisions
+- `20-spec` when enough evidence exists to write the delivery contract
+- `30-plan` only when the spec is already solid
 
 ## Output
 

package/template/.agents/skills/specialist-agent-routing/SKILL.md

@@ -76,13 +76,13 @@ Use `.agent/resources/schemas/agent_report.template.md` unless the invoking work
 
 Return to the owning step:
 
-- `/10-Define`
-- `/20-Spec`
-- `/30-Plan`
-- `/40-Implement`
-- `/50-Verify`
-- `/70-Release`
-- `/60-Report`
+- `10-define`
+- `20-spec`
+- `30-plan`
+- `40-implement`
+- `50-verify`
+- `70-release`
+- `60-report`
 - `PR-Review`
 - `Research`
 

package/template/.agents/skills/test/SKILL.md

@@ -69,14 +69,14 @@ Display an organized output listing Passed/Failed files, and explicitly show the
 
 - Classification: Companion command
 - Mainline status: Verification support command, not a numbered stage
-- Typical entry points: `/40-Implement`, `/50-Verify`, `Debug`
-- Typical handoff targets: `/50-Verify`, `Debug`, `QA-Orchestrate`
+- Typical entry points: `40-implement`, `50-verify`, `Debug`
+- Typical handoff targets: `50-verify`, `Debug`, `QA-Orchestrate`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agents/skills/test-execution-and-coverage/SKILL.md`
 - `.agent/resources/schemas/test_report.template.md`
-- Related commands: `/40-Implement`, `/50-Verify`, `Debug`, `QA-Orchestrate`
+- Related commands: `40-implement`, `50-verify`, `Debug`, `QA-Orchestrate`
 
 

package/template/.agents/skills/test-execution-and-coverage/SKILL.md

@@ -11,8 +11,8 @@ This skill complements TDD by handling test generation, execution, and persisten
 
 ## When to Use
 
-- During `/40-Implement` when tests need to be added
-- During `/50-Verify` when the test suite must be run and summarized
+- During `40-implement` when tests need to be added
+- During `50-verify` when the test suite must be run and summarized
 - During `Debug` when a bug needs a reproduction test
 
 ## Process
@@ -41,8 +41,8 @@ Use `.agent/resources/schemas/test_report.template.md` when saving a reusable re
 
 ### 4. Route Back
 
-- `/50-Verify` when tests support formal verification
-- `/40-Implement` when missing or failing tests require code changes
+- `50-verify` when tests support formal verification
+- `40-implement` when missing or failing tests require code changes
 - `Debug` when failures need RCA
 
 ## Output

package/template/.agents/skills/try/SKILL.md

@@ -8,12 +8,12 @@ description: "[Devflow] Generate human manual QA review walkthrough guide (where
 Where this sits in the workflow:
 
 ```text
-/40-implement or /50-verify or /60-report  ->  [try]  ->  human review & verification
+40-implement or 50-verify or 60-report  ->  [try]  ->  human review & verification
 (work implemented / verified)                  (manual    (where to go,
                                                steps)     what to click)
 ```
 
-`/50-verify` proves behavior from automated QA and test runs. `/try` gives the user and testers an actionable, step-by-step manual walkthrough: start this command, open this route, click these controls, expect this result, and watch for these failure signs.
+`50-verify` proves behavior from automated QA and test runs. `try` gives the user and testers an actionable, step-by-step manual walkthrough: start this command, open this route, click these controls, expect this result, and watch for these failure signs.
 
 It is always **read-only 100%**. It does not edit files, install dependencies, commit, merge, push, or run destructive commands.
 
@@ -23,7 +23,7 @@ Optional scope:
 
 - **no argument**: use the active run in `devflow/context/current-stage.md` (or the latest completed run under `devflow/runs/`)
 - `latest`: use the most recent completed run in `devflow/runs/`
-- a run ID or path: e.g. `/try RUN-002-add-onboard-adopt-doctor-skills`
+- a run ID or path: e.g. `try RUN-002-add-onboard-adopt-doctor-skills`
 - a specific route, endpoint, or CLI command: focus the walkthrough on that surface
 
 If there is no active run and no run history, ask what change or feature the user wants to test manually.

package/template/.agents/skills/verification-orchestration/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: verification-orchestration
-description: "[Devflow] Coordinate multi-lane QA, specialist review, test planning, and verification follow-up. Use when /50-Verify needs more structure than a single pass and the team needs a QA matrix or specialist routing."
+description: "[Devflow] Coordinate multi-lane QA, specialist review, test planning, and verification follow-up. Use when 50-verify needs more structure than a single pass and the team needs a QA matrix or specialist routing."
 ---
 
 # Verification Orchestration
@@ -11,7 +11,7 @@ This skill structures complex verification work across multiple QA lanes without
 
 ## When to Use
 
-- `/50-Verify` is too broad for a single simple pass
+- `50-verify` is too broad for a single simple pass
 - the change needs correctness, regression, security, performance, and UX checks together
 - the team needs specialist routing for QA
 
@@ -54,8 +54,8 @@ Use `.agent/resources/schemas/qa_orchestration.template.md` when saving a reusab
 
 ### 5. Route Back
 
-- `/50-Verify` when the QA matrix strengthens verification evidence
-- `/40-Implement` when actionable fixes are required
+- `50-verify` when the QA matrix strengthens verification evidence
+- `40-implement` when actionable fixes are required
 - `Followup` when findings become new scope
 
 ## Output

package/template/.agents/skills/wiki/SKILL.md

@@ -31,9 +31,9 @@ Use `Wiki` when:
 
 Preferred DevFlow 2.0 pairing:
 
-- after `/50-Verify`
-- after `/70-Release`
-- after `/60-Report`
+- after `50-verify`
+- after `70-release`
+- after `60-report`
 - after meaningful `Debug` or review output
 
 ## Process
@@ -131,7 +131,7 @@ Return:
 
 - Classification: Companion command
 - Mainline status: Knowledge system command, not a numbered stage
-- Typical entry points: after `/50-Verify`, `/60-Report`, `/70-Release`, `Debug`, `Insight`, `PR-Review`
+- Typical entry points: after `50-verify`, `60-report`, `70-release`, `Debug`, `Insight`, `PR-Review`
 - Typical handoff targets: return to the originating stage or finish as documentation-only work
 
 ## Sources
@@ -139,11 +139,11 @@ Return:
 - `AGENTS.md`
 - `.agent/resources/schemas/wiki_page.template.md`
 - `.agent/resources/schemas/wiki_project_index.template.md`
-- Related commands: `/50-Verify`, `/60-Report`, `/70-Release`, `Debug`, `Insight`, `PR-Review`, `Help`
+- Related commands: `50-verify`, `60-report`, `70-release`, `Debug`, `Insight`, `PR-Review`, `Help`
 
 ## Next Workflow Recommendation
 
 - **Primary**: return to the stage or artifact flow that produced the reusable knowledge
 - **Why**: `Wiki` compiles lessons after the source work is already validated
-- **Common routes**: `/60-Report`, `/70-Release`, or `/50-Verify`
+- **Common routes**: `60-report`, `70-release`, or `50-verify`