AI Code that Works · Get started
Prompts are not enough. Systems are.
Your AICTW MCP server lives at your project’s root and coaches your coding agent to score, plan, convert, and secure your work against the five-phase method — and to build every project to one agent-legible shape. Here is the method it measures against, the shape it builds to, the one command to run first, and the commands your agent runs from your editor.
The method
The five-phase method
Raw AI coding gives you speed; without structure, that speed produces fragile software faster than anyone can clean it up. The fix is not a better prompt — it is structure. These five phases are the structure: the guardrails you build into the repo and onto the AI so it builds reliably. Phase 0 comes first as the thinking you do before any of it.
DecomposePhase 0 · think first
Get the real work out of your head first.
Before you can give the AI context, you have to get the actual work out of your head. Do the task by hand and watch yourself do it — every step, every exception, the judgment calls you make without thinking — then break it into its smallest pieces and decide which an AI can run and which stay human. Most operators skip this and hand the AI a vague whole. Phase 0 is a thinking exercise, not a build step: nothing gets built yet, but it is what makes every phase after it possible.
Context
Give the AI the full picture before it builds.
Before the AI builds anything, hand it what it needs to make good decisions — the user, the goal, the constraints, and the patterns that already exist. Context comes first because everything after it depends on it: rules bind to the wrong things, docs describe a project the AI never understood, and verification checks against a definition of done nobody wrote. Generic context produces generic builds — name what you are building specifically, and keep the context living as the project changes.
Rules
Turn preferences into a governed process.
Define the standards the work must follow — how things get built, named, structured, and kept safe. Rules turn per-prompt negotiation into a governed process. The signal that a rule is needed is concrete: the moment you correct the AI on the same thing twice, that was a rule asking to be written. Rules earn their keep only if they stay honest — if a rule bends three times, change it, because a stale rule teaches the AI to distrust the whole file.
Documentation
Treat documentation as the project's memory.
Decision records explain why; reference docs explain how; active plans explain what is being worked on now. This is what stops the AI from repeating solved mistakes and forgetting context across sessions. The working unit is the five-field decision record — what we considered, why this one, and what would reopen it — and the deeper move is a documentation engine that has the AI maintain its own docs as a side effect of every change, so the project's memory stays current without anyone remembering to update it.
Verification
Never trust static success alone.
Linting and typechecking are necessary but not sufficient — a screen is not a system, and a demo is not an app. Real verification means runtime checks, end-to-end tests, error monitoring, and a clear definition of done written before you build. It carries one cardinal rule: find at least one thing wrong, then fix it. AI-built work almost always has a subtle bug, an awkward default, or a wrong edge case — if you found nothing, you skimmed.
Feedback Loops
Build the loops that replace guesswork.
Drift checks, observability, error feedback from production, and structured review — each cycle improves the system, not just the feature. The discipline that makes it compound is the split between the log and the upstream files: the feedback log is the project's history; the context, rules, and decision records it changes are the living memory. Capture continuously, not as an end-of-project retro, and the loop matures into real working memory between an operator with discipline and an AI with access.
The build architecture
Every project is built to one shape
The folder tree of a project is its architecture. Every build the AICTW method touches gets the same shape: a root router at the top plus layered context down the tree. That is what makes a build legible to an AI agent, portable across sessions, and maintainable long after the first burst of work. It is scaled — a one-page site gets the lean version, a growing app grows into the full framework — and it lives in your repository, working the same whether this tool is connected or not.
The router is one body written once and emitted under each agent’s filename — CLAUDE.md, AGENTS.md, GEMINI.md — so whichever coding agent lands in the repo reads the identical guidance.
Root routerEvery project
The file at the very top — the project's constitution plus a map that points your agent to the right context for the work at hand. Present on every project, tiny or large. This router-at-the-top is the signature of a build an AI agent can work in reliably.
Workspace routing
Which section owns what — it appears once the project grows past a single section.
Section context
Each section's own rules and the scope it is responsible for.
References
Durable, section-scoped knowledge — the why behind the decisions.
Output
Session-scoped working artifacts and scratch, kept apart from the durable tiers.
Start here
Run assess first
assess is the one command to run before anything else. It scores your repository against all five phases and hands back a prioritized plan — so you start from what actually matters in your project, not a generic checklist.
Ask your agent to run assess
From inside your editor, tell your coding agent to run the AICTW
assesscommand. It has no access to your files — it hands your agent a short list of signals to collect.Your agent gathers and analyzes
Your agent collects the signals (scrubbing secrets first) and sends them back. We score them server-side against the five-phase method — your code is processed in the moment and never stored.
Work the prioritized plan
You get a score per phase and an ordered plan of what to fix first. From there, reach for the other commands as each gap calls for them —
recommendfor what to change,planfor a new feature,fixfor a specific gap.Hand the work to your agent
When you’re ready to build,
packbundles the method steps, your repo’s rules, and a verification checklist into a Context Pack, andcomposewrites the exact prompt to paste into your coding agent — for the build, and again to verify it when your agent claims done. Both are plan-first: you see them before anything is written.
The commands
What this does
A handful of commands your agent runs from your editor. Most read commands (gather then analyze) report back; ask answers directly — a plain-language question in, a grounded answer out. Plan-first commands show the change-set and its risks and write nothing until you say go — then hand your agent the ordered edits to make. The server never touches your files.
assessreadScore your repo against the five-phase method and get a prioritized plan of what to improve first. Start here.
askreadAsk in plain language — “how do I…” or “what should I…” — and get grounded guidance and the right playbook to run next.
postreadTurn a messy problem into a clear community question — your goal, stack, what you tried, and the exact question, formatted and ready to paste. You review it and post it yourself; we never post for you.
planreadPlan a feature the AICTW way — a short interview, then a permanent plan file threaded through the five-phase method for your agent to work from.
packplan-firstMake your repo work the AICTW way for the one task you're about to hand off — pack the method steps, this repo's rules, and a verification checklist into a Context Pack under `.aictw/packs/`. Plan-first: you see it before your agent writes anything.
composereadThe hand-off — the exact prompt to paste into your coding agent for one moment (first prompt, implementation, verification, bug-fix, or task-split), grounded in your plan and Context Pack. It writes nothing; you paste it and run it.
implementplan-firstApply one of our playbooks or briefs to your repo — name it (or describe it) and we resolve the content for your agent to write.
fixplan-firstRemediate an issue from your AICTW report using our playbook for it — pass the fix id from an assess gap or a scan finding.
recommendreadStack-aware recommendations — what to improve, why it matters, and honest migration advice where a swap is involved.
Session prompts
A prompt to sharpen a session
Beyond the commands, a slash-invocable prompt pressure-tests an idea before you build (/ideate) — run it before plan. To get going, connect, then run assess for a read-only first look, then setup to scaffold.
/ideatePressure-test an idea before you build — validate what you bring, or generate candidates, then hand it to plan. You run the research; the coach never invents numbers.
A couple of commands run under the hood — setting your repo up the AICTW way (a fresh folder or an existing project) and the security review your agent calls for you — so you never have to think about them. Your agent reaches for them when the moment calls; you just work the plan.