@simplysm/sd-claude 13.0.78 → 13.0.81

package/claude/skills/sd-plan-dev/SKILL.md

@@ -1,294 +0,0 @@
----
-name: sd-plan-dev
-description: "Parallel execution of plan tasks (explicit invocation only)"
----
-
-# Parallel Plan Execution
-
-Execute plan tasks via parallel implementers with dependency-aware scheduling.
-
-**Core principle:** Dependency analysis + parallel implementers + orchestrator-managed reviews = maximum throughput
-
-## When to Use
-
-```mermaid
-flowchart TD
-    A{Have implementation plan?}
-    A -->|yes| B[sd-plan-dev]
-    A -->|no| C[Manual execution or brainstorm first]
-```
-
-## Execution Method
-
-All execution uses `Task(general-purpose)` for parallel execution.
-
-- **implementer**: `Task(general-purpose, model: min(sonnet, current))` — implements one task, commits, reports
-- **spec reviewer**: `Task(general-purpose)` — dispatched by orchestrator after implementer completes (read-only)
-- **quality reviewer**: `Task(general-purpose)` — dispatched by orchestrator in parallel with spec reviewer (read-only)
-- **final reviewer**: `Task(general-purpose)` — dispatched by orchestrator after all batches complete (read-only)
-
-**Model selection:**
-- **implementer**: use `min(sonnet, current model)`. If the user's current model is haiku, use haiku. Otherwise use sonnet.
-- **All other agents**: inherit current model (no explicit `model` parameter).
-
-Independent tasks run as **parallel Task calls in a single message**. After implementers complete, spec and quality reviews run as **parallel Task calls**.
-
-**CRITICAL: Always launch parallel tasks as multiple Task calls in a single message (foreground parallel).** Never set `run_in_background: true` — it causes Stop hooks to fire prematurely. This rule applies regardless of permission mode (yolo, plan, etc.).
-
-## The Process
-
-```mermaid
-flowchart TD
-    A["Read plan, extract tasks, create TaskCreate"] --> B["Dependency analysis: identify files per task, build graph, group into batches"]
-
-    subgraph BATCH["Per Batch (independent tasks)"]
-        subgraph PAR_IMPL["Parallel implementer Task calls (single message)"]
-            subgraph IMPL["Each Implementer"]
-                C["Implement the task"] --> D{"Questions?"}
-                D -->|yes| E["Return questions to orchestrator"]
-                E --> F["Re-launch with answers"]
-                F --> C
-                D -->|no| G["Commit and report"]
-            end
-        end
-
-        subgraph REVIEW["Orchestrator review loop (per implementer)"]
-            subgraph PAR_REV["Parallel reviewer Task calls (single message)"]
-                H["Task: spec reviewer"]
-                I["Task: quality reviewer"]
-            end
-            J{"Any issues?"}
-            K["Task: implementer fix"]
-            L["Re-review (parallel Task calls)"]
-        end
-    end
-
-    B --> C
-    G --> H
-    G --> I
-    H --> J
-    I --> J
-    J -->|yes| K
-    K --> L
-    L --> J
-    J -->|no| M["Batch integration check (typecheck + lint)"]
-    M --> N{"More batches?"}
-    N -->|"yes, next batch"| C
-    N -->|no| O["Task: final review for entire implementation"]
-    O --> P["Run /simplify on all changed code"]
-    P --> Q{"Changes made?"}
-    Q -->|yes| R["Typecheck + lint affected packages"]
-    R --> S(["Done"])
-    Q -->|no| S
-```
-
-## Dependency Analysis
-
-Before launching tasks, analyze the plan to build a dependency graph:
-
-1. **For each task**: identify which files/modules it will create or modify
-2. **Find overlaps**: tasks touching the same files depend on each other
-3. **Respect logical dependencies**: if task B uses what task A creates, B depends on A
-4. **Group into batches**: tasks with no dependencies between them form one batch
-
-```
-Example: 5 tasks
-  Task 1: creates utils/validator.ts
-  Task 2: creates hooks/useAuth.ts
-  Task 3: creates components/Login.tsx (uses hooks/useAuth.ts)
-  Task 4: modifies utils/validator.ts
-  Task 5: creates api/endpoints.ts
-
-  Batch 1: [Task 1, Task 2, Task 5] — independent, parallel
-  Batch 2: [Task 3] — depends on Task 2
-  Batch 3: [Task 4] — depends on Task 1
-```
-
-## Implementer Prompt
-
-Each implementer receives a prompt based on `./implementer-prompt.md`. Fill in all `[bracketed]` sections before dispatching.
-
-## Reviewer Dispatch
-
-After an implementer completes and reports, the orchestrator dispatches reviewers:
-
-1. Record the implementer's commit SHA and files changed from its report
-2. Dispatch TWO parallel Task calls (single message):
-   - spec reviewer — fill `./spec-reviewer-prompt.md` with task requirements + implementer report
-   - quality reviewer — fill `./code-quality-reviewer-prompt.md` with implementer report + BASE_SHA/HEAD_SHA
-3. If either reviewer returns CHANGES_NEEDED:
-   - Re-dispatch implementer with fix instructions (all issues from both reviewers combined)
-   - After fix, re-dispatch only the failed reviewers (parallel Task calls)
-   - Repeat until both approve
-4. Proceed to next task or batch
-
-## Prompt Templates
-
-- `./implementer-prompt.md` — implementer instructions
-- `./spec-reviewer-prompt.md` — spec compliance review prompt
-- `./code-quality-reviewer-prompt.md` — code quality review prompt
-- `./final-review-prompt.md` — final integration review prompt
-
-## Example Workflow
-
-```
-You: Using sd-plan-dev to execute this plan.
-
-[Read plan file: docs/plans/feature-plan.md]
-[Extract all 5 tasks with full text + create TaskCreate]
-
-[Dependency analysis]
-  Task 1 (validator): no deps
-  Task 2 (auth hook): no deps
-  Task 3 (login component): depends on Task 2
-  Task 4 (validator update): depends on Task 1
-  Task 5 (api endpoints): no deps
-
-  Batch 1: [Task 1, Task 2, Task 5]
-  Batch 2: [Task 3, Task 4]
-
---- Batch 1: parallel implementers ---
-
-[3 parallel implementer Task calls in single message]
-
-  Implementer 1: Implemented validator, tests 5/5 pass → committed
-  Implementer 2: "Should auth use JWT or session?" (question returned)
-  Implementer 5: Implemented endpoints, tests 3/3 pass → committed
-
-[Answer Implementer 2 question: "JWT"]
-[Re-launch Implementer 2 with answer]
-  Implementer 2: Implemented auth hook with JWT, tests 4/4 pass → committed
-
-[Orchestrator dispatches reviewers for each completed implementer]
-
-  Task 1 reviews: [parallel] spec ✅, quality ✅ → Done
-  Task 2 reviews: [parallel] spec ✅, quality ✅ → Done
-  Task 5 reviews: [parallel] spec ✅, quality ❌ (magic number)
-    → Re-dispatch Implementer 5 to fix → committed
-    → Re-review quality ✅ → Done
-
-[Batch 1 complete → integration check]
-
---- Batch 2: parallel implementers ---
-
-[2 parallel implementer Task calls in single message]
-
-  Implementer 3: Implemented login component → committed
-  Implementer 4: Updated validator → committed
-
-[Orchestrator dispatches reviewers]
-
-  Task 3 reviews: [parallel] spec ❌ (missing error state), quality ✅
-    → Re-dispatch Implementer 3 to fix → committed
-    → Re-review spec ✅ → Done
-  Task 4 reviews: [parallel] spec ✅, quality ✅ → Done
-
-[Batch 2 complete → integration check]
-
---- Final ---
-
-[Task: final review for entire implementation]
-Final reviewer: All requirements met, ready to merge
-
-[Run /simplify on all changed code]
-Simplify: extracted shared validation helper, removed 2 duplicate imports
-[typecheck + lint → pass]
-[Commit: refactor: simplify changed code]
-
-Done!
-```
-
-## Verification-Only Tasks
-
-If a task is purely verification (no code changes — just running tests, typecheck, or manual checks), merge its checks into the batch integration check or final review rather than dispatching an implementer. These tasks exist in the plan for documentation purposes but don't need the full implementer → reviewer cycle.
-
-## Batch Integration Check
-
-Between batches, run targeted verification on affected packages before starting the next batch.
-
-Detect the package manager first (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, otherwise → npm):
-
-```bash
-$PM run typecheck [affected packages]
-$PM run lint [affected packages]
-```
-
-This catches cross-task integration issues early — especially when the next batch depends on the current batch's output. Do NOT skip this even if individual task reviews passed.
-
-If typecheck or lint fails, treat the errors as review issues: re-dispatch the implementer(s) whose changes caused the failure with the error output. After fix, re-run the integration check. Do NOT start the next batch until integration passes.
-
-## Final Review Dispatch
-
-After all batches complete and pass integration checks, dispatch the final reviewer:
-
-1. Locate the original design document from `docs/plans/` — it shares the same date and topic as the plan file (e.g., plan `2026-03-04-dialog-confirm.md` → design `2026-03-04-dialog-confirm-design.md`)
-2. Fill `./final-review-prompt.md` with:
-   - The full text of the original design document
-   - The full text of the implementation plan
-   - Summaries of all completed tasks (commit SHAs, files changed, test results)
-3. Dispatch as `Task(general-purpose)`
-4. If the final reviewer returns **APPROVED** → done
-5. If the final reviewer returns **ISSUES**:
-   - For cross-task integration issues: create a fix task targeting specific files, run through implementer → review cycle
-   - For missing design requirements: create new implementation tasks and run through the full batch cycle
-   - Re-run final review after all fixes
-
-## Simplify
-
-After the final review passes, run `/simplify` to review all changed code for reuse, quality, and efficiency. This catches cross-task cleanup opportunities that individual reviewers miss.
-
-1. Orchestrator runs `/simplify` via the Skill tool
-2. If simplify made changes:
-   - Run typecheck/lint on affected packages
-   - If typecheck/lint fails → fix the issues and re-run typecheck/lint until it passes
-   - Commit simplify changes as a separate commit (`refactor: simplify changed code`)
-3. If simplify made no changes → skip to completion
-
-## Completion
-
-After simplify completes (or is skipped), report to the user: number of tasks completed, total files changed, and final review outcome.
-
-## Red Flags
-
-**Never:**
-
-- Start implementation on main/master without explicit user consent
-- Skip reviews (spec compliance OR code quality)
-- Proceed with unfixed issues
-- Put tasks with file overlap in the same parallel batch
-- Skip dependency analysis
-- Make implementer read plan file directly (provide full text instead)
-- Skip scene-setting context
-- Accept "close enough" on spec compliance
-- Skip review loops (issue found → fix → re-review)
-- Skip batch integration checks between batches
-- Skip `/simplify` after final review
-- Use `run_in_background: true` on Task calls (use foreground parallel instead)
-
-**If implementer returns questions:**
-
-- Answer clearly and completely
-- Re-launch that implementer with answers included
-- Other parallel implementers continue unaffected
-
-**If reviewers find issues:**
-
-- Orchestrator re-dispatches implementer with all issues from both reviewers combined
-- After fix, re-dispatch only the failed reviewers (parallel Task calls)
-- Repeat until both approved
-
-**If implementer fails or times out:**
-
-- Do NOT silently proceed — the affected files may be in an indeterminate state
-- Check if other tasks in the same batch depend on the failed task's output
-- Independent tasks' results still stand
-- Escalate to user with specific error details before proceeding
-- Do NOT re-launch on potentially partially-modified files without inspection
-
-## Integration
-
-**Related skills:**
-
-- **sd-plan** — creates the plan this skill executes
-- **sd-tdd** — implementers follow TDD
-- **sd-worktree** — branch isolation for worktree-based workflows

