@jakkrichm/create-nexus-devflow 2.0.9 → 2.0.10

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

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

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

@@ -8,14 +8,14 @@ description: "[Devflow] Survey existing brownfield codebase and bootstrap DevFlo
 Where this sits in the workflow:
 
 ```text
-existing codebase  ->  [adopt]  ->  project-overview + coding-standards  ->  /00-discover or /10-define
+existing codebase  ->  [adopt]  ->  project-overview + coding-standards  ->  00-discover or 10-define
 (already has code)     (survey +    (seeded from the real code;               (first feature / refactoring
                         interview)   shipped architecture documented)          delivery lifecycle)
 ```
 
 Standard onboarding assumes a freshly scaffolded, near-empty app. That does not fit a codebase that already has thousands of lines of working code.
 
-`/adopt` is the brownfield on-ramp for Nexus-DevFlow: it reads what is already there, asks only for what the code cannot reveal (the *intent*, the *why*, and the *upcoming roadmap*), and produces the exact context files the rest of the DevFlow lifecycle expects (`project-overview.md`, `coding-standards.md`, `AGENTS.md` commands).
+`adopt` is the brownfield on-ramp for Nexus-DevFlow: it reads what is already there, asks only for what the code cannot reveal (the *intent*, the *why*, and the *upcoming roadmap*), and produces the exact context files the rest of the DevFlow lifecycle expects (`project-overview.md`, `coding-standards.md`, `AGENTS.md` commands).
 
 ---
 
@@ -91,5 +91,5 @@ Present the adoption summary for review:
 - Inferred conventions and coding standards
 - Available verified commands in `AGENTS.md`
 - Recommended next step:
-  - Run `00-discover` (or `/00-discover`, `$00-discover`) to explore the next major initiative or feature
-  - Run `10-define` (or `/10-define`, `$10-define`) to immediately scope a delivery run for known roadmap items
+  - Run `00-discover` (or `00-discover`, `$00-discover`) to explore the next major initiative or feature
+  - Run `10-define` (or `10-define`, `$10-define`) to immediately scope a delivery run for known roadmap items

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

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

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

@@ -8,7 +8,7 @@ description: "[Devflow] Optional explicit mode for one bounded spec/plan/impleme
 Where this sits in the workflow:
 
 ```text
-/devflow  ->  [autopilot]  ->  review packet  ->  /70-release
+devflow  ->  [autopilot]  ->  review packet  ->  70-release
 (where        (spec, plan,     (human review,     (package, PR,
  are we?)      build, verify,   walkthrough)       merge with approval)
                report)
@@ -16,7 +16,7 @@ Where this sits in the workflow:
 
 Autopilot is an explicit opt-in execution skill for Nexus-DevFlow 2.0. It runs a single bounded loop across the delivery lifecycle (**`20-spec` -> `30-plan` -> `40-implement` -> `50-verify` -> `60-report`**) without requiring human confirmation between every sub-step.
 
-It does **not** replace the normal step-by-step workflow. Mainline commands (`/20-spec`, `/30-plan`, `/40-implement`, `/50-verify`, `/60-report`, `/70-release`) remain the conservative default.
+It does **not** replace the normal step-by-step workflow. Mainline commands (`20-spec`, `30-plan`, `40-implement`, `50-verify`, `60-report`, `70-release`) remain the conservative default.
 
 Do not suggest Autopilot as the default next action. Use it only when the user explicitly asks for it.
 
@@ -27,14 +27,14 @@ The explicit Autopilot request is permission to create checkpoint commits on the
 Common forms:
 
 - **No argument**: resume the active run in `devflow/context/current-stage.md`, or target the next planned run/feature in `devflow/context/project-overview.md`.
-- **Running ID or feature name**: target that run, e.g. `/autopilot RUN-004` or `/autopilot "add user authentication"`.
+- **Running ID or feature name**: target that run, e.g. `autopilot RUN-004` or `autopilot "add user authentication"`.
 - **`fix "<issue>"`**: write and execute an ad-hoc fix run.
 - **`resume`**: continue the current active run on its existing branch.
 
 If the requested target conflicts with a run already in progress, stop and ask which one should win. Do not overwrite active stage artifacts silently.
 
 > [!IMPORTANT]
-> Rollback is intentionally excluded from Autopilot. If the request is a rollback or the stage is marked Rollback, stop and direct the user to `/rollback` and reviewed `/40-implement`. Reversing completed work requires explicit dependency and human review gates.
+> Rollback is intentionally excluded from Autopilot. If the request is a rollback or the stage is marked Rollback, stop and direct the user to `rollback` and reviewed `40-implement`. Reversing completed work requires explicit dependency and human review gates.
 
 ---
 
@@ -61,7 +61,7 @@ Stop before changing files when:
 
 ## Step 2 - Choose or Write Specification (`20-spec`)
 
-1. If `devflow/runs/{running-id}-{slug}/20-spec.md` already exists, resume it.
+1. If `devflow/runs/{running-id}-{slug}20-spec.md` already exists, resume it.
 2. If no spec exists:
    - Ensure `10-define.md` exists with locked scope and allocated Running ID.
    - Write `20-spec.md` following the DevFlow specification schema.
@@ -77,7 +77,7 @@ Stop before changing files when:
    - Fix: `fix/{slug}-{running-id}`
    - Switch to or create the working branch. Never run Autopilot directly on `main` or `master`.
 2. **Planning**:
-   - Write `devflow/runs/{running-id}-{slug}/30-plan.md`.
+   - Write `devflow/runs/{running-id}-{slug}30-plan.md`.
    - Seed `checklists/implementation-checklist.md` and `checklists/verification-checklist.md`.
 
 ---
@@ -99,7 +99,7 @@ For every subtask:
    git add <modified-files> devflow/runs/{running-id}-{slug}/checklists/implementation-checklist.md
    git commit -m "feat({running-id}): checkpoint <concise step description>"
    ```
