@jakkrichm/create-nexus-devflow 2.0.8 → 2.0.10

package/template/.agents/skills/silent-failure-audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: silent-failure-audit
-description: Audits error handling, logging, fallbacks, and observability for silent failures. Use after adding catch blocks, fallback logic, retry handling, optional chaining, or user-facing failure paths.
+description: "[Devflow] Audits error handling, logging, fallbacks, and observability for silent failures. Use after adding catch blocks, fallback logic, retry handling, optional chaining, or user-facing failure paths."
 ---
 
 # Silent Failure Audit

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

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

package/template/.agents/skills/skill-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: skill-development
-description: Guides the creation and maintenance of agent skills. Use when building new skills or modifying existing ones to ensure they follow the PRP framework standards.
+description: "[Devflow] Guides the creation and maintenance of agent skills. Use when building new skills or modifying existing ones to ensure they follow the PRP framework standards."
 ---
 
 # Skill Development (Skill Anatomy)

package/template/.agents/skills/spec-driven-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spec-driven-development
-description: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea.
+description: "[Devflow] Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea."
 ---
 
 # Spec-Driven Development

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

@@ -1,6 +1,6 @@
 ---
 name: spec-orchestration
-description: Coordinate Brainstorm, Research, PRD, competitor context, and spec critique before the work re-enters the numbered mainline. Use when a broad idea needs orchestration rather than a straight pass.
+description: "[Devflow] Coordinate Brainstorm, Research, PRD, competitor context, and spec critique before the work re-enters the numbered mainline. Use when a broad idea needs orchestration rather than a straight pass."
 ---
 
 # Spec Orchestration
@@ -48,8 +48,8 @@ Route proportionally:
 - `Research` or `Spec-Research` for external or technical proof
 - `Competitor` for market context
 - `PRD` for product framing
-- `/10-Define` for scope and decision locking
-- `/20-Spec` for delivery contract writing
+- `10-define` for scope and decision locking
+- `20-spec` for delivery contract writing
 
 Do not stack every support surface by default.
 
@@ -76,9 +76,9 @@ Use `.agent/resources/schemas/spec_orchestration.template.md` and replace placeh
 
 ### 5. Route Back To Mainline
 
-- `/10-Define` when the idea still needs scope decisions
-- `/20-Spec` when enough evidence exists to write the delivery contract
-- `/30-Plan` only when the spec is already solid
+- `10-define` when the idea still needs scope decisions
+- `20-spec` when enough evidence exists to write the delivery contract
+- `30-plan` only when the spec is already solid
 
 ## Output
 

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

@@ -1,6 +1,6 @@
 ---
 name: specialist-agent-routing
-description: Route a request to the right specialist agent and preserve the DevFlow 2.0 stage-first contract. Use when the user wants direct specialist judgment on a file, folder, workspace, or concern.
+description: "[Devflow] Route a request to the right specialist agent and preserve the DevFlow 2.0 stage-first contract. Use when the user wants direct specialist judgment on a file, folder, workspace, or concern."
 ---
 
 # Specialist Agent Routing
@@ -76,13 +76,13 @@ Use `.agent/resources/schemas/agent_report.template.md` unless the invoking work
 
 Return to the owning step:
 
-- `/10-Define`
-- `/20-Spec`
-- `/30-Plan`
-- `/40-Implement`
-- `/50-Verify`
-- `/70-Release`
-- `/60-Report`
+- `10-define`
+- `20-spec`
+- `30-plan`
+- `40-implement`
+- `50-verify`
+- `70-release`
+- `60-report`
 - `PR-Review`
 - `Research`
 

package/template/.agents/skills/tailwind-patterns/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tailwind-patterns
-description: Tailwind CSS v4 principles. CSS-first configuration, container queries, modern patterns, design token architecture.
+description: "[Devflow] Tailwind CSS v4 principles. CSS-first configuration, container queries, modern patterns, design token architecture."
 allowed-tools: Read, Write, Edit, Glob, Grep
 ---
 

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

@@ -1,6 +1,6 @@
 ---
 name: test
