@drafthq/draft 3.6.0 → 3.7.2

package/skills/deep-review/SKILL.md

@@ -12,6 +12,7 @@ Perform an exhaustive end-to-end lifecycle review of a service, component, or mo
 When `draft/graph/schema.yaml` exists, this skill **must** follow the graph-first lookup contract in [core/shared/graph-query.md](../../core/shared/graph-query.md) §Mandatory Lookup Contract. Deep-review uses the graph to **narrow review scope** — a key 30–50% scope reduction:
 
 First resolve the bundled helpers:
+
 ```bash
 # Locate Draft's bundled helpers (cwd is the user's project; ${CLAUDE_PLUGIN_ROOT}
 # is not exported into skill Bash). See core/shared/tool-resolver.md.
@@ -28,11 +29,12 @@ DRAFT_TOOLS="${DRAFT_PLUGIN_ROOT:-$(cat ~/.cache/draft/plugin-root 2>/dev/null)}
 
 Filesystem `grep` is reserved for source-text scans (API contract strings, secret patterns, log message audits). Module enumeration and caller tracing go through the graph.
 
-## Red Flags - STOP if you're:
+## Red Flags - STOP if you're
 
 See [shared red flags](../../core/shared/red-flags.md) — applies to all code-touching skills.
 
 Skill-specific:
+
 - Acting without reading the Draft context (`draft/.ai-context.md`, `draft/tech-stack.md`, `draft/product.md`)
 - Modifying production code. This command is for auditing and reporting only. Fixes should be handled in a separate implementation track.
 - Reviewing a module that was already reviewed recently, unless explicitly requested.
@@ -74,6 +76,7 @@ If `.ai-context.md` is missing, check for `draft/architecture.md` as a fallback
 ## Review Phases
 
 ### Phase 1: Context & Structural Analysis
+
 - Load Draft context following the procedure in `core/shared/draft-context-loading.md`. Use loaded context to understand intended boundaries and critical invariants.
 - **Load track HLD/LLD if any track owns this module.** Scan `draft/tracks/*/hld.md` for §Detailed Design components matching the module path. When found, extract claims from §High-Level Design / Key Design Decisions, §Checklist (Performance/Scale/Security/Resiliency/Multi-tenancy/Upgrade/Cost), §Observability, §Deployment, and any LLD §Classes and Interfaces invariants and §Error Handling policies. These claims become the design contract this audit measures against (HLD claims vs code reality).
 - **Load Learned Anti-Patterns** — If `draft/guardrails.md` exists, read the `## Learned Anti-Patterns` section before analysis begins. During the audit, when an issue matches a learned anti-pattern, prefix the finding with `[KNOWN-ANTI-PATTERN: {pattern name}]`. This separates newly discovered issues from documented recurring patterns and allows the report to recommend systemic remediation rather than isolated fixes.
@@ -124,7 +127,7 @@ Every finding in this phase must cite the relevant rule range (e.g., `[RC-008..R
   - **Latency profiles:** Are p50, p95, p99 latency targets defined and achievable?
   - **Error budget:** What percentage of the error budget has been consumed? Is the module in "protect" or "innovate" mode?
   - **Availability:** Does the module's uptime target (99.9%, 99.99%) match its actual architecture?
-  - If no SLOs are defined, recommend defining them. Reference: Google SRE (https://sre.google/sre-book/service-level-objectives/).
+  - If no SLOs are defined, recommend defining them. Reference: Google SRE (<https://sre.google/sre-book/service-level-objectives/>).
 - **Database Schema Analysis:**
   - **Missing indexes:** Queries filtering/joining on unindexed columns.
   - **Wide table scans:** SELECT * or queries without WHERE clauses on large tables.
@@ -154,6 +157,7 @@ For each HLD claim extracted in Phase 1, validate it against code:
 Surface gaps as findings with prefix `[HLD-DRIFT: §<section>]` (Important if the gap is documentation-vs-implementation drift; Critical if the code violates a stated invariant or security claim).
 
 ### Phase 4: Identify Actionable Fixes (Spec Generation)
+
 Instead of mutating the source code, translate all findings into clear, actionable requirements that a developer (or agent) can implement via Test-Driven Development.
 
 ### Phase 5: Resilience & Chaos Engineering Assessment
@@ -225,11 +229,13 @@ reviewer: "{model name from runtime}"
 **Verdict:** PASS / CONDITIONAL PASS / FAIL
 
 **Verdict criteria:**
+
 - **FAIL** = any Critical issue found.
 - **CONDITIONAL PASS** = no Critical issues but Important issues exist.
 - **PASS** = only Minor issues or no issues.
 
 Format findings as actionable tasks:
+
 ```markdown
 ### [Critical/Important/Minor] Issue Name `[RC-### or CQ-### or SEC-## if applicable]`
 **File:** path/to/file:line
@@ -245,6 +251,7 @@ Cite the most specific rule ID from `core/guardrails/review-checks.md` (RC-###),
 **For Phase 3 (Security):** Load `core/guardrails/security.md` and apply the 5-step security reasoning chain. Hard red line violations (SEC-01…SEC-10) are always Critical. Run `core/guardrails/dependency-triage.md` procedure for any dependency manifest files in the module's scope `[RC-014]`.
 
 **Constraints:**
+
 - Do not refactor code yourself.
 - Flag ambiguous fixes for human review instead of guessing.
 - If the module is too large, decompose it and review sub-modules sequentially.
@@ -272,6 +279,7 @@ Every deep-review report must end with a `## Next Actions` section listing the s
 ```
 
 Rules:
+
 - Production-blocking findings (`[SEC-*]`, ACID violations, unbounded resource use) produce blocker rows.
 - Suggest `/draft:adr` for structural changes, `/draft:new-track` for multi-week remediation, `/draft:incident-response` for hot issues, `/draft:tech-debt` for systemic items.
 - Cap at 10 actions; group related fixes under one row.
@@ -283,14 +291,16 @@ Rules:
 After deep-review audit completion:
 
 **If architecture debt found:**
-```
+
+```text
 "Architecture debt identified in module audit. Consider:
   → /draft:tech-debt — Catalog and prioritize the architecture debt
   → /draft:adr — Document undiscovered design decisions found during review"
 ```
 
 **If documentation gaps found:**
-```
+
+```text
   → /draft:documentation runbook — Generate operational runbook for this module"
 ```
 
@@ -307,11 +317,13 @@ If `draft/graph/schema.yaml` does not exist, set `Graph files queried: NONE` and
 ## Graph Usage Report (append to report)
 
 Emit the canonical footer from [core/shared/graph-usage-report.md](../../core/shared/graph-usage-report.md) §Canonical footer. The lint hook `scripts/tools/check-graph-usage-report.sh` validates the section on save.
+
 ## Skill Telemetry
 
 As the last step after saving the deep-review report, emit a metrics record. Best-effort — never block.
 
 **Payload fields:**
+
 ```json
 {
   "skill": "deep-review",
@@ -327,6 +339,7 @@ As the last step after saving the deep-review report, emit a metrics record. Bes
 ```
 
 **Emit call:**
+
 ```bash
 # Locate Draft's bundled helpers (cwd is the user's project; ${CLAUDE_PLUGIN_ROOT}
 # is not exported into skill Bash). See core/shared/tool-resolver.md.

package/skills/deploy-checklist/SKILL.md

@@ -17,11 +17,12 @@ When `draft/graph/schema.yaml` exists, this skill **must** follow the graph-firs
 
 Filesystem `grep` is reserved for source-text scans (migration file names, flag-key strings). Module/impact discovery goes through the graph.
 
-## Red Flags — STOP if you're:
+## Red Flags — STOP if you're
 
 See [shared red flags](../../core/shared/red-flags.md) — applies to all code-touching skills.
 
 Skill-specific:
+
 - Deploying without a rollback plan
 - Skipping database migration verification
 - Deploying on Friday without explicit team approval
@@ -87,6 +88,7 @@ not be considered "ready to deploy" if `pre_deploy_status != passing`.
 ## Step 1: Parse Arguments
 
 Check for arguments:
+
 - `/draft:deploy-checklist` — Interactive: detect active track or ask for service name
 - `/draft:deploy-checklist <service>` — Generate checklist for named service
 - `/draft:deploy-checklist track <id>` — Generate from track's change scope
@@ -111,7 +113,7 @@ Generate a four-phase checklist customized to the project's tech stack. Adapt it
 
 ### Phase 0: HLD/LLD Gate (track-scoped only, when hld.md exists)
 
-> ** blocker:** the HLD's §Checklist sections were the design-time commitment. If they are still empty at deploy time, the design was never validated against operational reality. This phase enforces that.
+> **blocker:** the HLD's §Checklist sections were the design-time commitment. If they are still empty at deploy time, the design was never validated against operational reality. This phase enforces that.
 
 For `criticality ∈ {high, mission-critical}` (read from `hld.md` frontmatter `classification.criticality`), every row below MUST be checked before Phase 1 begins. For `standard` criticality, missing rows produce warnings but do not block. For `low`, this phase is informational.
 
@@ -176,6 +178,7 @@ If a partial file is needed for tracking, write it with `status: BLOCKED` in the
 ### Rollback Triggers
 
 Initiate rollback if ANY of these occur:
+
 - Error rate exceeds 2x baseline
 - p95 latency exceeds 3x baseline
 - Data corruption detected
@@ -195,10 +198,12 @@ Initiate rollback if ANY of these occur:
 ## Step 4: Present and Track
 
 Present the checklist interactively. For each critical item (marked **bold**):
+
 - If unchecked and user wants to proceed: warn "Critical item unchecked: [item]. Are you sure? [y/N]"
 - Default: stop and address critical items
 
 Allow the user to:
+
 - Check off items as they complete them
 - Add custom items specific to this deployment
 - Mark items as N/A with justification
@@ -219,6 +224,7 @@ Include the report header table immediately after frontmatter:
 ```
 
 Save to:
+
 - Track-scoped: `draft/tracks/<id>/deploy-checklist.md`
 - Standalone: `draft/deploy-checklist-<timestamp>.md` with symlink `deploy-checklist-latest.md`
 
@@ -241,6 +247,7 @@ If `draft/graph/schema.yaml` does not exist, set `Graph files queried: NONE` and
 ## Graph Usage Report (append to checklist)
 
 Emit the canonical footer from [core/shared/graph-usage-report.md](../../core/shared/graph-usage-report.md). The lint hook `scripts/tools/check-graph-usage-report.sh` validates the section on save.
+
 ## Cross-Skill Dispatch
 
 - **Auto-invoked by:** `/draft:upload` (pre-upload verification)

package/skills/documentation/SKILL.md

@@ -7,7 +7,7 @@ description: Technical documentation writing and maintenance. Modes — readme,
 
 You are generating or updating technical documentation for this project using structured writing principles.
 
-## Red Flags — STOP if you're:
+## Red Flags — STOP if you're
 
 - Writing docs without reading the code first
 - Duplicating information that exists elsewhere (link instead)
@@ -22,6 +22,7 @@ You are generating or updating technical documentation for this project using st
 ## Pre-Check
 
 1. Check for Draft context:
+
 ```bash
 ls draft/ 2>/dev/null
 ```
@@ -41,6 +42,7 @@ If `draft/` doesn't exist, this skill works standalone — generate docs from co
 ## Step 2: Gather Source Material
 
 ### README Mode
+
 - Read existing `README.md` (if any)
 - Read `draft/product.md` — Product vision, users, goals
 - Read `draft/tech-stack.md` — Technologies, setup requirements
@@ -48,6 +50,7 @@ If `draft/` doesn't exist, this skill works standalone — generate docs from co
 - Scan for `Makefile`, `package.json`, `pyproject.toml` — Build/run commands
 
 ### Runbook Mode
+
 - Read `draft/architecture.md` or `draft/.ai-context.md` — Service topology, dependencies
 - Read `draft/workflow.md` — Deployment conventions
 - Read `draft/tech-stack.md` — Infrastructure details
@@ -55,12 +58,14 @@ If `draft/` doesn't exist, this skill works standalone — generate docs from co
 - If Jira MCP available: check recent incident tickets for the service
 
 ### API Mode
+
 - Read source code for public interfaces, exported functions, API routes
 - Read existing API docs (Swagger, OpenAPI, JSDoc, docstrings)
 - Read `draft/architecture.md` — API conventions, data models
 - Read `draft/tech-stack.md` — API framework details
 
 ### Onboarding Mode
+
 - Read ALL draft context files in order:
   1. `draft/product.md` — What is this project?
   2. `draft/tech-stack.md` — What technologies?
@@ -83,6 +88,7 @@ Follow these principles (from `core/agents/writer.md`):
 ## Step 4: Generate Document
 
 ### README Structure
+
 ```markdown
 # {Project Name}
 
@@ -105,6 +111,7 @@ Follow these principles (from `core/agents/writer.md`):
 ```
 
 ### Runbook Structure
+
 ```markdown
 # Runbook: {Service Name}
 
@@ -128,6 +135,7 @@ Follow these principles (from `core/agents/writer.md`):
 ```
 
 ### API Documentation Structure
+
 ```markdown
 # API: {Module Name}
 
@@ -144,6 +152,7 @@ Follow these principles (from `core/agents/writer.md`):
 ```
 
 ### Onboarding Structure
+
 ```markdown
 # Welcome to {Project Name}
 
@@ -172,6 +181,7 @@ Follow these principles (from `core/agents/writer.md`):
 ## Step 5: Output
 
 Save to:
+
 - README: `README.md` in project root
 - Runbook: `draft/docs/runbook-<service>.md`
 - API: `draft/docs/api-<module>.md`
@@ -180,6 +190,7 @@ Save to:
 Create `draft/docs/` directory if needed.
 
 **Pre-save validation:**
+
 - Every file path referenced in the doc resolves to a real file (broken links are a common LLM failure mode here).
 - Every relative link in the doc resolves under the project root.
 - Code blocks copied from sources match the current commit (no stale snippets).

package/skills/draft/SKILL.md

@@ -7,7 +7,7 @@ description: "Lists Draft's canonical workflow commands, explains the Context-Dr
 
 Draft is a methodology for structured software development: **Context → Spec & Plan → Implement → Verify**
 
-## Red Flags - STOP if you're:
+## Red Flags - STOP if you're
 
 - Jumping straight to implementation without reading existing Draft context
 - Suggesting `/draft:implement` before a track has an approved spec and plan
@@ -22,16 +22,19 @@ Draft is a methodology for structured software development: **Context → Spec &
 ## Workflow Commands
 
 ### Canonical Workflow
-```
+
+```text
 init → plan → implement → review → upload
                ↑            |
                └────────────┘  (review auto-invoked at phase boundaries)
 ```
 
 ### Primary Workflow (Parent) Commands
+
 These 7 canonical parent commands coordinate and orchestrate the entire development lifecycle, automatically routing to specialist subcommands when appropriate.
 
 ### Routed Core Workflows (5 routers)
+
 The 5 router commands provide intent-based dispatch into the 20+ specialist commands. Use the router form for discoverability; leaf commands remain supported for compatibility.
 
 | Router | Scope | Dispatches To (examples) |
@@ -47,39 +50,45 @@ The 5 router commands provide intent-based dispatch into the 20+ specialist comm
 ---
 
 ### Specialist & Subcommands
+
 These commands remain available for targeted, specialist execution outside parent command orchestration. **Every command below appears exactly once in this reference.**
 
 #### 1. Planning & Architecture
-* `/draft:new-track` - Create a new feature/bug track with structured `spec.md` and `plan.md`
-* `/draft:decompose` - Perform module-level decomposition with dependency mapping
-* `/draft:change` - Safely manage and document mid-track requirement changes and plan updates
-* `/draft:adr` - Write Architecture Decision Records to capture permanent technical choices
+
+- `/draft:new-track` - Create a new feature/bug track with structured `spec.md` and `plan.md`
+- `/draft:decompose` - Perform module-level decomposition with dependency mapping
+- `/draft:change` - Safely manage and document mid-track requirement changes and plan updates
+- `/draft:adr` - Write Architecture Decision Records to capture permanent technical choices
 
 #### 2. Quality & Testing
-* `/draft:quick-review` - Fast, lightweight 4-dimension code review for staged changes or diffs
-* `/draft:bughunt` - Exhaustive 14-dimension codebase-wide bug hunt with verification protocol
-* `/draft:deep-review` - Rigorous module-scoped lifecycle audit (ACID compliance, resilience)
-* `/draft:coverage` - Measure and report code coverage (targeting 95%+ for changed code)
-* `/draft:testing-strategy` - Design testing plan and identify coverage/mocking strategies
-* `/draft:learn` - Discover coding patterns from recent Git diffs and update `draft/guardrails.md`
+
+- `/draft:quick-review` - Fast, lightweight 4-dimension code review for staged changes or diffs
+- `/draft:bughunt` - Exhaustive 14-dimension codebase-wide bug hunt with verification protocol
+- `/draft:deep-review` - Rigorous module-scoped lifecycle audit (ACID compliance, resilience)
+- `/draft:coverage` - Measure and report code coverage (targeting 95%+ for changed code)
+- `/draft:testing-strategy` - Design testing plan and identify coverage/mocking strategies
+- `/draft:learn` - Discover coding patterns from recent Git diffs and update `draft/guardrails.md`
 
 #### 3. Operations & Debugging
-* `/draft:status` - Display a comprehensive overview of active track phases, tasks, and modules
-* `/draft:revert` - Safely roll back active tasks or commits using Git-aware tracking
-* `/draft:debug` - Structured 4-stage debugging flow (reproduce → isolate → diagnose → fix)
-* `/draft:standup` - Summarize git activity and file changes for standup reporting
-* `/draft:deploy-checklist` - Pre-deployment checklist verification with automated rollback triggers
-* `/draft:upload` - Pre-upload gate: review, HLD approvals, validator chain, then git upload/PR
-* `/draft:incident-response` - Coordinate incident lifecycle (triage → mitigate → postmortem)
+
+- `/draft:status` - Display a comprehensive overview of active track phases, tasks, and modules
+- `/draft:revert` - Safely roll back active tasks or commits using Git-aware tracking
+- `/draft:debug` - Structured 4-stage debugging flow (reproduce → isolate → diagnose → fix)
+- `/draft:standup` - Summarize git activity and file changes for standup reporting
+- `/draft:deploy-checklist` - Pre-deployment checklist verification with automated rollback triggers
+- `/draft:upload` - Pre-upload gate: review, HLD approvals, validator chain, then git upload/PR
+- `/draft:incident-response` - Coordinate incident lifecycle (triage → mitigate → postmortem)
 
 #### 4. Setup & Documentation
-* `/draft` - Display this command overview and help reference
-* `/draft:init` - Single scope-aware entry point: builds the root-first code graph (`draft/graph/`) and project context; run at the repo root or inside any sub-module (monorepo context comes from running it at root)
-* `/draft:discover` - Phase 0 code-spike report (hotspots, mode flags, open questions) before spec freeze
-* `/draft:documentation` - Generate structured codebase documentation (API, Onboarding, Runbooks)
-* `/draft:tech-debt` - Audit technical debt across 6 key dimensions
+
+- `/draft` - Display this command overview and help reference
+- `/draft:init` - Single scope-aware entry point: builds the root-first code graph (`draft/graph/`) and project context; run at the repo root or inside any sub-module (monorepo context comes from running it at root)
+- `/draft:discover` - Phase 0 code-spike report (hotspots, mode flags, open questions) before spec freeze
+- `/draft:documentation` - Generate structured codebase documentation (API, Onboarding, Runbooks)
+- `/draft:tech-debt` - Audit technical debt across 6 key dimensions
 
 **Integration:**
+
 | Command | Purpose |
 |---------|---------|
 | `/draft:jira` | Unified Jira workflows (preview / create / review) |
@@ -123,9 +132,10 @@ flowchart TD
 ## Actionability: Command Invocation Examples
 
 ### Example 1: `/draft:status`
+
 Parses active tracks, phases, tasks, and module mappings:
 
-```
+```yaml
 PROJECT: Bookshelf API Service
 
 [track-042] OAuth2 Integration  —  [~] In Progress  (Phase 2/3, 4/9 tasks)
@@ -137,9 +147,10 @@ PROJECT: Bookshelf API Service
 ```
 
 ### Example 2: `/draft:implement`
+
 Reads `plan.md`, picks the current incomplete task, and continues it (TDD-aware):
 
-```
+```text
 Active track: [track-042] OAuth2 Integration
 Current task: [~] 2.1 Implement token generation endpoint
 TDD: on  →  writing tests/auth/token_generation_test.go (Red stage)
@@ -163,9 +174,9 @@ Used throughout `plan.md` files and referenced by the validation checkpoints abo
 
 You can also use natural language. Prefer the 5 router commands (`/draft:plan`, `/draft:ops`, `/draft:docs`, `/draft:discover`, `/draft:jira`) for grouped access; they analyze intent and dispatch.
 
-* **[quality-guide.md](./quality-guide.md)** — Quality Audit Spectrum, command choices, and coordination with external bug-hunting tools.
-* **[context-files.md](./context-files.md)** — Schema, role, and usage of each file inside the `draft/` context directory.
-* **[intent-mapping.md](./intent-mapping.md)** — Maps natural language phrasing to precise Draft commands for conversational AI usage.
+- **[quality-guide.md](./quality-guide.md)** — Quality Audit Spectrum, command choices, and coordination with external bug-hunting tools.
+- **[context-files.md](./context-files.md)** — Schema, role, and usage of each file inside the `draft/` context directory.
+- **[intent-mapping.md](./intent-mapping.md)** — Maps natural language phrasing to precise Draft commands for conversational AI usage.
 
 ---
 

package/skills/draft/context-files.md

@@ -6,7 +6,7 @@ When the `draft/` directory exists at the root of a project, the files within it
 
 All context files reside in `draft/` at your project root:
 
-```
+```text
 draft/
 ├── architecture.md       # Full human engineering reference (Source of Truth)
 ├── .ai-context.md        # Token-optimized AI context (derived automatically)
@@ -22,36 +22,43 @@ draft/
 ## Detailed File Reference
 
 ### 1. `draft/architecture.md` (Engineering Source of Truth)
+
 * **Purpose:** Comprehensive, human-readable reference detailing the system's design, domain model, services, module diagrams, and key data flows.
 * **When to read:** When designing new components, onboarding, or reviewing module boundaries.
 * **When to update:** After running decomposition, making major architectural changes, or completing an epic.
 
 ### 2. `draft/.ai-context.md` (Token-Optimized AI Context)
+
 * **Purpose:** A derived, lightweight (200-400 lines) copy of the architecture file designed specifically to maximize AI model efficiency. It omits verbose descriptions and captures essential system definitions, directory structures, and module APIs.
 * **When to read:** AI models read this automatically on every invocation to orient themselves.
 * **When to update:** Generated automatically whenever `draft/architecture.md` changes. Do not edit this file manually.
 
 ### 3. `draft/product.md` (Product & Business Vision)
+
 * **Purpose:** Defines the high-level business goals, core user personas, key workflows, success metrics, and long-term vision.
 * **When to read:** Before proposing features or starting plans, to verify alignment with business goals.
 * **When to update:** When product strategy changes or a new epic is initiated.
 
 ### 4. `draft/tech-stack.md` (Constraints & Stack Decisions)
+
 * **Purpose:** Records explicit details of the languages, frameworks, databases, libraries, deployment environment, and testing tools used. Contains absolute constraints (e.g., "No external ORMs allowed").
 * **When to read:** Before proposing libraries or deciding how to implement tasks.
 * **When to update:** When upgrading dependencies or making team-wide tech stack decisions.
 
 ### 5. `draft/workflow.md` (Work & Style Preferences)
+
 * **Purpose:** Outlines coding style conventions, test-driven development (TDD) rules, commit message guidelines, git branch naming schemes, and build scripts.
 * **When to read:** During implementation and review cycles to ensure compliance.
 * **When to update:** When adjusting developer processes, lint rules, or build tooling.
 
 ### 6. `draft/guardrails.md` (Learned Patterns & Anti-Patterns)
+
 * **Purpose:** Stores positive code conventions and negative anti-patterns discovered during development. This serves as an automated memory for the AI.
 * **When to read:** Before coding to avoid repeating common codebase-specific mistakes.
 * **When to update:** Run `/draft:learn` to automatically extract rules from your Git diffs or write them manually when discovering a repeated bug.
 
 ### 7. `draft/tracks.md` (Track Registry)
+
 * **Purpose:** Registers all active, completed, and blocked tracks (feature or bug fixes). Contains IDs, descriptions, and current status markers.
 * **When to read:** Before planning new work to prevent duplication, or when generating status reports.
 * **When to update:** Automatically updated by `/draft:plan` and `/draft:status`.

package/skills/draft/quality-guide.md

@@ -16,26 +16,34 @@ This guide helps you choose the most effective quality control and review comman
 ## Command Decision Guide
 
 ### 1. Fast Feedback / Pre-Commit Sanity Check
+>
 > [!TIP]
 > Use **`/draft:quick-review`** when you want a fast, lightweight sanity check of your modified files before opening a PR or running full reviews.
+
 - **When to run:** Before staging changes, during local development loops.
 - **Why:** Zero setup, rapid turnaround, checks standard dimensions (security, performance, styling).
 
 ### 2. Track Completion & Pull Request Quality Gate
+>
 > [!IMPORTANT]
 > Use **`/draft:review`** (the canonical review command) when you finish a development phase or an entire track.
+
 - **When to run:** Before submitting work for final PR approval.
 - **Why:** It validates the implementation directly against the active track's `spec.md` and `plan.md` to ensure all acceptance criteria and quality gates are met. It also auto-invokes coverage checks when TDD is active.
 
 ### 3. Debugging Hard-to-Find Defects or Refactoring
+>
 > [!WARNING]
 > Use **`/draft:bughunt`** if you are encountering elusive bugs, regression errors, or before refactoring a legacy module.
+
 - **When to run:** Prior to refactoring complex areas, or when users report intermittent production bugs.
 - **Why:** Conducts a deep, 14-dimension sweep specifically designed to surface edge cases, race conditions, memory leaks, and logic flaws.
 
 ### 4. Shipping Core Infrastructure to Production
+>
 > [!CAUTION]
 > Use **`/draft:deep-review`** before launching a critical service, API, database layer, or high-throughput component.
+
 - **When to run:** Before major deployments or architectural sign-offs.
 - **Why:** Audits the architecture for ACID compliance, concurrency safety, fault tolerance, rate limiting, and telemetry, providing a formal readiness score.
 
@@ -45,7 +53,7 @@ This guide helps you choose the most effective quality control and review comman
 
 Many AI tools and editors provide built-in bug-hunting agents (such as Claude Code's native `bughunt` or other automated scanners). Draft's quality commands are designed to be **complementary**:
 
-* **Built-in Agents:** Typically focus on fast, generic static analysis, automated linting, and rapid parallel auto-fixes.
-* **Draft Quality Commands:** Leverage project-specific context (including `draft/architecture.md`, `draft/product.md`, `draft/tech-stack.md`, and `draft/guardrails.md`). This eliminates false positives and ensures findings align with your specific domain constraints, team conventions, and technical stack choices.
+- **Built-in Agents:** Typically focus on fast, generic static analysis, automated linting, and rapid parallel auto-fixes.
+- **Draft Quality Commands:** Leverage project-specific context (including `draft/architecture.md`, `draft/product.md`, `draft/tech-stack.md`, and `draft/guardrails.md`). This eliminates false positives and ensures findings align with your specific domain constraints, team conventions, and technical stack choices.
 
 For maximum quality assurance, run built-in scanners in parallel with Draft commands!

package/skills/graph/SKILL.md

@@ -7,7 +7,7 @@ description: Initialize or refresh the knowledge-graph snapshot for a repository
 
 Initialize or refresh the `draft/graph/` knowledge-graph snapshot for a single repository. This is the narrow "give me a fresh structural graph" command — it does **not** generate `architecture.md`/`.ai-context.md` and does **not** re-inject doc diagram slots (both are `/draft:init`). For scope-aware, root-first graph memory across a monorepo (root spine + module→root links), use `/draft:init --graph-only`.
 
-## Red Flags - STOP if you're:
+## Red Flags - STOP if you're
 
 - Reporting counts without actually running `graph-snapshot.sh`
 - Claiming the graph is built when the engine was unavailable

package/skills/impact/SKILL.md

@@ -7,7 +7,8 @@ description: Generate a project-wide impact report on Draft track delivery — p
 
 Generate a project-wide impact report measuring Context-Driven Development effectiveness across all tracks.
 
-## Red Flags - STOP if you're:
+## Red Flags - STOP if you're
+
 - Profiling code coverage instead of measuring track-level impact.
 - Rewriting tracker logic when local state objects are available for inspection.
 - Generating reports without reading existing track metadata first.
@@ -92,6 +93,7 @@ Every impact/telemetry report must end with a `## Next Actions` section listing
 ```
 
 Rules:
+
 - Impact reports are advisory — `Blocker? = no` is the default; mark `yes` only when a metric breach demands immediate process change.
 - Suggest `/draft:tech-debt` for systemic friction, `/draft:adr` for methodology adjustments, `/draft:tour` for onboarding gaps.
 - Cap at 7 actions.