AI Agent Workflow Collection

Periodic cumulative-drift audit — look at the last stretch of shipped goals as a whole and ask whether the work still matches the north-star's stated bets, or whether the strategy has been quietly rewritten by accumulation. Use when the user runs /sdlc-align, when /sdlc-status reports an alignment check is due, or after a north-star revision.

The Goal phase — turn an idea into an approved design before any code: explore intent, requirements, and constraints; ask one question at a time; propose 2-3 approaches with trade-offs; restate as one concrete, checkable goal. Use at Goal, or when the user runs /sdlc-brainstorm. Portable executor — prefer superpowers:brainstorming on Claude when installed; this is the built-in equivalent for every other host.

Pre-flight recall — assemble a compact, cited "context brief" of prior art (knowledge graph + past issues + conventions) for a goal before running it, so a crucial earlier finding is never missed just because the context window flushed. Use at the start of a goal when the knowledge graph is enabled, or when the user runs /sdlc-context.

Detect breaking changes to public APIs, event shapes, exported types, CLI flags, or env vars before consumers hit them. Triggers on "breaking change", "API change", "contract", "consumers", "exported type", "event shape", "route change". A conditional-risk review orthogonal to sdlc-review; always LoopSmith's own (no companion equivalent). Use when a diff changes a public surface, or when the user runs /sdlc-contract-check.

Diagnose a bug hypothesis-first, reproduce-as-a-test-first — before writing any fix. Triggers on "bug", "broken", "not working", "error", "exception", "investigate", "why is X". A conditional-risk skill orthogonal to sdlc-review; always LoopSmith's own (no companion equivalent). Use to diagnose before sdlc-implement, or when the user runs /sdlc-debug.

Record an architectural decision as a machine-checkable invariant so an edit that breaks it is DENIED, not just discouraged. Use when the user runs /sdlc-decide, says "make this a rule / an invariant", "enforce this", "stop us breaking X", or after a retrospective proposes a standing rule that a linter can't catch.

One-command setup check-up — audits what THIS project needs (gh auth + project scope for the board, the graph builder for the KG, a filled north-star for vision-first, the .sdlc layer always) and prints what's ready plus the one-line command to fix anything missing. Use when the user runs /sdlc-doctor, hits a setup problem, or asks "why isn't the board / KG working".

Run ONE goal through the full Goal-Based SDLC interactively, pausing for your approval at each gate, then record the outcome. Use when the user runs /sdlc-goal or wants to drive a single goal end-to-end with oversight.

The Implement phase — build test-first (red → green → refactor) and execute the plan step by step, verifying each. Use during Implement, or when the user runs /sdlc-implement. Portable executor — prefer superpowers:test-driven-development + executing-plans on Claude when installed; this is the built-in equivalent for every other host.

Build, refresh, or query the project's optional knowledge graph — external research + internal analysis (+ optionally code) — via the configured builder (default graphify). Use when the user runs /sdlc-kg or asks to build / update / query the knowledge graph.

The team coordination ledger — set it up, read it, leave a note, or hand work off, all through the plugin instead of raw python paths. Use when the user runs /sdlc-ledger, wants to turn the ledger on or initialise it, check what's addressed to them, see who's done what, hand a blocker to a teammate, answer a hand-off, or regenerate TEAM.md. Do NOT use it to log claimed/done for a normal goal — the loop does that automatically.

For any DB schema or data migration, work the forward path, backfill, rollback, and canary before it ships. Triggers on "migration", "schema change", "ALTER TABLE", "new column", "backfill", "DDL", "data migration". A conditional-risk review orthogonal to sdlc-review; always LoopSmith's own (no companion equivalent). Use when a diff includes a migration, or when the user runs /sdlc-migration-check.

Predict the model tier a goal deserves (haiku/sonnet/opus/fable) so a goal's phases run at a tier matched to the work. Use when the user runs /sdlc-model or asks which model to use for a goal.

The Plan phase — write the implementation plan (files, steps, tests, definition-of-done) as bite-sized, independently-testable tasks, before any edit. Use during Plan, or when the user runs /sdlc-plan. Portable executor — prefer superpowers:writing-plans on Claude when installed; this is the built-in equivalent for every other host.

Adversarially review an implementation plan BEFORE coding — verify its claims against the actual code and stress-test what could go wrong after it ships. Use at SDLC Phase 4, when the user says "plan review" / "review the plan", or before implementing any non-trivial plan.

Proactive research scout (dry-run) — scan the open backlog, research the current SOTA against it, dedup against the radar ledger + the KG gap log, and write a ranked digest. Writes NOTHING external by default. Use when the user runs /sdlc-radar or wants a proactive "what's new / what should we look at" sweep over the backlog.

The pre-flight checklist run immediately before a non-trivial change ships to production — the final gate after Review. Triggers on "ready to ship", "deploy", "release", "merge to main", "go live", "pre-flight". A conditional-risk review orthogonal to sdlc-review; always LoopSmith's own (no companion equivalent). Use before shipping, or when the user runs /sdlc-release-check.

The Research phase executor — map a goal's real blast radius across the codebase, inventory the tech debt already sitting in it, and size the goal into a lane (small/medium/large) from what was actually found. Writes a short dossier the Plan and Plan-Review phases both read. Use at SDLC Phase 2, or when the user runs /sdlc-research or asks "what's the blast radius for X".

The Retrospective / learning executor — after a goal ships, surface the structural + product debt the narrow fix left behind, check what shipped against the original intent, and route each durable lesson to the right store (audit trail / north-star / standing rule). Advisory — it proposes, and parks north-star + standing-rule changes for your approval. Use at the end of a goal, in the Retrospective phase, or when the user runs /sdlc-retro.

The Review phase — a thorough code-quality review: a quantitative KPI pass, then a qualitative scan (dead code, duplication, DRY, consistency, async correctness, project-rule violations), with a diff-review mode for PRs and a counter-review mode that grades an external reviewer (Cursor / GPT / SonarQube). Use at Review, or when the user runs /sdlc-review. Portable executor — prefer the code-review plugin (/code-review) + superpowers:requesting-code-review on Claude when installed; this is the built-in equivalent for every other host.

Threat-model a change that touches auth, user data, external inputs, billing, or a public endpoint — catch the exposure before the internet does. Triggers on "security", "auth", "permissions", "PII", "external API", "public endpoint", "rate limit", "token". A conditional-risk review orthogonal to sdlc-review's code-quality pass; always LoopSmith's own (no companion equivalent). Use when a diff opens a security surface, or when the user runs /sdlc-security-review.

One-command adoption of LoopSmith into an EXISTING repo — detect the repo + board, scaffold .sdlc/, and write a safe config with the right defaults (github discovery scoped to @me, ledger on, PRs on), then bootstrap the ledger and verify. Use when the user runs /sdlc-setup, says "set LoopSmith up here", or is adopting the plugin into a project that already has code and history. For a brand-new empty project, /sdlc-init alone is enough.

Ground a sizing estimate in this repo's ACTUAL recent git throughput (commits/day, and merges-as-PRs/day) instead of "this feels like weeks". Converts a work estimate (N PR-sized units) into a calendar band at the measured rate. Use at the Plan phase, or when the user runs /sdlc-velocity or asks "how long will this take / what's our real pace".

Verification before completion — never claim done / fixed / passing without running the check and showing the output. Evidence before assertions, always. Use at the end of Implement/Review, before recording a goal done, or when the user runs /sdlc-verify. Portable executor — prefer superpowers:verification-before-completion on Claude when it's installed; this is the built-in equivalent for every other host.