-description: Test workflow
+description: "[Devflow] Test execution, missing test generation, and coverage analysis across unit, integration, and smoke test suites."
 ---
 
 ---
@@ -69,14 +69,14 @@ Display an organized output listing Passed/Failed files, and explicitly show the
 
 - Classification: Companion command
 - Mainline status: Verification support command, not a numbered stage
-- Typical entry points: `/40-Implement`, `/50-Verify`, `Debug`
-- Typical handoff targets: `/50-Verify`, `Debug`, `QA-Orchestrate`
+- Typical entry points: `40-implement`, `50-verify`, `Debug`
+- Typical handoff targets: `50-verify`, `Debug`, `QA-Orchestrate`
 
 ## Sources
 
 - `AGENTS.md`
 - `.agents/skills/test-execution-and-coverage/SKILL.md`
 - `.agent/resources/schemas/test_report.template.md`
-- Related commands: `/40-Implement`, `/50-Verify`, `Debug`, `QA-Orchestrate`
+- Related commands: `40-implement`, `50-verify`, `Debug`, `QA-Orchestrate`
 
 

package/template/.agents/skills/test-driven-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: test-driven-development
-description: Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.
+description: "[Devflow] Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality."
 ---
 
 # Test-Driven Development

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

@@ -1,6 +1,6 @@
 ---
 name: test-execution-and-coverage
-description: Generate missing tests, run existing tests, and summarize coverage and failures. Use when implementation or verification needs explicit testing evidence beyond a general TDD reminder.
+description: "[Devflow] Generate missing tests, run existing tests, and summarize coverage and failures. Use when implementation or verification needs explicit testing evidence beyond a general TDD reminder."
 ---
 
 # Test Execution And Coverage
@@ -11,8 +11,8 @@ This skill complements TDD by handling test generation, execution, and persisten
 
 ## When to Use
 
-- During `/40-Implement` when tests need to be added
-- During `/50-Verify` when the test suite must be run and summarized
+- During `40-implement` when tests need to be added
+- During `50-verify` when the test suite must be run and summarized
 - During `Debug` when a bug needs a reproduction test
 
 ## Process
@@ -41,8 +41,8 @@ Use `.agent/resources/schemas/test_report.template.md` when saving a reusable re
 
 ### 4. Route Back
 
-- `/50-Verify` when tests support formal verification
-- `/40-Implement` when missing or failing tests require code changes
+- `50-verify` when tests support formal verification
+- `40-implement` when missing or failing tests require code changes
 - `Debug` when failures need RCA
 
 ## Output

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

