@jakkrichm/create-nexus-devflow 2.0.9 → 2.0.10

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

@@ -77,14 +77,14 @@ Help Summary:
 Environment: All OK
 
 Active Runs:
-- 010-auth-refactor: stage=40-implement | approval=Pending | next=/50-Verify 010 | warnings: manual review open
-- 011-billing-phase-1: stage=20-spec | approval=Approved | next=/30-Plan 011
-- 012-admin-console: stage=50-verify | approval=Approved | next=/60-Report 012 | warnings: not ready for release
+- 010-auth-refactor: stage=40-implement | approval=Pending | next=50-verify 010 | warnings: manual review open
+- 011-billing-phase-1: stage=20-spec | approval=Approved | next=30-plan 011
+- 012-admin-console: stage=50-verify | approval=Approved | next=60-report 012 | warnings: not ready for release
 
 Recommended Next Action:
-- 010 -> /50-Verify 010
-- 011 -> /20-Spec 011
-- 012 -> /40-Implement 012
+- 010 -> 50-verify 010
+- 011 -> 20-spec 011
+- 012 -> 40-implement 012
 ```
 
 ### Phase C: Manual Review Soft Gate
@@ -108,13 +108,13 @@ Typical warning shape:
 ```text
 Manual Review Warning:
 - 014 -> 20-spec.md still shows Approval Status: Pending
-- Recommended action: review 20-spec.md and confirm the next allowed command before moving to /30-Plan 014
+- Recommended action: review 20-spec.md and confirm the next allowed command before moving to 30-plan 014
 ```
 
 ## DevFlow 2.0 Mainline
 
 ```text