package/claude/skills/sd-plan-dev/code-quality-reviewer-prompt.md

@@ -1,49 +0,0 @@
-# Code Quality Reviewer Prompt
-
-Template for `Task(general-purpose)`.
-Runs in parallel with spec reviewer. Fill in all `[bracketed]` sections.
-
-```
-You are reviewing code quality for a completed implementation.
-
-## Implementer Report
-
-[Paste the implementer's report: files changed, what they built]
-
-## Review Scope
-
-Use git diff to review only what changed:
-
-    git diff [BASE_SHA]..[HEAD_SHA]
-
-BASE_SHA: [commit before task started]
-HEAD_SHA: [implementer's commit SHA from report]
-
-Focus your review on the diff output. Read surrounding code for context only when needed.
-
-## Your Job
-
-Read the actual code. Report only issues you're confident about — skip style nitpicks.
-
-### Review Focus
-
-1. **Bugs & Logic Errors**: Off-by-one, null handling, race conditions, incorrect logic
-2. **Security**: Injection, XSS, unsafe input at system boundaries
-3. **Code Quality**: Unnecessary complexity, duplication, dead code, unclear naming
-4. **Error Handling**: Missing error handling at boundaries, swallowed errors
-5. **Project Conventions**: Follow CLAUDE.md (read it if unsure about conventions)
-6. **Test Quality**: Tests verify behavior not implementation, edge cases covered
-
-### DO NOT flag:
-
-- Spec compliance (that's the spec reviewer's job)
-- Missing JSDoc (project convention: not enforced)
-- Style preferences you're not confident about
-
-### Report
-
-- ❌ Critical: [must fix — bugs, security, data loss] (file:line)
-- ⚠️ Important: [should fix — logic errors, bad patterns] (file:line)
-- 💡 Suggestion: [confident improvement — informational only, does not block approval] (file:line)
-- Assessment: **APPROVED** or **CHANGES_NEEDED** (only Critical/Important trigger CHANGES_NEEDED; Suggestions alone = APPROVED)
-```

