AI Agent & Automation Workflows

Stand up a new AI/agent project - or add an AI subsystem to an existing repo - starting from a requirements intake and ending in a committed full stack. Use when the user says "scaffold an agent project", "set up a new AI app", "bootstrap a RAG/agent repo", "add an agent to this codebase", "add an AI/LLM feature to our existing app"; when they ask for the stack for a specific system they intend to build ("get me a stack", "which stack should we use for this", "pick the stack for this agent", "what should we build it with") - as opposed to open-ended options questions, which go to ai-engineering; when they make ANY "build me an agent that does X" request, even a trivial-sounding one, because the intake may rightly conclude a plain script suffices; and when they hand over a vague AI build idea that needs shaping first, in which case it calls interview-me and idea-refine before selecting anything. Exits with a named component per slot - harness, framework, model provider, memory, retrieval, ingestion, tools, MCP servers, eval, frontend - then generates the skeleton and hands implementation to agent-skills.

Authoritative source of truth on AI tooling and how to choose it - the knowledge behind building AI agents and AI systems. Use when choosing between agent frameworks, harnesses, memory, RAG, ingestion, serving or eval components; when weighing an architecture for an agent/LLM system; when asked "what's the current state of X", "what are my options for Y", "is Z still maintained", or "what license is Z"; and when reviewing whether an AI design honors sound engineering practice. Answers come from the bundled dated corpus, not from training memory. Standing up a new AI project or adding an AI subsystem to an existing repo goes to ai-agent-project-scaffold; updating the corpus goes to ai-engineering-update; general engineering discipline to agent-skills; MCP servers to build-mcp-server.

The write path for the ai-engineering tooling corpus - keeps it current, deduplicated, and honest about what we have actually seen. Three jobs. DISCOVER new AI tools and fold them in ("refresh the AI tooling", "any new agent frameworks", "add these AI links"). VERIFY what changed ("check the catalog for staleness", "is X still current", "did that project get archived", "is that license still MIT"). RECORD first-hand experience with a tool, good or bad ("note that X broke for us", "log that Y worked", "remember this library OOMs above 50k docs", "that framework's docs were wrong") - use it whenever a tool in the corpus is actually used and something is learned, not only during a maintenance pass. Wraps scripts/ledger.py (deterministic dedupe, conflict resolution, freshness, field notes) and the deep-research skill.

Strips the tells of machine-generated writing from a document while preserving its meaning exactly, then corrects errors, hallucinations, contradictions and unrequested inventions. Removes hedging, sycophancy, meta-commentary, inflated register, formulaic cadence, em dashes, emojis and decorative symbols, and equally fixes the opposite failure - clipped aphoristic prose that asserts instead of informs. Use when text is described as reading like AI, like ChatGPT, generic, templated, bloated, corny, cringe, or "not how I talk"; when it reads as clipped, punchy, noir, hardboiled, over-confident, preachy, or like it is performing authority; when polishing any model-drafted README, spec, ADR, PR description, report, email or client deliverable before it ships; when asked to de-slop, tighten, clean up, or humanize writing; and when reviewing prose a model produced for anything it invented or contradicted. Read it BEFORE drafting a document someone else will read, not only after. Ships a deterministic linter (scripts/slopcheck.py) for the countable tells; the judgment calls stay in the procedure. Not for changing what a document argues, and not for code logic.

Spawn a fresh-context senior peer (the supervisor subagent) to scrutinize in-flight work and catch it going off the rails: scope drift, context rot, rookie mistakes, lazy shortcuts, over-engineering, correctness/safety landmines. Non-blocking, advisory, surgical. MUST be used when the user asks for a second set of eyes, a look-over, a double-check, or review before declaring work finished ("get a second set of eyes on it", "before I call it done", "cover me on this") - spawn the supervisor rather than reviewing inline, because the fresh unanchored context is the point. Use on mission-critical or irreversible tasks (production migrations, schema changes), before declaring something done, or when context is getting long. Also auto-triggers when the user is visibly frustrated, swearing, or reporting repeated failure of the same fix (e.g. "fu," "dam it," "sht," "wtf," "this STILL doesn't work," "I've fixed this twice already"): venting is a reliable signal the work is going sideways and a cold second opinion helps. Invoked as /cover-me or /supervisor.

Designs, reviews, and hardens Kimball-style dimensional models: star schemas, conformed dimensions, bus matrix, slowly changing dimensions. Use when modeling analytical data for a warehouse, lakehouse, or BI semantic layer: declaring a fact table's grain, deciding whether something is a fact or a dimension attribute, picking an SCD type for an attribute that changes, or drafting the bus matrix that makes cross-process reporting reconcile. MUST be used whenever star-schema DDL, a dbt mart, or a model spec is reviewed, checked over, or handed to an ETL or engineering team - mixed grains, nullable foreign keys, descriptive attributes in fact tables, snowflaked dimensions and a type 2 dimension keyed on its business key are cheap to catch there and expensive to catch once history is loaded. Also use when preparing or facilitating a modeling workshop with business stakeholders, and when inheriting an unfamiliar warehouse whose reports disagree with each other. Ships an offline checker (scripts/dimcheck.py).

