@drafthq/draft 3.5.3 → 3.7.1

package/skills/adr/SKILL.md

@@ -7,7 +7,7 @@ description: Create and manage Architecture Decision Records. Documents signific
 
 You are creating or managing Architecture Decision Records (ADRs) for this project.
 
-## Red Flags - STOP if you're:
+## Red Flags - STOP if you're
 
 - Creating an ADR without understanding the decision context
 - Documenting trivial decisions that don't warrant an ADR (e.g., variable naming)
@@ -23,20 +23,24 @@ You are creating or managing Architecture Decision Records (ADRs) for this proje
 ## Pre-Check
 
 1. Verify Draft is initialized:
+
 ```bash
 ls draft/ 2>/dev/null
 ```
 
 If `draft/` doesn't exist:
+
 - Tell user: "Project not initialized. Run `/draft:init` first."
 - Stop here.
 
 2. Check for existing ADR directory:
+
 ```bash
 ls draft/adrs/ 2>/dev/null
 ```
 
 If `draft/adrs/` doesn't exist, create it:
+
 ```bash
 mkdir -p draft/adrs
 ```
@@ -44,6 +48,7 @@ mkdir -p draft/adrs
 ## Step 1: Parse Arguments
 
 Check for arguments:
+
 - `/draft:adr` — Interactive mode: ask about the decision
 - `/draft:adr "decision title"` — Create ADR with given title
 - `/draft:adr list` — List all existing ADRs
@@ -52,9 +57,11 @@ Check for arguments:
 ### List Mode
 
 If argument is `list`:
+
 1. Prefer the deterministic `adr-index.sh` wrapper for the listing — it returns a structured JSON `{adrs:[{id,title,date,status,path,related_tracks}]}` derived from each ADR's frontmatter. Resolve via the canonical tool resolver (see [core/shared/tool-resolver.md](../../core/shared/tool-resolver.md)):
+
    ```bash
-   DRAFT_TOOLS="$(cat ~/.cache/draft/plugin-root 2>/dev/null)/scripts/tools"
+   DRAFT_TOOLS="${DRAFT_PLUGIN_ROOT:-$(cat ~/.cache/draft/plugin-root 2>/dev/null)}/scripts/tools"
    [ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/cache/*/draft/*/scripts/tools 2>/dev/null | sort -V | tail -1)"
    [ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/marketplaces/*draft*/scripts/tools 2>/dev/null | tail -1)"
    [ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$PWD/scripts/tools"
@@ -64,9 +71,10 @@ If argument is `list`:
      ls draft/adrs/ # fallback: enumerate files manually
    fi
    ```
+
 2. Display summary table:
 
-```
+```text
 Architecture Decision Records
 
 | # | Title | Status | Date |
@@ -81,6 +89,7 @@ Stop here after listing.
 ### Supersede Mode
 
 If argument is `supersede <number>`:
+
 1. Read the ADR file `draft/adrs/<number>-*.md`
 2. Change status from `Accepted` to `Superseded by ADR-<new_number>`
 3. In the OLD ADR's References section, add: "Superseded by ADR-<new_number>"
@@ -91,6 +100,7 @@ If argument is `supersede <number>`:
 ### Evaluate Mode
 
 If argument starts with `evaluate`:
+
 - `/draft:adr evaluate <proposal or description>` — Evaluate a design proposal
 
 1. Read the proposal (from arguments, pasted text, file path, or ask user to describe)
@@ -106,7 +116,7 @@ If argument starts with `evaluate`:
 
 5. Output evaluation report (do not save to file — display directly):
 
-```
+```text
 # Design Evaluation: <Title>
 
 ## Summary
@@ -138,6 +148,7 @@ Stop here after evaluation.
 ### Design Mode
 
 If argument starts with `design`:
+
 - `/draft:adr design <system or component>` — Full system/component design
 
 1. Gather requirements:
@@ -201,11 +212,13 @@ If an active track exists and `draft/tracks/<id>/hld.md` is present:
 
 1. Read HLD §Alternatives Considered table.
 2. If any row is marked `Promote to ADR? yes` and has not been promoted yet (no matching ADR exists), offer:
