logbooks

Use when the user needs ideas or a name — brainstorming, naming, developing an idea further, hybridizing ideas, stress-testing candidates, reframing a problem, or picking a final direction. Ideas persist in a per-topic logbook across sessions.

Design and create a logbook — a shared, queryable, schema-stable working surface that agents and humans append to, annotate, and query across sessions. Invoke when the user explicitly wants to track structured entries across multiple sessions or multiple contributors (e.g. "I want to track X across sessions", "I need a draft layer before committing to Jira", "let me review what the agent found before applying it", "multiple agents need to collaborate on this"). Also invoke when a document is accumulating repeated structured entries that would be better shaped as rows with named columns. Do NOT invoke for single-session analysis tasks, ad hoc data collection, or when the user asks to "collect" or "gather" information without mentioning cross-session reuse or multiple contributors — those are scratch tasks, not logbook tasks. This skill creates the logbook itself and a spec file — it does NOT create or modify skills. For wiring the logbook into a skill, hand off to skill-creator afterward.

Validates test quality beyond coverage: uses Claude subagents to generate intelligent mutations for source code, runs them via the project's native test runner (pytest, jest, vitest, mocha, go test), prints a structured summary, generates mutation-todos.md with per-mutant rationale, persists every run to a per-project SQLite ledger and JSONL trace under ./.logbooks/mutation-testing/, and warns when the mutation score falls below 70%. Invoke for: "run mutation tests", "check mutation score", "mutation testing", "are our tests actually testing anything?", "which tests are weak?", "test quality check". Do not invoke for plain unit test runs, coverage reports, linting, or type checking.

Hotspot-first, multi-pass code review for pull requests, branches, pasted diffs, and work-in- progress changes. Models behavior changes, selects risky hotspots, acquires minimal local context, generates candidate findings and questions, runs a skeptic pass and dedup, then surfaces at most 5 high-signal outputs. Persists a per-run JSONL trace and per-PR SQLite ledger under ./.logbooks/code-review/. Invoke for any concrete review request: "review PR #123", "deep review", "check this diff", "review current branch", "review staged changes", "review codebase", "audit this repo", "review this repo". Do not invoke for vague opinion requests that have no diff, code, or concrete review target ("what do you think of these changes?", "any concerns?", "thoughts on this?") — requests like "check this diff" or "feedback on this PR" are reviewing tasks even without the word "review".