ajbarea

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 "r

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.

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

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

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.

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.

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 neve

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.

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 menti

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 fact