jah2488

Use when starting a work session, picking up new tasks, or when the user wants to collaborate on implementation rather than delegate it entirely. Use when user says "let's pair", "let's work on", or starts a new feature/bugfix session. Structures work into rounds with explicit task ownership and subagent dispatch for implementation.

Use when the programmer needs to visually understand a system, debug complex behavior, compare architectural approaches, or work through data-heavy decisions. Generates self-contained HTML visualizations using pre-built templates following Edward Tufte's principles. Invoke during brainstorming, architecture decisions, debugging, or when the user asks to "visualize", "see", "map", or "diagram" something.

One operating mode for a coding agent: say less, build less, claim less, build right. Fuses four disciplines: leaner output, a minimal-code ladder (don't write code unless necessary), nine engineering principles, and a refute-don't-confirm validation reflex. Use when the user says "flint", "flint mode", "be lean", "less tokens", "don't over-build", "only what's needed", or invokes /flint. Stays on every turn once set.

Render dense, read-heavy content (plans, option comparisons, decisions, intake forms) as a styled local HTML page and open it in the browser, instead of dumping it as a wall of text in the terminal. Use when output is genuinely table-heavy, a multi-step plan, a comparison of 3+ options, a decision writeup, or when you need structured input from the user via a form. Invoke on request (/render) or proactively when terminal prose would be hard to scan.

Query and annotate your other Claude Code sessions through tend. Use when the user asks to check on background or parallel Claude Code sessions (which need attention, what a session is doing, its cost or timeline), or to tag a session with a color pip or a short note so it stands out in tend's dashboard. Requires the tend MCP server (registered from `tend mcp`).

Adversarial validation of a claim. Invoke on any result, number, comparison, finding, conclusion, or PR claim BEFORE trusting or reporting it. Refutes rather than confirms; reconciles claims against source data; hunts confounds; labels the weakest defensible restatement. Use when a wrong-but- confident answer would be costly.

Graceful end-of-session cleanup before the session is killed (Ctrl-C / closing the tab). Persists anything that would be lost (learnings worth keeping, a handoff doc if mid-task, in-flight decisions) and makes uncommitted git work safe locally. Fast and silent like an OS flushing buffers before power-off, then says "safe to shutdown". Invoke when done with a session: /shutdown, "done", "goodbye", "shutting down", "wrap up".

Audit recent code changes against nine engineering principles, then report violations grouped by principle with file:line and severity. Run at the end of a major development phase, before a PR, or on demand via /eng-audit. Verifies findings against the code; never audits from memory.

Code archaeology — recover the full history and *intent* behind a specific piece of code: what it does, the commit that first introduced it, the most recent significant change, the PR(s) those commits merged in, and the discussion around them in PR reviews, linked tickets (GitHub Issues, Linear, Jira, etc.), and team chat. Use this whenever the user asks WHY a piece of code exists, the HISTORY or reasoning behind a decision, "who wrote this and why", "what's the context here", or "what was this change for". ALSO invoke it proactively, before editing code, whenever you are about to make a non-trivial change to code that is unfamiliar, legacy, fragile, or whose intent is unclear — understanding the original reasoning prevents reintroducing bugs that an earlier change deliberately fixed. Also use it when reviewing someone else's change under those same conditions. Triggers on: git blame, code archaeology, "why is this here", "why was this done this way", tracing a regression to its origin, and understanding lega