Chris-Graffagnino

Start the next unblocked task in the build with full ceremony (project specifics from the profile). Use when the user says "next task", "work the next task", "continue the build", "what's next", or names a task ID to implement. Picks the task, opens the issue, cuts the branch, implements with tests, verifies, and runs review — stopping at PR (review mode).

Verified review of an open PR — fetch the diff AND every inline reviewer comment (including bot/automated inline findings), verify each finding against current source (file:line) and run the project's checks where relevant, then post one structured, severity-ranked review comment. Never declares "no findings" until every inline comment is adjudicated and every finding is grounded to source. Project specifics from the profile. Use when the user says "review PR

Resolve the reviewer findings on your own open PR end-to-end — fetch the diff AND every inline comment (human and bot/automated), verify each against current source (file:line), apply the minimum scoped fix with red→green proof, RE-RUN the §7 gate on the fix (maker ≠ checker — a fix is not self-certified), reply to every comment, and confirm the head is green. Never merges — stops for the owner. Pushes fixes and posts replies (the write posture pr-review lacks). Project specifics from the profile. Use when the user says "address the reviewer comments on PR

Convert owner-filed GitHub issues into the tasks-file backlog via PR (project specifics from the profile). Classifies each unmapped issue (no task ID in title, unreferenced by any live tasks file) into spec work / repo-maintenance / bug / duplicate / underspecified, screens it against the constitution, drafts the backlog entry on a branch, and lands it as a PR the owner ratifies by merging. Use when the user says "intake", "run intake", "convert issue

Morning read-only triage heartbeat for the build (project specifics from the profile). Reads the tasks file, git history, and GitHub issues/PRs, then writes a fresh state snapshot to the out-of-repo inbox. Surfaces the next unblocked task, stale checkboxes, open PRs needing review, blocked/owner items, and upcoming constitution risks. Use when the user says "triage", "morning triage", "what's the state of the build", or when fired on a schedule. NEVER edits code, opens issues/PRs, or commits.

Run the standing maker-eval corpus (project specifics from .claude/PROJECT.md). Re-scores the MAKER — the generation path that writes the code — against the frozen golden-task corpus + per-task rubrics with the pinned judge, after a maker-behavior fingerprint change (the maker model resolution OR an instruction/runtime surface that shapes its output, not the model table alone) or on the weekly schedule. The maker analog of auditor-liveness for the reviewers. Executes each corpus task as a [headless run] of the maker, scores the output with a read-only [reviewer]-style judge, and APPENDS an observe-only record + transcript packet per task to the fenced eval channel — which never feeds a gate outcome, tier assignment, or gate semantics (P5). Use when the user says "maker eval", "run the maker corpus", "eval the maker", "re-score the maker", when triage flags MAKER-EVAL-STALE, or on the weekly schedule. Read-and-append only — never edits the frozen instrument, never gates, never merges.

Run the standing auditor-liveness corpus (project specifics from .claude/PROJECT.md). Re-confirms each judgment auditor (acceptance / constitution / contract / spec-quality) still catches its planted-violation fixtures and still passes its clean fixtures, after a reviewer-spec edit or model drift — the model-driven analog of guard.test.sh, promoted from the one-time P-RV probe. Dispatches the auditors READ-ONLY and report-only against materialized plants, compares each verdict to the corpus's expected verdict, and records an OBSERVE-ONLY outcome that never feeds gate outcomes, tier assignment, or gate semantics (P5). Use when the user says "auditor liveness", "run the auditor corpus", "re-confirm the auditors", when triage flags CORPUS-STALE, or on the weekly schedule. Read-and-report only — never edits a reviewer spec, never gates, never merges.

Back-test an escaped defect against the auditors (project specifics from .claude/PROJECT.md). Given a defect found on the base branch plus the commit/PR that introduced it, re-runs the acceptance/constitution/contract auditors READ-ONLY against that historical diff — exactly as the §7 gate would have — classifies the escape (WOULD-HAVE-CAUGHT / INCONSISTENT-CATCH / HUNT-RULE-GAP / INVARIANT-GAP) with file:line evidence, and proposes the resulting tightening (a reviewer-spec hunt rule or an invariant-checklist row) as a normal PR — never editing a rule directly. Use when the user says "retrospective", "back-test this defect", "run the retrospective on <commit/PR>", or when a defect/constitution violation is found on main. Per-incident, never a retroactive sweep; read-and-propose only — never merges, never edits reviewer specs/invariants/guards/the constitution outside the proposal PR.

