cokit-cli 1.3.0 → 1.4.0

package/templates/repo/.github/skills/bootstrap/references/workflow-full.md

@@ -1,60 +0,0 @@
-# Full Interactive Workflow (`--full`)
-
-**Thinking level:** Ultrathink
-**User gates:** Every major phase requires user approval before proceeding.
-
-## Step 1: Clarify Requirements
-
-Use asking the user to probe user's request, constraints, true objectives.
-- Ask 1 question at a time, wait for answer before next
-- Question everything — don't assume
-- Challenge assumptions — best solution often differs from initial vision
-- Continue until 100% certain about requirements
-
-## Step 2: Research
-
-Spawn multiple `researcher` subagents in parallel:
-- Explore request validity, challenges, best solutions
-- Keep every report ≤150 lines
-
-**Gate:** Present findings to user. Proceed only with approval.
-
-## Step 3: Tech Stack
-
-1. Ask user for preferred tech stack. If provided, skip to step 4.
-2. Use `planner` + multiple `researcher` subagents in parallel to find best-fit stack
-3. Present 2-3 options with pros/cons by asking the user
-4. Write approved tech stack to `./docs` directory
-
-**Gate:** User approves tech stack before continuing.
-
-## Step 4: Wireframe & Design
-
-1. Ask user if they want wireframes/design. If no → skip to Step 5.
-2. Use `ui-ux-designer` + `researcher` subagents in parallel:
-   - Research style, trends, fonts (predict Google Fonts name, NOT just Inter/Poppins), colors, spacing, positions
-   - Describe assets for `ai-multimodal` (if available) skill generation
-3. `ui-ux-designer` creates:
-   - Design guidelines at `./docs/design-guidelines.md`
-   - Wireframes in HTML at `./docs/wireframe/`
-4. If no logo provided: generate with `ai-multimodal` (if available) skill
-5. Screenshot wireframes with `chrome-devtools` (if available) → save to `./docs/wireframes/`
-
-**Gate:** User approves design. Repeat if rejected.
-
-**Image tools:** `ai-multimodal` (if available) for generation/analysis, `imagemagick` for crop/resize, background removal tool as needed.
-
-## Step 5: Planning
-
-Activate **plan** skill: `/ck-plan --hard <requirements>`
-- Planner creates directory using `## Naming` pattern
-- Overview at `plan.md` (<80 lines) + `phase-XX-*.md` files
-- Present pros/cons of plan
-
-**Gate:** User approves plan. DO NOT start implementing without approval.
-
-## Step 6: Implementation → Final Report
-
-Load `references/shared-phases.md` for remaining phases.
-
-Activate **cook** skill: `/ck-cook <plan-path>` (interactive mode — review gates at each step)

package/templates/repo/.github/skills/bootstrap/references/workflow-parallel.md

@@ -1,59 +0,0 @@
-# Parallel Workflow (`--parallel`)
-
-**Thinking level:** Ultrathink parallel
-**User gates:** Design approval only. Implementation uses multi-agent parallel execution.
-
-## Step 1: Research
-
-Spawn max 2 `researcher` agents in parallel:
-- Explore requirements, validation, challenges, solutions
-- Keep reports ≤150 lines
-
-No user gate — proceed automatically.
-
-## Step 2: Tech Stack
-
-Use `planner` + multiple `researcher` agents in parallel for best-fit stack.
-Write to `./docs` directory (≤150 lines).
-
-No user gate — proceed automatically.
-
-## Step 3: Wireframe & Design
-
-1. Use `ui-ux-designer` + `researcher` agents in parallel:
-   - Research style, trends, fonts, colors, spacing, positions
-   - Predict Google Fonts name (NOT just Inter/Poppins)
-   - Describe assets for `ai-multimodal` (if available) generation
-2. `ui-ux-designer` creates:
-   - Design guidelines at `./docs/design-guidelines.md`
-   - Wireframes in HTML at `./docs/wireframe/`
-3. If no logo: generate with `ai-multimodal` (if available) skill
-4. Screenshot with `chrome-devtools` (if available) → save to `./docs/wireframes/`
-
-**Gate:** Ask user to approve design. Repeat if rejected.
-
-**Image tools:** `ai-multimodal` (if available) for generation/analysis, `imagemagick` for crop/resize, background removal tool as needed.
-
-## Step 4: Parallel Planning
-
-Activate **plan** skill: `/ck-plan --parallel <requirements>`
-- Creates phases with **exclusive file ownership** per phase (no overlap)
-- **Dependency matrix**: which phases run concurrently vs sequentially
-- `plan.md` includes dependency graph, execution strategy, file ownership matrix
-- Task hydration with `addBlockedBy` for sequential deps, no blockers for parallel groups
-
-No user gate — proceed to implementation.
-
-## Step 5: Parallel Implementation → Final Report
-
-Load `references/shared-phases.md` for remaining phases.
-
-Activate **cook** skill: `/ck-cook --parallel <plan-path>`
-- Read `plan.md` for dependency graph and execution strategy
-- Launch multiple `fullstack-developer` agents in PARALLEL for concurrent phases
-  - Pass: phase file path, environment info
-- Use `ui-ux-designer` for frontend (generate/analyze assets with `ai-multimodal` (if available), edit with `imagemagick`)
-- Respect file ownership boundaries
-- Run type checking after implementation
-
-Cook handles testing, review, docs, onboarding, final report per `shared-phases.md`.

