@jakkrichm/create-nexus-devflow 2.0.8 → 2.0.10

package/template/.agents/skills/powershell-windows/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: powershell-windows
-description: PowerShell Windows patterns. Critical pitfalls, operator syntax, error handling.
+description: "[Devflow] PowerShell Windows patterns. Critical pitfalls, operator syntax, error handling."
 allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 ---
 

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

@@ -1,6 +1,6 @@
 ---name: pr
 
-description: Create Pull Request (Git Orchestration) - Create a well-formatted pull request from the current branch with a clear summary of changes and linked artifacts.
+description: "[Devflow] Pull Request creation with automated change summaries, verification evidence, and linked stage artifacts."
 ---
 # Create Pull Request (Git Orchestration)
 
@@ -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

@@ -1,6 +1,6 @@
 ---name: pr-review
 
-description: PR Review Addon - Review a pull request using GitHub review prompt patterns and the credited 9arm-skills/scrutinize discipline.
+description: "[Devflow] PR Review Addon - Review a pull request using GitHub review prompt patterns and the credited 9arm-skills/scrutinize discipline."
 ---
 
 # Phase 55: PR Review Addon
@@ -9,7 +9,7 @@ description: PR Review Addon - Review a pull request using GitHub review prompt
 
 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

@@ -1,6 +1,6 @@
 ---
 name: pr-review-analysis
-description: Review pull requests or local diffs with structured finding discipline, selective review lanes, and Nexus-DevFlow report templates. Use when the team needs a substantial review without turning review into a numbered workflow stage.
+description: "[Devflow] Review pull requests or local diffs with structured finding discipline, selective review lanes, and Nexus-DevFlow report templates. Use when the team needs a substantial review without turning review into a numbered workflow stage."
 ---
 
 # PR Review Analysis
@@ -20,7 +20,7 @@ This skill should reuse and align with:
 
 ## When to Use
 
-- after `/50-Verify` when the change needs structured review before `/60-Report` and `/70-Release`
+- after `50-verify` when the change needs structured review before `60-report` and `70-release`
 - when a local diff, branch, or pull request needs findings-first analysis
 - when the user wants review without directly editing code
 
@@ -86,4 +86,4 @@ Return:
 - open questions or assumptions
 - residual risks or test gaps
 - where the review report was saved
-- the recommended next route such as `/40-Implement`, `/70-Release`, or `PR-Followup`
+- the recommended next route such as `40-implement`, `70-release`, or `PR-Followup`

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 ---
 name: prototype
-description: Build a throwaway prototype to answer a design question during Discover, Define, Spec, Research, or Plan.
+description: "[Devflow] Build a throwaway prototype to answer a design question during Discover, Define, Spec, Research, or Plan."
 disable-model-invocation: true
 ---
 
@@ -8,7 +8,7 @@ disable-model-invocation: true
 
 A prototype is throwaway code that answers one question.
 
-Use this support skill behind `Research`, `Brainstorm`, `/00-Discover`, `/10-Define`, `/20-Spec`, or `/30-Plan` when conversation alone cannot settle the uncertainty.
+Use this support skill behind `Research`, `Brainstorm`, `00-discover`, `10-define`, `20-spec`, or `30-plan` when conversation alone cannot settle the uncertainty.
 
 ## Branches
 

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

@@ -1,6 +1,6 @@
 ---
 name: python-patterns
-description: Python development principles and decision-making. Framework selection, async patterns, type hints, project structure. Teaches thinking, not copying.
+description: "[Devflow] Python development principles and decision-making. Framework selection, async patterns, type hints, project structure. Teaches thinking, not copying."
 allowed-tools: Read, Write, Edit, Glob, Grep
 ---
 

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 ---
 name: review-followup-routing
-description: Classify review comments, extend existing work safely, and route corrective or future work back into the right DevFlow 2.0 stage. Use for PR follow-up and post-review follow-up planning.
+description: "[Devflow] Classify review comments, extend existing work safely, and route corrective or future work back into the right DevFlow 2.0 stage. Use for PR follow-up and post-review follow-up planning."
 ---
 
 # Review Follow-up Routing
@@ -83,9 +83,9 @@ For task follow-up, append the approved follow-up work directly into the relevan
 
 ### 5. Route Back
 
-- `/40-Implement` for immediate corrective work
-- `/50-Verify` when only verification needs another pass
-- `/10-Define` or `/20-Spec` when the follow-up becomes genuinely new scope
+- `40-implement` for immediate corrective work
+- `50-verify` when only verification needs another pass
+- `10-define` or `20-spec` when the follow-up becomes genuinely new scope
 
 ## Output
 

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

@@ -1,6 +1,6 @@
 ---
 name: roadmap-strategy
