donnfelker

>

>

Triangulated multi-reviewer code-review orchestrator that runs comprehensive, security, Codex, and Codex adversarial reviews in parallel, then a QA analyst subagent substantiates each finding (verifying any third-party library claims via the context7 MCP) and demotes unsubstantiated ones into an 'Invalidated Findings' section of the timestamped report. Use whenever the user asks for 'a thorough code review,' 'triangulated review,' 'review my changes,' 'multi-reviewer review,' 'run all the reviews,' 'code review with security,' 'pre-PR review,' wants more than a single perspective on pending changes, or invokes the triangulated-code-review orchestrator. Prefer this over a single reviewer whenever the user wants real coverage before opening a PR.

Use when the operator points at a parent ticket, audit, RFC, design doc, or multi-finding report with N actionable subtasks and wants every subtask shipped as its own stacked pull request, then driven to merge-ready by addressing every bot/human review comment and re-requesting review per round. Triggers on: 'fix all subtasks of [ticket]', 'work through P1/P2/P3 items', 'open a PR per finding and stack them', 'ship the audit remediations', 'knock out this report end to end', 'use agent teams to fix [parent]', 'address all comments on these stacked PRs', 'drive the stack to merge-ready', 'do a review-response sweep', 'comment @bot re-review when done'.

Drive a single unit of work — one spec, ticket, finding, or change request — from spec to a committed, reviewed result with a dev team of coordinating agents: Dev → QA → Reviewer/code-review in a bounded cycle. Runs as an agent team when the harness supports one, else coordinated subagents, so it works across agents and models. Use whenever the operator wants a change implemented with rigor instead of a quick edit: 'use a dev team to build and verify this', 'fire off the dev team on this', 'spin up the dev/QA/review agents', 'implement this with a dev/QA/review loop', 'drive this change through dev then QA then code review', 'QA and review this before committing'. This is also the per-subtask engine behind implement-full-spec — that skill calls this dev team once per subtask, then handles stacking, PRs, and review-response on its own. Use this skill for ONE unit of work; for a parent ticket with many subtasks shipped as stacked PRs, use implement-full-spec (which delegates here).

Import a structured planning document (implementation plan, project plan, design doc with tasks) into a task-tracking system as a ticket hierarchy with dependencies wired. Use whenever the operator says 'break this plan into tickets', 'import this into ClickUp/Linear/Jira/Asana', 'create tickets for this plan', 'turn this doc into tasks', 'set up the project in [tracker]', or any variation of converting a written plan into trackable work items. Also use when the operator references a planning doc and a target tracker URL or list in the same request. Covers hierarchy negotiation, ID mapping, dependency wiring, and the platform-specific gotchas that bite on the first attempt. Includes a readiness check up front that will stop and ask the operator to spec the plan out further if it's not yet structured enough to ticket — refusing to import a half-baked plan is part of the contract, not a failure mode.

Drive any artifact to convergence by alternating two genuinely different LLM reviewers — a Codex reviewer and an independent Claude review subagent — applying each round's findings and looping until BOTH independently agree it clears the bar (default: no critical/high findings). Artifact-agnostic: works on a plan, PRD, design doc, spec, or implementation diff. Use whenever the user says 'have two LLMs converge on this', 'loop Claude and Codex until they agree', 'review and revise until consensus', 'iterate this plan/PRD/spec until there are no blockers', or wants cross-model agreement rather than one reviewer's opinion. Prefer this over a single review pass whenever the user wants different models to actually agree on an end result. NOT pr-autopilot (one GitHub PR's comment threads) — this is the artifact-agnostic, alternating-different-models, iterate-to-consensus loop.

When the user wants a comprehensive technical analysis of a codebase or project. Also use when the user mentions 'analyze this codebase,' 'technical overview,' 'document this architecture,' 'what does this codebase do,' 'summarize this repo,' 'code audit,' 'architecture review,' 'codebase walkthrough,' or 'analyze this project.' Performs a multi-phase analysis covering architecture, code quality, testing, and infrastructure, producing a detailed markdown report targeting engineers. For quick code searches or single-file reviews, see standard editor tools.

Searches past Claude Code session transcripts under ~/.claude/projects/ to recover a previous conversation by recalled phrase, error string, or topic. Use when the user says 'search your history for', 'find the conversation about', 'look through your past sessions', 'did I ever finish that work on', 'what did we decide about X last week', 'remind me what came out of that session', or otherwise asks you to recall a prior session. Returns session ID, project, date, and a 2-4 sentence summary; on request, also reports the outcome (commit, branch, PR opened or merged). Not for searching the current codebase, current PR comments, or external systems like Slack/Jira — for those, see codebase-analyzer and address-pr-comments.