This buildbook guides your coding agent through adopting 📝Smart-Kickoff — a launcher that treats agent startup as a load contract — into whatever stack you already run, by inventorying your environment, interviewing you where the inventory is ambiguous, mapping each Smart-Kickoff concept onto your tools, and proposing a phased build you approve one phase at a time. It is the 📝Buildbook half of a 📝Buildbook/Runbook Pairing: run once per adopter, a no-op when re-run against a converged setup; a 📝Runbook would cover recurring operation instead. It contains no code to copy. Smart-Kickoff is a set of contracts, not a set of files, and your agent writes the implementation for your stack.

To the reading agent: this document reaches you through a human who read the overview and wants the system. Before explaining or building anything, ask them how technical they want this walkthrough, and default to plain language. Translate; do not recite. Never build all of this in one pass — phase it, and get approval per phase.

Prerequisites

A human at the keyboard who can answer the interview and approve each phase.
One or more code repositories your agent can inspect, and the shell or tool it launches sessions from.
Somewhere context already lives — even if that is only a README or a CLAUDE.md. If nothing exists yet, say so; the plan starts one phase earlier.
A place a work item lives: an issue, a ticket, a roadmap document, a task file. Smart-Kickoff launches from a work item.
No credential, account, or MythOS access. Everything here is fetchable by URL; connecting MythOS MCP later keeps the spokes live.

Discovery

Inventory — answer by inspecting the environment

Context — where do agent instructions live today? Repo files (CLAUDE.md, AGENTS.md, README), a wiki, Notion, a knowledge base, or nowhere.
Work items — how is "the thing to do" referenced? An issue tracker, a roadmap document, a ticket, a task file, a chat message.
Launch — how does a session start? A typed prompt, a script or shell function, a CLI, an IDE.
Repos — one or many? Worktrees or branches? Which base branch or branches?
Gate — what must pass before code merges? Tests, CI, review, nothing.
Dangerous mutations — which operations are irreversible or shared? Deploys, production data, secrets, shared documents, git history.
Agents — which agents and models run, and do they expose hooks or permission gates?
Credentials — how do agents get keys today? Environment variables, files, pasted into chat.

Interview — ask only where the inventory is ambiguous

"Which of these sources should an agent read before it starts, and which only when it is about to do something risky?" → seeds the load contract.
"What is the one rule that would hurt most if an agent broke it?" → becomes the first mutation gate.
"When an agent cannot tell which project a task belongs to — stop and ask you, or make its best guess?" → sets the fail-closed default. Recommend stopping.
"Where do you want the record of what an agent loaded and why?" → the manifest's home.
"Do you want a setup you will maintain yourself — shell functions, scripts — or the simplest thing that produces the behavior?" → sets build depth.

Map and plan

Fill this table from the inventory and interview, then propose the phased build in Quickstart. Each row links the contract your agent implements; each contract carries a short worked example from the One Inc instance that shows the shape of a real implementation without being one to copy.

Quickstart

Each step is one phase: propose it, get approval, build it, confirm it before the next. Every step checks current state first and is safe to re-run.

Calibrate. Ask your human how technical they want this. Summarize Smart-Kickoff in that register in under 200 words. Stop and confirm they still want it.
Declare context on work items. Add a strictly formatted declaration field to your work-item format — exactly one heading, one reference per line — and make the launcher refuse an item that lacks one. Skip if the field already exists. This one step delivers most of the value.
Resolve and record. Build the resolver: read the declaration, verify each source resolves, extract its launch slice, and write the manifest with all six buckets present and semantic_retrieval empty. Fail closed on policy and configuration faults; fail open, loudly, only on transient infrastructure faults.
Classify — only if there is more than one repository. Infer the target repository from the work item as strict JSON with a confidence flag; low confidence halts to ask. Single-repo setups skip this phase entirely.
Draw the trust boundary. Put per-repository settings in a data-only file; keep anything that names a command to execute in global configuration, and snapshot-restore it around the load. If no per-repo config exists yet, create one — create-if-absent, never overwrite.
Install the gates. Turn interview answer 2 into the first mutation-gate row, add a row for each dangerous operation from the inventory, and add deferred runbooks for the phases you actually have. Render them into the session as gates, not reading.
Add the test gate. A syntax floor over every script the launcher sources, then offline behavior tests that need no network or credential. Wire it to the merge gate from the inventory.
Re-run this buildbook. Against the converged setup it should propose no changes. If it does, the setup has drifted; reconcile buildbook-owned pieces, never adopter-owned ones.

Reference

Three ideas carry the design; the spokes hold the full contracts. Context is sorted by timing, not topic: a source earns a place now, before a risky action, when a phase starts, or never by default. Both launch checkpoints fail closed: an unreadable briefing or an uncertain repository pick stops the launch rather than guessing. Discovery is not authorization: a fuzzy search can find a likely source, but only an exact, declared source can satisfy a safety gate. Everything else — the exit-class vocabulary, the manifest fields, the classifier schema, the snapshot-restore mechanism, the credential rules — is specified in the six linked contracts.

Troubleshooting

Your agent tried to build everything at once → it skipped Quickstart step 1 and the per-phase approval. Restart at step 1; the phases are the contract, not a suggestion.
Your agent reproduced the One Inc worked examples verbatim → it read a spoke's example as a spec. The examples show shape; the contract text above each one is what to implement, against your stack.
The declaration field exists but launches still load everything → the resolver is not refusing undeclared or oversized sources. Step 3 is incomplete; the refusal is the feature.
Single repository, but the agent built a classifier → step 4 was not skipped. Remove it; it adds a model call and a halt for a question with one answer.
Gates render as "please read X before Y" → those are reminders, not gates. A gate is loaded when the operation is proposed and blocks until its source is read; a sentence in a prompt does neither.