package/claude/skills/sd-plan-dev/final-review-prompt.md

@@ -1,50 +0,0 @@
-# Final Review Prompt
-
-Template for `Task(general-purpose)`.
-Run after all batches complete. Fill in all `[bracketed]` sections.
-
-```
-You are performing a final integration review of a multi-task implementation.
-
-## Original Design
-
-[FULL TEXT of the design document that corresponds to the current plan (match by topic/date in docs/plans/). If no matching design document exists, write "N/A" and skip design traceability checks.]
-
-## Original Plan
-
-[FULL TEXT of the complete plan]
-
-## Completed Tasks
-
-[For each task: summary of what was implemented, files changed, review outcomes]
-
-## Your Job
-
-Individual tasks already passed spec and quality reviews. Focus on cross-task integration and design traceability:
-
-### Design Traceability (skip if Original Design is N/A)
-
-1. **Design coverage**: Every requirement in the design document is addressed by the plan AND implemented in code?
-2. **No drift**: Implementation matches the design intent? (not just the plan — the plan could have missed design requirements)
-3. **Gaps**: Any design requirements that were lost between design → plan → implementation?
-
-### Cross-Task Integration
-
-1. **Plan completeness**: All tasks from the plan implemented?
-2. **Integration**: Do tasks work together? Import/export chains correct?
-3. **Consistency**: Naming and patterns consistent across tasks?
-4. **Wiring**: No missing exports, broken imports, or dead connections?
-
-### Verification
-
-Detect the package manager (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, otherwise → npm), then run and report results:
-- `$PM run typecheck [affected packages]`
-- `$PM run lint [affected packages]`
-
-### Report
-
-- ✅ APPROVED — all tasks integrated correctly, design fully implemented, checks pass
-- ❌ ISSUES:
-  - [Specific problems with file:line references]
-  - [Design requirements not implemented (if any)]
-```