-/00-Discover -> /10-Define -> /20-Spec -> /30-Plan -> /40-Implement -> /50-Verify -> /60-Report -> /70-Release
+00-discover -> 10-define -> 20-spec -> 30-plan -> 40-implement -> 50-verify -> 60-report -> 70-release
 ```
 
 ## Public Companion Commands
@@ -163,38 +163,38 @@ These files still exist because their prompt bodies contain useful behavior, but
 
 ### 1. If the user is just starting
 
-Recommend `/00-Discover`. Discover selects `Brainstorm`, `PRD`, `Research`, `Debug`, or direct decision and owns the return synthesis.
+Recommend `00-discover`. Discover selects `Brainstorm`, `PRD`, `Research`, `Debug`, or direct decision and owns the return synthesis.
 If the request is large, high-risk, multi-phase, or requirement-heavy, explain that the run should use the manual review flow with explicit human approval at each stage.
 
 ### 2. If an approved discovery needs delivery boundaries
 
-Recommend `/10-Define {discovery_id}` so Define can create one or more Running IDs.
+Recommend `10-define {discovery_id}` so Define can create one or more Running IDs.
 
-If the go/no-go decision is not approved, return to `/00-Discover {discovery_id}` instead.
+If the go/no-go decision is not approved, return to `00-discover {discovery_id}` instead.
 
 ### 3. If the task is already defined and needs requirements
 
-Recommend `/20-Spec`.
+Recommend `20-spec`.
 
 ### 4. If requirements already exist and implementation planning is next
 
-Recommend `/30-Plan`.
+Recommend `30-plan`.
 
 ### 5. If planning is done and work should begin
 
-Recommend `/40-Implement`.
+Recommend `40-implement`.
 
 ### 6. If implementation exists and needs checking
 
-Recommend `/50-Verify`.
+Recommend `50-verify`.
 
 ### 7. If work is done and needs a final human-friendly summary before release
 
-Recommend `/60-Report`.
+Recommend `60-report`.
 
 ### 8. If the work needs packaging or release handling after the report is aligned
 
-Recommend `/70-Release`.
+Recommend `70-release`.
 
 ## General Q And A Role
 

package/template/.claude/skills/human-review-decisions/SKILL.md

@@ -18,7 +18,7 @@ This skill handles the human review loop after implementation and verification.
 
 ## When to Use
 
-- After `/50-Verify` when a human must decide whether the work is acceptable
+- After `50-verify` when a human must decide whether the work is acceptable
 - When verified work needs non-blocking feedback
 - When review fails and the task must be sent back with explicit action items
 - When a read-only re-evaluation is needed before the human chooses a decision
@@ -42,23 +42,23 @@ Read only what is necessary to understand the review question and evidence.
 
 - confirm the task is genuinely review-ready
 - record approval in the current review-facing artifact
-- route to `/60-Report` first, then `/70-Release` when release execution is the remaining step
+- route to `60-report` first, then `70-release` when release execution is the remaining step
 
 #### Feedback
 
 - record requested improvements without treating them as hard rejection
 - preserve the feedback round and source
-- route to `/40-Implement` or `/30-Plan` if the feedback changes scope
+- route to `40-implement` or `30-plan` if the feedback changes scope
 
 #### Reject
 
 - record rejection reason and concrete action items
-- route to `/40-Implement`, `/30-Plan`, or `Debug` depending on the issue
+- route to `40-implement`, `30-plan`, or `Debug` depending on the issue
 
 #### Recheck
 
 - keep the action read-only unless the user explicitly asks to record it
-- evaluate the evidence and recommend `approve`, `feedback`, `reject`, or `/50-Verify`
+- evaluate the evidence and recommend `approve`, `feedback`, `reject`, or `50-verify`
 
 ### 3. Record Reusable Lessons
 

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

@@ -70,8 +70,8 @@ Use the smallest durable destination:
 
 - stage artifacts when the lesson is specific to the current run
 - `devflow/lessons.md` for project-wide lessons
-- `/60-Report` for final narrative communication before release
-- `/70-Release` for release-facing notes and execution details
+- `60-report` for final narrative communication before release
+- `70-release` for release-facing notes and execution details
 
 For token/context learning, prefer the smallest concrete note:
 
@@ -104,22 +104,22 @@ If `post-mortem` was applied, include a short `Source Discipline` note crediting
 
 - Classification: Companion command
 - Mainline status: Knowledge capture command, not a numbered stage
-- Typical entry points: after `Debug`, `/50-Verify`, incident work, or review findings
-- Typical handoff targets: `Wiki`, `/60-Report`, `Help`
+- Typical entry points: after `Debug`, `50-verify`, incident work, or review findings
+- Typical handoff targets: `Wiki`, `60-report`, `Help`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agent/resources/schemas/lessons.template.md`
-- Related commands: `Debug`, `/50-Verify`, `Wiki`, `/60-Report`, `Help`
+- Related commands: `Debug`, `50-verify`, `Wiki`, `60-report`, `Help`
 
 ## Next Workflow Recommendation
 
 - **Primary**: `Wiki project ingest {source}` when the insight is reusable project knowledge.
 - **Why**: `Insight` extracts lessons; `Wiki` compiles selected lessons into navigable knowledge pages.
 - **Alternatives**:
-  - `/60-Report {ID}` - choose this when the insight should become the final communication summary before release.
-  - `/70-Release {ID}` - choose this when the insight should shape release packaging or execution details.
+  - `60-report {ID}` - choose this when the insight should become the final communication summary before release.
+  - `70-release {ID}` - choose this when the insight should shape release packaging or execution details.
   - `Help {ID}` - choose this when the next route is unclear.
 
 ## Wiki Update Recommendation

package/template/.claude/skills/insight-capture/SKILL.md

@@ -20,7 +20,7 @@ This skill should reuse and align with:
 
 ## When to Use
 
-- after `/50-Verify`, release preparation, or a completed implementation run
+- after `50-verify`, release preparation, or a completed implementation run
 - after debugging, regression fixes, or incidents that deserve durable learning
 - when reusable project knowledge should move into lessons, wiki material, or final reporting
 
@@ -68,7 +68,7 @@ Prefer:
 - stage artifacts when the lesson is run-specific
 - `devflow/lessons.md` for project-wide knowledge
 - `Wiki` when the knowledge should become navigable team documentation