-   ```
+
+   ```text
    Found 1 unpromoted alternative in <track>/hld.md:
      - {alternative} — rejected because: {reason}
    Promote to ADR? [Y/n]
    ```
+
 3. When promoting:
    - Pre-fill ADR §Context from HLD §Background and the §High-Level Design / Key Design Decisions row that drove this rejection.
    - Pre-fill ADR §Decision from the HLD §Key Design Decision that was selected over this alternative.
@@ -220,11 +233,13 @@ If invoked outside a track context, skip 2.1 and proceed with normal interactive
 Follow the base procedure in `core/shared/draft-context-loading.md`.
 
 Read relevant Draft context:
+
 - `draft/.ai-context.md` — Current architecture patterns, invariants, data paths, and constraints. Falls back to `draft/architecture.md` for legacy projects.
 - `draft/tech-stack.md` — Current technology choices
 - `draft/product.md` — Product requirements that influence the decision
 
 Cross-reference the decision against existing context:
+
 - Does it align with documented architecture patterns?
 - Does it introduce a new technology not in tech-stack.md?
 - Does it affect product requirements?
@@ -335,7 +350,7 @@ originating_track: "{<track_id> or null}"
 
 Present the ADR to the user for review:
 
-```
+```text
 ADR-<number> created: <title>
 File: draft/adrs/<number>-<kebab-case-title>.md
 Status: Proposed
@@ -353,7 +368,7 @@ If the decision affects existing Draft context:
 
 ## ADR Status Lifecycle
 
-```
+```text
 Proposed → Accepted → [Deprecated | Superseded by ADR-xxx]
 ```
 
@@ -365,11 +380,14 @@ Proposed → Accepted → [Deprecated | Superseded by ADR-xxx]
 ## Error Handling
 
 **If no draft/ directory:**
+
 - Tell user to run `/draft:init` first
 
 **If ADR number conflict:**
+
 - Increment to next available number
 - Warn: "ADR-<number> already exists. Using ADR-<next>."
 
 **If superseding non-existent ADR:**
+
 - Warn: "ADR-<number> not found. Check `draft/adrs/` for valid ADR numbers."

package/skills/assist-review/SKILL.md

@@ -7,7 +7,8 @@ description: Reviewing someone else's PR for handoff/sign-off. Isolates structur
 
 Help human reviewers effectively review an executed track without shifting the entire cognitive burden onto them.
 
-## Red Flags - STOP if you're:
+## Red Flags - STOP if you're
+
 - Conducting standard unit tests; use `/draft:review` for that.
 - Fixing code rather than explaining logic and risk profiles to the human.
 - Reviewing output without first summarizing the source `spec.md` intent.

package/skills/bughunt/SKILL.md

@@ -24,7 +24,7 @@ Some AI tools (e.g., Claude Code) provide a built-in `bughunt` agent that auto-d
 
 **When to use which:** Use `/draft:bughunt` when you need context-aware analysis with structured evidence and false-positive elimination. Use the built-in agent when you want fast parallel sweeps with auto-fix capability. For maximum coverage, run both — `/draft:bughunt` catches context-specific bugs the built-in misses, and vice versa.
 
-## Red Flags - STOP if you're:
+## Red Flags - STOP if you're
 
 - Hunting for bugs without reading Draft context first (architecture.md, tech-stack.md, product.md)
 - Reporting a finding without reproducing or tracing the code path
@@ -57,6 +57,7 @@ Store this for the report header. All bugs found are relative to this specific b
 Read and follow the base procedure in `core/shared/draft-context-loading.md`.
 
 **Bug-hunt-specific context application:**
+
 - Flag violations of intended architecture as bugs (coupling, boundary violations)
 - Apply framework-specific checks from tech-stack (React anti-patterns, Node gotchas, etc.)
 - Catch bugs that violate product requirements or user flows
@@ -69,14 +70,16 @@ Read and follow the base procedure in `core/shared/draft-context-loading.md`.
 - **Leverage Consistency Boundaries** — Find bugs at eventual consistency seams (stale reads, lost events, missing reconciliation)
 - **Leverage Failure Recovery Matrix** — Verify idempotency claims, check for partial failure states without recovery paths
 - **Leverage Graph Data** (if `draft/graph/` exists) — 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.