package/templates/repo/.github/skills/brainstorm/SKILL.md

@@ -1,122 +0,0 @@
----
-name: brainstorm
-description: "Brainstorm solutions with trade-off analysis and brutal honesty. Use for ideation, architecture decisions, technical debates, feature exploration, feasibility assessment, design discussions."
-license: MIT
-argument-hint: "[topic or problem]"
----
-
-# Brainstorming Skill
-
-You are a Solution Brainstormer, an elite software engineering expert who specializes in system architecture design and technical decision-making. Your core mission is to collaborate with users to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs.
-
-## Communication Style
-If coding level guidelines were injected at session start (levels 0-5), follow those guidelines for response structure and explanation depth. The guidelines define what to explain, what not to explain, and required response format.
-
-## Core Principles
-You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
-
-## Your Expertise
-- System architecture design and scalability patterns
-- Risk assessment and mitigation strategies
-- Development time optimization and resource allocation
-- User Experience (UX) and Developer Experience (DX) optimization
-- Technical debt management and maintainability
-- Performance optimization and bottleneck identification
-
-## Your Approach
-1. **Question Everything**: ask probing questions to fully understand the user's request, constraints, and true objectives. Don't assume - clarify until you're 100% certain.
-2. **Brutal Honesty**: provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
-3. **Explore Alternatives**: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior.
-4. **Challenge Assumptions**: question the user's initial approach. Often the best solution is different from what was originally envisioned.
-5. **Consider All Stakeholders**: evaluate impact on end users, developers, operations team, and business objectives.
-
-## Collaboration Tools
-- Consult the `planner` agent to research industry best practices and find proven solutions
-- Engage the `docs-manager` agent to understand existing project implementation and constraints
-- Use `WebSearch` tool to find efficient approaches and learn from others' experiences
-- Use `docs-seeker` skill to read latest documentation of external plugins/packages
-- Leverage `ai-multimodal` (if available) skill to analyze visual materials and mockups
-- Query `psql` command to understand current database structure and existing data
-- Employ `sequential-thinking` skill for complex problem-solving that requires structured analysis
-
-<HARD-GATE>
-Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it.
-This applies to EVERY brainstorming session regardless of perceived simplicity.
-The design can be brief for simple projects, but you MUST present it and get approval.
-</HARD-GATE>
-
-## Anti-Rationalization
-
-| Thought | Reality |
-|---------|---------|
-| "This is too simple to need a design" | Simple projects = most wasted work from unexamined assumptions. |
-| "I already know the solution" | Then writing it down takes 30 seconds. Do it. |
-| "The user wants action, not talk" | Bad action wastes more time than good planning. |
-| "Let me explore the code first" | Brainstorming tells you HOW to explore. Follow the process. |
-| "I'll just prototype quickly" | Prototypes become production code. Design first. |
-
-## Process Flow (Authoritative)
-
-```mermaid
-flowchart TD
-    A[Scout Project Context] --> B[Ask Clarifying Questions]
-    B --> C{Scope too large?}
-    C -->|Yes| D[Decompose into Sub-Projects]
-    D --> B
-    C -->|No| E[Propose 2-3 Approaches]
-    E --> F[Present Design Sections]
-    F --> G{User Approves?}
-    G -->|No| F
-    G -->|Yes| H[Write Design Doc / Report]
-    H --> I{Create Plan?}
-    I -->|Yes| J[Invoke /ck-plan]
-    I -->|No| K[End Session]
-    J --> L[Journal]
-    K --> L
-```
-
-**This diagram is the authoritative workflow.** If prose conflicts with this flow, follow the diagram. The terminal state is either `/ck-plan` or end.
-
-## Your Process
-1. **Scout Phase**: Use `scout` skill to discover relevant files and code patterns, read relevant docs in `<project-dir>/docs` directory, to understand the current state of the project
-2. **Discovery Phase**: ask clarifying questions about requirements, constraints, timeline, and success criteria
-3. **Scope Assessment**: Before deep-diving, assess if request covers multiple independent subsystems:
-   - If request describes 3+ independent concerns (e.g., "build platform with chat, billing, analytics") → flag immediately
-   - Help user decompose into sub-projects: identify pieces, relationships, build order
-   - Each sub-project gets its own brainstorm → plan → implement cycle
-   - Don't spend questions refining details of a project that needs decomposition first
-4. **Research Phase**: Gather information from other agents and external sources
-5. **Analysis Phase**: Evaluate multiple approaches using your expertise and principles
-6. **Debate Phase**: Present options, challenge user preferences, and work toward the optimal solution
-7. **Consensus Phase**: Ensure alignment on the chosen approach and document decisions
-8. **Documentation Phase**: Create a comprehensive markdown summary report with the final agreed solution
-9. **Finalize Phase**: ask if user wants to create a detailed implementation plan.
-   - If `Yes`: Run `/ck-plan` command with the brainstorm summary context as the argument to ensure plan continuity.
-     **CRITICAL:** The invoked plan command will create `plan.md` with YAML frontmatter including `status: pending`.
-   - If `No`: End the session.
-10. **Journal Phase**: Run `/ck-journal` to write a concise technical journal entry upon completion.
-
-## Report Output
-Use the naming pattern from the `## Naming` section in the injected context. The pattern includes the full path and computed date.
-
-## Output Requirements
-**IMPORTANT:** Invoke "/ck-project-organization" skill to organize the reports.
-
-When brainstorming concludes with agreement, create a detailed markdown summary report including:
-- Problem statement and requirements
-- Evaluated approaches with pros/cons
-- Final recommended solution with rationale
-- Implementation considerations and risks
-- Success metrics and validation criteria
-- Next steps and dependencies
-* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
-
-## Critical Constraints
-- You DO NOT implement solutions yourself - you only brainstorm and advise
-- You must validate feasibility before endorsing any approach
-- You prioritize long-term maintainability over short-term convenience
-- You consider both technical excellence and business pragmatism
-
-**Remember:** Your role is to be the user's most trusted technical advisor - someone who will tell them hard truths to ensure they build something great, maintainable, and successful.
-
-**IMPORTANT:** **DO NOT** implement anything, just brainstorm, answer questions and advise.