-description: Create or refresh product roadmap direction using markdown-first discovery and roadmap artifacts. Use when strategic planning should stay outside the mainline but still follow DevFlow 2.0 contracts.
+description: "[Devflow] Create or refresh product roadmap direction using markdown-first discovery and roadmap artifacts. Use when strategic planning should stay outside the mainline but still follow DevFlow 2.0 contracts."
 ---
 
 # Roadmap Strategy
@@ -23,7 +23,7 @@ This skill should reuse and align with:
 
 - when product direction, priority, or sequencing needs a dedicated roadmap pass
 - when competitor, PRD, research, or delivery insight should be consolidated into strategy
-- when roadmap work should stay outside the numbered mainline but still hand off cleanly into `PRD`, `/10-Define`, or `/20-Spec`
+- when roadmap work should stay outside the numbered mainline but still hand off cleanly into `PRD`, `10-define`, or `20-spec`
 
 ## Canonical Artifacts
 
@@ -79,8 +79,8 @@ Replace placeholder content fully and keep headings and tables intact so validat
 ### 5. Route Back
 
 - `PRD` when product framing needs to deepen
-- `/10-Define` when roadmap decisions should become bounded work
-- `/20-Spec` when one item is ready for delivery contract work
+- `10-define` when roadmap decisions should become bounded work
+- `20-spec` when one item is ready for delivery contract work
 - `Brainstorm` when strategy is still too fuzzy to lock
 
 ## Output

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

@@ -0,0 +1,108 @@
+---
+name: rollback
+description: "[Devflow] Plan safe feature or run reversal with dependency and commit risk analysis."
+---
+
+# rollback - Safe Feature Reversal & Rollback Planner
+
+Where this sits in the workflow:
+
+```text
+completed run + git history  ->  [rollback]  ->  40-implement (or fix run)  ->  50-verify  ->  70-release
+(run archive + commits)          (risk review    (reverse product diff)          (prove)      (log & finalize)
+                                  + plan)
+```
+
+This skill **plans a rollback**. It does not silently alter product code, reset branches destructively, force-push, or mutate repository history. It identifies the completed run and its exact git commit, analyzes what changed afterward, drafts a guarded rollback specification, and stops for human review before execution.
+
+## Input
+
+A completed run by Running ID, name, or run path, plus an optional reason. Examples:
+
+```text
+rollback RUN-002-add-onboard-adopt-doctor-skills
+rollback "auth login" because OAuth provider changed
+rollback devflow/runs/RUN-001-align-devflow-blueprint
+```
+
+With no target, list recent completed runs from `devflow/runs/` and `devflow/context/current-stage.md` and ask the user to choose. Never silently guess the target. If the reason is missing, ask for one before finalizing the rollback plan.
+
+## Step 0 - Preflight Check
+
+Read `AGENTS.md`, `devflow/context/current-stage.md`, `devflow/context/project-overview.md`, completed run archives under `devflow/runs/`, and git state.
+
+Stop before planning when:
+
+- The directory is not a git repository.
+- There is uncommitted active work in the working tree (unless the user asks to inspect it).
+- The target run cannot be identified unambiguously in `devflow/runs/` or Git history.
+
+Do not discard, force-reset, switch branches, or destroy untracked files automatically.
+
+## Step 1 - Resolve Target Run & Commits
+
+Match the requested ID or name against `devflow/runs/` and git commit history:
+
+```bash
+git log --grep="RUN-002" --oneline
+```
+
+Identify:
+
+- Exact commit SHA(s) introducing the feature.
+- Parent commit before the feature was introduced.
+- Associated stage artifacts (`20-spec.md`, `40-implement.md`, `70-release.md`).
+
+## Step 2 - Separate Product Changes From DevFlow History
+
+Inspect the files touched by the target commit(s).
+
+**Protected Workflow Paths (Never Revert Automatically):**
+- `.agents/**`
+- `.claude/**`
+- `devflow/**` (preserve run records, schemas, and historical reports)
+- `AGENTS.md` / `CLAUDE.md` (unless explicitly intended to update commands)
+- `.nexus/**`
+
+The rollback must preserve DevFlow's durable history while isolating the **Product Code Diff** (application code, UI components, backend APIs, configuration).
+
+## Step 3 - Review Later-Commit Risk (Dependency Risk Analysis)
+
+Inspect every commit after the target commit through `HEAD` that touches any of the product files.
+
+Classify the risk into one of 4 standard categories:
+
+| Risk Level | Meaning | Action |
+| :--- | :--- | :--- |
+| **No Overlap** | No subsequent commits touched these product files. | Clean reversal is safe and straightforward. |
+| **Overlap, Compatible** | Later edits touched the same files, but the target code can be cleanly extracted without breaking newer behavior. | Plan selective reverse-patching. |
+| **Dependency Risk** | Subsequent features or bugfixes directly depend on types, APIs, tables, or exports introduced by the target. | Explicitly warn that dependent features will be affected; plan compatibility shims. |
+| **Blocked** | Reversing the target would cause data loss, break database schema, or require a cascading rollback of multiple runs. | Stop and present the blocker to the user for explicit architectural guidance. |
+
+## Step 4 - Produce The Guarded Rollback Plan
+
+Draft the rollback plan containing:
+
+1. **Target Run & Rationale**: Running ID, original commit SHA, author, and reason for reversal.
+2. **Product Files to Revert**: Exact list of application files to modify/delete/restore.
+3. **Protected Paths**: Explicit declaration of preserved history files.
+4. **Risk Classification**: Dependency analysis findings and required compatibility repairs.
+5. **Step-by-Step Reversal Steps**:
+   - Step 1: Apply reverse product diff.
+   - Step 2: Apply compatibility fixes for downstream dependencies.
+   - Step 3: Run project verify command (`npm test`, `npm run check`).
+6. **Acceptance & Verification Criteria**: How to prove the removed behavior is truly gone without breaking existing unaffected features.
+
+## Step 5 - Stop For Human Confirmation
+
+Present the rollback plan to the user:
+
+- Summarize affected files and dependency risks.
+- If approved, route to `40-implement` (or allocate a dedicated Fixrollback Run) to safely execute the reversal steps behind review gates.
+
+## Rules
+
+- **Preserve History**: Never delete run folders under `devflow/runs/`. Historical reports must remain intact.
+- **No Destructive Git Commands**: Never execute `git reset --hard HEAD~N` or `git push --force`. All reversals must be applied as forward commits.
+- **One Target Per Rollback**: Avoid bundling multiple unrelated rollbacks into one pass.
+- **Explicit Human Gate**: Always wait for user approval before applying any reverse diffs to code.

