@jakkrichm/create-nexus-devflow 2.0.12 → 2.0.14

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

@@ -3,119 +3,40 @@ name: preview
 description: "[Devflow] Local preview server management, smoke-check, and temporary runtime inspection before formal verification."
 ---
 
----
-description: Preview management and temporary runtime checks. Transitional compatibility path for the Preview companion command in DevFlow 2.0.
----
-
-# Preview Management
-
-## Usage
-
-```text
-Preview
-Preview start
-Preview stop
-Preview restart
-Preview check
-```
-
-This file keeps its old numeric path for migration compatibility.
-
-In DevFlow 2.0, `Preview` is a companion command, not a numbered mainline workflow.
-
-Primary behavior now lives in:
-
-```text
-.agents/skills/preview-local-check/SKILL.md
-```
+# Preview Management & Local Runtime Inspection
 
-Treat this workflow file as a compatibility wrapper around that skill.
+## Overview
 
-Manage the local preview development server or temporary runtime check.
+This is the preview master skill for Nexus-DevFlow. It manages local development/preview servers (`npm run dev`, `npm run preview`, `vite`, `next dev`), handles port conflicts, and executes smoke checks before formal verification.
 
-Use it when:
+## Usage & Sub-Commands
 
-- the team wants a quick visual or runtime check before formal verification
-- implementation needs a local smoke check
-- a temporary render helps clarify what changed
-- a human reviewer needs something concrete to inspect before giving feedback
-
-Preferred DevFlow 2.0 pairing:
-
-- from `40-implement`
-- from `50-verify`
+- `/preview`         - Inspect current preview status and health
+- `/preview start`   - Start the local preview/dev server
+- `/preview stop`    - Stop the running server process
+- `/preview restart` - Restart the preview server
+- `/preview check`   - Perform runtime smoke check against `http://localhost:<port>`
 
 ---
 
-## Sub-commands
+## 1. Process & Runtime Management
 
-- `Preview` - show current preview status
-- `Preview start` - start the server
-- `Preview stop` - stop the server
-- `Preview restart` - restart the server
-- `Preview check` - run a health check
+1. **Detect Framework & Command**: Identify the project runtime (`npm run dev`, `vite preview`, `pnpm start`, `python -m http.server`).
+2. **Handle Port Conflicts**: Check if the standard port (3000, 5173, 8080) is occupied; auto-select fallback port or terminate stale background processes.
+3. **Health & Smoke Check**: Query local endpoint via HTTP GET to verify HTTP 200 OK and asset loading.
+4. **Report Status**:
+   ```markdown
+   ## Preview Status
+   - **URL**: `http://localhost:3000`
+   - **App Type**: Next.js / Vite / Node.js
+   - **Health Status**: `OK` (200 OK)
+   - **Console / Network**: Zero fatal runtime errors
+   ```
 
 ---
 
-## Internal Process
-
-`Preview` manages the local preview workflow using the `preview-local-check` skill plus any available preview automation or equivalent project-local commands.
-
-When handling preview operations:
-
-1. detect the correct project or server command path
-2. report the current state clearly
-3. handle port conflicts gracefully
-4. keep the action scoped to preview management, not broader deployment
-5. distinguish between preview success and full verification success
-
-Commands should use the nearest equivalent project-local preview command for the project, such as `npm run dev`, `npm run preview`, framework-specific local servers, or other runtime helpers that already exist in the target project.
-
-### Resolving Port Conflicts
-
-If the port is in use, offer options:
-
-1. start on a different port
-2. terminate the process on the existing port
-3. specify a custom port
-
-### Status Format
-
-When displaying status, clearly state:
-
-- URL
-- project path
-- app type
-- health status
-- notes about blockers, missing dependencies, or startup warnings
-
-Example summary:
-
-```markdown
-## Preview Status
-
-- **URL**: `http://localhost:3000`
-- **Project Path**: `[absolute path]`
-- **App Type**: `Next.js | FastAPI | Odoo | PHP | Other`
-- **Health Status**: `OK | Warning | Failed`
-- **Notes**: [port conflict, startup issue, missing dependency, or none]
-```
-
 ## Relationship To DevFlow 2.0
 
-- 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`
-
-## Sources
-
-- `AGENTS.md`
-- `.agents/skills/preview-local-check/SKILL.md`
-- 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
-
+- **Classification**: Companion command & Runtime support
+- **Mainline stages**: `40-implement` (interactive visual check), `50-verify` (smoke test check)
+- **Handoff**: `50-verify`