-8. Write `devflow/runs/{running-id}-{slug}/40-implement.md`.
+8. Write `devflow/runs/{running-id}-{slug}40-implement.md`.
 
 ---
 
@@ -111,7 +111,7 @@ For every subtask:
    - Project test suite (Unit tests, integration tests)
    - Build / Package smoke tests
 2. Update `checklists/verification-checklist.md` with concrete evidence.
-3. Write `devflow/runs/{running-id}-{slug}/50-verify.md` with QA verdict (`PASS` / `FAIL`).
+3. Write `devflow/runs/{running-id}-{slug}50-verify.md` with QA verdict (`PASS` / `FAIL`).
 
 ---
 
@@ -129,9 +129,9 @@ Review diffs and inspect `devflow/context/findings.md`:
 
 ## Step 7 - Delivery Digest & Review Packet (`60-report`)
 
-1. Write `devflow/runs/{running-id}-{slug}/60-report.md`.
-2. Render standalone HTML dashboard `devflow/runs/{running-id}-{slug}/60-report.html` (via `md2html` or report generator).
-3. Update `devflow/context/current-stage.md` to indicate ready for `/70-release`.
+1. Write `devflow/runs/{running-id}-{slug}60-report.md`.
+2. Render standalone HTML dashboard `devflow/runs/{running-id}-{slug}60-report.html` (via `md2html` or report generator).
+3. Update `devflow/context/current-stage.md` to indicate ready for `70-release`.
 4. Stop with a concise **Review Packet Dashboard** for human approval.
 
 ---
@@ -159,17 +159,17 @@ When Autopilot finishes successfully, output a scannable review packet:
 - **Branch**: `{branch-name}`
 - **Target Run**: `{running-id} - {title}`
 - **Artifacts Generated**:
-  - Spec: `devflow/runs/{id}/20-spec.md`
-  - Plan: `devflow/runs/{id}/30-plan.md`
-  - Implement Evidence: `devflow/runs/{id}/40-implement.md`
-  - QA Verify Report: `devflow/runs/{id}/50-verify.md`
-  - Digest Report: `devflow/runs/{id}/60-report.md`
-  - HTML Dashboard: `devflow/runs/{id}/60-report.html`
+  - Spec: `devflow/runs/{id}20-spec.md`
+  - Plan: `devflow/runs/{id}30-plan.md`
+  - Implement Evidence: `devflow/runs/{id}40-implement.md`
+  - QA Verify Report: `devflow/runs/{id}50-verify.md`
+  - Digest Report: `devflow/runs/{id}60-report.md`
+  - HTML Dashboard: `devflow/runs/{id}60-report.html`
 - **Validation & Tests**: `All Passed (Green)`
 - **Checkpoint Commits**: `{count} commits created on {branch-name}`