-- `/60-Report` when the lesson belongs in the final communication package before release
+- `60-report` when the lesson belongs in the final communication package before release
 
 When updating `devflow/lessons.md`, use `.agent/resources/schemas/lessons.template.md` and replace placeholder text completely.
 
@@ -81,4 +81,4 @@ Return:
 - approach outcome
 - recommendations
 - where the insight was recorded
-- whether `Wiki` or `/60-Report` should be the next handoff
+- whether `Wiki` or `60-report` should be the next handoff

package/template/.claude/skills/intelligent-routing/SKILL.md

@@ -25,7 +25,7 @@ When routing to support skills, follow `docs/skill-selection-policy.md`.
 
 ## Timeline Stages
 
-`/00-Discover -> /10-Define -> /20-Spec -> /30-Plan -> /40-Implement -> /50-Verify -> /60-Report -> /70-Release`
+`00-discover -> 10-define -> 20-spec -> 30-plan -> 40-implement -> 50-verify -> 60-report -> 70-release`
 
 ## Public Companion Commands
 
@@ -66,14 +66,14 @@ Use these agent mappings when expert judgment is the best next step:
 
 | User State | Recommended Route |
 |---|---|
-| new request, vague or clear | `/00-Discover`; it selects support inquiry and owns the delivery decision |
-| approved discovery needs one or more delivery boundaries | `/10-Define {discovery_id}` |
-| needs requirements and acceptance criteria | `/20-Spec` |
-| has a stable spec and needs execution plan | `/30-Plan` |
-| needs implementation work | `/40-Implement` |
-| needs testing, review, or validation evidence | `/50-Verify` |
-| needs packaging, commit, PR, or release handling | `/70-Release` |
-| needs the final summary or handoff narrative | `/60-Report` |
+| new request, vague or clear | `00-discover`; it selects support inquiry and owns the delivery decision |
+| approved discovery needs one or more delivery boundaries | `10-define {discovery_id}` |
+| needs requirements and acceptance criteria | `20-spec` |
+| has a stable spec and needs execution plan | `30-plan` |
+| needs implementation work | `40-implement` |
+| needs testing, review, or validation evidence | `50-verify` |
+| needs packaging, commit, PR, or release handling | `70-release` |
+| needs the final summary or handoff narrative | `60-report` |
 
 ## Routing Heuristics
 
@@ -97,9 +97,9 @@ Use these agent mappings when expert judgment is the best next step:
 
 If `grill-with-docs` is available in the current environment, prefer it as an optional internal support skill for:
 
-- `/10-Define` when scope or terminology is unstable
-- `/20-Spec` when acceptance criteria or rules are ambiguous
-- `/30-Plan` when architecture or verification choices are still reversible but unclear
+- `10-define` when scope or terminology is unstable
+- `20-spec` when acceptance criteria or rules are ambiguous
+- `30-plan` when architecture or verification choices are still reversible but unclear
 
 Do not use deep questioning by default in every stage. Collect only the information that affects the current Timeline-stage decision.
 
@@ -111,9 +111,9 @@ Do not use deep questioning by default in every stage. Collect only the informat
 
 If `grill-with-docs` is available in the current environment, prefer it as an optional internal support skill for:
 
-- `/10-Define` when scope or terminology is unstable
-- `/20-Spec` when acceptance criteria or rules are ambiguous
-- `/30-Plan` when architecture or verification choices are still reversible but unclear
+- `10-define` when scope or terminology is unstable
+- `20-spec` when acceptance criteria or rules are ambiguous
+- `30-plan` when architecture or verification choices are still reversible but unclear
 
 Do not use deep questioning by default in every stage. Collect only the information that affects the current stage decision.
 
@@ -145,18 +145,18 @@ Key conflict defaults:
 | `grilling` vs `grill-with-docs` | `grill-with-docs` when a codebase or durable docs matter |
 | `grill-with-docs` vs `domain-modeling` | `grill-with-docs` interviews; `domain-modeling` records confirmed glossary terms or ADRs |
 | `to-prd` vs `PRD` | `PRD` owns the public surface; `to-prd` is an internal synthesis method |