package/template/.agents/skills/report-html/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: report-html
+description: "[Devflow] Standalone HTML Report Generator - render an interactive standalone HTML dashboard from spec.md or 60-report.md on demand."
+argument-hint: "{running-id or workspace path}"
+---
+
+# Standalone: Report HTML
+
+$ARGUMENTS
+
+Standalone companion command to generate an interactive, self-contained HTML report dashboard on demand from either a Fast-Track `spec.md` or a Deep-Track `60-report.md`.
+
+> [!NOTE]
+> HTML reports are **never automatically generated** during normal mainline stages (`/complete` or `60-report`). Use this command whenever you or stakeholders wish to view or share an interactive web report.
+
+## Invocations & Aliases
+
+- `/report:html`: Generate HTML report for the active or most recent run
+- `/report:html {running-id}`: Generate HTML report for the specified running ID
+- `npm run report:html -- {running-id}`: CLI npm script invocation
+- `$report:html`: Codex CLI invocation
+
+## Behavior & Contract
+
+When invoked:
+
+### 1. Identify Target Run
+1. Locate target run directory in `devflow/runs/{running-id}` from argument or `devflow/context/current-stage.md`.
+2. Check for either:
+   - Fast-Track Living Spec: `devflow/runs/{RUNNING_ID}/spec.md` (or `blueprint.md`)
+   - Deep-Track Report Digest: `devflow/runs/{RUNNING_ID}/60-report.md`
+
+### 2. Render Interactive HTML Dashboard
+Execute the HTML generation engine:
+```bash
+npm run report:html -- {RUNNING_ID}
+```
+Or execute the renderer to transform Markdown into a styled, standalone HTML document:
+- Path: `devflow/runs/{RUNNING_ID}/report.html`
+
+### 3. Output
+Provide:
+- Generated HTML file path: `file:///devflow/runs/{RUNNING_ID}/report.html`
+- Summary of sections rendered (Spec, Plan, Progress, QA Evidence, Release Notes)
+- Instructions to open the file in any browser

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

@@ -1,55 +1,71 @@
 ---
 name: 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."
+description: "[Devflow] Multi-axis code and PR review. Reviews diffs against standards, specs, correctness, security, performance, and 9arm scrutinize discipline."
 ---
 
-# Review
+# Code Review, Quality & PR Analysis
 
-Use this support skill as one verification lane. `50-verify` owns validation evidence; this skill reviews a diff from two separate angles.
+## Overview
 
-## Axes
+This is the comprehensive review master skill for Nexus-DevFlow. It evaluates code modifications, local diffs, branches, and pull requests across multiple dimensions before merging or releasing. Every change gets reviewed before merge — no exceptions.
 
-- **Standards**: does the change follow documented repo conventions?
-- **Spec**: does the change implement the originating issue, PRD, spec, or stage artifact?
+**The approval standard**: Approve a change when it definitely improves overall code health and satisfies the specification, even if it isn't perfect.
 
-Keep the axes separate so one does not hide the other.
+---
+
+## 1. The Scrutinize Discipline (9arm Review Pattern)
+
+Before jumping into line-by-line comments, apply the 4-step Scrutiny check:
+1. **Intent Check**: What problem is this change truly trying to solve? Is this the right problem?
+2. **Safer / Smaller Alternative**: Could this be achieved with fewer lines, zero new dependencies, or less complexity?
+3. **Runtime Path Trace**: Trace the execution path through inputs, error handling, async boundaries, and state mutations.
+4. **Precision & Evidence**: Does the code contain unproven assumptions or missing test evidence?
 
-## Process
+---
+
+## 2. The Five-Axis Review Framework
 
-1. Pin the fixed point.
-   - Use the user-supplied commit, branch, tag, or merge-base.
-   - If none is supplied, default to the active branch merge-base with `main` when available.
-   - Confirm the diff is non-empty.
+Every review evaluates code across these 5 core axes:
 