package/template/.agents/skills/security-and-hardening/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: security-and-hardening
-description: Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.
+description: "[Devflow] Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services."
 ---
 
 # Security and Hardening

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

@@ -1,6 +1,6 @@
 ---name: security-review
 
-description: High-severity security code review for folders, projects, files, or diffs with English Markdown output contract.
+description: "[Devflow] High-severity security code review and vulnerability audit for folders, projects, files, or diffs."
 argument-hint: "[target folder, project path, file list, or git diff] [--lang=en]"
 ---
 
@@ -107,8 +107,8 @@ related_files: []
 
 ## 8. Next Allowed Command
 
-- `/40-Implement {running_id}` (if fail, for code remediation)
-- `/50-Verify {running_id}` (if pass, to verify execution correctness)
+- `40-implement {running_id}` (if fail, for code remediation)
+- `50-verify {running_id}` (if pass, to verify execution correctness)
 
 ## 9. Nexus Event
 
@@ -157,7 +157,7 @@ Evaluate high-severity risks including:
 
 - **Classification**: Companion command
 - **Mainline Status**: Not part of the linear Timeline. Can be run at any stage.
-- **Typical Entry Points**: Any stage, especially before `/50-Verify` or `/70-Release` to verify security health.
+- **Typical Entry Points**: Any stage, especially before `50-verify` or `70-release` to verify security health.
 
 ## Sources
 

package/template/.agents/skills/seo-fundamentals/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: seo-fundamentals
-description: SEO fundamentals, E-E-A-T, Core Web Vitals, and Google algorithm principles.
+description: "[Devflow] SEO fundamentals, E-E-A-T, Core Web Vitals, and Google algorithm principles."
 allowed-tools: Read, Glob, Grep
 ---
 

package/template/.agents/skills/server-management/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: server-management
-description: Server management principles and decision-making. Process management, monitoring strategy, and scaling decisions. Teaches thinking, not commands.
+description: "[Devflow] Server management principles and decision-making. Process management, monitoring strategy, and scaling decisions. Teaches thinking, not commands."
 allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 ---
 

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

@@ -1,6 +1,6 @@
 ---
 name: shipping-and-launch
-description: Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
+description: "[Devflow] Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy."
 ---
 
 # Shipping and Launch
@@ -17,7 +17,7 @@ Ship with confidence. The goal is not just to deploy — it's to deploy safely,
 - Opening a beta or early access program
 - Any deployment that carries risk (all of them)
 
-In DevFlow 2.0, this skill most often supports `/70-Release` and assumes `/60-Report` is already aligned as the communication baseline.
+In DevFlow 2.0, this skill most often supports `70-release` and assumes `60-report` is already aligned as the communication baseline.
 
 ## The Pre-Launch Checklist