@@ -0,0 +1,108 @@
+---
+name: try
+description: "[Devflow] Generate human manual QA review walkthrough guide (where to go, what to click, what to expect)."
+---
+
+# try - Manual QA & Review Walkthrough Guide
+
+Where this sits in the workflow:
+
+```text
+40-implement or 50-verify or 60-report  ->  [try]  ->  human review & verification
+(work implemented / verified)                  (manual    (where to go,
+                                               steps)     what to click)
+```
+
+`50-verify` proves behavior from automated QA and test runs. `try` gives the user and testers an actionable, step-by-step manual walkthrough: start this command, open this route, click these controls, expect this result, and watch for these failure signs.
+
+It is always **read-only 100%**. It does not edit files, install dependencies, commit, merge, push, or run destructive commands.
+
+## Input
+
+Optional scope:
+
+- **no argument**: use the active run in `devflow/context/current-stage.md` (or the latest completed run under `devflow/runs/`)
+- `latest`: use the most recent completed run in `devflow/runs/`
+- a run ID or path: e.g. `try RUN-002-add-onboard-adopt-doctor-skills`
+- a specific route, endpoint, or CLI command: focus the walkthrough on that surface
+
+If there is no active run and no run history, ask what change or feature the user wants to test manually.
+
+## Step 1 - Find The Work To Explain
+
+Read:
+
+- `AGENTS.md` (Commands section)
+- `devflow/context/current-stage.md`
+- `devflow/context/project-overview.md`
+- `devflow/context/coding-standards.md`
+- Active run artifacts: `20-spec.md`, `30-plan.md`, `40-implement.md`, `50-verify.md` (or archived run artifacts)
+- Current git branch and status
+
+Do not dump the full spec. Extract only the concrete routes, screens, CLI commands, API endpoints, test data, and expected outcomes that a human needs to verify the feature.
+
+## Step 2 - Identify How To Run The App
+
+Check the Commands section in `AGENTS.md`. Adapt to the project type:
+
+- **Web app**: dev server command (e.g. `npm run dev`), local URL (e.g. `http://localhost:3000`), and specific route/screen.
+- **Server / API**: start command, base URL, endpoint, HTTP method, payload, and expected response shape.
+- **CLI**: exact CLI command, flags, arguments, and expected terminal output.
+- **Library / Module**: sample usage snippet, REPL call, or interactive test command.
+- **Fullstack / Microservices**: minimal combined startup commands (e.g. backend + frontend).
+
+If a startup command is missing or unclear in `AGENTS.md`, report that as a configuration gap rather than guessing.
+
+## Step 3 - Produce The Manual Walkthrough Guide
+
+Format the guide with these 5 standard sections:
+
+1. **1. Start** - exact command(s) to start the system and where to run them.
+2. **2. Open** - URL(s), screens, tabs, API endpoints, or terminal locations.
+3. **3. Do** - specific clicks, form inputs, toggles, selections, or arguments.
+4. **4. Expect** - expected visible UI change, response payload, state change, output, or absence of errors.
+5. **5. Watch For** - common failure symptoms, console errors, network 4xx/5xx errors, stale state, layout breakage, or safety warnings.
+
+### Example Walkthrough Style:
+
+```markdown
+### 1. Start
+Run `npm run dev` in the project root.
+
+### 2. Open
+Navigate to `http://localhost:3000/dashboard/reports`.
+
+### 3. Do
+1. Click the **"Export Report"** button in the top right.
+2. Select **"Format: HTML"** from the dropdown.
+3. Click **"Download"**.
+
+### 4. Expect
+- A new file `report.html` is downloaded.
+- The UI displays a green success toast: *"Report exported successfully"*.
+- The downloaded HTML file opens in the browser with full styling and charts.
+
+### 5. Watch For
+- Spinner hanging indefinitely without downloading.
+- Console error related to `Blob` or `URL.createObjectURL`.
+- Broken styling or unrendered Mermaid charts in the exported HTML.
+```
+
+## Step 4 - Include Confidence, Best Signal & Gaps
+
+Conclude with:
+
+- **Best Signal**: the single most critical action the user should try first to confirm functionality.
+- **Edge Cases & Error Flows**: optional secondary checks (e.g. invalid input, empty state, network failure).
+- **Gaps & Assumptions**: anything the guide cannot know for certain (e.g. seed credentials, third-party API keys, required database fixtures).
+
+## Rules
+
+- **Strictly Read-Only**: Never edit code, commit, push, install packages, or mutate repository state.
+- **Do Not Run Automatically**: Do not launch the server or run commands unless the user explicitly instructs you to do so in the chat.
+- **Be Concrete & Specific**: Provide exact URLs, button labels, and payloads.
+- **Acknowledge Uncertainty**: If a route or behavior is not specified in the spec, state it clearly as an assumption.
+
+## Output Formatting
+
+Follow the project conventions in `devflow/context/ai-interaction.md`: concise, scannable markdown with numbered steps and clear bold headers.

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

@@ -1,6 +1,6 @@
 ---
 name: type-design
-description: Analyzes type and interface design for encapsulation, invariant expression, usefulness, and enforcement. Use when introducing new types, reviewing PRs with type changes, or refactoring domain models.
+description: "[Devflow] Analyzes type and interface design for encapsulation, invariant expression, usefulness, and enforcement. Use when introducing new types, reviewing PRs with type changes, or refactoring domain models."
 ---
 
 # Type Design

package/template/.agents/skills/ui-ux-pro-max/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ui-ux-pro-max
-description: AI-powered design intelligence with 50+ styles, 95+ color palettes, and automated design system generation. Use when designing, building, or reviewing UI/UX.
+description: "[Devflow] AI-powered design intelligence with 50+ styles, 95+ color palettes, and automated design system generation. Use when designing, building, or reviewing UI/UX."
 ---
 
 # UI/UX Pro Max (Design Intelligence)

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

@@ -1,6 +1,6 @@
 ---
 name: using-agent-skills
-description: Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
+description: "[Devflow] Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked."
 ---
 
 # Using Agent Skills

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

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

package/template/.agents/skills/vulnerability-scanner/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vulnerability-scanner
-description: Advanced vulnerability analysis principles. OWASP 2025, Supply Chain Security, attack surface mapping, risk prioritization.
+description: "[Devflow] Advanced vulnerability analysis principles. OWASP 2025, Supply Chain Security, attack surface mapping, risk prioritization."
 allowed-tools: Read, Glob, Grep, Bash
 ---
 

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

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

package/template/.agents/skills/workflow-documentation-sync/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: workflow-documentation-sync
-description: Enforces the synchronization and comprehensive update of documentation, manuals, usage guides, and examples whenever a new workflow is introduced or modified in the project. Use when introducing new workflows or changing existing ones.
+description: "[Devflow] Enforces the synchronization and comprehensive update of documentation, manuals, usage guides, and examples whenever a new workflow is introduced or modified in the project. Use when introducing new workflows or changing existing ones."
 ---
 
 # Workflow Documentation Sync
@@ -27,7 +27,7 @@ Whenever a workflow is added or modified, compile the list of documents that mus
 
 ### Step 2: Extract Workflow Metadata
 Identify the exact interface changes:
-- What is the **Command trigger**? (e.g., `/70-Release` or `Brainstorm`)
+- What is the **Command trigger**? (e.g., `70-release` or `Brainstorm`)
 - What are the **Arguments**? (e.g., Target Branch, default main)
 - What is the **Process flow**? (Pre-flight -> Execution -> Cleanup)
 - What are the **Mandatory Rules**? (e.g., Enforced branch checks)

package/template/.claude/skills/00-discover/SKILL.md

@@ -1,6 +1,6 @@
 ---name: 00-discover
 
-description: Discover stage in DevFlow 2.0 - explore a request, route supporting inquiry, and decide whether delivery work should begin without allocating a running ID.
+description: "[Devflow] Discover stage in DevFlow 2.0 - explore a request, route supporting inquiry, and decide whether delivery work should begin without allocating a running ID."
 argument-hint: "{title, request, or discovery-id}"
 ---
 
@@ -13,8 +13,8 @@ Explore a request before delivery commitment. Create or resume a Discovery ID, c
 ## Usage
 
 ```text