-2. Identify the spec source.
-   - 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.
+```text
+┌──────────────────────────────────────────────────────────┐
+│                 FIVE-AXIS CODE REVIEW                    │
+├──────────────┬───────────────────────────────────────────┤
+│ 1. Correctness│ Logic, edge cases, error paths, races     │
+│ 2. Simplicity │ Readable, concise, no dead code, DAMP/DRY │
+│ 3. Architecture│ Boundaries, dependencies, design patterns │
+│ 4. Security   │ Input validation, auth, no secrets/XSS    │
+│ 5. Performance│ No N+1 queries, async I/O, memoization    │
+└──────────────┴───────────────────────────────────────────┘
+```
 
-3. Identify standards sources.
-   - Look for repo docs such as `AGENTS.md`, `CONTRIBUTING.md`, coding standards, workflow docs, or stage contracts.
+---
 
-4. Review standards.
-   - Cite the violated standard.
-   - Distinguish hard violations from judgment calls.
-   - Skip issues that tooling already enforces unless tooling is missing.
+## 3. Review Lenses & Finding Severities
 
-5. Review spec.
-   - Report missing or partial requirements.
-   - Report scope creep.
-   - Report implemented behavior that appears wrong against the spec.
+Categorize all findings into actionable severities:
 
-6. Aggregate findings.
-   - Present `Standards` and `Spec` separately.
-   - Lead with concrete findings and file references.
-   - Record residual risk and skipped axes.
+- **P0 (Critical Blocker)**: Security vulnerability, data loss, runtime crash, broken main functionality. (Blocks `70-release`)
+- **P1 (Major Blocker)**: Spec mismatch, broken error handling, severe regression risk. (Blocks `70-release`)
+- **P2 (Normal Improvement)**: Readability, missing edge-case test, minor performance optimization.
+- **P3 (Nit / Suggestion)**: Naming polish, optional refactor, comment clarity.
 
-## Output
+---
+
+## 4. PR Review Process
+
+1. **Load Context**: Pin fixed point (merge-base with `main`), read spec (`20-spec.md`) and coding standards.
+2. **Review Standards vs. Spec**: Check adherence to project instructions (`AGENTS.md`) and acceptance criteria.
+3. **Validate Findings**: Ensure every finding is reproducible and points to specific files and line numbers.
+4. **Generate Report**: Save substantial review reports under:
+   ```text
+   devflow/runs/{ID}-{slug}/pr_review.md
+   ```
+
+---
 
-Return:
+## Relationship To DevFlow 2.0
 
-- fixed point and diff scope
-- standards sources
-- spec source or skipped reason
-- findings by axis
-- worst issue per axis
-- recommended DevFlow route
+- **Classification**: Companion command & Verification support
+- **Mainline stages**: `50-verify` (QA & Code Review lane), `70-release` (Pre-merge review)
+- **Handoff**: `40-implement` (for fixes), `50-verify`, `70-release`

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

@@ -103,6 +103,7 @@ Present the rollback plan to the user:
 ## Rules
 
 - **Preserve History**: Never delete run folders under `devflow/runs/`. Historical reports must remain intact.
+- **Update History Ledger**: When the rollback is completed and verified, update the target entry's status in `devflow/history/HISTORY.md` to `Rolled Back` with reference to the reversal commit.
 - **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-review/SKILL.md

@@ -1,166 +1,63 @@
----name: security-review
-
-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]"
 ---
