claude_researcher

End a research session — runs update-docs to checkpoint all progress, then commits and pushes. Use update-docs for mid-session checkpoints without ending the session.

Checkpoint research progress mid-session — create/update convo summary, save results with provenance, update RESEARCH_LOG (and, in main_only mode only, a capped STATUS one-liner). Core operation that finish-convo builds on.

Use when setting up a new repo (or an existing repo) for the research-first workflow — creates docs/active/ and docs/historical/ directories, seeds STATUS.md with the Archived Research Lines table

Triage skill — routes academic-style papers to `paper-processing-academic`, institutional-style reports to `paper-processing-institutional`, non-paper documents to `document-processing` (deferred). Step 0 triage runs here; the routed per-protocol skill handles Steps 1-6.

Check docs/active/ structure for consistency — every convo indexed in RESEARCH_LOG, every plan linked to a convo, no orphaned files. Prompts the user for discrepancies rather than auto-fixing.

Check papers/ structure for completeness and accuracy — every PDF has text extraction, every paper is indexed in PAPER_INDEX.md and summarized in PAPER_SUMMARIES.md, summaries are factually accurate. Prompts the user for discrepancies.

Protocol A workflow for academic-style papers — rename → extract → index → dual-protocol summary (Protocol A shape) → BibTeX → stage. Triage by `add-paper` Step 0 routes here.

Protocol B workflow for institutional-style reports — rename → extract (institutional rules: preserve acronyms / boxes / figure captions) → index → dual-protocol summary (Protocol B shape) → BibTeX → stage. Triage by `add-paper` Step 0 routes here.

Convert "I should remember to do X" into a tracked GitHub issue — auto-detects repo/branch/convo, drafts title+summary for user approval, asks "when?" (optional ISO date prefix for reminder-style items), creates the issue with a `task` label, back-links the issue from the convo doc, and auto-commits the back-link. Use when the user says "add a task," "add task," "capture this," "capture a task," "open a task," "track this for later," "remind me later," "add a reminder," "track this with a date," or similar.

Session-start check for fired reminders. Queries the current repo + `home_repo` for open issues with a `[YYYY-MM-DD]` title prefix, filters to those whose date is `<= today`, and presents them in two labeled sections. Reads metadata only (no body fetches). Offers close / snooze / skip / strip-prefix (last one only if the user signals uncertainty about when to revisit). Use at session-start, or when the user says "check reminders," "what's pending," "session-start reminders," "any reminders?", "/task-remind," or similar.

List all open `task`-labeled issues across the user's GH repos, group them by repo, and have a conversational priority discussion. Read-only — does not modify issues. Shows date-prefixed (reminder) items inline with regular tasks; the fired-vs-pending split is `task-remind`'s job at session-start. Use when the user says "task-triage," "triage," "what should I work on," "/task-triage," "/triage-tasks," or otherwise wants a cross-repo view of pending work.

Use when a research conversation has produced something ready to implement — creates implementation plans that reference their originating conversation, carry epistemic context, and assume the implementing agent has zero codebase context

A branch-based workflow for collaborative document review when Claude and the user are co-producing a document. Use when the user wants to read and comment on a long markdown deliverable (slide content, talking points, briefing, narrative draft, paper) before signoff — especially when the markdown has companion artifacts (.docx, .pptx) generated from it. Edits live in the branch via inline bracketed comments or direct text changes; `main` only updates when review is done. Do NOT use for general-purpose branch work (experiments, code refactors, parallel versions) — those use plain git, not this skill.

A two-protocol workflow for knowledge work with Claude: one protocol for reading, thinking, and note-taking (fully interactive, step-by-step), and another for drafting written content (outline interactively, draft in one pass, revise in chunks). Use this skill whenever the user is working on a writing project that involves both research/reading and producing written deliverables — white papers, policy notes, reports, academic papers, book chapters, or any substantial document. Also use when the user asks to set up a writing workflow, wants to organize how they collaborate with Claude on a document, or says things like 'let's start writing,' 'how should we work on this,' or 'set up the project.' This skill is especially useful for projects where the user is both the thinker and the writer — where reading feeds into writing.

IMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation

Use this skill when faced with a difficult debugging task where you need to replicate some bug or behavior in order to see what is going wrong.

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions

Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first