garikipatisai-code/sdlc-lean

Use when a task needs a capability, skill, plugin, agent, MCP server, or solution the suite lacks, or when a proven/verified implementation likely exists. Search trusted sources and reuse or install before reimplementing

Use when a significant architectural decision is made and must be recorded - a choice that is hard to reverse or affects multiple modules

Use when asked to achieve a goal autonomously - "keep going until", "loop until", "run end to end", "do whatever it takes", or any goal with acceptance criteria. Loop route-decide-plan-execute-verify-correct until done or an honest budget stop

Use when running agentic loops with adjustable autonomy - Observe to Auto tiers, named check command, audit ledger, reversal path, escalation on a failed check

Use when facing any creative work before code exists - new features, components, behavior changes, or vague ideas. MUST run before writing-plans and before any implementation

Use when work connects to, inspects, runs code on, or releases a Google Colab runtime through the colab-mcp server, or when a Colab session must be shut down and the release state is uncertain. Not for local Python, generic Jupyter, or non-Colab compute.

Use whenever communicating with the human - status updates, explanations, reviews, or any generated documentation. Enforces the 30-second attention budget with visuals over text walls

Use when a question needs external evidence rather than local code - "research this", "find everything about", "deep dive", "compare options/approaches", "state of the art", "is X better than Y", competitive analysis, due diligence, literature review, or any decision that depends on facts you must verify online. Not for quick factual lookups or questions answerable from the repo (use exploring-codebase)

Use when upgrading a dependency or a major version, or clearing version drift - so a bump cannot silently break the build or runtime

Use when a session went wrong - derailed plan, ignored skills, repeated failures - to diagnose the breakdown with evidence before retrying

Use when 2 or more independent tasks can run concurrently (fan-out), or when results from several workers/agents/sources must be combined (fan-in). Covers dispatch, parallel execution, and the merge contract

Use when changing APIs, database schemas, or shared contracts. Expand/contract sequencing - never additive and destructive changes in one deploy

Use when executing an approved implementation plan yourself in the current session, task by task with TDD and verification checkpoints

Use when orienting in unfamiliar code - mapping architecture, tracing flows, assessing change impact or finding dead code. Read-only reconnaissance

Use when implementation is complete and all tests pass, to decide how to integrate the work - merge, PR, or keep the branch

Use when building new UI or reshaping existing UI - distinctive visual design, aesthetic direction, typography, avoid templated defaults, React Tailwind shadcn

Use when an incident or outage has happened and needs a blameless postmortem - so the team learns and the same failure cannot silently repeat

Use when starting agentic work that needs approval - read-only research, preview plan, wait for accept before implementation

Use when facing a performance problem or optimization request. Measurement names the bottleneck before any code changes

Use when a diff feels big, before merging, or to audit a repo for over-engineering. Tagged delete-list with net line savings; never applies fixes

Use for work spanning sessions - persistent task state, progress ledger, and handover prompts that survive compaction and restarts

Use when choosing between options or approaches - "which option", "choose between", "is X better than Y", "best way", "compare X vs Y", "pick a tool/library". Research before deciding, score binary criteria in a matrix, pick, and record the decision

Use when receiving code review feedback, before implementing suggestions. Verify each item skeptically, especially unclear or questionable feedback

Use when completing tasks, implementing features, or before merging. Dispatches a reviewer for correctness, security, performance, and maintainability

Use when running empirical AI experiments with frozen protocols - hypotheses, splits, seeds, cache identity, evidence bundles, device locks, provenance

Use when a claim rests on a shipped artifact rather than readable source - decompile or trace binaries, packaged apps (Electron, APK/IPA, .NET, WASM, EVM), firmware, databases, or network/signal captures; compare shipped versions; verify or build a reconstruction. Covers the REA connection ladder, target routing, evidence discipline (observation vs inference vs unknown), S-tier reconstruction gates, and fallback tooling. Not for ordinary source-repo analysis.

Use when reviewing code for security, before merging auth, input-handling, or data-access changes. No finding without a traced attacker path

Use when writing long prose, explanations, or generated documentation that must be unambiguous and easy to read - applies an ASD-STE100-informed subset (short simple sentences, one meaning per word, active voice), never claiming certification or compliance

Use when executing an approved implementation plan with independent tasks via fresh parallel subagents, each with its own reviewer

Use when encountering any bug, test failure, or unexpected behavior, before proposing any fix. Root cause first, always

Use when implementing any feature or bugfix, before writing implementation code. RED-GREEN-REFACTOR cycle with failing-test-first discipline

Use when designing or changing anything that crosses a trust boundary - auth, input handling, data access, or external calls - before implementation

Use when asked to review UI, check accessibility, audit design, review UX, or check site against best practices - terse file-line findings plus React performance rules

Use when starting feature work that needs isolation, before executing implementation plans with parallel agents or risky changes

Use when starting any conversation - establishes how to find and use SDLC skills, requiring a skill check before ANY response including clarifying questions

Use when about to claim work is complete, fixed, or passing, before committing, merging, or creating PRs. Fresh evidence required

Use when building, designing, porting, or shipping a web-based game - 2D/3D engine choice, fixed-step loop, WebGPU/WebGL rendering, physics, game feel, netcode, performance budgets, playtesting, accessibility, PWA/portal shipping (Phaser 4, PixiJS v8, three.js, Babylon.js, PlayCanvas, Godot web export)

Use when you have an approved spec or requirements for a multi-step task, before touching any code. Produces a bite-sized implementation plan

Use when preparing a release, changelog entry, or version bump. Reader-change entries only - never code descriptions

Use when creating new skills, editing existing skills, or verifying skills work before deployment. Minimal trigger descriptions, pressure-tested