-- **Manual QA Walkthrough**: Run `/try {running-id}` for human review guide
+- **Manual QA Walkthrough**: Run `try {running-id}` for human review guide
 
 ---
 👉 **Next Recommended Action**:
-Inspect diffs and `/try` walkthrough, then run `/70-release {running-id}` to package, merge, or create PR.
+Inspect diffs and `try` walkthrough, then run `70-release {running-id}` to package, merge, or create PR.
 ```

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

@@ -24,10 +24,10 @@ Use it when:
 
 Preferred DevFlow 2.0 pairing:
 
-- from `/00-Discover` when the request is still fuzzy
-- from `/10-Define` when the direction is still unstable
+- from `00-discover` when the request is still fuzzy
+- from `10-define` when the direction is still unstable
 
-When invoked with a Discovery ID, link the brainstorming report to that discovery and return to `/00-Discover {discovery_id}` for synthesis. Do not allocate a Running ID or jump directly from a discovery-owned brainstorm into Define.
+When invoked with a Discovery ID, link the brainstorming report to that discovery and return to `00-discover {discovery_id}` for synthesis. Do not allocate a Running ID or jump directly from a discovery-owned brainstorm into Define.
 
 ## Behavior
 
@@ -145,24 +145,24 @@ Brainstorm caching strategy
 - Honest tradeoffs over fake confidence
 - Multiple viable paths before recommending one
 - Persistent output saved to disk
-- Mainline remains: `/00-Discover -> /10-Define -> /20-Spec -> /30-Plan -> /40-Implement -> /50-Verify -> /60-Report -> /70-Release`
+- Mainline remains: `00-discover -> 10-define -> 20-spec -> 30-plan -> 40-implement -> 50-verify -> 60-report -> 70-release`
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Companion command
 - Mainline status: Not a numbered stage
-- Typical entry points: `/00-Discover`, `/10-Define`
-- Typical handoff targets: `/00-Discover {discovery_id}` for discovery-owned work, or the active numbered stage for run-owned work
+- Typical entry points: `00-discover`, `10-define`
+- Typical handoff targets: `00-discover {discovery_id}` for discovery-owned work, or the active numbered stage for run-owned work
 
 ## Sources
 
 - `AGENTS.md`
 - `.agent/resources/schemas/brainstorm.template.md`
-- Related commands: `/00-Discover`, `/10-Define`, `Research`, `PRD`, `/20-Spec`
+- Related commands: `00-discover`, `10-define`, `Research`, `PRD`, `20-spec`
 
 ## Next Workflow Recommendation
 
-- Default: return to `/00-Discover {discovery_id}` when Discover requested the work; otherwise return to the stage that requested it
+- Default: return to `00-discover {discovery_id}` when Discover requested the work; otherwise return to the stage that requested it
 - Alternate: `Research` when facts are still missing
-- Alternate: `/10-Define` or `/20-Spec` only when the work was not opened from a pending discovery
+- Alternate: `10-define` or `20-spec` only when the work was not opened from a pending discovery
 

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

@@ -8,7 +8,7 @@ description: "[Devflow] Read-only scope, dependency, and risk pre-briefing befor
 Where this sits in the workflow:
 
 ```text