-/00-Discover {title or request}
-/00-Discover {discovery-id}
+00-discover {title or request}
+00-discover {discovery-id}
 ```
 
 Use this when:
@@ -28,7 +28,7 @@ Use this when:
 Write the primary discovery artifact to:
 
 ```text
-devflow/discoveries/{DISCOVERY_ID}-{slug}/00-discover.md
+devflow/discoveries/{DISCOVERY_ID}-{slug}00-discover.md
 ```
 
 using:
@@ -65,7 +65,7 @@ Run discovery as a decision-and-routing loop, not as task initialization.
 - **Observation**: use concrete evidence such as option tradeoffs, product framing, research results, root cause, stakeholder constraints, open questions, and visible risk.
 - **Adjustment**: invoke only the companion route needed to resolve the current uncertainty; every companion invoked by Discover must return to this Discovery ID for synthesis.
 - **Stop Condition**: stop when the selected route and evidence are recorded, open questions are visible, and the decision is `Proceed`, `Defer`, or `Reject`.
-- **Handoff**: only an approved `Proceed` discovery may hand off to `/10-Define {discovery_id}`. `Defer` and `Reject` end without allocating a Running ID.
+- **Handoff**: only an approved `Proceed` discovery may hand off to `10-define {discovery_id}`. `Defer` and `Reject` end without allocating a Running ID.
 
 ### 1. Create Or Resume The Discovery
 
@@ -99,7 +99,7 @@ After each companion route:
 
 - update `00-discover.md` with the durable findings and source path
 - reassess whether another route is materially necessary
-- return to the Discover decision rather than jumping directly to `/10-Define`
+- return to the Discover decision rather than jumping directly to `10-define`
 
 ### 5. Decide
 
@@ -109,7 +109,7 @@ Set one decision:
 - `Defer`: the idea remains relevant but timing, evidence, or ownership is not ready
 - `Reject`: the idea should not proceed under the current framing
 
-Candidate delivery slices may be suggested, but they remain provisional and unnumbered until `/10-Define`.
+Candidate delivery slices may be suggested, but they remain provisional and unnumbered until `10-define`.
 
 ### 6. Write `00-discover.md`
 
@@ -117,11 +117,11 @@ Candidate delivery slices may be suggested, but they remain provisional and unnu
 - follow the configured `artifact_language`
 - replace placeholders with concrete context
 - record selected routes, returned findings, open questions, decision, and rationale
-- keep `related_runs` empty until `/10-Define` materializes approved slices
+- keep `related_runs` empty until `10-define` materializes approved slices
 
 ### 7. Manual Review Gate
 
-Before `/10-Define`:
+Before `10-define`:
 
 - confirm the selected route and evidence are sufficient
 - confirm the decision is `Proceed`
@@ -138,15 +138,15 @@ Report:
 - selected support route and why
 - important findings and open questions
 - `Proceed`, `Defer`, or `Reject` decision
-- recommended next step, including `/10-Define {discovery_id}` only when Proceed is approved
+- recommended next step, including `10-define {discovery_id}` only when Proceed is approved
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline discovery stage
 - Previous state: request intake
-- Next state: `/10-Define {discovery_id}` only after approved Proceed
+- Next state: `10-define {discovery_id}` only after approved Proceed
 - Common companion routes: `Brainstorm`, `PRD`, `Research`, `Debug`
-- Running ID lifecycle: begins in `/10-Define`, not in Discover
+- Running ID lifecycle: begins in `10-define`, not in Discover
 
 ## Sources
 
@@ -156,7 +156,7 @@ Report:
 
 ## Next Workflow Recommendation
 
-- **Primary**: the selected companion route, or `/10-Define {discovery_id}` after approved Proceed
+- **Primary**: the selected companion route, or `10-define {discovery_id}` after approved Proceed
 - **Alternatives**:
   - `Brainstorm {discovery_id}` for unresolved options
   - `PRD {discovery_id}` for product framing

package/template/.claude/skills/10-define/SKILL.md

@@ -1,6 +1,6 @@
 ---name: 10-define
 
-description: Define stage in DevFlow 2.0 - turn an approved discovery into one or more bounded delivery runs with stable scope.
+description: "[Devflow] Define stage in DevFlow 2.0 - turn an approved discovery into one or more bounded delivery runs with stable scope."
 argument-hint: "{approved discovery-id, discovery path, running-id, or run path}"
 ---
 
@@ -13,8 +13,8 @@ Convert an approved `Proceed` discovery into bounded delivery slices. Allocate o
 ## Usage
 
 ```text
