AI Agent Workflow Collection

Use when setting up, checking, writing, linting, or troubleshooting Brigade memory handoffs for a repo or agent workspace, especially when a user wants durable agent memory, handoff inboxes, cross-harness memory routing, or a safe first Brigade setup.

Use before implementing, scaffolding, prototyping, or adding a feature when the work should start with the smallest useful code path, avoid speculative architecture, or prevent overbuilding before reduce would be needed.

Use when the user wants to act on an audit, fix the findings in a line-check/bug-hunt/security-sweep report, work a prioritized backlog, or asks to "fix the findings", "work the backlog", "clear the audit", or "do the high-leverage items". The step after the audit trio.

Use when auditing or fixing discoverability metadata for a website before publication, including titles, descriptions, canonical URLs, robots policy, Open Graph, structured data, and sitemaps. Not for content strategy or keyword research.

Use when answering structural code questions in an indexed repo - who calls this, what does this call, what breaks if I change it, what changed between two versions. Reach for it BEFORE grep whenever the question is about relationships between symbols rather than text. Triggers include "who calls", "what uses", "blast radius", "impact of changing", "callers of", "what depends on", and reviewing a diff's structural effect.

Use when reviewing a diff or module for hidden assumptions - things the code takes for granted that nothing guarantees - or when asked \"what could break this later\", \"what does this assume\", or to harden code that works today. Complements bug-hunt: bug-hunt finds defects with triggers today; this finds the ones waiting for tomorrow.

Use when asked to audit a repository, assess project health, find the highest-value improvements a repo needs, check whether a project is ready for contributors or coding agents, or decide what to work on next in a codebase.

Use at the end of any session that discovered durable knowledge (architecture decisions, root causes, setup gotchas, workflow changes, security findings, reusable patterns), or when the user says "hand off", "write a handoff", or "save this for the memory system".

Use before opening a pull request, before running gh pr create, or before pushing follow-up commits to an existing PR. Also use when the user asks "is this PR ready", "should I file this", or wants a change inspected before it goes out for review.

Use before any prose artifact goes public - a blog post, social post, README section, PR or issue body, commit message, release notes - to scrub identity and infrastructure leaks and apply writing conventions. Also use when the user asks to "scrub this", "is this safe to post", or "clean this up before it goes out". For repo and git-history leak scans use publish-readiness instead.

Use before a rendered reel, screen-recording, demo video, or GIF goes public (social, YouTube, a landing page) to catch identity and infrastructure leaks burned into the frames. Also use when the user asks "is this reel safe to post", "scrub this video", or before a video-publishing pipeline ships an MP4. For plain prose use plate; for repos use publish-readiness.

Use when anything misbehaves - a failing test, a production bug, a build break, flaky or unexpected behavior - before proposing or attempting any fix. Especially under pressure ("CI is blocking everyone", "just get it green") and after a previous fix didn't hold.

Use when a diff carries side effects - database writes, migrations, file mutations, network calls, payments, queue messages - to check whether running it twice is safe. Also when reviewing retry logic, crash recovery, or anything a scheduler, queue, or impatient caller might re-run. Silent when the diff touches no side-effecting surface.

Use when code review feedback arrives - from a human reviewer, a bot, or a review agent - before implementing any of it. Especially when the feedback is partly unclear, technically questionable, or comes wrapped in authority ("senior reviewer says").

Use when asked what to build next, what features a repo is missing, where the opportunities are, or to suggest a direction or roadmap grounded in the code. Triggers on "what should we build next", "what's missing", "suggest features", "what's the next thing". Proposes opportunities, not fixes; for finding problems use line-check, bug-hunt, or security-sweep.

Use when the current session needs an answer or a work product from a model on ANOTHER vendor's stack - a second opinion from a different model family, a cheap fast model for bulk work, or a cross-model review - by dispatching that vendor's own CLI as a one-shot worker. Triggers include "ask grok/composer/gemini/claude/codex what it thinks", "get a second opinion from a different model", "cross-model review", "run this by another model", "poll several models". No orchestration framework required; if a Brigade roster exists, prefer brigade run --worker instead.

Use when facing two or more independent pieces of work - separate bugs, separate subsystems, separate repos - that could be executed by concurrent agents, before dispatching any of them. Also use when the user says "fan out", "parallelize this", or hands over a pile of unrelated failures.

Use when auditing, updating, or migrating project dependencies, runtimes, package managers, lockfiles, or toolchains. Requires reading authoritative release and migration notes, changing one compatibility boundary at a time, and verifying the resolved dependency graph.

Use when configuring or troubleshooting T3 Code projects, multi-machine environments, desktop or headless servers, project names or icons, updates, launchers, or private remote access. Trigger on stale project entries, wrong workspace identity, missing favicons, update banners, saved backend setup, server reachability, Tailscale exposure, SSH tunnel fallback, or T3 service setup.

Use when investigating or improving performance, latency, throughput, memory use, CPU use, startup time, or bundle size. Establishes a repeatable baseline and profiles the measured bottleneck before any optimization.

Use when starting any conversation - establishes how to find and use skillet skills, requiring skill invocation before ANY response including clarifying questions.