How it works
Why the code that comes out is code you can trust
Deep Skills runs your idea through six single-job stages. Each hands a self-contained artifact to the next, every claim needs evidence, and nothing ships on vibes.
The pipeline
Six stages, one clean loop
No do-everything agent quietly cutting corners. Each stage does exactly one job, then hands off - so every step is predictable, inspectable, and easy to rerun on its own.
Plan
A steerable planning session that ends in a plan so complete a fresh agent could execute it cold. It plans - it never writes code.
hands off → the plan document STAGE 02 · CRITIQUE /deep-plan-reviewReview the plan
Fresh, codebase-aware agents critique the plan against what you asked for and what the repo actually supports - before any code exists, when problems are cheapest to fix.
hands off → an independent critique STAGE 03 · EXECUTE /deep-implementImplement
Executes the plan phase by phase - implement, validate, fix, commit - with every phase landing as a clean, resumable checkpoint. The only stage allowed to write source.
hands off → validated, committed phases STAGE 04 · VERIFY /deep-code-reviewReview the code
A multi-agent review where every finding must cite evidence - and the serious ones are adversarially attacked before you ever see them. What survives is what's real.
hands off → evidence-backed findings STAGE 05 · REMEDIATE /deep-bugfixFix for real
Clusters findings by root cause and fixes minimally at the cause - then a separate fresh agent must prove the fix works. The fixer never grades itself.
hands off → proven fixes STAGE 06 · ORIENT /deep-docsDocument
Maps what actually got built - every claim anchored to a real file and line and verified against the code, sized for agents reading under a token budget.
hands off → docs that match the codeThe tight loop before anything ships: review → fix → re-review. Findings don't get argued away - they get fixed at the root cause and put back in front of fresh reviewers until the work holds up.
Fresh-agent resumability
The chat is disposable. The artifact isn't.
Every stage passes one acceptance test: could a fresh agent - given only the artifact and the repo, with zero conversation history - pick this up cold?
Walk away mid-effort
Close the laptop after planning, resume implementation tomorrow - in a new session, on a new machine, with zero re-explaining. The artifact carries all the context.
Hand it to anyone
A teammate - or a different assistant entirely - continues from the same artifact. Work stops being trapped in one person's chat history.
Reviews stay honest
Because reviewers start fresh, they never inherit the author's reasoning - or its blind spots. They see the artifact and the codebase, not the argument that produced them.
Where everything lands
An artifact tree in your repo
Every run writes to a per-effort directory in the repo you're working on - not a chat log, not a vendor dashboard. Version it, diff it, hand it off.
# one directory per effort, in the target repo
.deep-skills/<effort-name>/
00-Manifest/ manifest.md ← every stage's status, one table
01-Plan/ plan.md ← /deep-plan - the durable spine
02-Plan-Review/ review.md ← /deep-plan-review
03-Implementation/ summary.md ← /deep-implement
04-Code-Review/ report.md · findings.json · certificate.md
06-Bug-Fix/ round-N/ scope.json · fix-summary.mdThe plan is the spine. It accumulates phase summaries, deferred decisions, and review outcomes as the effort progresses - so the whole history of a change is legible from one document, and the manifest tells any newcomer exactly where things stand.
The trust mechanics
Four rules that make the output defensible
Trustworthy code isn't a promise - it's a set of structural constraints no stage is allowed to skip.
One writer of source
deep-implement is the only stage that writes code. Planners plan, reviewers review, fixers fix - when a stage is tempted to cross its boundary, it stops and points to the right sibling instead.
Independence by construction
Both review stages run in fresh agents that never see the upstream conversation. Independent critique isn't a policy anyone has to remember - it's how the pipeline is wired.
Findings must survive attack
Serious review findings are adversarially verified before they reach you - and every fix must be proven by an agent that didn't write it. Nothing grades its own work.
Evidence or it didn't happen
The system hunts the last mile - code that looks wired but doesn't actually behave. Every claim must cite a file and line, a named symbol, or an observed behavior.
Try it
Run the loop on something real
Install once, then start with a plan - the rest of the pipeline builds on it. Works in Claude Code, Codex, Cursor, and GitHub Copilot.