-10-define or project-overview.md  ->  [brief]  ->  /20-spec  ->  /30-plan  ->  /40-implement
+10-define or project-overview.md  ->  [brief]  ->  20-spec  ->  30-plan  ->  40-implement
 (proposed scope & context)            (read-only   (write        (break down)  (build it)
                                       explainer)    contract)
 ```
@@ -22,10 +22,10 @@ It is **strictly read-only 100%**. It never writes specs, creates directories, b
 ## Input
 
 - **no argument**: briefs the active run in `devflow/context/current-stage.md` (or the first planned feature in `devflow/context/project-overview.md`).
-- **running ID or feature name**: e.g. `/brief RUN-003`, `/brief "OAuth Login"`.
-- **topic / concern**: e.g. `/brief "database migration"`.
+- **running ID or feature name**: e.g. `brief RUN-003`, `brief "OAuth Login"`.
+- **topic / concern**: e.g. `brief "database migration"`.
 
-If there is no active run and the overview does not list planned features, plainly report that context is needed and recommend `/00-discover` or `/10-define`.
+If there is no active run and the overview does not list planned features, plainly report that context is needed and recommend `00-discover` or `10-define`.
 
 ## Step 1 - Read Context (Read-Only)
 
@@ -44,7 +44,7 @@ Evaluate:
 - **Depends On**: Required upstream models, tables, APIs, environment variables, or sibling runs.
 - **Unblocks**: Downstream features or workflows that this run enables.
 - **Touches**: Files, modules, API routes, database tables, or UI components likely to change.
-- **Estimated Size**: Small (S), Medium (M), Large (L), or Extra-Large (XL - recommend splitting in `/10-define`).
+- **Estimated Size**: Small (S), Medium (M), Large (L), or Extra-Large (XL - recommend splitting in `10-define`).
 - **Open Questions & Risks**: Ambiguous requirements, missing external APIs, or complex migrations.
 
 ## Step 3 - Output Structured Briefing
@@ -59,16 +59,16 @@ Produce a short, scannable briefing:
 - **Unblocks**: Downstream capabilities enabled by this feature.
 - **Touches**: Anticipated files, schemas, endpoints, and UI views.
 - **Estimated Scope & Size**: `[S / M / L / XL]` (and split recommendation if XL).
-- **Key Risks & Open Questions**: Technical or product unknowns that must be settled in `/20-spec`.
+- **Key Risks & Open Questions**: Technical or product unknowns that must be settled in `20-spec`.
 
 ---
-👉 **Next Recommended Action**: `/20-spec {running-id}` (or resolve prerequisite blocker first).
+👉 **Next Recommended Action**: `20-spec {running-id}` (or resolve prerequisite blocker first).
 ```
 
 ## Rules
 
 - **Always Read-Only**: Never edit any workspace file, never allocate running IDs, never commit or execute scripts.
-- **Explain, Don't Spec**: Focus on scope, architectural dependencies, and size estimation. The formal delivery contract is the responsibility of `/20-spec`.
+- **Explain, Don't Spec**: Focus on scope, architectural dependencies, and size estimation. The formal delivery contract is the responsibility of `20-spec`.
 - **Ground In Reality**: Trace all assertions back to `project-overview.md` or actual codebase facts. Do not invent non-existent packages or fictional architecture.
 - **Highlight Blockers Early**: Flagging a missing prerequisite before speccing is the primary value of this command.
 

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

@@ -96,14 +96,14 @@ When changelog input is too implementation-heavy, apply `.agents/skills/9arm-ski
 
 - Classification: Companion command
 - Mainline status: Release communication support, not a numbered stage
-- Typical entry points: `/70-Release`, `Deploy`, `PR`
-- Typical handoff targets: `/60-Report`, `Wiki`
+- Typical entry points: `70-release`, `Deploy`, `PR`
+- Typical handoff targets: `60-report`, `Wiki`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agents/skills/release-git-operations/SKILL.md`
 - `.agent/resources/schemas/changelog_entry.template.md`
-- Related commands: `/70-Release`, `Deploy`, `PR`, `/60-Report`, `Wiki`
+- Related commands: `70-release`, `Deploy`, `PR`, `60-report`, `Wiki`
 
 

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

@@ -8,7 +8,7 @@ description: "[Devflow] Set up automated GitHub Actions CI workflow (.github/wor
 Where this sits in the workflow:
 
 ```text
-/onboard or /adopt  ->  [ci]  ->  Verify locally  ->  GitHub Actions runs Verify on PR & Push
+onboard or adopt  ->  [ci]  ->  Verify locally  ->  GitHub Actions runs Verify on PR & Push
 (project setup)         (setup)    (same command)     (automated checks)
 ```
 

package/template/.agents/skills/ci-cd-and-automation/SKILL.md

