@jakkrichm/create-nexus-devflow 2.0.12 → 2.0.13

package/lib/update.js

@@ -71,7 +71,6 @@ function createManifest(version, adapters, templateFiles) {
         "prd",
         "issue-triage",
         "security-review",
-        "wiki",
         "check-for-updates",
         "help"
       ]
@@ -305,6 +304,21 @@ async function applyPreparedUpdate(prepared, { replaceConflicts = false } = {})
     try {
       await fs.unlink(fileToRemove);
       removedCount++;
+
+      let parentDir = path.dirname(fileToRemove);
+      while (parentDir !== prepared.targetDir && parentDir.startsWith(prepared.targetDir)) {
+        try {
+          const entries = await fs.readdir(parentDir);
+          if (entries.length === 0) {
+            await fs.rmdir(parentDir);
+            parentDir = path.dirname(parentDir);
+          } else {
+            break;
+          }
+        } catch {
+          break;
+        }
+      }
     } catch (error) {
       if (error.code !== "ENOENT") {
         throw error;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jakkrichm/create-nexus-devflow",
-  "version": "2.0.12",
+  "version": "2.0.13",
   "description": "Installer package for Nexus-DevFlow agentic workflow layer.",
   "license": "MIT",
   "author": "Jakkrich",

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

@@ -77,6 +77,8 @@ Before packaging, merging, or releasing:
    - **การ Push ไปยัง Remote หรือ Deploy จะต้องขออนุมัติแยกต่างหากอย่างชัดเจน (Merge approval DOES NOT equal Push approval)**
 3. **Archive Resolved Findings**:
    - ย้ายรายการ Findings ที่ปิดแล้ว (`closed`, `accepted`, `invalid`) ไปบันทึกในเอกสาร Release และรีเซ็ต `findings.md` ให้สะอาด
+4. **Append to Master History Ledger**:
+   - บันทึก Entry ใหม่ลงใน `devflow/history/HISTORY.md` พร้อมระบุ Running ID, Title, วันที่, Git Commit Hash / Tag, สถานะ (`Released`), และลิงก์ไปยังรายงานสรุป `60-report.md`
 
 ### 1. Load Verified Context
 

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

@@ -1,70 +1,36 @@
 ---
 name: ci
-description: "[Devflow] Set up automated GitHub Actions CI workflow (.github/workflows/verify.yml) aligned with project verify command."
+description: "[Devflow] CI/CD pipeline automation and GitHub Actions setup (.github/workflows/verify.yml). Automates quality gates, typechecks, tests, and build checks."
 ---
 
-# ci - Automated GitHub Actions Pipeline Setup
+# CI/CD Pipeline Automation & Quality Gates
 
-Where this sits in the workflow:
+## Overview
+
+This is the CI/CD and automation master skill for Nexus-DevFlow. It automates quality gates so that no change reaches production without passing static analysis, typechecking, tests, security audits, and builds.
 
 ```text
-onboard or adopt  ->  [ci]  ->  Verify locally  ->  GitHub Actions runs Verify on PR & Push
-(project setup)         (setup)    (same command)     (automated checks)
+PR / Push ➔ Lint & Typecheck ➔ Unit & Integration Tests ➔ Build Verification ➔ Security Audit
 ```
 
-This skill connects local verification with automated GitHub checks using **one shared Verify recipe**:
-
-- **Verify is the recipe**: Runs the project's real checks (typecheck, tests, build) defined in `AGENTS.md`.
-- **GitHub Actions is the worker**: Executes the same recipe automatically on pull requests and pushes.
-- **Branch Protection / Ruleset is the gate**: Optionally requires the check to pass before merging.
-
-This skill configures the workflow file. It **never pushes to remote, changes remote repository rulesets, or publishes releases** without explicit permission.
-
-## Input
-
-No argument is required. A preferred package manager or branch name can be optionally provided.
-
-## Step 1 - Inspect Project Setup (Read-Only)
-
-Inspect the repository without modifying files:
-
-1. **Commands in `AGENTS.md`**: Look for existing `Verify`, `Test`, `Build`, and `Dev` commands.
-2. **Project Manifests**: `package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, etc.
-3. **Lockfiles & Package Manager**: `pnpm-lock.yaml` (pnpm), `package-lock.json` (npm), `yarn.lock` (yarn), `bun.lockb` (bun), `poetry.lock` (poetry), `Cargo.lock` (cargo).
-4. **Runtime Versions**: `.node-version`, `.nvmrc`, `package.json` engines, `.python-version`.
-5. **Existing Workflows**: Inspect `.github/workflows/` to check if a CI workflow already exists.
-6. **Git Default Branch**: Detect `main` or `master`.
-
-If a healthy and matching workflow already exists, report that CI is already in place and stop.
-
-## Step 2 - Define The Single Verify Command
-
-Build one combined Verify command from actual checks that exist in the project, in this standard order:
-
-1. **Typecheck** (e.g. `tsc --noEmit`, `mypy`, `pyright`, `go vet`)
-2. **Tests** (e.g. `npm test`, `pytest`, `go test ./...`, `cargo test`) - only if real tests exist
-3. **Build** (e.g. `npm run build`, `cargo build`)
-
-For JavaScript/TypeScript projects, ensure a `verify` or `check` script exists in `package.json` (or combine existing scripts: e.g. `npm run check:static && npm test && npm run build`).
-
-Record the exact command in the Commands section of `AGENTS.md`:
+---
 
-```markdown
-## Commands
-- Verify: `npm run check` (or detected verify command)
-```
+## 1. Shift-Left Quality Gate Pipeline
 
-## Step 3 - Generate `.github/workflows/verify.yml`
+1. **Static Analysis & Typecheck**: `tsc --noEmit`, `eslint`, `biome` (Catches syntax & type flaws in seconds).
+2. **Automated Tests**: Unit & Integration tests (`npm test`, `pytest`, `go test`).
+3. **Build Integrity**: `npm run build` (Ensures bundle compiles cleanly without warnings).
+4. **Security Hygiene**: `npm audit --audit-level=high` (Flags vulnerable dependencies).
 
-Create `.github/workflows/verify.yml` with security and stability best practices:
+---
 
-- **Trigger**: Pull requests to default branch + Pushes to default branch.
-- **Permissions**: Set least privilege `permissions: contents: read`.
-- **Concurrency**: Cancel in-progress runs on the same PR branch.
-- **Lockfile-Safe Install**: Use `npm ci`, `pnpm install --frozen-lockfile`, `yarn install --immutable`, or `cargo --locked`.
-- **Exact Verify Step**: Run the exact Verify command from `AGENTS.md`.
+## 2. GitHub Actions Setup (`.github/workflows/verify.yml`)
 
-### Standard GitHub Actions Template (Node.js Example):
+When setting up or updating CI:
+- **Trigger**: Pull requests and pushes to `main` / `master`.
+- **Permissions**: Enforce least privilege (`permissions: contents: read`).
+- **Concurrency**: Cancel stale in-progress runs on the same PR.
+- **Deterministic Install**: Use `npm ci` or `--frozen-lockfile`.
 
 ```yaml
 name: Verify
@@ -90,7 +56,7 @@ jobs:
       - name: Checkout Code
         uses: actions/checkout@v4
 
-      - name: Setup Runtime
+      - name: Setup Node
         uses: actions/setup-node@v4
         with:
           node-version: 20
@@ -103,29 +69,10 @@ jobs:
         run: npm run check
 ```
 
-## Step 4 - Verify Locally
-
-Execute the Verify command locally to confirm that it succeeds on clean code before recommending it:
-
-```bash
-npm run check
-```
-
-If local verification fails, report the failing check and assist in resolving it before claiming CI readiness.
-
-## Step 5 - Summary & Handoff
-
-Output a concise summary:
-
-- **Verify Command**: Documented command in `AGENTS.md`.
-- **Workflow File**: `.github/workflows/verify.yml` (created/updated).
-- **Trigger Events**: `pull_request` & `push`.
-- **Local Test**: Result of local execution.
-- **Next Steps**: Advise user to commit and push the workflow to activate GitHub Actions.
+---
 
-## Rules
+## Relationship To DevFlow 2.0
 
-- **Preserve Existing CI**: Never overwrite existing custom workflows without explicit user consent.
-- **No Dummy Tests**: Do not invent fake test commands or install unrequested test runners.
-- **Least Privilege Security**: Always specify `permissions: contents: read`.
-- **No Auto-Push**: Stop at local file creation; do not push to remote automatically.
+- **Classification**: Companion command & Automated testing infrastructure
+- **Mainline integration**: Invoked via `/ci` during `onboard` or `adopt`.
+- **Handoff**: `50-verify`, `70-release`

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

@@ -1,63 +1,59 @@
----name: commit
-
-description: "[Devflow] Smart Commit (Git Orchestration) - Stage files intelligently and write a concise, imperative commit message according to project standards."
 ---
-# ๐Ÿ’พ Smart Commit (Git Orchestration)
+name: commit
+description: "[Devflow] Smart Commit (Git Orchestration) - Stage files intelligently, write conventional imperative commit messages, and manage trunk-based versioning."
+---
 
-## Target: $ARGUMENTS
+# Smart Commit & Git Workflow Versioning
 
-Stage files intelligently and write a concise, imperative commit message according to project standards.
+## Overview
 
-Primary behavior now lives in:
-
-```text
-.agents/skills/release-git-operations/SKILL.md
-```
-
-Treat this workflow file as a compatibility wrapper around that skill in `commit` mode.
+This is the Git orchestration and versioning master skill for Nexus-DevFlow. It enforces atomic commits, conventional commit formatting, intelligent staging, and safe trunk-based workflows. Commits are save points, branches are sandboxes, and Git history is durable documentation.
 
 ---
 
-## ๐Ÿ› ๏ธ Internal Process
+## 1. Commit Discipline & The Conventional Commits Standard
+
+Each commit should represent one atomic, self-contained change:
 
-You are an orchestrator. Your goal is to call the specialized Git Committer agent to perform a high-quality commit.
+```text
+<type>(<scope>): <short imperative summary>
 
-### Phase 1: Assessment & Staging
-**Call Agent**: `prp-core-git-committer`
-- Provide the target description (e.g., "all", "backend only", "staged").
-- The agent will:
-  - Check the current Git status and branch.
-  - **MANDATORY BRANCH RULE:** Use the user's current branch as-is. Do not create, switch, or checkout a branch automatically. Only create or switch branches when the user explicitly asks for that exact branch action in the current request.
-  - If the current branch appears risky for the intended commit (for example `main`/`master` or a protected branch), warn the user and ask whether they want to continue on the current branch or explicitly create/switch to another branch.
-  - Interpret your description to stage the correct files.
-  - Review the staged changes to understand the context.
+[optional detailed body explaining WHY, not WHAT]
+```
 
-### Phase 2: Message Generation & Commit
-- Ensure the agent generates an imperative commit message (e.g., `feat: Add user auth`).
-- The agent will execute the commit and capture the result.
+### Commit Types:
+- `feat`: A new user-facing feature or capability
+- `fix`: A bug fix
+- `docs`: Documentation only changes
+- `refactor`: A code change that neither fixes a bug nor adds a feature
+- `test`: Adding missing tests or correcting existing tests
+- `chore`: Maintenance, build tasks, package updates
 
-### Phase 3: Result Summary
-- Verify the agent reports:
-  - Commit Hash.
-  - Final Commit Message.
-  - Statistics (Files changed, additions, deletions).
+### Formatting Rules:
+- Use the imperative mood: `"feat(auth): add password reset flow"` (NOT `"added"` or `"adds"`).
+- Never mix formatting/refactoring with behavioral feature changes in the same commit.
 
 ---
 
-๐Ÿ“Œ **Next Step**: Run `PR` to create a Pull Request.
+## 2. Trunk-Based Branching & Safety
 
-## Relationship To DevFlow 2.0
+- **Keep `main` deployable**: Feature branches (`feature/{slug}-{running-id}`) must be short-lived.
+- **Never commit directly to `main` without review**: Use feature/fix branches during development.
+- **Small, verified increments**: Test and verify before committing each checkpoint.
 
-- Classification: Companion command
-- Mainline status: Release support command, not a numbered stage
-- Typical entry points: `70-release` after the report is aligned and release execution is ready
-- Typical handoff targets: `PR`, `Deploy`, `70-release`
+---
 
-## Sources
+## 3. Execution Flow
 
-- `AGENTS.md`
-- `.agents/skills/release-git-operations/SKILL.md`
-- `.agents/skills/git-workflow-and-versioning/SKILL.md`
-- Related commands: `70-release`, `PR`, `Deploy`, `Merge`
+1. Check `git status` and verify current branch.
+2. Stage relevant files explicitly (`git add <files>` — avoid blindly running `git add .` if untracked temporary files exist).
+3. Generate concise conventional commit message.
+4. Execute `git commit` and capture commit hash.
 
+---
+
+## Relationship To DevFlow 2.0
 
+- **Classification**: Companion command & Version control support
+- **Mainline integration**: Used during `40-implement` (checkpoint commits), `70-release` (final release commit).
+- **Handoff**: `pr`, `merge`, `70-release`

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

@@ -3,129 +3,68 @@ name: debug
 description: "[Devflow] Root cause investigation and diagnostic loop before or during implementation without editing code. Use when encountering broken behavior, test failures, or bugs."
 ---
 
----
-description: Root cause analysis and debugging. Transitional compatibility path for the Debug companion command in DevFlow 2.0.
----
-
-# Debug - Root Cause Analysis
-
-## Issue: $ARGUMENTS
-
-This file keeps its old numeric path for migration compatibility.
-
-In DevFlow 2.0, `Debug` is a companion command, not a numbered mainline workflow. Its investigative depth should remain comparable to the original debug workflow.
-
-## Purpose
-
-Use `Debug` to find the actual origin of an issue, not just the visible symptom.
-
-Use it when:
-
-- implementation work is blocked by a defect
-- verification reveals a failure that needs root-cause analysis
-- the team needs RCA before deciding the next implementation step
+# Debug & Root Cause Analysis (RCA)
 
-Preferred DevFlow 2.0 pairing:
+## Overview
 
-- from `00-discover` when a new request begins with a failure whose root cause is unknown
-- from `40-implement`
-- from `50-verify`
+This is the comprehensive debugging master skill for Nexus-DevFlow. It guides systematic root-cause investigation without blindly editing code. The goal is to find the actual origin of an issue, not merely suppress visible symptoms.
 
-When invoked with a Discovery ID, link the RCA report to that discovery and return to `00-discover {discovery_id}` for the delivery decision. Do not allocate a Running ID for an unapproved fix during Debug.
-
-## Source Discipline
-
-Apply the local skill pack at `.agents/skills/9arm-skills/debug-mantra/SKILL.md`.
-
-- Source pack: `9arm-skills`
-- Credit: `thananon/9arm-skills`
-- Upstream: https://github.com/thananon/9arm-skills
-- Mantra: `Reproduce -> Trace fail path -> Falsify hypothesis -> Cross-reference breadcrumbs`
+**The Debug Mantra (9arm Pattern)**:
+```text
+Reproduce ➔ Trace Fail Path ➔ Falsify Hypotheses ➔ Cross-reference Breadcrumbs ➔ RCA Proof
+```
 
 ---
 
-## Internal Process
-
-You are doing Root Cause Analysis, not just symptom triage. Keep the richer original debugging discipline and map the next step back into DevFlow 2.0.
-
-### Phase 1: Reproduce And Classify
-
-- restate the symptom clearly
-- capture expected vs actual behavior
-- determine whether the issue is reproducible
-- do not recommend a fix before the reproduction story is credible
+## 1. The 4-Phase Diagnostic Loop
 
-### Phase 2: Isolate And Hypothesize
+### Phase 1: Reproduce & Classify
+- Restate the observed symptom vs. expected behavior with exact steps.
+- Create a minimal reproduction script, test case, or curl command.
+- Rule: **Do not propose a code fix before the reproduction story is verified.**
 
-- identify likely components, recent changes, or conditions
-- generate 2-4 hypotheses ordered by likelihood
-- define what evidence would falsify each hypothesis
+### Phase 2: Isolate & Hypothesize
+- Generate 2–4 distinct hypotheses ranked by probability.
+- Formulate specific criteria and evidence that would *falsify* each hypothesis.
 
-### Phase 3: Investigate With Evidence
+### Phase 3: Non-Destructive Investigation
+- Trace code execution paths end-to-end (stack traces, logs, variable states, async boundaries).
+- Inspect recent commits or configuration changes that touch the affected boundary.
+- Test hypotheses methodically using tests and logging without altering business logic.
 
-- trace the real fail path end-to-end
-- test hypotheses methodically
-- record evidence with file:line or command output
-- maintain a breadcrumb trail of observations and conclusions
+### Phase 4: Root Cause Conclusion (RCA)
+- State precisely *why* the bug occurred (underlying invariant violation).
+- Define the minimal, robust architectural fix direction.
+- Propose regression prevention measures (unit test, type guard, linter rule).
 
-### Phase 4: Conclude With RCA
-
-- name the root cause
-- explain why it is the root cause
-- describe the fix direction
-- capture prevention or follow-up measures
-
-This command supports the active stage. It does not replace the mainline stage itself.
-
-## Output Format
-
-Save the RCA report to `devflow/debug/rca-{slug}.md`.
-
-Before generating the report:
+---
 
-1. Inspect `.agent/resources/schemas/rca.template.md`
-2. Preserve its required headings and structure
-3. Replace placeholder text with concrete evidence
-4. Re-check the output against `rca.template.md`, ensure required headings remain, and remove all placeholders before completion
+## 2. Output Format (RCA Report)
 
-Present the summary in this shape:
+Save substantial RCA investigations under:
+```text
+devflow/debug/rca-{slug}.md
+```
 
+Structure:
 ```markdown
 ## Debug Summary
 
-1. **Symptom**: [What is happening]
-2. **Evidence**: [error log, file, line, failing command]
-3. **Investigation Path**: [what was tested and what happened]
-4. **Root Cause**: [why this happened]
-5. **Fix Direction**: [what should be changed]
-6. **Prevention**: [how to avoid recurrence]
+1. **Symptom**: [What is happening vs expected]
+2. **Evidence**: [Error logs, stack trace, file:line references]
+3. **Investigation Path**: [Hypotheses tested and falsification proof]
+4. **Root Cause**: [The exact mechanism causing the failure]
+5. **Fix Direction**: [Recommended scoped change]
+6. **Regression Guard**: [Reproduction test to add before fixing]
 ```
 
-## Examples
-
-```text
-Debug flaky login redirect
-Debug failing migration in CI
-Debug why webhook verification breaks in staging
-Debug unexpected duplicate records
-```
+---
 
 ## Relationship To DevFlow 2.0
 
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: `00-discover`, `40-implement`, `50-verify`, `Issue-Triage`, production failure analysis
-- Typical handoff targets: `00-discover {discovery_id}` for discovery-owned RCA, `40-implement`, `50-verify`, `Insight`, `Wiki`
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/rca.template.md`
-- Related commands: `40-implement`, `50-verify`, `Test`, `Insight`, `Wiki`, `Agent`
-
-## Next Workflow Recommendation
-
-- Default: return to `00-discover {discovery_id}` when the failure entered through discovery; otherwise return to `40-implement` when a tracked fix already exists
-- Alternate: `30-plan` if the fix needs planning changes
-- Alternate: `50-verify` when the issue is resolved and needs re-checking
-
+- **Classification**: Companion command & Investigation lane
+- **Mainline integration**:
+  - During `00-discover`: Unclear failure intake before allocation
+  - During `40-implement`: Hard test failure or unexpected runtime exception
+  - During `50-verify`: Defect found during QA inspection
+- **Handoff**: `test` (write repro test), `40-implement` (execute fix), `50-verify` (re-check)

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

@@ -1,91 +1,63 @@
----name: deploy
-
-description: "[Devflow] Production deployment pre-flight checks, smoke validation, and deployment execution."
 ---
-# ๐Ÿš€ Phase 52: Production Deployment (Auto-Deploy)
+name: deploy
+description: "[Devflow] Production deployment pre-flight checks, launch readiness, smoke validation, and deployment execution."
+---
 
-## Usage: `Deploy [subcommand]`
+# Production Deployment & Launch Readiness
 
-Perform pre-flight checks, deployment execution, and verification for production releases.
+## Overview
 
-Primary behavior now lives in:
+This is the comprehensive deployment master skill for Nexus-DevFlow. It handles pre-flight validation, multi-platform deployment execution (Vercel, Render, Railway, Fly.io, Docker), health checks, smoke verification, and safe rollback readiness.
 
 ```text
-.agents/skills/release-git-operations/SKILL.md
+Pre-Flight Checks ➔ Build & Smoke Test ➔ Deployment Execution ➔ Health Verification ➔ Release Logging
 ```
 
-Treat this workflow file as a compatibility wrapper around that skill in `deploy` mode.
-
 ---
 
-## ๐Ÿ› ๏ธ Sub-commands
+## 1. Pre-Flight Verification Checklist
 
-- `Deploy`            - Interactive deployment wizard
-- `Deploy check`      - Run pre-deployment checks only
-- `Deploy preview`    - Deploy to preview/staging
-- `Deploy production` - Deploy to production
-- `Deploy rollback`   - Rollback to previous version
+Before initiating any deployment, verify:
+1. **Code & Quality**: Zero syntax/type errors, linters clean, unit & integration tests passing (`npm test`).
+2. **Security**: No secrets in source code, environment variables documented in `.env.example`, `npm audit` checked.
+3. **Database & Migrations**: Schema migrations verified backwards-compatible and applied.
+4. **Performance & Assets**: Production bundles compiled, assets compressed, Core Web Vitals considered.
+5. **Observability**: Healthcheck endpoint (`/api/health`) responsive, error tracking configured.
 
 ---
 
-## ๐Ÿšฆ Internal Process
+## 2. Platform Deployment Matrix
 
-### Phase 1: Pre-Flight Checks
-Before any deployment, the AI MUST verify the following Checklist:
-1. **Code Quality**: No syntax errors, Linters passing, Tests passing.
-2. **Security**: No hardcoded secrets, Environment variables documented, Dependencies audited.
-3. **Performance**: Bundle size acceptable, Images optimized, No N+1 queries.
-4. **Accessibility**: Keyboard nav works, screen reader compatible, contrast adequate.
-5. **Infrastructure**: Env vars set, migrations ready, monitoring configured.
-6. **Documentation**: README / ADRs / CHANGELOG updated.
+| Target Platform | Deploy Method / Command | Verification Method |
+| :--- | :--- | :--- |
+| **Vercel** | `vercel --prod` or Git push | Inspect deployment URL & build logs |
+| **Render / Railway** | `railway up` or Git integration | Check service status & container logs |
+| **Fly.io** | `fly deploy` | Check `fly status` and HTTP response |
+| **Docker / VPS** | `docker compose up -d --build` | Check container health & PM2 logs |
 
-*You MUST run appropriate validation commands to systematically audit the codebase before giving the green light.*
+---
 
-### Phase 2: Deployment Execution
-Determine the project's platform (Vercel, Railway, Docker, Fly.io, etc.) and execute the appropriate build & deploy commands.
-- Vercel: `vercel --prod`
-- Railway: `railway up`
-- Docker: `docker compose up -d`
-- Fly.io: `fly deploy`
+## 3. Post-Deployment Smoke Verification & Health Check
 
-### Phase 3: Health Check, Verify & Report
-- **Template Verification**: **MANDATORY:** Before final deployment, inspect `.agent/resources/schemas/deploy_report.template.md`, preserve its required layout, and replace placeholder text with concrete environment, commands, checks, rollback notes, and deployment result.
-- Save the final deployment and pre-flight check report to `devflow/reports/{date}-deploy-report-{timestamp}.md` (where `{date}` is today's date in `YYYY-MM-DD` format and `{timestamp}` is a clean date/time slug).
-- Verify that the deployed application is responding (HTTP 200 OK) and all services (Database, API) are healthy.
+1. Send an HTTP request to the deployed domain: verify HTTP 200 OK.
+2. Test critical paths (Authentication, API endpoints, core database transactions).
+3. Confirm telemetry and error log stream are free of unhandled exceptions.
 
 ---
 
-## ๐Ÿ“ Output Formats
+## 4. Rollback Readiness
 
-### Successful Deploy
-Generate a summary indicating:
-- **Summary**: Version, Environment, Duration, Platform
-- **URLs**: Production, Dashboard
-- **Report Location**: Confirm the deploy checklist and validation report has been written to the specified workspace path.
-- **What Changed**: Bullet points of new features or fixes
-- **Health Check**: Status of API and Database
+Always have an immediate rollback plan before triggering production releases:
+- Pin the previous stable build artifact, Docker image tag, or Git commit hash.
+- If post-deployment smoke tests fail, trigger rollback immediately:
+  ```text
+  deploy rollback
+  ```
 
-### Failed Deploy
-Generate an Error summary detailing:
-- **Error**: Step where it failed (e.g., Build failed at TypeScript compilation)
-- **Details**: Exact error snippet
-- **Resolution**: Step-by-step fix recommendation
-- **Rollback Available**: Suggest running `Deploy rollback` if needed.
+---
 
 ## Relationship To DevFlow 2.0
 
-- Classification: Companion command
-- Mainline status: Release support command, not a numbered stage
-- Typical entry points: `70-release` after the report is aligned and packaging is ready to execute
-- Typical handoff targets: `60-report`, `Changelog`, `Wiki`
-
-## Sources
-
-- `AGENTS.md`
-- `.agents/skills/release-git-operations/SKILL.md`
-- `.agents/skills/shipping-and-launch/SKILL.md`
-- `.agents/skills/deployment-procedures/SKILL.md`
-- `.agent/resources/schemas/deploy_report.template.md`
-- Related commands: `70-release`, `Commit`, `PR`, `Changelog`, `60-report`
-
-
+- **Classification**: Companion command & Delivery support
+- **Mainline integration**: Invoked after `70-release` when ready to deploy.
+- **Handoff**: `60-report`, `changelog`, `rollback`