asaf-shitrit

ai-native-sdlc

Router and shared model for running software work as a chain of committed artifacts — intent, spec, plan, verified diff, reviewed PR, monitored production — so that planning, review and deploy keep pace when an agent writes most of the code. Use when deciding how to run a piece of work end to end, when asked "how should we structure this change", when setting up or improving a project's agentic workflow, when the build is fast but everything around it is slow, or when picking which sdlc-* skill applies. Also covers what to adopt first and which numbers say it worked.

sdlc-agent-evals

Regression-test the configuration that steers the agent — run a suite of real tasks whenever CLAUDE.md, skills, hooks, subagent definitions or the model change, and gate the change on the result. Use when editing agent configuration and wondering whether it helped, when upgrading or switching models, when a skill or prompt is rewritten, when asked to set up evals or measure agent quality, or after an incident that must not recur. Covers assembling the suite from real work, wiring it into CI, and why a suite that always passes has stopped working.

sdlc-claude-md

Move institutional knowledge out of heads and wikis into files the agent reads — a short CLAUDE.md for repo context, and skills for rules that must apply consistently. Use when the agent repeats a mistake, when onboarding knowledge is undocumented or stale, when asked to write or trim a CLAUDE.md, when running /init and deciding what to keep, when a convention is enforced inconsistently, or when deciding whether something belongs in CLAUDE.md, a skill, or just the prompt. Covers the boundary between the three, keeping the file short, and why a skill alone can't guarantee anything.

sdlc-close-loop

Close the lifecycle loop — a deterministic detector watches production, invokes the agent when a threshold is crossed, and whatever it finds re-enters the pipeline as a new intent. Use when designing autonomous or headless agent workflows, when asked to run the agent non-interactively from CI, cron or a webhook, when monitoring should act rather than only alert, when defining how much autonomy an agent gets per environment, when post-mortem actions never reach the codebase, or when incidents wait on a person before anything starts. Covers deterministic detection, tiered response, rollback, and the boundary the agent cannot cross.

sdlc-feedback-loop

Give the agent a way to check its own work before a human sees it — one-command build and test, a target it can evaluate, a failing test written first for bug fixes, and a visual comparison for UI. Use when setting up a repo for agentic work, when the agent reports done without evidence, when a person is verifying every change by hand, when fixing a bug, when building against a mock, or when asked how to make sessions run longer unattended. Covers the setup, protecting the check from the agent that is fixing the code, and how a final verifier differs from the loop itself.

sdlc-hooks

Make a rule deterministic with hooks — block writes to protected paths, run a formatter after edits, keep secrets out of a diff, or hold an action until a named person approves. Use when a rule must hold every time, when a documented convention keeps getting ignored, when an approval must survive automation (releases, migrations, infrastructure, protected paths), when asked to configure settings.json or write a hook script, or when deciding whether something should be a skill or a hook. Covers allow/ask/block, where each belongs in a session, and why the block message matters as much as the block.

sdlc-intent

Capture an idea, ticket, bug report or production alert as a committed intent file — the problem, the outcome wanted, who and what it touches, the constraints, and what is still unknown. Use at the start of any piece of work, when someone says "I have an idea" or "we should build X", when users keep hitting something, when a ticket or incident needs turning into actionable work, or when asked to write a proposal, proto-spec or problem statement before any design or code. Covers the interview, the template, where the file lives, and when writing one is a waste of time.

sdlc-parallel-work

Run several streams of work at once using isolated worktrees, and factor recurring jobs into subagents with their own context and tool limits. Use when there is more work in flight than one session can hold, when asked to parallelize or run tasks concurrently, when the same job recurs across tasks (verifying the app runs, simplifying after implementation, exploring a codebase without flooding context), when writing subagent definitions, or when deciding how many sessions one person can genuinely supervise. Covers splitting work so sessions do not collide, what makes a good subagent, and the real ceiling.

sdlc-plan

Write, interrogate and commit a plan before any code is generated — which files change, in what order, what could break, and what will prove it worked. Use before implementing anything non-trivial, when starting in plan mode, when asked "how would you approach this", when a change spans several files or carries blast radius, and when judging whether a session can safely run unattended. Covers the bar a plan has to clear, the questions that make one worth having, keeping plan and diff honest with each other, and when auto-accept is earned.

Code & Development Listed

sdlc-pr-review

Give every pull request the same review passes — correctness, security, and whether the change matches what was agreed — with findings ranked so human attention lands on intent and risk. Use when PRs queue or review depth varies by who picks them up, when setting up automated review, when asked to write a review policy, when review comments are drowning in style nits, when addressing feedback on an agent-authored PR, or when deciding what a human must still approve. Covers the policy file, keeping severity meaningful, and routing repeat findings back into the repo's context.

sdlc-spec

Turn accepted intent into a committed spec in one working session, applying policy while the design is written and surfacing contradictions instead of quietly resolving them. Use when an intent has been accepted and needs designing, when asked to write requirements, a design doc, a technical spec or a PRD, when collapsing separate requirements and design phases into a single pass, or when someone needs to review a design before implementation is planned. Covers the pass itself, the flagged-conflict discipline, and what the reviewer is actually checking.