@@ -58,7 +58,7 @@ Pull Request Opened
 ### Basic CI Pipeline
 
 ```yaml
-# .github/workflows/ci.yml
+# .github/workflowsci.yml
 name: CI
 
 on:
@@ -127,11 +127,11 @@ jobs:
       - name: Run migrations
         run: npx prisma migrate deploy
         env:
-          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
+          DATABASE_URL: postgresql:/ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
       - name: Integration tests
         run: npm run test:integration
         env:
-          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
+          DATABASE_URL: postgresql:/ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
 ```
 
 > **Note:** Even for CI-only test databases, use GitHub Secrets for credentials rather than hardcoding values. This builds good habits and prevents accidental reuse of test credentials in other contexts.

package/template/.agents/skills/codebase-design/SKILL.md

@@ -5,16 +5,16 @@ description: "[Devflow] Shared vocabulary for designing deep modules. Use when a
 
 # Codebase Design
 
-Use this support skill when `/20-Spec`, `/30-Plan`, `/40-Implement`, or `/50-Verify` needs better module shape.
+Use this support skill when `20-spec`, `30-plan`, `40-implement`, or `50-verify` needs better module shape.
 
 Design deep modules: a lot of behavior behind a small interface, placed at a clean seam, and testable through that interface. The aim is leverage for callers, locality for maintainers, and behavior-focused tests.
 
 ## DevFlow Placement
 
-- `/20-Spec`: use when requirements depend on a stable module or interface contract.
-- `/30-Plan`: use when planning needs file-level architecture, seams, or dependency strategy.
-- `/40-Implement`: use when implementation reveals shallow modules or awkward test seams.
-- `/50-Verify`: use when review finds code that is hard to test, hard to change, or too spread out.
+- `20-spec`: use when requirements depend on a stable module or interface contract.
+- `30-plan`: use when planning needs file-level architecture, seams, or dependency strategy.
+- `40-implement`: use when implementation reveals shallow modules or awkward test seams.
+- `50-verify`: use when review finds code that is hard to test, hard to change, or too spread out.
 
 ## Vocabulary
 

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

@@ -50,14 +50,14 @@ You are an orchestrator. Your goal is to call the specialized Git Committer agen
 
 - Classification: Companion command
 - Mainline status: Release support command, not a numbered stage
-- Typical entry points: `/70-Release` after the report is aligned and release execution is ready
-- Typical handoff targets: `PR`, `Deploy`, `/70-Release`
+- Typical entry points: `70-release` after the report is aligned and release execution is ready
+- Typical handoff targets: `PR`, `Deploy`, `70-release`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agents/skills/release-git-operations/SKILL.md`
 - `.agents/skills/git-workflow-and-versioning/SKILL.md`
-- Related commands: `/70-Release`, `PR`, `Deploy`, `Merge`
+- Related commands: `70-release`, `PR`, `Deploy`, `Merge`
 
 

package/template/.agents/skills/competitor-analysis/SKILL.md

@@ -51,9 +51,9 @@ Use `.agent/resources/schemas/competitor_analysis.template.md` when saving a reu
 ### 5. Route Back
 
 - `PRD` for product framing
-- `/10-Define` for scope and decision shaping
+- `10-define` for scope and decision shaping
 - `Roadmap` for prioritization
-- `/20-Spec` when a selected opportunity becomes actionable
+- `20-spec` when a selected opportunity becomes actionable
 
 ## Output
 

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

@@ -27,11 +27,11 @@ Use it when:
 
 Preferred DevFlow 2.0 pairing:
 
-- from `/00-Discover` when a new request begins with a failure whose root cause is unknown
-- from `/40-Implement`
-- from `/50-Verify`
+- from `00-discover` when a new request begins with a failure whose root cause is unknown
+- from `40-implement`
+- from `50-verify`
 
-When invoked with a Discovery ID, link the RCA report to that discovery and return to `/00-Discover {discovery_id}` for the delivery decision. Do not allocate a Running ID for an unapproved fix during Debug.
+When invoked with a Discovery ID, link the RCA report to that discovery and return to `00-discover {discovery_id}` for the delivery decision. Do not allocate a Running ID for an unapproved fix during Debug.
 
 ## Source Discipline
 
@@ -114,18 +114,18 @@ Debug unexpected duplicate records
 
 - Classification: Companion command
 - Mainline status: Not a numbered stage
-- Typical entry points: `/00-Discover`, `/40-Implement`, `/50-Verify`, `Issue-Triage`, production failure analysis
-- Typical handoff targets: `/00-Discover {discovery_id}` for discovery-owned RCA, `/40-Implement`, `/50-Verify`, `Insight`, `Wiki`
+- Typical entry points: `00-discover`, `40-implement`, `50-verify`, `Issue-Triage`, production failure analysis
+- Typical handoff targets: `00-discover {discovery_id}` for discovery-owned RCA, `40-implement`, `50-verify`, `Insight`, `Wiki`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agent/resources/schemas/rca.template.md`
-- Related commands: `/40-Implement`, `/50-Verify`, `Test`, `Insight`, `Wiki`, `Agent`
+- Related commands: `40-implement`, `50-verify`, `Test`, `Insight`, `Wiki`, `Agent`
 
 ## Next Workflow Recommendation
 