-| `to-issues` vs `/30-Plan` | `/30-Plan` owns work breakdown; `to-issues` packages slices when issue tracker output is needed |
-| `implement` vs `/40-Implement` | `/40-Implement` owns implementation |
-| `review` vs `/50-Verify` | `/50-Verify` owns verification; `review` is one lane |
+| `to-issues` vs `30-plan` | `30-plan` owns work breakdown; `to-issues` packages slices when issue tracker output is needed |
+| `implement` vs `40-implement` | `40-implement` owns implementation |
+| `review` vs `50-verify` | `50-verify` owns verification; `review` is one lane |
 
 ## Examples
 
 | User Request | Route |
 |---|---|
-| "I have an idea but not the shape yet" | `/00-Discover`, likely `Brainstorm`, then return to Discover |
-| "Turn this stable new goal into requirements" | `/00-Discover`, then `/10-Define {discovery_id}` before `/20-Spec {running_id}` |
-| "Fix this newly reported broken auth flow" | `/00-Discover`, likely `Debug`, then return to Discover before Define |
-| "Review this implementation for risks" | `/50-Verify` or `Agent code-reviewer ...` |
+| "I have an idea but not the shape yet" | `00-discover`, likely `Brainstorm`, then return to Discover |
+| "Turn this stable new goal into requirements" | `00-discover`, then `10-define {discovery_id}` before `20-spec {running_id}` |
+| "Fix this newly reported broken auth flow" | `00-discover`, likely `Debug`, then return to Discover before Define |
+| "Review this implementation for risks" | `50-verify` or `Agent code-reviewer ...` |
 | "Install or upgrade Nexus-DevFlow on this machine" | `Check-For-Updates` |
 | "Help me figure out which command to use" | `Help` |
 

package/template/.claude/skills/issue-triage/SKILL.md

@@ -84,8 +84,8 @@ Use:
 - `Debug` for confirmed bugs needing root cause work
 - `Research` or `Spec-Research` for external dependency uncertainty
 - `PRD` for product-level feature requests that need problem framing
-- `/10-Define` for actionable work that still needs scope decisions
-- `/20-Spec` for work that is already stable enough to become a delivery contract
+- `10-define` for actionable work that still needs scope decisions
+- `20-spec` for work that is already stable enough to become a delivery contract
 - `Help` when the issue is not actionable yet
 
 ## Output Triage Recommendation
@@ -103,13 +103,13 @@ Return:
 - Classification: Companion command
 - Mainline status: Intake support command, not a numbered stage
 - Typical entry points: issue intake before scope or implementation begins
-- Typical handoff targets: `Debug`, `PRD`, `/10-Define`, `Research`, `Help`
+- Typical handoff targets: `Debug`, `PRD`, `10-define`, `Research`, `Help`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agent/resources/schemas/triage.template.md`
-- Related commands: `Debug`, `PRD`, `/10-Define`, `Research`, `Help`
+- Related commands: `Debug`, `PRD`, `10-define`, `Research`, `Help`
 - Support skills: `triage`, `to-issues`, `domain-modeling`
 
 

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

@@ -59,18 +59,18 @@ You are an orchestrator. Your goal is to safely integrate code and clean up loca
 - Classification: Companion command
 - Mainline status: Release support command, not a numbered stage
 - Typical entry points: after `PR` and review gates are complete
-- Typical handoff targets: `/70-Release`, `Wiki`
+- Typical handoff targets: `70-release`, `Wiki`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agents/skills/release-git-operations/SKILL.md`
 - `.agents/skills/git-workflow-and-versioning/SKILL.md`