-
-# Security Review
-
-$ARGUMENTS
-
-Perform a focused security-only review of a specified target (directory, project, list of files, or code diff) for **High Severity** and **Critical** security vulnerabilities.
-
-This workflow is a companion command in DevFlow 2.0. It creates a standardized stage artifact contract inside the active workspace.
-
-## Purpose
-
-Use this workflow to check an entire folder, project, or changed files for major security risks. It ensures your codebase does not introduce high-severity flaws before advancing to verification or release.
-
-## Behavior
-
-When `Security-Review` is triggered:
-
-1. **Resolve target and scope**:
-   - Determine the target folder, project, list of files, or git diff from the arguments.
-   - Scan all source files in the target directory recursively, or evaluate the specific list of files/diff.
-2. **Anchor the run**:
-   - Locate the active `running_id` from the workspace.
-   - If no active running ID is found, prompt the user or create a temporary run workspace (e.g., `sec-global` under `devflow/runs/sec-global/`).
-3. **Execute security-focused analysis**:
-   - Trace trust boundaries and inputs across the target files.
-   - Check only for **High Severity** and **Critical** security vulnerabilities (e.g., SQL/Command Injection, hardcoded secrets, authentication bypass, path traversal, RCE, data exposure).
-   - Ignore theoretical, style, low-impact, or medium/low severity findings for status blocking, but report them under Suggestions if present.
-4. **Load Template**:
-   - Inspect `.agent/resources/schemas/security_review.template.md`.
-   - Read the `artifact_language` configuration (framework default: `"th"`).
-   - Generate the report in English.
-5. **Write the Artifact**:
-   - Write the finalized security report to `devflow/runs/{ID}-{slug}/security-review.md`.
-   - Ensure the output strictly follows the template contract structure (Headings 1 to 11).
-
-## Output Contract & Formats
-
-The generated artifact must follow the English contract shape below.
-
-### English Output Template
-
-```markdown
+name: security-review
+description: "[Devflow] Security review, vulnerability scanner, and code hardening. Audits for OWASP vulnerabilities, secrets, injections, and auth flaws."
 ---
-id: "{running_id}-security-review"
-title: "Security Review: {Work Title}"
-doc_type: "companion"
-stage: "security-review"
-created: "{Date}"
-updated: "{Date}"
-owner: "{Owner}"
-status: "draft"
-artifact_language: "th"
-related_run: "{running_id}"
-related_files: []
----
-
-# Security Review: {Work Title}
-
-## 1. Objective
-
-- Perform a focused security review on the target directory, project, or files to detect High Severity and Critical security vulnerabilities.
-
-## 2. Source Inputs
-
-- Review Target: {Review Target}
-- Files Evaluated: []
-
-## 3. Project Context To Preserve
 
-- Global security constraints and authorization invariants.
-- Known exceptions or legacy patterns excluded from security flags.
+# Security Review, Hardening & Vulnerability Audit
 
-## 4. Stage-Specific Content
+## Overview
 
-### 🛡️ Security Review Result
-- **Status:** [pass | fail]
-- **Reason:** [Explain in detail with file and line references if fail, or "No high-severity or Critical security vulnerabilities found" if pass]
+This is the comprehensive security master skill for Nexus-DevFlow. It combines static vulnerability scanning, threat modeling, OWASP Top 10 defenses, and code hardening. Treat every external input as hostile, every secret as sacred, and every authorization check as mandatory.
 
-### 💡 Suggestions for Next Agent Action / Handoff
-[Provide concrete instructions and guidance for the subsequent Agent. If pass, list any medium/low security findings or recommendations for human consideration, directing the next verification/release Agent accordingly. If fail, list step-by-step remediation tasks for the implementer Agent to execute.]
-
-### 🔍 Detailed Scope Analysis
-- **Secrets & Configuration:** [Pass | Fail]
-- **Input Validation & Injection:** [Pass | Fail]
-- **Access Control & Auth:** [Pass | Fail]
-- **Data Protection & Cryptography:** [Pass | Fail]
-- **File System & Shell Safety:** [Pass | Fail]
-
-## 5. AI Actions Performed
-
-- Analyzed target codebase and traced untrusted inputs to critical sinks.
-- Scanned for hardcoded secrets, API keys, and environment leaks.
-
-## 6. Human Review Required
-
-- Verify findings and evaluate false positives if any.
-- Review medium/low risk suggestions for optional implementation.
-
-## 7. Approval Status
-
-- Pending
-
-## 8. Next Allowed Command
-
-- `40-implement {running_id}` (if fail, for code remediation)
-- `50-verify {running_id}` (if pass, to verify execution correctness)
-
-## 9. Nexus Event
-
-- `Debug` for deep-dive diagnostics or debugging.
-- `grill-with-docs` to clarify security guidelines.
-
-## 10. Change Log
-
-- {Date}: Initial English security review report created.
-
-## 11. Additional Notes
+---
 
-- [Add custom sub-headings below if needed]
-```
+## 1. The Three-Tier Security Boundary
 