-- Default: return to `/00-Discover {discovery_id}` when the failure entered through discovery; otherwise return to `/40-Implement` when a tracked fix already exists
-- Alternate: `/30-Plan` if the fix needs planning changes
-- Alternate: `/50-Verify` when the issue is resolved and needs re-checking
+- Default: return to `00-discover {discovery_id}` when the failure entered through discovery; otherwise return to `40-implement` when a tracked fix already exists
+- Alternate: `30-plan` if the fix needs planning changes
+- Alternate: `50-verify` when the issue is resolved and needs re-checking
 

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

@@ -76,8 +76,8 @@ Generate an Error summary detailing:
 
 - Classification: Companion command
 - Mainline status: Release support command, not a numbered stage
-- Typical entry points: `/70-Release` after the report is aligned and packaging is ready to execute
-- Typical handoff targets: `/60-Report`, `Changelog`, `Wiki`
+- Typical entry points: `70-release` after the report is aligned and packaging is ready to execute
+- Typical handoff targets: `60-report`, `Changelog`, `Wiki`
 
 ## Sources
 
@@ -86,6 +86,6 @@ Generate an Error summary detailing:
 - `.agents/skills/shipping-and-launch/SKILL.md`
 - `.agents/skills/deployment-procedures/SKILL.md`
 - `.agent/resources/schemas/deploy_report.template.md`
-- Related commands: `/70-Release`, `Commit`, `PR`, `Changelog`, `/60-Report`
+- Related commands: `70-release`, `Commit`, `PR`, `Changelog`, `60-report`
 
 

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

@@ -9,14 +9,14 @@ Use this skill to guide the user on what to do next, inspect current workspace s
 
 ## Input
 
-- **No argument (`devflow`, `/devflow`, `$devflow`, or `status`)**: Inspect current workspace state (active run in `devflow/runs/` or `devflow/context/current-stage.md`, active discovery in `devflow/discoveries/`, open findings in `devflow/context/findings.md`, and project overview in `devflow/context/project-overview.md`) and recommend the exact next action.
+- **No argument (`devflow`, `devflow`, `$devflow`, or `status`)**: Inspect current workspace state (active run in `devflow/runs/` or `devflow/context/current-stage.md`, active discovery in `devflow/discoveries/`, open findings in `devflow/context/findings.md`, and project overview in `devflow/context/project-overview.md`) and recommend the exact next action.
 - **With user request (`devflow "<request>"`)**: Classify the user's intent and guide them to the matching DevFlow 2.0 stage or companion command path.
 
 ## Workspace State Inspection
 
 When invoked without an argument (or when determining the next step), inspect:
 
-1. **Project Setup Baseline**: Read `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`. If they are empty or default placeholders, recommend `/onboard` (for fresh projects) or `/adopt` (for existing codebases).
+1. **Project Setup Baseline**: Read `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`. If they are empty or default placeholders, recommend `onboard` (for fresh projects) or `adopt` (for existing codebases).
 2. **Active Delivery Run**: Read `devflow/context/current-stage.md` and check `devflow/runs/{RUNNING_ID}/` for active artifacts (`10-define.md`, `20-spec.md`, `30-plan.md`, `40-implement.md`, `50-verify.md`, `60-report.md`, `70-release.md`).
 3. **Active Discovery**: Check `devflow/discoveries/` for open discovery notes.
 4. **Audit Findings Ledger**: Check `devflow/context/findings.md` for open high-severity findings.
