@jakkrichm/create-nexus-devflow 2.0.8 → 2.0.10

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

@@ -1,6 +1,6 @@
 ---name: 70-release
 
-description: Release stage in DevFlow 2.0 - package verified work for delivery, merge, PR, deployment, or handoff.
+description: "[Devflow] Release stage in DevFlow 2.0 - package verified work for delivery, git merge, PR, or deployment."
 argument-hint: "{running-id or workspace path}"
 ---
 
@@ -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

@@ -1,6 +1,6 @@
 ---
 name: adopt
-description: Bootstrap Nexus-DevFlow into an existing (brownfield) codebase. Surveys the real repository (read-only), interviews the user for intent, generates project-overview.md and coding-standards.md from existing code, tunes AGENTS.md commands, and seeds the initial Discovery or Run map. Use when the user runs adopt, /adopt, $adopt, is overlaying DevFlow onto an app that already has meaningful code, or asks to adopt DevFlow into an existing project. For freshly scaffolded or early projects, use onboard instead.
+description: "[Devflow] Survey existing brownfield codebase and bootstrap DevFlow context files."
 ---
 
 # adopt - Bootstrap Nexus-DevFlow from an Existing Codebase
@@ -8,14 +8,14 @@ description: Bootstrap Nexus-DevFlow into an existing (brownfield) codebase. Sur
 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

@@ -1,6 +1,6 @@
 ---name: agent
 
-description: Invoke Agent - Run a specialist persona on a file, folder, stage artifact, or codebase concern.
+description: "[Devflow] Invoke specialist persona or role-based agent on a target file, folder, stage artifact, or concern."
 ---
 # Phase 90: Invoke Agent
 
@@ -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/api-and-interface-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: api-and-interface-design
-description: Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
+description: "[Devflow] Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend."
 ---
 
 # API and Interface Design

package/template/.agents/skills/app-builder/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: app-builder
-description: Main application building orchestrator. Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents.
+description: "[Devflow] Main application building orchestrator. Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents."
 allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent
 ---
 

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

@@ -1,6 +1,6 @@
 ---
 name: architecture
-description: Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
+description: "[Devflow] Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design."
 allowed-tools: Read, Glob, Grep
 ---
 

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