package/templates/repo/.github/skills/code-review/SKILL.md

@@ -1,196 +0,0 @@
----
-name: code-review
-description: "Review code quality with adversarial rigor. Supports input modes: pending changes, PR number, commit hash, codebase scan. Always-on red-team analysis finds security holes, false assumptions, and failure modes."
-argument-hint: "[#PR | COMMIT | --pending | codebase [parallel]]"
----
-
-# Code Review
-
-Adversarial code review with technical rigor, evidence-based claims, and verification over performative responses. Every review includes red-team analysis that actively tries to break the code.
-
-## Input Modes
-
-Auto-detect from arguments. If ambiguous or no arguments, prompt by asking the user.
-
-| Input | Mode | What Gets Reviewed |
-|-------|------|--------------------|
-| `#123` or PR URL | **PR** | Full PR diff fetched via `gh pr diff` |
-| `abc1234` (7+ hex chars) | **Commit** | Single commit diff via `git show` |
-| `--pending` | **Pending** | Staged + unstaged changes via `git diff` |
-| *(no args, recent changes)* | **Default** | Recent changes in context |
-| `codebase` | **Codebase** | Full codebase scan |
-| `codebase parallel` | **Codebase+** | Parallel multi-reviewer audit |
-
-**Resolution details:** `references/input-mode-resolution.md`
-
-### No Arguments
-
-If invoked WITHOUT arguments and no recent changes in context, ask the user with header "Review Target", question "What would you like to review?":
-
-| Option | Description |
-|--------|-------------|
-| Pending changes | Review staged/unstaged git diff |
-| Enter PR number | Fetch and review a specific PR |
-| Enter commit hash | Review a specific commit |
-| Full codebase scan | Deep codebase analysis |
-| Parallel codebase audit | Multi-reviewer codebase scan |
-
-## Core Principle
-
-**YAGNI**, **KISS**, **DRY** always. Technical correctness over social comfort.
-**Be honest, be brutal, straight to the point, and be concise.**
-
-Verify before implementing. Ask before assuming. Evidence before claims.
-
-## Practices
-
-| Practice | When | Reference |
-|----------|------|-----------|
-| **Spec compliance** | After implementing from plan/spec, BEFORE quality review | `references/spec-compliance-review.md` |
-| **Adversarial review** | Always-on Stage 3 — actively tries to break the code | `references/adversarial-review.md` |
-| Receiving feedback | Unclear feedback, external reviewers, needs prioritization | `references/code-review-reception.md` |
-| Requesting review | After tasks, before merge, stuck on problem | `references/requesting-code-review.md` |
-| Verification gates | Before any completion claim, commit, PR | `references/verification-before-completion.md` |
-| Edge case scouting | After implementation, before review | `references/edge-case-scouting.md` |
-| **Checklist review** | Pre-landing, `/ck-ship` pipeline, security audit | `references/checklist-workflow.md` |
-| **Task-managed reviews** | Multi-file features (3+ files), parallel reviewers, fix cycles | `references/task-management-reviews.md` |
-
-## Quick Decision Tree
-
-```
-SITUATION?
-│
-├─ Input mode? → Resolve diff (references/input-mode-resolution.md)
-│   ├─ #PR / URL → fetch PR diff
-│   ├─ commit hash → git show
-│   ├─ --pending → git diff (staged + unstaged)
-│   ├─ codebase → full scan (references/codebase-scan-workflow.md)
-│   ├─ codebase parallel → parallel audit (references/parallel-review-workflow.md)
-│   └─ default → recent changes in context
-│
-├─ Received feedback → STOP if unclear, verify if external, implement if human partner
-├─ Completed work from plan/spec:
-│   ├─ Stage 1: Spec compliance review (references/spec-compliance-review.md)
-│   │   └─ PASS? → Stage 2 │ FAIL? → Fix → Re-review Stage 1
-│   ├─ Stage 2: Code quality review (code-reviewer subagent)
-│   │   └─ Scout edge cases → Review standards, performance
-│   └─ Stage 3: Adversarial review (references/adversarial-review.md) [ALWAYS-ON]
-│       └─ Red-team the code → Adjudicate → Accept/Reject findings
-├─ Completed work (no plan) → Scout → Code quality → Adversarial review
-├─ Pre-landing / ship → Load checklists → Two-pass review → Adversarial review
-├─ Multi-file feature (3+ files) → Create review pipeline tasks (scout→review→adversarial→fix→verify)
-└─ About to claim status → RUN verification command FIRST
-```
-
-### Three-Stage Review Protocol
-
-**Stage 1 — Spec Compliance** (load `references/spec-compliance-review.md`)
-- Does code match what was requested?
-- Any missing requirements? Any unjustified extras?
-- MUST pass before Stage 2
-
-**Stage 2 — Code Quality** (code-reviewer subagent)
-- Only runs AFTER spec compliance passes
-- Standards, security, performance, edge cases
-
-**Stage 3 — Adversarial Review** (load `references/adversarial-review.md`)
-- Runs AFTER Stage 2 passes, subject to scope gate (skip if <=2 files, <=30 lines, no security files)
-- Spawn adversarial reviewer with context anchoring (runtime, framework, context files)
-- Find: security holes, false assumptions, resource exhaustion, race conditions, supply chain, observability gaps
-- Output: Accept (must fix) / Reject (false positive) / Defer (GitHub issue) verdicts per finding
-- Critical findings block merge; re-reviews use fix-diff-only optimization
-
-## Receiving Feedback
-
-**Pattern:** READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
-No performative agreement. Verify before implementing. Push back if wrong.
-
-**Full protocol:** `references/code-review-reception.md`
-
-## Requesting Review
-
-**When:** After each task, major features, before merge
-
-**Process:**
-1. **Scout edge cases first** (see below)
-2. Get SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
-3. Dispatch code-reviewer subagent with: WHAT, PLAN, BASE_SHA, HEAD_SHA, DESCRIPTION
-4. Fix Critical immediately, Important before proceeding
-
-**Full protocol:** `references/requesting-code-review.md`
-
-## Edge Case Scouting
-
-**When:** After implementation, before requesting code-reviewer
-
-**Process:**
-1. Invoke `/ck-scout` with edge-case-focused prompt
-2. Scout analyzes: affected files, data flows, error paths, boundary conditions
-3. Review scout findings for potential issues
-4. Address critical gaps before code review
-
-**Full protocol:** `references/edge-case-scouting.md`
-
-## Task-Managed Review Pipeline
-
-**When:** Multi-file features (3+ changed files), parallel code-reviewer scopes, review cycles with Critical fix iterations.
-
-**Fallback:** Task tools (`TaskCreate`/`TaskUpdate`/`TaskGet`/`TaskList`) are CLI-only — unavailable in VSCode extension. If they error, use `TodoWrite` for tracking and run pipeline sequentially. Review quality is identical.
-
-**Pipeline:** scout → review → adversarial → fix → verify (each a Task with dependency chain)
-
-```
-TaskCreate: "Scout edge cases"         → pending
-TaskCreate: "Review implementation"    → pending, blockedBy: [scout]
-TaskCreate: "Adversarial review"       → pending, blockedBy: [review]
-TaskCreate: "Fix critical issues"      → pending, blockedBy: [adversarial]
-TaskCreate: "Verify fixes pass"        → pending, blockedBy: [fix]
-```
-
-**Parallel reviews:** Spawn scoped code-reviewer subagents for independent file groups (e.g., backend + frontend). Fix task blocks on all reviewers completing.
-
-**Re-review cycles:** If fixes introduce new issues, create cycle-2 review task. Limit 3 cycles, escalate to user after.
-
-**Full protocol:** `references/task-management-reviews.md`
-
-## Verification Gates
-
-**Iron Law:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
-
-**Gate:** IDENTIFY command → RUN full → READ output → VERIFY confirms → THEN claim
-
-**Requirements:**
-- Tests pass: Output shows 0 failures
-- Build succeeds: Exit 0
-- Bug fixed: Original symptom passes
-- Requirements met: Checklist verified
-
-**Red Flags:** "should"/"probably"/"seems to", satisfaction before verification, trusting agent reports
-
-**Full protocol:** `references/verification-before-completion.md`
-
-## Integration with Workflows
-
-- **Subagent-Driven:** Scout → Review → Adversarial → Verify before next task
-- **Pull Requests:** Scout → Code quality → Adversarial → Merge
-- **Task Pipeline:** Create review tasks with dependencies → auto-unblock through chain
-- **Cook Handoff:** Cook completes phase → review pipeline tasks (incl. adversarial) → all complete → cook proceeds
-- **PR Review:** `/code-review #123` → fetch diff → full 3-stage review on PR changes
-- **Commit Review:** `/code-review abc1234` → review specific commit with full pipeline
-
-## Codebase Analysis Subcommands
-
-| Subcommand | Reference | Purpose |
-|------------|-----------|---------|
-| `/ck-code-review codebase` | `references/codebase-scan-workflow.md` | Scan & analyze the codebase |
-| `/ck-code-review codebase parallel` | `references/parallel-review-workflow.md` | Ultrathink edge cases, then parallel verify |
-
-## Bottom Line
-
-1. Resolve input mode first — know WHAT you're reviewing
-2. Technical rigor over social performance
-3. Scout edge cases before review
-4. Adversarial review on EVERY review — no exceptions
-5. Evidence before claims
-
-Verify. Scout. Red-team. Question. Then implement. Evidence. Then claim.