@@ -24,15 +24,15 @@ When invoked without an argument (or when determining the next step), inspect:
 ### State-Based Recommendation Rules
 
 - If context is empty/unconfigured -> Recommend `onboard` (for fresh project) or `adopt` (for brownfield codebase).
-- If a run is at `10-define.md` -> Recommend `20-spec {RUNNING_ID}` (or `/20-spec`, `$20-spec`, `spec`).
-- If a run is at `20-spec.md` -> Recommend `30-plan {RUNNING_ID}` (or `/30-plan`, `$30-plan`, `plan`).
-- If a run is at `30-plan.md` -> Recommend `40-implement {RUNNING_ID}` (or `/40-implement`, `$40-implement`, `implement`).
+- If a run is at `10-define.md` -> Recommend `20-spec {RUNNING_ID}` (or `20-spec`, `$20-spec`, `spec`).
+- If a run is at `20-spec.md` -> Recommend `30-plan {RUNNING_ID}` (or `30-plan`, `$30-plan`, `plan`).
+- If a run is at `30-plan.md` -> Recommend `40-implement {RUNNING_ID}` (or `40-implement`, `$40-implement`, `implement`).
 - If a run is at `40-implement.md` with incomplete tasks -> Recommend `40-implement {RUNNING_ID}`.
-- If a run is at `40-implement.md` with all tasks done -> Recommend `50-verify {RUNNING_ID}` (or `/50-verify`, `$50-verify`, `verify`).
+- If a run is at `40-implement.md` with all tasks done -> Recommend `50-verify {RUNNING_ID}` (or `50-verify`, `$50-verify`, `verify`).
 - If a run passed `50-verify.md` -> Recommend `60-report {RUNNING_ID}` then `70-release {RUNNING_ID}`.
 - If no run is active and user wants to explore an idea -> Recommend `00-discover` (or `discover`, `Brainstorm`).
 - If no run is active and open P0/P1 findings exist -> Recommend `security-review` or `debug`.
-- If user asks to check system health or configuration -> Recommend `doctor` (or `/doctor`, `$doctor`).
+- If user asks to check system health or configuration -> Recommend `doctor` (or `doctor`, `$doctor`).
 
 ## Intent Classification & Skill Routing
 
@@ -71,25 +71,25 @@ When the user specifies a request, map it to the matching DevFlow 2.0 stage or c
 Always provide a clean summary of available Nexus-DevFlow skills grouped by lifecycle stage:
 
 ### 1. Mainline Lifecycle Stages (Linear Order)
-- `00-discover` (`discover`, `/00-discover`, `$00-discover`) - Explore request, route inquiries, go/no-go under Discovery ID
-- `10-define` (`define`, `/10-define`, `$10-define`) - Lock delivery boundaries and allocate Running ID (`devflow/runs/{ID}`)
-- `20-spec` (`spec`, `/20-spec`, `$20-spec`) - Formalize markdown-first specifications and acceptance criteria
-- `30-plan` (`plan`, `/30-plan`, `$30-plan`) - Transform spec into executable task breakdown with test decisions
-- `40-implement` (`implement`, `/40-implement`, `$40-implement`) - Execute planned tasks incrementally with evidence
-- `50-verify` (`verify`, `/50-verify`, `$50-verify`) - Senior QA review, validation checks, and pass/fail gate
-- `60-report` (`report`, `/60-report`, `$60-report`) - Generate standardized markdown and HTML summary report
-- `70-release` (`release`, `/70-release`, `$70-release`) - Package verified work for PR merge or deployment
+- `00-discover` (`discover`, `00-discover`, `$00-discover`) - Explore request, route inquiries, go/no-go under Discovery ID
+- `10-define` (`define`, `10-define`, `$10-define`) - Lock delivery boundaries and allocate Running ID (`devflow/runs/{ID}`)
+- `20-spec` (`spec`, `20-spec`, `$20-spec`) - Formalize markdown-first specifications and acceptance criteria
+- `30-plan` (`plan`, `30-plan`, `$30-plan`) - Transform spec into executable task breakdown with test decisions
+- `40-implement` (`implement`, `40-implement`, `$40-implement`) - Execute planned tasks incrementally with evidence
+- `50-verify` (`verify`, `50-verify`, `$50-verify`) - Senior QA review, validation checks, and pass/fail gate
+- `60-report` (`report`, `60-report`, `$60-report`) - Generate standardized markdown and HTML summary report
+- `70-release` (`release`, `70-release`, `$70-release`) - Package verified work for PR merge or deployment
 
 ### 2. Public Companion Commands