-## Pass Response Requirements
+### Always Do (No Exceptions)
+- **Validate & sanitize all inputs** at the boundary (Zod, Yup, schema validation).
+- **Parameterize all queries** — never concatenate user input into SQL/NoSQL queries.
+- **Encode outputs** to prevent XSS (rely on framework auto-escaping).
+- **Hash credentials** using bcrypt, Argon2, or scrypt.
+- **Enforce secure cookies**: `httpOnly`, `secure`, `sameSite=lax/strict`.
 
-When no High Severity or Critical vulnerability is found, the sections under **Stage-Specific Content** must be formatted as:
+### Never Do
+- **Never commit secrets**, API keys, tokens, or credentials to git.
+- **Never trust client-side checks** as a security barrier.
+- **Never use `eval()`, `exec()`, or raw `innerHTML`** with untrusted user data.
+- **Never expose internal stack traces** or detailed database errors to users.
 
-```markdown
-### 🛡️ Security Review Result
-- **Status:** pass
-- **Reason:** No high-severity or Critical security vulnerabilities found
+---
 
-### 💡 Suggestions for Next Agent Action / Handoff
-[List any medium, low security findings or recommendations for human consideration, directing the next verification/release Agent accordingly]
-```
+## 2. OWASP & Critical Vulnerability Vectors
 
-## Fail Response Requirements
+| Category | Primary Risk | Mandatory Defense |
+| :--- | :--- | :--- |
+| **A01: Broken Access Control** | IDOR, missing role checks | Enforce server-side authorization on every endpoint/data fetch |
+| **A02: Cryptographic Failures** | Plaintext tokens/passwords, weak cipher | Use TLS 1.3, salted hashing, secret managers / `.env` |
+| **A03: Injection** | SQL, NoSQL, OS Command, Template | Parameterized queries, avoid shell spawning with user input |
+| **A04: Insecure Design** | Missing rate limits, business logic flaw | Defense-in-depth, token bucket throttling, safe defaults |
+| **A05: Security Misconfig** | Permissive CORS (`*`), exposed debug endpoints | Restrict CORS origins, disable debug/admin paths in production |
+| **A07: Identification & Auth** | Session fixation, brute-force | Account lockouts, secure session rotation, MFA support |
+| **A08: Software & Data Integrity**| Untrusted CI/CD packages, deserialization | Run `npm audit`, pin dependency hashes, validate payloads |
+| **A09: Logging & Monitoring** | Missing audit logs or logging secrets | Structured logging with PII masking, alert on repeated auth failure |
+| **A10: SSRF** | Fetching internal URLs from user input | Whitelist allowable destination protocols and domains |
 
-When a High Severity or Critical vulnerability is found:
+---
 
-- Use status `fail`.
-- Explain why the issue is High/Critical Severity with file and line references.
-- In **Suggestions for Next Agent Action / Handoff**, write a clear set of step-by-step remediation tasks for the Coder/Implementer Agent to resolve the vulnerability.
+## 3. Security Review Process
 
-## Security Scope & Rules
+1. **Target & Scope**: Inspect targeted files, PR diffs, or entire project directories.
+2. **Trace Trust Boundaries**: Follow untrusted data from entry (HTTP handlers, CLI arguments, file uploads) to sinks (DB, shell, HTML).
+3. **Scan for Secrets & Configs**: Detect hardcoded passwords, private keys, and environment variable leaks.
+4. **Generate Report**: Save formal security audits under:
+   ```text
+   devflow/runs/{ID}-{slug}/security-review.md
+   ```
 
-Evaluate high-severity risks including:
-- **Hardcoded secrets**: passwords, API keys, private keys, database strings.
-- **Injections**: SQL, NoSQL, OS Command, Template, or Path traversal.
-- **Unvalidated inputs**: dynamic evaluation (`eval`), shell execution, or raw unescaped HTML rendering.
-- **Insecure configuration**: broken authorization, sensitive exposure in public endpoints/logs.
+---
 
 ## Relationship To DevFlow 2.0
 
