IMA AI · Resources
The AI Work
Routing Standard
Where AI work should happen — and how it moves between projects without you becoming the courier between your own AI sessions.
The Problem
You become the courier between your own AI sessions.
Once you run more than one AI project, you hit a quiet bottleneck.
Each project's AI session sees only its own slice — one codebase, one brand, one context. But real decisions cut across slices. So you discuss strategy in the project that can see everything, the AI produces something useful… and then you download the file, open the other project, upload it, and explain it all over again. Every trip loses detail. Every re-explanation drifts from the original. And the work only moves when you personally carry it.
We run an entire company on AI sessions — products, client brands, marketing sites. This standard is how work travels between them with zero hand-carrying.
The Principle
Hub and spokes.
Rule 1Discuss where the context is.
One project is the hub — it holds your full knowledge base: every spec, every brand, every standard. Anything strategic, cross-project, or standards-shaping is discussed there, because only the hub can see everything the decision touches. Discussing cross-project work in a spoke means half the picture is missing.
Rule 2Build where the ownership is.
Deliverables are built in the project that owns them — its AI session carries the right craft context: the design system, the build rules, the codebase. The hub never builds another project's deliverables. A hub that builds is a hub that is trying to do two jobs at once — and doing both badly.
Rule 3Git is the courier.
A handoff is a commit, not a file passed by hand. The substance travels in the repo where the work will happen; the task lands in the backlog the owning project already reads. Nothing moves by download-upload-re-explain. The courier is the version-control system — it does not lose detail, it does not drift, and it does not require you to be online for the transfer to happen.
Where It Goes
The routing table.
When in doubt: if the discussion needs more context than one project loads, it belongs in the hub.
| Subject | Discussed in | Built in |
|---|---|---|
| Strategy, cross-project decisions | the hub | wherever the outcome lands |
| Company standards | the hub | the hub, then synced outward |
| Content for a public page | the hub (it can see the source material) | the owning site project |
| A product feature | that product's project | same project |
| Client or brand work | that brand's project | same project |
| Anything touching two or more projects | the hub | per-project handoffs |
The Mechanism
The handoff — two artifacts, always both.
A handoff without both artifacts is not a handoff. It is a plan to lose context later.
Artifact 1
The Brief
A complete markdown file pushed into the target repo at
drafts/<deliverable>.md. It carries build notes (filenames, what to update afterwards), sanitisation rules if internal material is being adapted for public use, and the full substance at final quality. The owning session does its craft — design, code, deploy — not content archaeology.Artifact 2
The Task
One entry in the owning project's backlog, pointing at the brief. Without this, the brief sits in the repo invisibly — no one knows it is waiting. The task is what triggers the pickup. One brief = one task = one deliverable.
The pickup is one sentence. Open the owning project and say "build it from the drafts brief." Nothing else needs explaining — the session has the brief in its repo and its own rules in context. If you need to say more than one sentence to initiate the work, the brief was not self-sufficient.
Completion
The return path.
Step 1Mark it done and update records.
On completion, the owning project marks the task done and updates its own records — the hub sees completion on its next read. No courier trip required.
Step 2Delete the brief from drafts/.
The brief is deleted from
drafts/ after shipping. Nothing is lost — git history keeps every version forever, and the outcome is recorded in the knowledge base. A brief still sitting in the folder means, by itself, "not built yet." The folder is a reliable signal because it is kept clean.Step 3Anything company-wide goes back to the hub.
If the owning project learns something that matters across the organisation — a new reusable pattern, a gap in a standard — it goes back to the hub's backlog. It never stays buried in the project. One session's learning becomes the whole organisation's standard.
Non-Negotiables
The rules.
RuleA handoff without a brief is not a handoff.
"I'll explain it next session" always loses context. The brief must exist in the repo before the pickup. If it does not exist, the handoff has not happened.
RuleA brief without a task is invisible.
Both halves are mandatory. The brief without a task is an unreachable file. The task without a brief is a mystery ticket. You need both.
RuleOne brief = one deliverable.
Batch work means multiple briefs. Combining two deliverables into one brief makes them impossible to track independently. Ship one, delete the brief, then the other brief represents remaining work clearly.
RuleThe hub writes at final substance quality.
The owning project polishes for its medium — it formats, designs, codes — but does not re-decide the content. Content disagreements come back to the hub. Splitting the substance decision and the craft execution is what makes one-sentence pickups possible.
From Experience
One warning before you start.
If your site deploys straight from the repo — which most static hosts do, including Cloudflare Pages — the host publishes every file, including your drafts folder.
We verified our own first handoff and found the brief publicly reachable within minutes of pushing it. We fixed it the same hour by adding a redirect rule that excludes /drafts/*. Now it is a non-negotiable step before the first handoff in any new repo.
Before your first handoff: add a redirect rule that sends all requests to
/drafts/* back to your homepage. Cloudflare Pages uses a _redirects file at root: one line, /drafts/* / 302. Next.js static exports are safe by default — only the build output deploys.Every Handoff
The handoff checklist.
| 1 | Write the brief | Build notes + sanitisation rules if needed + full final-quality content. The owning session must be able to ship from this alone. |
| 2 | Push to drafts/ | Commit the brief to the target repo at drafts/<deliverable>.md. Git is the courier. |
| 3 | Log the task | One entry in the owning project's backlog, pointing at the brief path. Both halves — always both. |
| 4 | Pick it up | Open the owning project. Say one sentence. Ship it. Delete the brief from drafts/. |
Built for founders and teams running several AI projects at once in Malaysia — anyone tired of being the courier between their own AI sessions.
Free. No form. No email.
Companion Resource
How rules stay consistent inside each project.
This standard covers how work moves between projects. The companion standard covers the other half: how your rules stay consistent across every project, without anyone remembering to enforce them.
Pair with this
The AI Project Context Standard
How to make AI agents actually follow your company standards across every project, without anyone remembering the rules. 3 layers. 1 synced block. 0 instructions maintained by hand.
Read the standard →