-- Related commands: `PR`, `PR-Review`, `PR-Followup`, `/60-Report`, `/70-Release`
+- Related commands: `PR`, `PR-Review`, `PR-Followup`, `60-report`, `70-release`
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/70-Release`
+- **Primary**: `70-release`
 - **Why**: after merge, the remaining work is usually release execution, deployment coordination, or final packaging against the already aligned report.
-- **Alternative**: `/60-Report` if merge outcomes changed the story enough that the final summary must be refreshed first.
+- **Alternative**: `60-report` if merge outcomes changed the story enough that the final summary must be refreshed first.
 

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

@@ -8,15 +8,15 @@ description: "[Devflow] Set up Nexus-DevFlow after overlaying it onto a freshly
 Where this sits in the workflow:
 
 ```text
-scaffold app  ->  overlay DevFlow  ->  [onboard]  ->  /00-discover or /10-define  ->  Mainline Loop
+scaffold app  ->  overlay DevFlow  ->  [onboard]  ->  00-discover or 10-define  ->  Mainline Loop
 (user/tool)       (create-nexus)       (tune setup)   (discovery / run scoping)      (20-spec -> 70-release)
 ```
 
-`/onboard` is the fresh-project on-ramp for Nexus-DevFlow. It assumes the application was scaffolded first (e.g. via `create-next-app`, `create-vite`, `cargo new`, etc.) and DevFlow was overlaid after.
+`onboard` is the fresh-project on-ramp for Nexus-DevFlow. It assumes the application was scaffolded first (e.g. via `create-next-app`, `create-vite`, `cargo new`, etc.) and DevFlow was overlaid after.
 
-Run `/onboard` before starting discovery or delivery runs. Its job is to make DevFlow fit the real project from day one: detecting commands, project name, coding conventions, ignore rules, and tool adapters.
+Run `onboard` before starting discovery or delivery runs. Its job is to make DevFlow fit the real project from day one: detecting commands, project name, coding conventions, ignore rules, and tool adapters.
 
-Use `/adopt` instead when the app already has substantial shipped code, working routes, and existing business logic.
+Use `adopt` instead when the app already has substantial shipped code, working routes, and existing business logic.
 
 ---
 
@@ -32,7 +32,7 @@ Inspect the repository and context files:
 
 - If the project is freshly scaffolded with minimal boilerplate, proceed.
 - If `devflow/context/project-overview.md` and `devflow/context/coding-standards.md` already contain rich, user-customized content, do not overwrite them without explicit confirmation.
-- If the repository already has substantial existing routes, controllers, or database models, stop and recommend `/adopt` instead.
+- If the repository already has substantial existing routes, controllers, or database models, stop and recommend `adopt` instead.
 
 Never run a framework scaffolder. DevFlow is already overlaid.
 
@@ -125,5 +125,5 @@ Present a concise onboarding summary report:
 - Files tuned during onboarding
 - Adapter status (`.agents/`, `.claude/`)
 - Recommended next step:
-  - Run `00-discover` (or `/00-discover`, `$00-discover`) to explore the first feature or product direction
-  - Run `10-define` (or `/10-define`, `$10-define`) if the initial delivery slice is already clear and ready for execution
+  - Run `00-discover` (or `00-discover`, `$00-discover`) to explore the first feature or product direction
+  - Run `10-define` (or `10-define`, `$10-define`) if the initial delivery slice is already clear and ready for execution

package/template/.claude/skills/parallel-agents/SKILL.md

@@ -24,7 +24,7 @@ Before parallelizing:
 2. identify the lifecycle owner
 3. split the work into independent questions
 
-If those conditions are missing, return first to `/00-Discover`, `/20-Spec`, or `/30-Plan`.
+If those conditions are missing, return first to `00-discover`, `20-spec`, or `30-plan`.
 
 ## Basic Invocation Patterns
 

package/template/.claude/skills/planning-and-task-breakdown/SKILL.md

@@ -24,7 +24,7 @@ Decompose work into small, verifiable tasks with explicit acceptance criteria. G
 - You need to communicate scope to a human
 - The implementation order isn't obvious
 
-In DevFlow 2.0, this skill primarily supports `/30-Plan`.
+In DevFlow 2.0, this skill primarily supports `30-plan`.
 
 **When NOT to use:** Single-file changes with obvious scope, or when the spec already contains well-defined tasks.
 

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