-/10-Define {discovery-id or discovery path}
-/10-Define {running-id or run path}
+10-define {discovery-id or discovery path}
+10-define {running-id or run path}
 ```
 
 Use a Discovery ID to materialize new delivery runs. Use an existing Running ID only to revise or split a definition that already exists.
@@ -24,7 +24,7 @@ Use a Discovery ID to materialize new delivery runs. Use an existing Running ID
 For every approved delivery slice, write:
 
 ```text
-devflow/runs/{ID}-{slug}/10-define.md
+devflow/runs/{ID}-{slug}10-define.md
 ```
 
 using:
@@ -57,8 +57,8 @@ Run definition as a scope-stabilization and run-allocation loop.
 - **Context**: read the approved `00-discover.md`, linked Brainstorm/PRD/Research/Debug outputs, project-wide rules, existing run IDs, and dependencies between candidate slices.
 - **Action**: lock initiative and scope boundaries, decompose delivery slices, review the run map, allocate collision-free Running IDs, and write one `10-define.md` per slice.
 - **Observation**: use independent acceptance boundaries, release boundaries, ownership, dependencies, context size, cross-domain coupling, and reviewability as evidence for splitting or combining slices.
-- **Adjustment**: merge slices that are only implementation tasks; split slices that require separate specs, releases, ownership, or large independent context; return to `/00-Discover` if the decision or product direction is still unstable.
-- **Stop Condition**: stop when the run map is approved, IDs are materialized without collision, each run has stable in/out scope, and every generated run can proceed independently to `/20-Spec {running_id}`.
+- **Adjustment**: merge slices that are only implementation tasks; split slices that require separate specs, releases, ownership, or large independent context; return to `00-discover` if the decision or product direction is still unstable.
+- **Stop Condition**: stop when the run map is approved, IDs are materialized without collision, each run has stable in/out scope, and every generated run can proceed independently to `20-spec {running_id}`.
 - **Handoff**: each `10-define.md` must identify its source Discovery ID, sibling runs, dependencies, scope, non-goals, and exact next command.
 
 ### 1. Validate The Discovery Gate
@@ -69,7 +69,7 @@ For new delivery work, require:
 - `Approval Status: Approved`
 - a resolvable Discovery ID and `00-discover.md`
 
-If either gate is missing, do not create a Running ID. Return to `/00-Discover {discovery_id}`.
+If either gate is missing, do not create a Running ID. Return to `00-discover {discovery_id}`.
 
 ### 2. Build The Delivery Run Map
 
@@ -83,7 +83,7 @@ Create separate runs when work has materially independent:
 - dependency sequencing
 - implementation context large enough to threaten reliable planning or review
 
-Keep ordinary subtasks inside `/30-Plan` and checklists.
+Keep ordinary subtasks inside `30-plan` and checklists.
 
 For every slice record:
 
@@ -126,11 +126,11 @@ If an existing definition is too broad:
 - preserve traceability to the original run and discovery
 - allocate new IDs only after approval
 - mark the old definition as `Superseded` and list its replacement runs
-- do not silently fork scope during `/20-Spec`
+- do not silently fork scope during `20-spec`
 
 ### 7. Manual Review Gate
 
-Before recommending `/20-Spec`, confirm each generated definition independently. Approval of one run must not imply approval of every sibling run.
+Before recommending `20-spec`, confirm each generated definition independently. Approval of one run must not imply approval of every sibling run.
 
 ## Output
 
@@ -141,13 +141,13 @@ Report:
 - workspace path for every generated run
 - scope and dependency summary per run
 - any superseded run
-- exact `/20-Spec {running_id}` commands for approved runs
+- exact `20-spec {running_id}` commands for approved runs
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline workflow and Running ID creation boundary
-- Previous state: approved `/00-Discover`
-- Next state: `/20-Spec {running_id}` per generated run
+- Previous state: approved `00-discover`
+- Next state: `20-spec {running_id}` per generated run
 - Running ID lifecycle: starts here
 
 ## Sources
@@ -158,13 +158,13 @@ Report:
 
 ## Next Workflow Recommendation
 
-- **Primary**: `/20-Spec {running_id}` for each approved run
+- **Primary**: `20-spec {running_id}` for each approved run
 - **Alternatives**:
-  - `/00-Discover {discovery_id}` when the go/no-go decision or direction is unstable
+  - `00-discover {discovery_id}` when the go/no-go decision or direction is unstable
   - `Research {discovery_id}` when evidence still blocks a reliable split
   - `grill-with-docs` when boundaries or terminology remain ambiguous
 
 ## Nexus Event
 
 - Use `domain-modeling` when sibling runs need shared language or durable architectural decisions.
-- Use `planning-and-task-breakdown` only after the delivery boundary is stable; small tasks belong in `/30-Plan`, not separate Running IDs.
+- Use `planning-and-task-breakdown` only after the delivery boundary is stable; small tasks belong in `30-plan`, not separate Running IDs.