@jakkrichm/create-nexus-devflow 2.0.9 → 2.0.10

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

@@ -12,7 +12,7 @@ Any time during development -> [doctor] -> Health Report & Actionable Fixes
 (read-only inspection)          (diagnostics)    (remediation recommendations)
 ```
 
-`/doctor` is a safe, read-only diagnostic skill that verifies whether your repository's Nexus-DevFlow configuration, context files, tool adapters, commands, and active runs are healthy and aligned.
+`doctor` is a safe, read-only diagnostic skill that verifies whether your repository's Nexus-DevFlow configuration, context files, tool adapters, commands, and active runs are healthy and aligned.
 
 ---
 
@@ -29,7 +29,7 @@ Run through these 5 health checks:
 ### Check 1: Core Framework & Context Files Integrity
 - Check if [AGENTS.md](AGENTS.md) and [CLAUDE.md](CLAUDE.md) exist and are populated.
 - Check required context files under `devflow/context/`:
-  - `project-overview.md` (Check if still empty/placeholder -> recommend `/onboard` or `/adopt`)
+  - `project-overview.md` (Check if still empty/placeholder -> recommend `onboard` or `adopt`)
   - `coding-standards.md` (Check if customized for stack)
   - `ai-interaction.md` (Check if rules are configured)
   - `current-stage.md` (Check if active run matches filesystem)
@@ -80,5 +80,5 @@ Present a clean, scannable diagnostic report:
 
 ### Recommended Remediation Actions:
 1. [Action item if any warning or failure detected]
-2. [Suggested next command, e.g. /devflow, /onboard, /adopt, etc.]
+2. [Suggested next command, e.g. devflow, onboard, adopt, etc.]
 ```

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

@@ -33,11 +33,11 @@ Preserve existing phases, subtasks, statuses, logs, QA results, and completed co
 
 Read:
 
-- `devflow/runs/{ID}-*/10-define.md`
-- `devflow/runs/{ID}-*/20-spec.md`
-- `devflow/runs/{ID}-*/30-plan.md`
-- `devflow/runs/{ID}-*/40-implement.md`
-- `devflow/runs/{ID}-*/50-verify.md` if present
+- `devflow/runs/{ID}-*10-define.md`
+- `devflow/runs/{ID}-*20-spec.md`
+- `devflow/runs/{ID}-*30-plan.md`
+- `devflow/runs/{ID}-*40-implement.md`
+- `devflow/runs/{ID}-*50-verify.md` if present
 
 ### 2. Classify The Follow-Up
 
@@ -57,7 +57,7 @@ Append the follow-up scope directly to the relevant stage markdown files for the
 
 ### 4. Ask For Confirmation
 
-After adding or proposing follow-up subtasks, ask the user to confirm before `/40-Implement`.
+After adding or proposing follow-up subtasks, ask the user to confirm before `40-implement`.
 
 ## Output
 
@@ -66,18 +66,18 @@ Return:
 - follow-up category
 - new phase/subtask plan
 - validation result
-- next command: `/40-Implement {ID}`
+- next command: `40-implement {ID}`
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Companion command
 - Mainline status: Not a numbered stage
 - Typical entry points: after review, triage, or release follow-up work is identified
-- Typical handoff targets: `/10-Define`, `/20-Spec`, `/30-Plan`, `/40-Implement`
+- Typical handoff targets: `10-define`, `20-spec`, `30-plan`, `40-implement`
 
 ## Sources
 
 - `AGENTS.md`
-- Related commands: `PR-Followup`, `Issue-Triage`, `Human-Feedback`, `/10-Define`, `/20-Spec`, `/40-Implement`
+- Related commands: `PR-Followup`, `Issue-Triage`, `Human-Feedback`, `10-define`, `20-spec`, `40-implement`
 
 

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

@@ -48,11 +48,11 @@ The Boss first classifies the request into one of these paths:
 
 | Flow | Use When | Typical Next Step |
 | :--- | :--- | :--- |
-| DevFlow Mainline | New feature, bug, test, docs, migration, or refactor requests. | `/00-Discover`, which owns the delivery decision |
-| PRD / Spec Orchestration | Product ideas or requirement-heavy planning before a Discovery ID exists. | `/00-Discover`, likely routing to `PRD` |
-| Brainstorm Flow | Early ambiguous ideas that need options and tradeoff analysis. | `/00-Discover`, likely routing to `Brainstorm` |
-| Research Flow | External facts, docs, codebase evidence, or feasibility proof are needed. | `/00-Discover`, likely routing to `Research` |
-| RCA / Debug Flow | Failures, errors, regressions, or investigation-heavy bug reports. | `/00-Discover`, likely routing to `Debug` |
+| DevFlow Mainline | New feature, bug, test, docs, migration, or refactor requests. | `00-discover`, which owns the delivery decision |
+| PRD / Spec Orchestration | Product ideas or requirement-heavy planning before a Discovery ID exists. | `00-discover`, likely routing to `PRD` |
+| Brainstorm Flow | Early ambiguous ideas that need options and tradeoff analysis. | `00-discover`, likely routing to `Brainstorm` |
+| Research Flow | External facts, docs, codebase evidence, or feasibility proof are needed. | `00-discover`, likely routing to `Research` |
+| RCA / Debug Flow | Failures, errors, regressions, or investigation-heavy bug reports. | `00-discover`, likely routing to `Debug` |
 
 ## Process
 
@@ -124,22 +124,22 @@ Report:
 - Classification: Companion command
 - Mainline status: Not a numbered stage
 - Typical entry points: broad goals before a Discovery ID exists
-- Typical handoff target: `/00-Discover`, with a likely companion route recorded as guidance rather than executed outside Discover
+- Typical handoff target: `00-discover`, with a likely companion route recorded as guidance rather than executed outside Discover
 
 ## Sources
 
 - `AGENTS.md`
 - `.agent/scripts/goal-runner.mjs`
-- Related commands: `/00-Discover`, `Brainstorm`, `Research`, `PRD`, `Spec-Orchestrate`, `Debug`
+- Related commands: `00-discover`, `Brainstorm`, `Research`, `PRD`, `Spec-Orchestrate`, `Debug`
 
 ## Next Workflow Recommendation
 
 - **Primary**: the first command listed in `recommended_commands`
 - **Why**: `Goal` exists to route broad intent into the correct DevFlow 2.0 entry point
 - **Alternatives**:
-  - `/00-Discover "{goal}"` for all new work; Discover chooses Brainstorm, PRD, Research, Debug, or direct decision
-  - `/10-Define {discovery_id}` only after an approved Proceed decision
-  - `/20-Spec {running_id}` only for an existing approved delivery run
+  - `00-discover "{goal}"` for all new work; Discover chooses Brainstorm, PRD, Research, Debug, or direct decision
+  - `10-define {discovery_id}` only after an approved Proceed decision
+  - `20-spec {running_id}` only for an existing approved delivery run
 
 ## Wiki Update Recommendation
 

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