SebastianElvis

Extract structured information from a research paper: system model, theorem statements, proof techniques, complexity claims, and red flags. Use when asked to analyze, summarize, or review an academic paper.

Generate, prioritize, and refine research ideas based on current investigation state. Use when the pipeline needs new or better hypotheses — after formalization, between investigation batches, or when all current ideas are resolved.

Ask the user targeted clarifying questions about their research goal before the pipeline runs. Use when the research goal is vague, ambiguous, or missing key context (e.g., which sections to focus on, threat model assumptions, what 'broken' means). Works with or without a paper.

Provide critique on investigation results via human feedback, Codex consultation, or self-review. Can trigger additional investigation cycles for deepen/explore feedback. Use when iterating on research, requesting AI review, or providing human feedback.

Formalize a research question into precise, testable hypotheses with model assumptions, core properties, and explicit success/failure conditions. Use when asked to formalize, define, or scope a research problem after paper analysis.

Run investigation cycles that test hypotheses through proof verification, counterexample search, or security analysis, with keep-or-discard discipline. Use when asked to investigate, verify, prove, or disprove claims.

Run the full Reaper research pipeline: analyze a paper (optional), review literature, formalize the problem, investigate hypotheses with critique loops, and synthesize a report. Use when given a research goal, optionally with a paper.

Search for related academic work, download and read key papers, and produce a structured literature survey. Use when asked to find prior art, related papers, competing approaches, or known results for a research topic.

Evaluation harness for the senate skill. Runs fixture debates end-to-end, applies deterministic graders against the run-dir contract, and uses Claude CLI as an LLM judge for quality dimensions (verdict, agenda, notes, transcript). Use when the user wants to measure which models are reliable in which formats, benchmark a new CLI playbook, or verify a format file after changes.

Drives a multi-agent debate from a planned agenda — builds prompts, dispatches each CLI turn into a standalone subagent, commits the shared transcript and context, handles budget/failure/checkpoint policy, and adapts the agenda mid-run when the situation diverges from the plan. Use this skill when senate has an `agenda.md` ready and needs the actual turns run, or when resuming a paused or stalled debate run.

Plans the agenda for a multi-agent debate — picks the format, picks the roster, sequences stages, resolves sub-debate composition, and asks the user for clarification when the request is ambiguous. Use this skill when the senate orchestrator needs an agenda before debating, when the user asks "which format should I use for X?" or "how should we structure this debate?", or when the user describes a multi-step decision (e.g., "draft an RFC, have it reviewed, then vote") that needs stages laid out.

Consolidates a finished debate run into a single user-facing notes.md — reads the agenda, transcript, shared context, and per-stage verdicts (multi-stage), and writes the canonical user-facing summary that merges what was decided (verdict) with what happened (meeting notes). Use this skill when moderate-debate has finished a run and the user needs a clean summary of what happened, what was decided, and what to do next, or when the user asks for "the notes", "the summary", or "the verdict" of a past debate run.

Top-level orchestrator for multi-agent debates between coding CLIs (codex, gemini, cursor, kimi, claude). Routes a request through three sub-skills — debate-agenda (plan), moderate-debate (run), meeting-note (consolidate) — and returns a single user-facing notes.md summary. Use this skill when the user wants a debate, second opinion, adversarial review, or cross-model agreement on a non-trivial question — even if they don't say "debate" — and especially when they say "debate", "parliament", "court", "peer-review", "red-team", "committee", "senate", "have X and Y argue", or "ask multiple models".

Playbook for invoking non-interactive coding-agent CLIs (codex, gemini, cursor, kimi, claude) as subprocesses. Use this skill inside a moderate-debate per-turn subagent, or when any skill needs to shell out to another AI CLI with a prompt and capture the reply — covers install checks, exact non-interactive invocation, input/output conventions, budget flags, and known per-CLI quirks.

Use this skill for a systematic review of another person's GitHub Pull Request. Trigger on "review PR 123", "is this safe to merge", "check this PR's design", "does this break the protocol", or "does this solve the issue". Check the problem, architecture, protocol conformance, root cause, necessity, correctness, security, and project rules. Require the human to confirm the specification, the problem, and the approach before a detailed review. Do NOT use for an uncommitted local diff, a PR description, or a lint check.

Use when the user asks to generate, write, draft, refresh, retitle, or align a GitHub Pull Request title or description for the current branch — including phrasings like "write the PR description", "update the PR", "summarize this branch for review", "match our PR template", or "regenerate the body". Analyzes `git diff` against the base branch (final state, not commit history) so added-then-removed work is omitted and fabrication is avoided. Skip for changelogs, release notes, issue comment summaries, or open-ended code review.

Use when the user wants to learn or be taught a topic interactively over multiple turns, with the agent acting as tutor rather than answer-giver. Triggers on phrases like "teach me", "tutor me", "quiz me", "let's learn", "help me understand X by working through it step by step", or any request framed around *learning* a topic rather than *completing* a task. Also triggers for spaced review of previously-learned material and explain-back-to-check-understanding. Do NOT trigger for one-shot factual lookups ("what is a monad"), debugging help ("walk me through why this code fails"), task execution ("help me write this query"), or procedural explanations where the user wants to accomplish something rather than build understanding. The distinguishing signal is whether the user wants to *become able to do it themselves later* (trigger) vs *get it done now* (do not trigger).