@@ -0,0 +1,175 @@
+---
+name: autopilot
+description: "[Devflow] Optional explicit mode for one bounded spec/plan/implement/verify/report pass with checkpoint commits and review packet."
+---
+
+# autopilot - Autonomous Bounded DevFlow Loop
+
+Where this sits in the workflow:
+
+```text
+devflow  ->  [autopilot]  ->  review packet  ->  70-release
+(where        (spec, plan,     (human review,     (package, PR,
+ are we?)      build, verify,   walkthrough)       merge with approval)
+               report)
+```
+
+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.
+
+Do not suggest Autopilot as the default next action. Use it only when the user explicitly asks for it.
+
+The explicit Autopilot request is permission to create checkpoint commits on the feature or fix branch after passing implementation steps. It is **not** permission to merge into `main`, push to remote, deploy, publish, delete data, or run destructive actions.
+
+## Input
+
+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"`.
+- **`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.
+
+---
+
+## Step 1 - Preflight & Safety Check
+
+Read the project state:
+
+- `AGENTS.md` & `CLAUDE.md`
+- `devflow/context/project-overview.md`
+- `devflow/context/current-stage.md`
+- `devflow/context/coding-standards.md`
+- `devflow/context/ai-interaction.md`
+- `devflow/context/findings.md`
+- git branch, status, and recent log
+
+Stop before changing files when:
+
+1. The repo is not a git repository.
+2. The working tree is dirty with uncommitted changes unrelated to this run.
+3. `current-stage.md` has an active run and the user requested a different target without resolving conflict.
+4. The task requires architectural, financial, auth, billing, or destructive decisions not documented in the context.
+
+---
+
+## Step 2 - Choose or Write Specification (`20-spec`)
+
+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.
+   - Critique and red-team the spec (edge cases, unhappy paths, testable criteria).
+   - Apply fixes to the spec.
+
+---
+
+## Step 3 - Branch Setup & Implementation Plan (`30-plan`)
+
+1. **Branch Management**:
+   - Feature: `feature/{slug}-{running-id}`
+   - 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`.
+   - Seed `checklists/implementation-checklist.md` and `checklists/verification-checklist.md`.
+
+---
+
+## Step 4 - Implement in Small Increments (`40-implement`)
+
+Work through the implementation checklist in order. Each step must remain reviewable.
+
+For every subtask:
+
+1. Implement only that scoped unit.
+2. Run relevant verification (unit tests, typecheck, lint, build).
+3. If UI is involved, inspect behavior, verify console errors and network calls.
+4. Self-review diff against `coding-standards.md`.
+5. Fix issues and rerun failed checks.
+6. Mark the task checked `[x]` in `checklists/implementation-checklist.md`.
+7. **Create a Checkpoint Commit** on the feature/fix branch for the passing step:
+   ```bash
+   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`.
+
+---
+
+## Step 5 - Senior QA Verification (`50-verify`)
+
+1. Execute full project verification commands:
+   - Framework integrity (`npm run check` or equivalent)
+   - Static contracts (`npm run check:static` when applicable)
+   - 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`).
+
+---
+
+## Step 6 - Targeted Quality Audit & Repair
+
+Review diffs and inspect `devflow/context/findings.md`:
+
+1. **Repair confirmed P0 and P1 findings** within the current run scope.
+2. Update finding status in `devflow/context/findings.md`.
+3. Rerun verification tests after repairs.
+4. Create a checkpoint commit for the fix.
+5. If a P0/P1 finding cannot be repaired within scope or fails twice consecutively, stop immediately and report.
+
+---
+
+## 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`.
+4. Stop with a concise **Review Packet Dashboard** for human approval.
+
+---
+
+## 🛑 Strict Hard Stops (Never Exceed)
+
+Stop immediately and report to the user instead of continuing when Autopilot would need to:
+
+- Commit directly to `main` or `master`, merge branches, delete branches, or force push.
+- Run `git push` to remote repositories.
+- Deploy to staging/production or publish packages to npm/registries.
+- Delete data, drop databases, or run irreversible destructive migrations.
+- Make product, business, or architecture decisions not specified in the context.
+- Continue after two failed attempts to fix the same issue (Two-attempt hard stop).
+
+---
+
+## Output Review Packet Format
+
+When Autopilot finishes successfully, output a scannable review packet:
+
+```markdown
+### 🛸 Autopilot Execution Summary: [{running-id}]
+
+- **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`
+- **Validation & Tests**: `All Passed (Green)`
+- **Checkpoint Commits**: `{count} commits created on {branch-name}`
+- **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.
+```

package/template/.agents/skills/bash-linux/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bash-linux
-description: Bash/Linux terminal patterns. Critical commands, piping, error handling, scripting. Use when working on macOS or Linux systems.
+description: "[Devflow] Bash/Linux terminal patterns. Critical commands, piping, error handling, scripting. Use when working on macOS or Linux systems."
 allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 ---
 

package/template/.agents/skills/behavioral-modes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: behavioral-modes
-description: AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type.
+description: "[Devflow] AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type."
 allowed-tools: Read, Glob, Grep
 ---
 

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

@@ -1,6 +1,6 @@
 ---name: brainstorm
 
-description: Structured brainstorming for projects and features. Transitional compatibility path for the Brainstorm companion command in DevFlow 2.0.
+description: "[Devflow] Structured divergent and convergent ideation for features and ideas without allocating running IDs."
 ---
 
 # Brainstorm - Structured Idea Exploration
@@ -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

@@ -0,0 +1,77 @@
+---
+name: brief
+description: "[Devflow] Read-only scope, dependency, and risk pre-briefing before speccing a run."
+---
+
+# brief - Scope, Dependency & Risk Pre-Check
+
+Where this sits in the workflow:
+
+```text
+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)
+```
+
+This skill answers one essential question: ***"What does this upcoming feature or run actually involve before I commit to writing a full specification?"***
+
+It inspects the relevant context files and provides a concise briefing so the team can decide whether to spec it now, split it into smaller runs, reorder priorities, or clear an architectural blocker first.
+
+It is **strictly read-only 100%**. It never writes specs, creates directories, branches, or commits code.
+
+## 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"`.
+
+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)
+
+Gather and synthesize:
+
+1. **Active/Target Scope**: Target Running ID, `10-define.md`, or roadmap feature item.
+2. **Project Context**: `devflow/context/project-overview.md` (Data models, architecture layout, primary stack, existing shipped capabilities).
+3. **Existing Codebase State**: Inspect existing directory structures, schemas, and routes touching this feature.
+4. **Dependencies**: What previously completed runs (`devflow/runs/`) or modules must be in place first.
+
+## Step 2 - Analyze & Assess
+
+Evaluate:
+
+- **What It Is**: Core capability and user-visible or system-visible outcome.
+- **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`).
+- **Open Questions & Risks**: Ambiguous requirements, missing external APIs, or complex migrations.
+
+## Step 3 - Output Structured Briefing
+
+Produce a short, scannable briefing:
+
+```markdown
+### 📋 Feature Briefing: [Feature / Run Name]
+
+- **What**: Brief summary of the core outcome.
+- **Depends On**: Prerequisite modules, runs, or infrastructure.
+- **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`.
+
+---
+👉 **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`.
+- **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.
+
+## Output Formatting
+
+Follow the project conventions in `devflow/context/ai-interaction.md`: concise, scannable markdown with bold labels and actionable bullet points.

package/template/.agents/skills/browser-testing-with-devtools/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: browser-testing-with-devtools
-description: Tests in real browsers. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data via Chrome DevTools MCP.
+description: "[Devflow] Tests in real browsers. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data via Chrome DevTools MCP."
 ---
 
 # Browser Testing with DevTools

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

@@ -1,6 +1,6 @@
 ---name: changelog
 
-description: Update CHANGELOG.md - Automatically gather changes from specs, git history, or current state to update the project changelog.
+description: "[Devflow] Update CHANGELOG.md automatically from specs, git commits, and stage report history."
 ---
 # Phase 53: Update Changelog
 
@@ -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`