Explains a code diff, commit, branch, or PR at three depths — summary (quick triage for humans or AI agents), teach-me (teaching walkthrough for novice coders), or expert (dense expert analysis with a review-focus map highlighting likely bugs, regressions, and design problems). Use when the user asks to "explain this diff", "explain this PR", "what does this change do", "walk me through these changes", or wants to understand a code change before reviewing or merging it. Supports --html for a rich interactive page and "help" for usage. Do NOT use for verified bug-hunting or posting review verdicts — hand off to a dedicated code-review pass for that (e.g. /code-review in Claude Code).

Acts as a software architect using canonical references on architectural posture, engineering trade-off methodology, distributed-systems patterns, complexity diagnosis, data-systems mechanics, domain-driven design, and team topology. Use when the user asks for an architecture review, service boundary or decomposition advice, monolith-vs-microservices decisions, saga or distributed-transaction design, consistency-model selection, bounded-context analysis, fitness functions, ADR drafting, or any "should we split / merge / restructure / extract" system-level question. Also activates inside a Spec-Kit-Claw session when the user mentions "spec-kit", "/spec-kit", or "spec-driven development" and architectural decisions are needed. Do NOT use for code-level refactoring, framework choices (React vs Vue, Postgres vs MySQL), debugging, or single-component implementation tasks.

Conducts rigorous, structured interviews to stress-test a plan, design, or idea by walking every branch of the decision tree until reaching shared understanding. Use when user says "grill me", "stress-test my plan", "poke holes in this", "interview me about my design", "challenge my assumptions", or "help me think through this".

Guide for creating technical specifications using Spec-Driven Development (SDD). Use when planning a new feature, project, or system — helps structure thinking from initial idea to executable plan with phases, templates, and decision frameworks.

Relational database design and SQL best practices for building software applications. Covers schema modeling, normalization, data types, keys, constraints, indexing, query performance and EXPLAIN, transactions, isolation and locking, migrations, and PostgreSQL/MySQL-specific gotchas and antipatterns. Use when designing a database schema, creating or altering tables, choosing data types or keys, adding indexes, writing or optimizing SQL queries, debugging slow queries or deadlocks, planning a migration, or choosing between Postgres and MySQL. Triggers on "design a schema", "create table", "add an index", "normalize", "foreign key", "slow query", "EXPLAIN", "N+1", "migration", "deadlock", "Postgres", "MySQL", "SQL best practices".

Engineering-craft practices for building, testing, and structuring code at the implementation and component level — distilled from gold-standard open-source codebases. Covers testing and correctness, error and failure handling, extensibility and module/plugin boundaries, backpressure and resource control, observability, API and backward-compatibility discipline, and implementation simplicity. Use whenever the user asks how to build, structure, or test a component; the best-practice or "how do the best codebases do it" approach for a code-level concern (testing, error handling, flow control, logging/metrics, API stability); for a craft-level review; or to distill engineering practices from a repository — even if they don't say "craft". Do NOT use for system-level architecture decisions — service boundaries, monolith-vs-microservices, distributed transactions, consistency models, bounded contexts, ADRs, or team topology — the software-architect skill owns those; hand off to it.

Surfaces hard-won axioms and pattern-matched wisdom from experienced startup founders and operators across hiring, fundraising, product, sales, finance, co-founders, governance, and crisis management. Use this skill whenever someone is wrestling with a startup, scale-up, or early-stage company decision — including hiring or firing, raising capital, picking a co-founder, pricing, building a board, managing burn, navigating a pivot, surviving a crisis, or any "I'm a founder and I'm not sure what to do" moment. Trigger even when the person doesn't explicitly ask for "advice" — questions framed as "should I…", "is it normal that…", "we're thinking about…", or "how do experienced founders handle…" are all in scope. Also useful when the person is helping someone else with founder-stage decisions (advisor, coach, mentor, investor).

Structured Socratic interview that surfaces the one-way doors, hidden assumptions, and recovery-phase risks in an agent design or production plan. Use when deciding what should require a Posteria-style checkpoint, when stress-testing a plan before shipping, or on phrases like "find the one-way doors", "what should require a checkpoint", "stress-test this design", "grill me", "poke holes in this", "challenge my assumptions".

Analyzes the oil market for equities traders using the Bouchouev storage-capacity-utilization model, futures curve structure, inventory dynamics, shock classification, and geopolitical risk assessment. Frames market conditions and oil-related equity sub-sector sensitivities (E&P, refiners, midstream, oilfield services, integrated majors) for educational analysis. Use when user says "analyze oil", "oil market", "crude oil", "WTI", "Brent", "oil inventory", "oil spreads", "contango", "backwardation", "oil equities", "energy sector", "oil squeeze", "storage capacity", "OPEC", "oil stocks", or asks about oil market conditions, energy sector positioning, or crude oil prices. Do NOT use for precious metals, natural gas standalone analysis, cryptocurrency, or individualized investment recommendations.