Use when creating UI designs to avoid generic "AI slop" aesthetics. Enforces distinctive typography, cohesive color systems, purposeful motion, and atmospheric backgrounds. Critical for landing pages, dashboards, and branded interfaces.

Orchestration loop - plan, delegate to parallel workers, verify, synthesize - with a premium advisor consulted off the hot path. The session model orchestrates, fan-out runs as Agent calls against two pinned subagents (reader on sonnet for read-only gathering, worker on opus for anything that changes the tree), and the advisor agent (model fable) is pulled in for decomposition critique, risk, and taste. MUST be used whenever the user asks to run something as a loop, orchestrate, fan out, or delegate to workers ("run this as a meta loop", "orchestrate this", "fan this out with an advisor", "use cheap workers for the leg work"), whenever a requested task visibly splits into three or more independent subtasks, and for any mid-loop situation: verifying a worker's returned result against its claims, re-delegating a rejected subtask, or critiquing a decomposition before fan-out. Also on "/meta-loop". Not for single-file or single-step tasks.

Personal pre-merge security gate for agent tooling - skills, subagents, slash commands, hooks, shell/sync scripts, dotfiles, settings.json, and plugin/MCP trust. Also scans for user-specific absolute paths, device/vault overfitting, and hardcoded personal constants (names, emails, handles, personal repo URLs, vault/project names) in shared tooling - anything the agent should instead infer at runtime or ask for live - and can fix them (prefer ~/ on macOS). Scans any file an agent reads as instructions for text hidden from the human reviewer - invisible Unicode, ASCII/tag smuggling, zero-width characters, bidi overrides - so use it whenever asked whether a skill, prompt, rules file, or pasted content has hidden or invisible instructions in it. MUST be used before committing or merging any change to ~/.agents or ~/.claude, before keeping or enabling a new or changed hook (PreToolUse/PostToolUse/SessionStart in settings.json - "review this hook", "check my hook before I keep it"), before installing or trusting a plugin or MCP server, and for any automation that runs commands, touches files, or consumes untrusted agent/LLM/web/MCP output - apply this checklist rather than reviewing ad hoc.

Structured thought partner for consequential decisions, running John Boyd's OODA loop plus the prescriptive decision corpus: decision theory, game theory, mechanism design, systems thinking, and behavioral bets. Classifies the decision (reversibility, stakes, emotional load, time pressure), routes to the right lens, and exits with a committed act, an installed policy, or a scheduled decision - never "think about it more". Use when the user owns a live choice under uncertainty with real stakes - strategic ("should I take this job", "help me decide"), technical ("which database/architecture", "build vs buy", "migrate or rewrite"), or both; when asked to stress-test, tear apart, or devil's-advocate a plan, idea, design, or RFC; when the user keeps circling without converging (rumination, analysis paralysis); when asked how to get better at a recurring activity (capability audit); or to review a past decision without outcome bias. Not for factual questions, already-made decisions, or trivial reversible picks.

Builds and queries a SQLite+FTS5 knowledge graph over an Obsidian vault - wikilinks ([[Note]], [[Note|alias]], [[Noteheading]]), embeds (![[...]]), frontmatter properties/aliases/tags, and standard markdown links. Use when asked to index, search, query, or traverse an Obsidian vault - e.g. "make this vault queryable", "search the vault for X", "what links to note Y", "backlinks for Z", "how are these notes connected" - when answering any factual question from a wikilink vault's contents, when diagnosing link problems an ingest reported ("ambiguous links", "two notes with the same name", "unresolved link"), or when any agent needs ranked search or the link graph of a wikilink vault instead of raw grep. Fully offline and deterministic - no API keys, no network. The graph lives at /.obsidian-kg.db and rebuilds idempotently from the markdown. For OKF vaults (standard-md-link concept notes) use okf-kg instead.

Builds and queries a SQLite+FTS5 knowledge graph over an OKF markdown vault (a curated knowledge base of frontmattered concept notes joined by standard markdown links). Use when asked to ingest, index, search, query, or traverse an OKF vault or knowledge base - e.g. "ingest this vault", "search the knowledge base for X", "what links to concept Y", "how are A and B connected", "rebuild the knowledge graph" - when answering ANY factual or relationship question from such a vault's contents ("using the vault at , what/how..."; "what does the knowledge base say about X") - or when any agent needs to orient inside a vault of concept notes before answering from it or generating docs. Fully offline and deterministic - no API keys, no network. The graph lives at /.okf-kg.db and rebuilds idempotently from the markdown.

Multi-device git sync ritual for repos worked on from several machines, sometimes concurrently. Fetches and diffs origin before work starts, reconciles inbound commits from other devices, re-fetches immediately before every push, and verifies branch parity (e.g. develop == main == origin) afterward. Divergence is a stop-and-ask condition - never force-push, rebase shared history, or hard reset. Commits default to ONE per session and verify the staged set first, because git commit writes the whole index rather than the paths just added. In ~/.agents it adds a station drift-check against SPEC-CLAUDE.md. MUST be used for ANY commit, push, or pull intent in a repo worked from multiple machines, however casually phrased - "ok push this up", "ship it", "just commit it all", "anything to pull from my other machine?" - do not just run git directly; the ritual (verify the index, re-fetch, reconcile, verify parity) is the point. Also after a sync reports divergence, and on "/repo-device-sync".