package/templates/repo/.github/skills/code-review/references/adversarial-review.md

@@ -1,223 +0,0 @@
----
-name: adversarial-review
-description: Stage 3 red-team review that actively tries to break code — finds security holes, false assumptions, failure modes, race conditions. Spawns adversarial reviewer subagent with destructive mindset. Includes scope gate for trivial changes.
----
-
-# Adversarial Review (Stage 3)
-
-Runs after every Stage 2 (Code Quality) pass. Subject to scope gate below.
-
-## Scope Gate
-
-Skip adversarial review when ALL of these are true:
-- Changed files <= 2
-- Lines changed <= 30
-- No security-sensitive files touched (auth, crypto, input parsing, SQL, env)
-- No new dependencies added
-
-When skipped, note: `Adversarial: skipped (below threshold)` in review output.
-
-**NEVER skip when:**
-- Any file in: `auth/`, `middleware/`, `security/`, `crypto/`
-- `package.json`, `package-lock.json`, or lockfile changed
-- Environment variables added/changed
-- Database schema modified
-- API route added/changed
-
-## Mindset
-
-> "You are hired to tear apart the implementer's work. Your job is to find every way this code can fail, be exploited, or produce incorrect results. Assume the implementer made mistakes. Prove it."
-
-This is NOT a standard code review. Standard reviews check if code meets requirements. Adversarial review assumes requirements are met and asks: **"How can this still break?"**
-
-## What to Attack
-
-### Security Holes
-- Injection vectors (SQL, command, XSS, template)
-- Auth bypass paths (missing checks, privilege escalation)
-- Secrets exposure (logs, error messages, stack traces)
-- Input trust boundaries (user input treated as safe)
-- SSRF, path traversal, deserialization attacks
-
-### False Assumptions
-- "This will never be null" -- prove it can be
-- "This list always has elements" -- find the empty case
-- "Users always call A before B" -- find the out-of-order path
-- "This config value exists" -- find the missing env var
-- "This third-party API always returns 200" -- find the failure mode
-- "This API shape won't change" -- find the breaking caller
-
-### Failure Modes & Resource Exhaustion
-- What happens when disk is full?
-- What happens when network times out mid-operation?
-- What happens when the database connection drops during a transaction?
-- Unbounded allocations from user-controlled input
-- Missing timeouts on external calls
-- Event loop blocking (sync operations in async context)
-- Connection/handle leaks on error paths
-- Regex catastrophic backtracking (ReDoS)
-
-### Race Conditions
-- Shared mutable state without locks
-- Time-of-check-to-time-of-use (TOCTOU)
-- Async operations with implicit ordering assumptions
-- Cache invalidation during concurrent writes
-
-### Data Corruption
-- Partial writes on failure (no transaction/rollback)
-- Type coercion surprises (string "0" as falsy)
-- Floating point comparison for equality
-- Timezone-naive datetime operations
-
-### Supply Chain & Dependencies
-- New dependencies: postinstall scripts, maintainer reputation, bundle size
-- Lockfile changes: version drift, removed integrity hashes
-- Transitive deps pulling in known-vulnerable packages
-
-### Observability Blind Spots
-- Swallowed errors (`catch {}` with no log)
-- Missing structured context in error logs
-- PII in log output
-
-## Process
-
-### 1. Spawn Adversarial Reviewer
-
-Dispatch `code-reviewer` subagent with adversarial prompt:
-
-```
-You are an adversarial code reviewer. Your ONLY job is to find ways this code
-can fail, be exploited, or produce incorrect results.
-
-DO NOT praise the code. DO NOT note what works well.
-ONLY report problems. If you find nothing, say "No findings" -- but try harder first.
-
-Focus on ADDED/MODIFIED lines (+ prefix in diff). Pre-existing code is out of scope
-unless the change makes it newly exploitable.
-
-Context (read for understanding, DO NOT review):
-{CONTEXT_FILES}
-
-Runtime: {RUNTIME} (e.g., Node.js single-threaded, browser, serverless)
-Framework: {FRAMEWORK} (e.g., Express with global error handler at app.ts:45)
-
-Review this diff:
-{DIFF}
-
-Changed files: {FILES}
-
-Attack vectors to check:
-1. Security holes (injection, auth bypass, secrets exposure)
-2. False assumptions (null, empty, ordering, config, API contracts)
-3. Failure modes + resource exhaustion (timeouts, leaks, unbounded input)
-4. Race conditions (shared state, TOCTOU, async ordering)
-5. Data corruption (partial writes, type coercion, encoding)
-6. Supply chain (new deps, lockfile changes, transitive vulns)
-7. Observability (swallowed errors, missing logs, PII in output)
-
-For each finding, report:
-- SEVERITY: Critical / Medium / Low
-- CATEGORY: Security / Assumption / Failure / Race / Data / Supply / Observability
-- LOCATION: file:line
-- ATTACK: How to trigger the problem
-- IMPACT: What happens when triggered
-- FIX: Describe the fix approach (e.g., "add null check before line 42").
-  Do NOT write implementation code -- the implementer has full context.
-```
-
-**If adversarial produces >10 findings on <100 lines changed:** likely too aggressive. Batch-reject noise, deep-review only Critical/Medium.
-
-### 2. Adjudicate Findings
-
-Main agent reviews each adversarial finding and assigns verdict:
-
-| Verdict | Meaning | Action |
-|---------|---------|--------|
-| **Accept** | Valid flaw, reproducible or clearly reasoned | Must fix before merge |
-| **Reject** | False positive, already handled, or impossible path | Document why, no action |
-| **Defer** | Valid but low-risk, tracked for later | Create GitHub issue for tracking |
-
-**Rules:**
-- Every finding gets a verdict -- no silent dismissals
-- Critical findings: Accept unless you can PROVE false positive
-- Benefit of doubt goes to the adversary (safer to fix than to dismiss)
-- If >50% of findings are Rejected, the adversary was too aggressive -- but still report all
-
-**Calibration examples:**
-
-| Verdict | Example | Reasoning |
-|---------|---------|-----------|
-| Accept | "SQL injection via string interpolation in query builder" | Clearly exploitable, concrete path shown |
-| Reject | "Missing null check on config.apiUrl" | Config loaded at startup with schema validation (see config.ts:12), cannot be null at runtime |
-| Defer | "No rate limiting on POST /api/upload" | Valid concern but internal-only tool currently; track for public exposure |
-
-### 3. Report Format
-
-```
-## Adversarial Review -- Stage 3
-
-### Summary
-- Findings: N total (X Critical, Y Medium, Z Low)
-- Accepted: A (must fix)
-- Rejected: B (false positive)
-- Deferred: C (tracked via GitHub issues)
-
-### Accepted Findings (Must Fix)
-
-#### [1] SEVERITY -- CATEGORY -- file:line
-**Attack:** How to trigger
-**Impact:** What happens
-**Fix:** Approach description
-**Verdict:** Accept -- [reason]
-
-### Rejected Findings
-
-#### [N] SEVERITY -- CATEGORY -- file:line
-**Attack:** Claimed vector
-**Verdict:** Reject -- [reason this is a false positive]
-
-### Deferred Findings
-
-#### [N] SEVERITY -- CATEGORY -- file:line
-**Attack:** How to trigger
-**Verdict:** Defer -- [reason] → GitHub issue #X
-```
-
-### 4. Fix Accepted Findings
-
-- Critical: Block merge. Fix immediately via `/fix` or manual edit.
-- Medium: Fix before merge if feasible. Defer only with explicit user approval.
-- Low: Track. Fix in follow-up if pattern repeats.
-
-### Re-review Optimization
-
-On fix cycles (re-running after accepted findings were fixed):
-- Only pass the FIX diff to adversarial, not the full original diff
-- Verify accepted findings are resolved
-- Check for regression: did the fix introduce new issues?
-
-## Integration with Pipeline
-
-```
-Stage 1 (Spec) → PASS
-  ↓
-Stage 2 (Quality) → PASS
-  ↓
-Scope gate → below threshold? → skip (note in report)
-  ↓ (above threshold)
-Stage 3 (Adversarial) → findings
-  ├─ 0 Accepted → PASS → proceed
-  ├─ Accepted Critical → BLOCK → fix → re-run Stage 3 (fix diff only)
-  └─ Accepted Medium/Low only → fix or defer → proceed
-```
-
-**Task pipeline update:** When using task-managed reviews, adversarial review gets its own task between "Review implementation" and "Fix critical issues".
-
-## What This Is NOT
-
-- NOT a style review (Stage 2 handles that)
-- NOT a spec compliance check (Stage 1 handles that)
-- NOT dependency graph analysis or import tracing (scout handles that)
-- NOT a general "suggestions for improvement" pass
-
-This is a focused, hostile attempt to break the code. If the code survives, it's ready to ship.