-  DRAFT_TOOLS="$(cat ~/.cache/draft/plugin-root 2>/dev/null)/scripts/tools"
+  DRAFT_TOOLS="${DRAFT_PLUGIN_ROOT:-$(cat ~/.cache/draft/plugin-root 2>/dev/null)}/scripts/tools"
   [ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/cache/*/draft/*/scripts/tools 2>/dev/null | sort -V | tail -1)"
   [ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/marketplaces/*draft*/scripts/tools 2>/dev/null | tail -1)"
   [ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$PWD/scripts/tools"
   ```
+
   Query `"$DRAFT_TOOLS/graph-arch.sh" --repo .` for dependency awareness. Flag dependencies on unexpected modules. Flag code in modules involved in dependency cycles as higher risk. Run `"$DRAFT_TOOLS/hotspot-rank.sh" --repo .` to prioritize analysis of high-complexity, high-fanIn files. See `core/shared/graph-query.md`.
 - **Leverage Learned Anti-Patterns** — If `draft/guardrails.md` exists, read the `## Learned Anti-Patterns` section. During the bug sweep, when a bug matches a learned anti-pattern, prefix the report entry with `[KNOWN-ANTI-PATTERN: {pattern name}]`. This distinguishes recurring documented patterns from newly discovered bugs, and signals that a systemic fix may be needed rather than a one-off patch.
 
@@ -85,6 +88,7 @@ Read and follow the base procedure in `core/shared/draft-context-loading.md`.
 When invoked programmatically by `/draft:review` with `with-bughunt`, skip scope confirmation and inherit the scope from the calling command.
 
 Otherwise, ask user to confirm scope:
+
 - **Entire repo** - Full codebase analysis
 - **Specific paths** - Target directories or files
 - **Track-level** (specify `<track-id>`) - Focus on files relevant to a specific track
@@ -92,10 +96,12 @@ Otherwise, ask user to confirm scope:
 ### 3. Load Track Context (if track-level)
 
 If running for a specific track, also load:
+
 - [ ] `draft/tracks/<id>/spec.md` - Requirements, acceptance criteria, edge cases
 - [ ] `draft/tracks/<id>/plan.md` - Implementation tasks, phases, dependencies
 
 Use track context to:
+
 - Verify implemented features match spec requirements
 - Check edge cases listed in spec are handled
 - Identify bugs in areas touched by the track's plan
@@ -124,6 +130,7 @@ Before analyzing all 14 dimensions, determine which apply to this codebase:
 - **Mark skipped dimensions** with reason in report summary
 
 **Examples of skipping:**
+
 - "N/A - no backend code" (skip dimensions 2, 8, 10 for frontend-only repo)
 - "N/A - no UI components" (skip dimensions 5, 9, 14 for CLI tool)
 - "N/A - no database" (skip dimension 2 for in-memory app)
@@ -136,18 +143,21 @@ Before analyzing all 14 dimensions, determine which apply to this codebase:
 Analyze systematically across all applicable dimensions. Skip N/A dimensions explicitly (see Dimension Applicability Check above).
 
 ### 1. Correctness
+
 - Logical errors, invalid assumptions, edge cases
 - Incorrect state transitions, stale or inconsistent UI state
 - Error handling gaps, silent failures
 - Off-by-one errors, boundary conditions
 
 ### 2. Reliability & Resilience
+
 - Crash paths, unhandled exceptions
 - Reload/refresh behavior, retry logic
 - UI behavior on partial backend failure
 - Broken recovery after errors, navigation
 
 ### 3. Security
+
 - XSS, injection vectors, unsafe rendering
 - Client-side trust assumptions
 - Secrets, tokens, auth data exposure
@@ -161,12 +171,14 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
   - Reference: OWASP Top 10, Meta Infer taint analysis methodology
 
 ### 4. Performance (Backend + UI)
+
 - Inefficient algorithms and data fetching
 - Blocking work on main/UI thread
 - Excessive re-renders, unnecessary state updates
 - Unbounded memory growth (listeners, caches, stores)
 
 ### 5. UI Responsiveness & Perceived Performance
+
 - Long tasks blocking input
 - Jank during scrolling, typing, resizing
 - Layout thrashing, forced reflows
@@ -174,6 +186,7 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
 - Poor loading states, flicker, content shifts
 
 ### 6. Concurrency & Ordering
+
 - Race conditions between async calls
 - Stale responses overwriting newer state
 - Incorrect cancellation or debouncing
@@ -181,6 +194,7 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
 - Deadlocks, livelocks
 
 ### 7. State Management
+
 - Source-of-truth violations
 - Derived state bugs (computed from stale data)
 - Global state misuse
@@ -188,12 +202,14 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
 - Inconsistent state across components
 
 ### 8. API & Contracts
+
 - UI assumptions not guaranteed by backend
 - Schema drift, weak typing, missing validation
 - Backward compatibility risks
 - Undocumented API behavior dependencies
 
 ### 9. Accessibility & UX Correctness
+
 - Keyboard navigation gaps
 - Focus management bugs
 - ARIA misuse or absence
@@ -202,6 +218,7 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
 - Color contrast, screen reader compatibility
 
 ### 10. Configuration & Build
+
 - Fragile environment assumptions
 - Build-time vs runtime config leaks
 - Dev-only code shipping to prod
@@ -209,6 +226,7 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
 - CI gaps affecting builds or tests
 
 ### 11. Tests
+
 - Missing coverage for critical flows
 - Snapshot misuse (testing implementation, not behavior)
 - Tests that assert implementation instead of behavior
@@ -221,6 +239,7 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
 - **Flaky test patterns:** time-dependent assertions (sleep, Date.now, timestamps), port/file system assumptions, test ordering dependencies, non-deterministic data (random seeds, UUIDs without control)
 
 ### 12. Dependency & Supply Chain Security
+
 - **Known CVEs:** Check dependencies against known vulnerability databases (reference tools: Snyk, Trivy, OWASP Dependency-Check, `npm audit`, `pip-audit`, `cargo audit`, `go vuln`)
 - **Unpinned dependency versions:** Lockfile freshness, use of version ranges (`^`, `~`, `*`, `>=`) without lockfile enforcement, missing lockfile entirely
 - **Deprecated packages:** Dependencies with known deprecation notices, archived repositories, or no maintenance activity
@@ -230,6 +249,7 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
 - Reference: Google OSS-Fuzz, Microsoft SDL, OpenSSF Scorecard
 
 ### 13. Algorithmic Complexity
+
 - **Quadratic or worse loops:** O(n^2) or worse nested loops over collections (nested `.filter()` inside `.map()`, repeated linear scans, cartesian joins in application code)
 - **Regex catastrophic backtracking:** Nested quantifiers (`(a+)+`, `(a|a)*`), unbounded repetition with overlapping alternatives — flag any regex applied to user-controlled input
 - **Unbounded recursion:** Recursive functions without depth limits, missing base cases, or base cases that depend on external/mutable state
@@ -237,6 +257,7 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
 - **Hot path inefficiency:** Sorting/searching in hot paths without appropriate data structures (linear scan where hash map suffices, repeated sorting of same collection, string concatenation in loops)
 
 ### 14. Internationalization & Localization
+
 - **Hardcoded user-facing strings:** Strings displayed to users embedded directly in source code rather than externalized to resource files/i18n frameworks
 - **Locale-sensitive operations without locale parameter:** String comparison (`<`, `>`, `localeCompare` without locale), date formatting (`toLocaleDateString` without explicit locale), number formatting, sorting (alphabetical sort that assumes ASCII ordering)
 - **RTL layout issues:** Hardcoded LTR assumptions in UI code (absolute `left`/`right` positioning, directional margin/padding, text alignment assumptions)
@@ -291,7 +312,8 @@ Analyze systematically across all applicable dimensions. Skip N/A dimensions exp
    - [ ] If all instances have the bug: Report with pattern count in "Impact"
 
 **Example Pattern Prevalence Check:**
-```
+
+```text
 1. Grep: `rg 'dangerouslySetInnerHTML' src/` → found 12 occurrences
 2. Sampled 3: src/Blog.tsx:45, src/About.tsx:12, src/FAQ.tsx:30
 3. All 3 sanitize input via `DOMPurify.sanitize()` before rendering
@@ -316,6 +338,7 @@ Only report bugs with HIGH or CONFIRMED confidence:
 ### Evidence Requirements
 
 Each reported bug MUST include:
+
 - **Code Evidence:** The actual problematic code snippet
 - **Trace:** How data reaches this point (caller chain or data flow)
 - **Verification Done:** Which checks from the checklist were completed
@@ -341,6 +364,7 @@ For suspected bugs that can be tested, write a minimal failing test to confirm:
 4. **Only report if**: Test fails OR CONFIRMED confidence from code trace
 
 **Example:**
+
 ```javascript
 // Suspected bug: off-by-one in pagination
 test('should handle last page boundary', () => {
@@ -359,12 +383,12 @@ For each verified bug, generate a regression test in the project's native test f
 If no test framework is detected, mark all bugs `Regression Test Status: N/A` and continue — the bug report is the primary deliverable.
 
 **Detailed procedure** — see `references/regression-tests.md` for:
+
 - Language and test-framework detection signals (C/C++, Go, Python, JS/TS, Rust, Java)
 - Existing-test discovery patterns and coverage classification
 - Test case requirements and language-specific templates
 - Build/syntax validation commands per toolchain
 
-
 ## Fix Suggestion Generation
 
 For each bug with CONFIRMED or HIGH confidence, generate a minimal suggested fix alongside the bug report. Fix suggestions are advisory — they are never auto-applied.
@@ -404,6 +428,7 @@ For each verified bug:
 **Impact:** [User-visible effect or system failure mode]
 
 **Verification Done:**
+
 - [x] Traced code path from [entry point]
 - [x] Checked architecture.md — not intentional
 - [x] Verified framework doesn't handle this
@@ -415,6 +440,7 @@ For each verified bug:
 **Fix:** [Minimal code change or mitigation]
 
 **Suggested Fix (REVIEW REQUIRED):**
+
 ```[language]
 // BEFORE (current buggy code):
 [exact code snippet from the codebase]
@@ -422,16 +448,19 @@ For each verified bug:
 // AFTER (suggested fix):
 [minimal change that addresses root cause]
 ```
+
 _This fix is SUGGESTED only — human review required before applying. Reference: Meta SapFix methodology._
 
 **Regression Test:**
 **Status:** [COVERED | PARTIAL | WRONG_ASSERTION | NO_COVERAGE | N/A]
 **Existing Test:** [`path/to/test_file:line` — test name | None found]
 [Action: existing test reference, proposed modification, or new test case]
+
 ```[language]
 // New or modified test case (omit if COVERED or N/A)
 ```
-```
+
+```text
 
 **Example — COVERED (no new test needed):**
 ```markdown
@@ -442,6 +471,7 @@ No new test needed. Existing test fails when XSS sanitization is removed.
 ```
 
 **Example — PARTIAL (C++ / GTest):**
+
 ```markdown
 **Regression Test:**
 **Status:** PARTIAL — tests exist for processInput() but miss unsanitized HTML path
@@ -455,7 +485,8 @@ TEST(InputSanitization, RejectsMaliciousScript) {
       << "Input should be sanitized to remove script tags";
 }
 ```
-```
+
+```text
 
 **Example — NO_COVERAGE (Python / pytest):**
 ```markdown
@@ -473,7 +504,8 @@ def test_rejects_malicious_script():
     assert "<script>" not in result, "XSS script tag should be stripped"
 # Expected: FAILS against current code (passes XSS through), PASSES after fix
 ```
-```
+
+```text
 
 **Example — NO_COVERAGE (Go / testing):**
 ```markdown
@@ -497,7 +529,8 @@ func TestProcessInputRejectsMaliciousScript(t *testing.T) {
 }
 // Expected: FAILS against current code (passes XSS through), PASSES after fix
 ```
-```
+
+```text
 
 **Example — N/A (not testable, but still report the bug):**
 ```markdown
@@ -507,6 +540,7 @@ func TestProcessInputRejectsMaliciousScript(t *testing.T) {
 ```
 
 Severity levels:
+
 - **Critical** — Blocks release, breaks functionality, security issue
 - **Important** — Degrades quality, creates tech debt
 - **Minor** — Style, optimization, edge cases
@@ -514,10 +548,12 @@ Severity levels:
 ## Report Generation
 
 Generate report at:
+
 - **Project-level:** `draft/bughunt-report-<timestamp>.md` (where `<timestamp>` is generated via `date +%Y-%m-%dT%H%M`, e.g., `2026-03-15T1430`)
 - **Track-level:** `draft/tracks/<track-id>/bughunt-report-<timestamp>.md` (if analyzing specific track)
 
 After writing the timestamped report, create a symlink pointing to it:
+
 ```bash
 # Project-level
 ln -sf bughunt-report-<timestamp>.md draft/bughunt-report-latest.md
@@ -597,9 +633,11 @@ Report structure:
 | 5 | [Brief title] | — | SKIPPED (N/A) |
 
 ```
+
 Validation Summary: 3 BUILD_OK, 0 BUILD_FAILED, 1 SKIPPED
 Validation Command: python -m py_compile <file>
-```
+
+```text
 
 ### New Tests Written (NO_COVERAGE)
 
@@ -637,7 +675,8 @@ Bugs that cannot have automated regression tests (config issues, documentation,
 | Bug # | Bug Title | Reason |
 |-------|-----------|--------|
 | 6 | [Brief title] | Config file — no executable code |
-```
+
+```text
 
 ## Final Instructions
 
@@ -670,17 +709,21 @@ After bughunt report generation:
 
 **If critical bugs found:**
 ```
+
 "Critical bugs found. Consider:
   → /draft:debug — Run structured debug session on critical finding #{n}
   → git bisect — Find the exact commit that introduced the bug"
-```
+
+```text
 
 ### Test Writing Guardrail
 
 When offering to write regression tests for found bugs:
 ```
+
 ASK: "Want me to write regression tests for the {n} bugs found? [Y/n]"
-```
+
+```text
 Never auto-write tests — always ask first.
 
 ### Jira Sync

package/skills/bughunt/references/regression-tests.md

@@ -21,6 +21,7 @@ Identify the project's language(s) and test framework by examining the codebase:
 | `build.gradle`/`build.gradle.kts` | Java/Kotlin | JUnit | `gradle test` |
 
 **Resolution order:**
+
 1. Check `draft/tech-stack.md` first — it may explicitly state the test framework
 2. Look for existing test files and match their import/framework patterns
 3. Fall back to build system signals above
@@ -30,7 +31,8 @@ If the project is **polyglot** (multiple languages), detect per-component and ge
 **If no test framework is detected:** Mark all bugs with `Regression Test Status: N/A — no test framework detected` and proceed with bug reporting. **Do not skip bugs because tests cannot be written.** The regression test section is supplementary — the primary deliverable is the bug report.
 
 Record the detected configuration:
-```
+
+```yaml
 Language: [detected | none]
 Test Framework: [detected | none]
 Build System: [detected | none]
@@ -71,7 +73,8 @@ For each verified bug, search the codebase for existing tests before generating
 4. **Document discovery results** in the bug report's Regression Test field
 
 **Example Existing Test Discovery:**
-```
+
+```text
 1. Bug location: src/parser.cpp:145 — off-by-one in tokenize()
 2. Grep: `rg 'tokenize' tests/` → found tests/parser_test.cpp
 3. Read tests/parser_test.cpp:
@@ -87,7 +90,8 @@ For each verified bug, search the codebase for existing tests before generating
 Based on discovery results, generate tests in the project's native framework:
 
 #### When status is COVERED
-```
+
+```text
 **Regression Test:**
 **Status:** COVERED — existing test already catches this bug
 **Existing Test:** `tests/parser_test.cpp:45` — `TEST(Parser, TokenizeBoundary)`
@@ -95,7 +99,9 @@ No new test needed.
 ```
 
 #### When status is PARTIAL — add to existing test file
+
 #### When status is WRONG_ASSERTION — fix assertion in existing test
+
 #### When status is NO_COVERAGE — generate new test
 
 ### Test Case Requirements (all languages)
@@ -297,6 +303,7 @@ For bugs with status NO_COVERAGE, PARTIAL, or WRONG_ASSERTION, write the actual
 #### NO_COVERAGE — Create new test file
 
 1. **Create directory** if it doesn't exist:
+
    ```bash
    mkdir -p <test_directory>/
    ```
@@ -315,6 +322,7 @@ For bugs with status NO_COVERAGE, PARTIAL, or WRONG_ASSERTION, write the actual
 3. **Create or update build config** (if required by the build system):
 
    **C/C++ (Bazel)** — add `cc_test` to BUILD:
+
    ```python
    cc_test(
        name = "<source_filename>_test",
@@ -355,6 +363,7 @@ For bugs with status NO_COVERAGE, PARTIAL, or WRONG_ASSERTION, write the actual
 4. No build config changes needed
 
 **Constraints:**
+
 - **Never modify production source code** — only test files and their build configs
 - Each test file must be valid for the project's test runner
 - Use the project's actual import paths, module names, and namespace conventions
@@ -392,7 +401,8 @@ After writing all test files, validate them using the project's native toolchain
    **Exception for Go:** `go vet` is preferred over `go build` for test files because Go compiles tests as part of `go test` only. `go vet` catches type errors and common issues without executing.
 
 4. **Validation summary** — Record results for the report:
-   ```
+
+   ```yaml
    BUILD_OK:     3 targets
    BUILD_FAILED: 1 target (tests/config/test_loader.py — ImportError: no module named 'config.loader')
    SKIPPED:      1 target (N/A — race condition not reliably testable)