package/claude/skills/sd-plan-dev/implementer-prompt.md

@@ -1,60 +0,0 @@
-# Implementer Prompt
-
-Template for the orchestrator to send to `Task(general-purpose)`.
-Fill in all `[bracketed]` sections.
-
-```
-You are implementing Task [N]: [task name]
-
-## Task Description
-
-[FULL TEXT of task from plan — paste everything here, do NOT reference a plan file]
-
-## Context
-
-[Where this task fits in the overall system]
-[What other tasks depend on this task's output]
-[For batch 2+: what previous batches produced and which files now exist]
-
-## Before You Begin
-
-If anything is unclear about requirements or approach, return your questions under a `## Questions` heading and STOP. Do not guess — do not implement.
-
-## Plan Deviations
-
-Plans may contain minor inaccuracies (wrong file paths, outdated API signatures, incorrect line numbers). Handle deviations by severity:
-
-- **Minor** (file path renamed, import path different, line numbers shifted): Adapt to the actual codebase and note the deviation in your report.
-- **Major** (API doesn't exist, approach fundamentally different, missing dependency): Return your questions under `## Questions` and STOP.
-
-## While You Work
-
-If you encounter something unexpected mid-implementation (missing APIs, unexpected patterns, ambiguous behavior), **ask questions rather than guess**. Return your questions under `## Questions` and STOP. It's always OK to pause and clarify.
-
-## Your Job
-
-0. **Before writing any code**: Read `.claude/refs/sd-code-conventions.md` and check `.claude/rules/sd-refs-linker.md` for additional refs relevant to the code you'll touch (e.g., `sd-solid.md` for SolidJS, `sd-orm.md` for ORM). Follow all project conventions — implementing a task does NOT exempt you from conventions.
-1. Implement exactly what the task specifies — nothing more, nothing less
-2. Write tests (follow TDD if the plan says to)
-3. Verify: tests pass, no type errors
-4. Self-review:
-   - **Completeness**: Every requirement implemented? Edge cases handled?
-   - **Quality**: Names clear? Code clean and maintainable?
-   - **Discipline**: Nothing overbuilt (YAGNI)? Only what was requested?
-   - **Testing**: Tests verify behavior (not implementation)? Comprehensive?
-5. Fix anything found in self-review
-6. Commit using conventional commit format: `type(scope): description` (e.g., `feat(solid): add ConfirmDialog component`)
-7. Report back
-
-Work from: [directory path]
-
-## Report
-
-When done, provide:
-- Commit SHA (from step 6)
-- Files created/modified (with brief description of changes)
-- Plan deviations (if any — what the plan said vs. what you did and why)
-- Test results
-- Self-review findings (if any were fixed)
-- Open concerns (if any)
-```

package/claude/skills/sd-plan-dev/spec-reviewer-prompt.md

@@ -1,45 +0,0 @@
-# Spec Compliance Reviewer Prompt
-
-Template for `Task(general-purpose)`.
-Runs in parallel with quality reviewer. Fill in all `[bracketed]` sections.
-
-```
-You are verifying that an implementation matches its specification exactly.
-
-## Requirements
-
-[FULL TEXT of task requirements from the plan]
-
-## Implementer Report
-
-[Paste the implementer's report: files changed, what they built, test results]
-
-## Your Job
-
-Read the ACTUAL CODE. Do NOT trust the report — verify everything independently.
-
-### Checklist
-
-Categorize every finding as:
-
-**MISSING** — requirement in spec but absent from code:
-1. Compare spec line by line against code. Every requirement present?
-2. Tests exist for each specified behavior?
-3. New public APIs exported in the package's index.ts?
-
-**EXTRA** — code present but not in spec:
-4. Did the implementer build things not requested? (Public methods, new exports, "nice to have" features)
-5. Private helpers are OK; public API additions without spec approval are not.
-
-**WRONG** — present but incorrectly implemented:
-6. Did they solve the right problem? Correct interpretation of requirements?
-7. Do test assertions match spec expectations (not just implementation behavior)?
-
-### Report
-
-- ✅ APPROVED — all requirements verified in code, nothing extra
-- ❌ CHANGES_NEEDED:
-  - MISSING: [requirement not implemented] (file:line)
-  - EXTRA: [built but not requested] (file:line)
-  - WRONG: [incorrect interpretation] (file:line)
-```

package/claude/skills/sd-review/api-reviewer-prompt.md

@@ -1,75 +0,0 @@
-# API Reviewer Prompt
-
-Template for `Agent(general-purpose)`. Fill in `[CONVENTIONS]` and `[EXPLORE_FILES]`.
-
-```
-You are reviewing a library's public API for developer experience (DX).
-Your question: "Would a first-time developer be confused or make mistakes using this API?"
-
-## Context
-
-1. Review the following project conventions relevant to API design and naming:
-
-[CONVENTIONS]
-
-2. Read these explore result files: [EXPLORE_FILES]
-3. From the explore results' **Tagged Files → API** sections, collect all entries — these are your deep-read targets
-
-## Step 1: Deep Review
-
-Read each file from the API tagged list. For each:
-1. Map the public API surface (exports, types, interfaces, function signatures)
-2. Verify suspected API issues from screening
-3. Look for additional issues
-
-Look for:
-- Naming consistency: same concept with different names, inconsistent prefix/suffix
-- Intuitiveness: behavior can't be predicted from the name alone
-- Type design: insufficient types for autocompletion, `any` in public interfaces, generic inference failures
-- Defaults: basic use cases requiring excessive configuration
-- Pattern consistency: similar tasks requiring different patterns
-
-Internal consistency takes priority over external standards.
-
-Do NOT report:
-- Bugs, security, logic errors, race conditions
-- Code complexity, duplication, readability
-- TypeScript type system limitations (language constraints, not API flaws)
-- Naming preferences where current name is used consistently
-- Minor field duplication in small interfaces (< 10 fields)
-
-## Step 2: Self-verify
-
-1. CRITICAL = developers WILL write wrong code because of this API
-2. Before suggesting a rename, search ALL usages — consistent usage is NOT a finding
-3. Only report on PUBLIC API of the target
-
-**Quality over quantity: 3 verified findings > 10 maybe-findings.**
-
-## Constraints
-
-- Analysis only. Do NOT modify any files.
-- Only report issues with real evidence.
-- CRITICAL requires proof the API actively misleads.
-
-## Output Format
-
-### [CRITICAL|WARNING|INFO] title
-
-- **File**: path/to/file.ts:42
-- **Evidence**: what you observed (include code snippet)
-- **Issue**: what the problem is
-- **Suggestion**: how to improve it
-
-Start with:
-
-## API Review Results
-
-### Summary
-- Files deep-reviewed: N (list them)
-- Public API surface: brief description
-- Findings: X CRITICAL, Y WARNING, Z INFO
-
-### Findings
-[findings here]
-```

package/claude/skills/sd-review/code-reviewer-prompt.md

@@ -1,82 +0,0 @@
-# Code Reviewer Prompt
-
-Template for `Agent(general-purpose)`. Fill in `[CONVENTIONS]` and `[EXPLORE_FILES]`.
-
-```
-You are reviewing code for correctness and safety.
-Your question: "Does this code produce wrong results or pose risks?"
-
-## Context
-
-1. Review the following project conventions relevant to correctness/safety:
-
-[CONVENTIONS]
-
-2. Read these explore result files: [EXPLORE_FILES]
-3. From the explore results' **Tagged Files → CORRECTNESS** sections, collect all entries — these are your deep-read targets
-
-## Step 1: Deep Review
-
-Read each file from the CORRECTNESS tagged list. For each:
-1. Verify the suspected issue from screening — is it real?
-2. Look for additional issues the screening might have missed
-
-Look for:
-- Bugs: null/undefined risks, off-by-one, wrong conditions, missing return values
-- Security: injection, XSS, auth/authz gaps, sensitive data exposure, input validation
-- Race conditions: async ordering, shared state without synchronization
-- Resource leaks: uncleared subscriptions/listeners, unclosed handles
-- Error handling: swallowed exceptions, wrong fallbacks, missing propagation
-- Architectural defects: circular dependencies, boundary violations
-
-Do NOT report:
-- Naming, API design, pure type quality
-- Code complexity, duplication, readability
-- Style preferences unless they cause actual bugs
-- Type definitions alone without runtime trigger
-- Speculative future risks
-- Issues outside the reviewed files
-
-**`any` type boundary**: Do NOT report `any` as a type quality issue. But DO report `any` if it enables a runtime crash (e.g., `(obj as any).method()` where `method` may not exist).
-
-## Step 2: Self-verify
-
-Before including ANY finding:
-1. Is there runtime code that actually triggers this?
-2. Does the evidence contradict my conclusion?
-3. Is this within scope?
-
-If you write "in practice this is unlikely because..." — drop it.
-
-**Quality over quantity: 3 verified findings > 10 maybe-findings.**
-
-## Constraints
-
-- Analysis only. Do NOT modify any files.
-- Only report issues where runtime behavior is demonstrably wrong or risky.
-
-## Output Format
-
-### [CRITICAL|WARNING|INFO] title
-
-- **File**: path/to/file.ts:42
-- **Evidence**: what you observed (include code snippet)
-- **Issue**: what the problem is
-- **Suggestion**: how to fix it
-
-Severity:
-- CRITICAL: Will cause bugs, outages, or security breaches
-- WARNING: Real problem that can occur in practice
-- INFO: Defensive improvement, low risk
-
-Start with:
-
-## Code Review Results
-
-### Summary
-- Files deep-reviewed: N (list them)
-- Findings: X CRITICAL, Y WARNING, Z INFO
-
-### Findings
-[findings here]
-```