-- `devflow` (`status`, `/devflow`, `$devflow`) - Guide, state inspector, and intent router
-- `onboard` (`/onboard`, `$onboard`) - Baseline stack setup for freshly scaffolded projects
-- `adopt` (`/adopt`, `$adopt`) - Survey and bootstrap DevFlow into existing brownfield projects
-- `doctor` (`/doctor`, `$doctor`) - Read-only health check for setup, scripts, and workflow drift
-- `try` (`/try`, `$try`) - Step-by-step human manual QA review guide (where to go, what to click, what to expect)
-- `rollback` (`/rollback`, `$rollback`) - Safe feature/run reversal planner with dependency risk analysis
-- `ci` (`/ci`, `$ci`) - Automatic GitHub Actions workflow (`.github/workflows/verify.yml`) setup
-- `brief` (`/brief`, `$brief`) - Read-only scope, dependency, and size pre-briefing before speccing
-- `autopilot` (`/autopilot`, `$autopilot`) - Optional bounded autonomous loop (spec -> plan -> implement -> verify -> report)
+- `devflow` (`status`, `devflow`, `$devflow`) - Guide, state inspector, and intent router
+- `onboard` (`onboard`, `$onboard`) - Baseline stack setup for freshly scaffolded projects
+- `adopt` (`adopt`, `$adopt`) - Survey and bootstrap DevFlow into existing brownfield projects
+- `doctor` (`doctor`, `$doctor`) - Read-only health check for setup, scripts, and workflow drift
+- `try` (`try`, `$try`) - Step-by-step human manual QA review guide (where to go, what to click, what to expect)
+- `rollback` (`rollback`, `$rollback`) - Safe feature/run reversal planner with dependency risk analysis
+- `ci` (`ci`, `$ci`) - Automatic GitHub Actions workflow (`.github/workflows/verify.yml`) setup
+- `brief` (`brief`, `$brief`) - Read-only scope, dependency, and size pre-briefing before speccing
+- `autopilot` (`autopilot`, `$autopilot`) - Optional bounded autonomous loop (spec -> plan -> implement -> verify -> report)
 - `goal` - Route broad goals before Discovery
 - `brainstorm` - Ideate without allocating running IDs
 - `research` - Conduct codebase or web research

package/template/.agents/skills/diagnosing-bugs/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: diagnosing-bugs
-description: "[Devflow] Diagnosis loop for hard bugs and performance regressions. Use inside Debug, /40-Implement, or /50-Verify when behavior is broken, throwing, failing, flaky, or slow."
+description: "[Devflow] Diagnosis loop for hard bugs and performance regressions. Use inside Debug, 40-implement, or 50-verify when behavior is broken, throwing, failing, flaky, or slow."
 ---
 
 # Diagnosing Bugs
 
 Use this support skill when the active DevFlow owner needs a disciplined root-cause loop.
 
-Do not let this skill replace `Debug`, `/40-Implement`, or `/50-Verify`. It supplies the method; the owning workflow records the artifact.
+Do not let this skill replace `Debug`, `40-implement`, or `50-verify`. It supplies the method; the owning workflow records the artifact.
 
 ## Phase 1: Build A Tight Feedback Loop
 
@@ -79,7 +79,7 @@ When a correct test seam exists:
 4. Watch it pass.
 5. Re-run the original feedback loop.
 
-If no correct seam exists, record that architecture finding and route to `codebase-design` or `/30-Plan` after the bug is fixed.
+If no correct seam exists, record that architecture finding and route to `codebase-design` or `30-plan` after the bug is fixed.
 
 ## Phase 6: Cleanup And Post-Mortem