-- **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.
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/security_review.template.md`
-- `docs/workspace-artifacts.md`
+- **Classification**: Companion command & Safety gate
+- **Mainline integration**: Run during `40-implement` or `50-verify` before `70-release`.
+- **Handoff**: P0/P1 security findings block release and return to `40-implement` for immediate remediation.

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

@@ -3,77 +3,68 @@ name: simplify
 description: "[Devflow] Code simplification and refactoring for clarity and maintainability without altering runtime behavior."
 ---
 
----
-description: Simplify code for clarity and maintainability while preserving behavior.
----
-
-# Simplify - Code Simplification And Refactoring
+# Code Simplification & Refactoring
 
-Invoke the `code-simplification` skill.
+## Overview
 
-Primary behavior already lives in:
-
-```text
-.agents/skills/code-simplification/SKILL.md
-```
+This is the comprehensive code simplification master skill for Nexus-DevFlow. It reduces cognitive load, cleans up unnecessary abstractions, flattens deep nesting, and removes dead code while **preserving 100% exact runtime behavior**.
 
-Treat this workflow file as a wrapper around that skill.
+**Core Rule**: Every simplification must pass: *"Would a new team member understand this faster than the original, without any behavioral regression?"*
 
-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`.
+## 1. The Five Principles of Simplification
 
-## Process
+1. **Preserve Behavior Exactly**: Same inputs, outputs, error conditions, side effects, and ordering.
+2. **Follow Project Conventions**: Consistency with neighboring files beats personal style preferences.
+3. **Delete Dead & Unused Code**: Remove abandoned helpers, dead branch paths, and leftover debugging code.
+4. **Flatten Control Flow**: Replace nested conditionals and callback pyramids with guard clauses and early returns.
+5. **Eliminate Speculative Generalization**: Replace single-use abstractions with clear, direct implementations.
 
-1. Read project instructions and study local conventions.
-2. Identify the target code: recent changes unless a broader scope is specified.
-3. Understand purpose, callers, edge cases, and test coverage before touching it.
-4. Scan for simplification opportunities:
-   - deep nesting to guard clauses or extracted helpers
-   - long functions to responsibility-based splits
-   - nested ternaries to clearer control flow
-   - vague names to descriptive names
-   - duplicated logic to shared helpers
-   - dead code to removal after confirmation
-   - speculative abstraction to simpler concrete flow
-5. Inspect `.agent/resources/schemas/refactoring.template.md` before generating a report.
-6. Apply each simplification incrementally and run verification after each meaningful change.
-7. Save the refactoring report to:
+---
 
-```text
-devflow/reports/{date}-refactoring-{slug}.md
+## 2. High-Impact Simplification Techniques
+
+### A. Guard Clauses Over Nested Conditionals
+```typescript
+// Before: Deep indentation
+function processOrder(order) {
+  if (order) {
+    if (order.isValid) {
+      if (order.isPaid) {
+        return fulfill(order);
+      }
+    }
+  }
+}
+
+// After: Early returns
+function processOrder(order) {
+  if (!order || !order.isValid) return;
+  if (!order.isPaid) return;
+  return fulfill(order);
+}
 ```
 
-8. Verify tests pass, the build succeeds, and the diff stays behavior-preserving.
-
-If tests fail after a simplification, revert that specific change and reconsider.
+### B. Inline Single-Use Helpers & Dead Shims
+If a helper function is only called once and adds indirection without semantic clarity, inline it directly.
 
-## Output
+### C. Remove Dead Code & Leftover Comments
+Delete commented-out code blocks, `// removed` notes, and unused variables (`_unused`). Version control (Git) remembers the history.
 
-Return:
-
-- what was simplified
-- what was intentionally left alone
-- validation evidence
-- remaining risks or debt
-
-## Relationship To DevFlow 2.0
-
-- 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`
+---
 
-## Sources
+## 3. Verification & Safety Loop
 
-- `AGENTS.md`
-- `.agents/skills/code-simplification/SKILL.md`
-- `.agent/resources/schemas/refactoring.template.md`
-- Related commands: `40-implement`, `50-verify`, `PR-Review`, `Agent`
+1. Run unit tests before touching code (`npm test` -> GREEN).
+2. Apply one small refactoring step at a time.
+3. Rerun tests immediately after each step. If tests break, revert and reconsider.
+4. Verify overall build and linter checks.
 
-## Next Workflow Recommendation
+---
 
-- **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
+## Relationship To DevFlow 2.0
 
+- **Classification**: Companion command & Refactoring support
+- **Mainline integration**: Used during `40-implement` (Refactor step of TDD) or `50-verify`.
+- **Handoff**: `50-verify` (proves zero regressions).