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 — working with your project’s own architecture, not reshaping it to look like a method. Here is the control plane it measures against, the lifecycle it tracks you across, how it treats your repository’s structure, the one command to run first, and the commands your agent runs from your editor.
The method
The five controls
Raw AI coding gives you speed; without control, that speed produces fragile software faster than anyone can clean it up. The fix is not a better prompt. These five are the control plane: what the agent needs to know, what it may and may not do, the decisions and plans it works from, the checks that prove the result, and the lessons that improve the next cycle.
They are not five stages you finish in order, and they are not a folder layout your project gets reshaped into. Where the product is sits on the eight-stage production lifecycle below; the five controls govern how work is carried out across it, and each one lights up where it is material to the risk and the output in front of you. Phase 0 is the step that bounds the next result before any of it runs.
DecomposePhase 0 · bound the work
Turn the next desired result into bounded work.
Before the agent can be given anything to run, the next result has to become bounded work. 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 agent can run and which stay human. Most operators skip this and hand over a vague whole. What comes out is one executable job with its inputs, process, outputs, verification, and stop conditions named: the brief you approve before anything is built.
Context
Give the AI the full picture before it builds.
Hand the agent what it needs to make good decisions — the user, the goal, the constraints, the recorded architecture map, and the patterns that already exist. Every other control leans on this one: rules bind to the wrong things, documentation describes a project the agent never understood, and verification checks against a definition of done nobody wrote. Generic context produces generic builds — name what you are building specifically, scope each area's context to the job it actually owns, and keep it 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: try honestly to break it, and report what you actually found. Name and run the checks most likely to catch a real problem — the messy input, the empty case, the second click — then diagnose, fix, and re-run every real one you turn up. When nothing fails, record the exact checks you ran as an honest clean pass; you never have to produce a defect for a verification pass to count.
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
The stack and the domain decide the structure
A competent web application looks like a competent web application. A library looks like a library. A research corpus looks like a research corpus. Your language, framework, runtime, package manager, build system, deployment model, and domain already decide where source, packages, tests, migrations, configuration, assets, and deliverables belong — so the job is to discover or propose that native layout, record it, and then govern the work across it. Nothing here reshapes a project so it resembles a methodology.
What AICTW adds alongside that layout is small: context, rules, documentation, verification, and feedback. Everything the coach proposes is additive, right-sized to the project in front of it, and shown to you as a change plan before a single file is written — and it lives in your repository, in plain text, working the same whether this tool is connected or not.
Context, rules, documentation, verification, and feedback are a small governing control plane, not production-code buckets: they never hold application source, packages, executable tests, migrations, datasets, research sources, or build outputs, and they never replace an ecosystem's conventions. Those belong where your stack and domain already put them.
Inspect and classify before prescribing
Before anything is proposed, your agent reports what is actually there — the language and runtime, the framework, the package manager, the real source roots, where tests live, the commands that actually run — and classifies the project from that evidence. Thin evidence is reported as unclassified rather than guessed.
Preserve what already works
A repository that already builds, tests, and deploys has earned its conventions. Nothing populated is migrated automatically and no file moves on a heuristic. If part of the current structure is genuinely broken, that is a separate, evidence-backed migration you approve later — never a cleanup smuggled into setup.
Record the architecture map
The map is the recorded statement of where the real work lives: the project kind, the stack and what decided it, each path's responsibility, whether that path is executable work or a governing control, and the canonical install / run / build / check / test commands. It stays a draft until you approve it — and once approved, your own `context/repository-architecture.md` is the authority on your project's layout. Nothing here overrides it.
Layer the smallest compatible controls
Only then does the governing layer go in — context, rules, documentation, verification, feedback, plus the project state, the active-stage plan, the current brief, the evidence receipt, and the checkpoint. A small project gets a small amount of it; more arrives when the work demands it, not in advance.
One canonical router; other entry points are thin pointers
A project benefits from one short router — its non-negotiable rules plus a table mapping the kind of work at hand to the files to read first. Where another coding tool expects a differently-named entry file, that file is a few lines naming the router and deferring to it, never a duplicated body. Duplicated bodies drift into competing constitutions. Where a repository already has a working authority file, it is preserved and routed into.
Routing appears only when the project earns it
Section or workspace routing is added when a project has real, independent areas — genuine workspaces, distinct services, separate domains with their own conventions or tooling. Sections are never invented: a small project handed a fake hierarchy is harder to work in, and the absence of a section map in a single-purpose project is correct, not a deficiency.
The eight-stage production lifecycle
The lifecycle records where the product is — the five controls govern how work is carried out across it. A project can move backward when the evidence calls for it; this is a map, not a fixed itinerary.
- Idea
- Architecture and High-Level Planning
- Detailed Specification and Plan Iteration
- Layered Build
- Integration and Tie-Out
- Testing and Refinement
- Release and Market Validation
- Production Operation and Evolution
Start here
Run assess first
assess is the one command to run before anything else. It scores your repository against all five controls 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 controls — your code is processed in the moment and never stored.
Work the prioritized plan
You get a score per control 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.