ajbarea

audit

Run the repo's make targets in dependency order (setup → lint → test → end-to-end) and verify each command's terminal output against its `logs/dev-<ts>-<cmd>.log` archive. Supports a full audit and a fast variant. Use whenever the user wants to validate the toolchain is clean, run lint+test locally before pushing, or reconcile terminal output against the dev-runner log archives — phrasings like "run the audit", "is the build clean", "check my toolchain", "am I ready to push", "make sure CI will pass", "verify make targets". Requires the `logs/dev-<ts>-<cmd>.log` archive convention; see `docs/conventions.md`.

auto-commit

Analyze pending git changes and write a structured, conventional-commit plan to COMMITS.md so the user can review and stage commits in batches before committing. Use whenever the user wants to group working-tree or staged changes into sensible commits, draft commit messages for a dirty working tree, or prepare a commit plan from a diff.

catchup

Reads every comment, review, inline review thread, and state change on one GitHub repo's issues and PRs since the user last participated, then reports what is waiting on them, what is waiting on someone else, and what needs nothing. Read-only; never merges, comments, labels, or closes. Use when the user returns to a repo after time away, or before they resume work on an issue or PR — phrasings like "catch me up on <repo>", "did anything change", "is anyone waiting on me", "what did I miss", "any new comments", "sitrep on <repo>", "re-read the threads before I start". Accepts a bare repo name and resolves it against the local clone, so repos owned by a collaborator work.

ci-audit

Audit the latest GitHub Actions workflow runs on the current branch/PR for warnings, errors, failures, deprecation notices, and other log noise — then fix what's fixable in-repo (workflow YAML, configs, source, tests). Hands commit + push back to the developer. Use after CI finishes and before merge, or whenever the user asks about failing/noisy CI — phrasings like "audit the PR", "why did CI fail", "check the workflow logs", "what's wrong with the build on GitHub", "fix the Actions warnings", "review the latest CI run", "clean up the green-with-warnings run", or names a specific check (Codecov, GitGuardian, Renovate) that's failing on the PR.

deslop

Scan the codebase for AI-generated slop in comments and docstrings — temporal markers, self-referential AI framing, narrative WHAT-comments, marketing padding — and propose tightened rewrites, routing claim-bearing docstrings that need a code-grounded rewrite to its sibling /techne:reslop. Use when the user wants to audit pending changes or the whole codebase for verbose, low-value commentary left by other assistants (Copilot, Gemini, GPT, etc.).

docs-site

Maintain the Zensical-powered documentation site — nav ordering in zensical.toml, the docs GitHub Pages workflow, CSS and JS assets, and link/anchor integrity across docs/**/*.md. Sibling of /techne:docsync (which only verifies prose claims against code). Use when the user wants the site itself audited — config, deploy pipeline, theming, assets, cross-page links — rather than content accuracy.

docsync

Check a documentation file for drift against the actual codebase — CLI commands, file paths, config keys, function signatures, version numbers, environment variables — and propose corrections. Use when the user wants to audit README.md, docs/*.md, or similar for claims that no longer match reality. Drift usually comes from refactors that forgot to update the docs.

elenchus

Adversarial pre-merge code review — drive /code-review, then run the three passes diff-reading skips (reproduce the load-bearing claim, trace every consumer, review against the whole repo) and the bug-class rubric that catches reachable destructive ops, unmirrored parallel-path guards, migration crashes, and dead features that still pass CI. Use before merging a substantive change, when asked to "review it like a hostile reviewer", "hunt edge cases", "break this before merge", "is this actually mergeable", or to give a self-authored change an independent pass. Reads optional per-repo hints from the `## elenchus` section of `.claude/skill-context.md`.

paper-review

Use when a draft research paper needs a pre-submission novelty and reviewer pass — whether its contributions are actually new, what related work it misses, whether its claims hold up, and whether it overlaps a lab or co-author line that must be disclosed. Triggers include "review my paper for novelty", "is this contribution novel", "novelty check before submitting", "what related work am I missing", "verify my citations are real", "paper-review <name>".

research-grounded

Audit a plan's design decisions — library, framework, pattern, and architecture choices in IMPL.md / ROADMAP.md — for missing `# research(YYYY-MM):` provenance, then web-search to ground them. Use when you want architectural choices verified against current best practice before they harden into code, rather than resting on training-cutoff recall. Catches committed decisions stated as fact but never checked — the class of miss that becomes revertable work.

reslop

Rewrite docstrings and comments by reading the actual implementation, call sites, and tests — produce grounded, factual prose instead of deleting slop. Sibling of /techne:deslop. Use when the user wants to replace overhyped or hallucinated documentation with accurate one- or two-line descriptions derived from what the code actually does.

sisters

Cross-repo drift audit across linked repos listed in `~/.claude/techne.toml` (configurable per-user). Read-only inspection of CI action pins, toolchain pins in pyproject.toml, skill-context structural parity, GitHub merge settings, open PRs, and branch hygiene. Triggers on phrases like "audit the sisters", "are the sisters in sync", "check cross-repo drift", or when multiple sister repos are mentioned together for a consistency check.

theoros

Run an observed live dev session — Claude drives an interactive REPL in a named tmux session, the human spectates read-only via `tmux attach -r`. Use when the user wants to play through, debug, or explore a service's REPL together. Trigger phrases include "let's do a live smoke", "run a theoros session", "I want to spectate while you drive the CLI", "start an observed dev run". Reads per-repo facts from the `## theoros` section of `.claude/skill-context.md`.

paper

Use when starting or scaffolding a new research paper in a papers-style monorepo (a repo of LaTeX paper directories that share one bibliography). Triggers include "scaffold a paper", "start a new paper", "set up a paper dir", "new paper from <repo>", "add a paper to papers/".