Reference

The prompt library & reference

Everything you paste, in one place: the label, status, tier, and decision vocabulary the prompts depend on, a worked example, and answers to common questions. Each prompt block is copy-safe; paste it verbatim into your agent session.

Prompt library

Two prompts, Set up and Launch, are all you need to begin. The rest keep the template current and the run under your control.

Set up to begin

Pull the template into your repo and fill in MISSION.md. Paste into an agent session in your project repo.

Fetch the autonomous-kickoff template from https://github.com/pedrofuentes/autonomous-kickoff — download all files from the template/ directory into this project's root (you'll get MISSION.md plus docs/KICKOFF.md, docs/ORCHESTRATION.md, docs/CONTINUOUS-OPERATION.md, docs/BRIEFS.md, and docs/VERSION). Then read docs/KICKOFF.md. Scan my project and auto-fill everything you can in MISSION.md (name, repo, stack, package manager, test runner from manifests/config); then ask me — in one batch — for the concrete facts you can't infer (MVP, security/auth, harness pre-answers, what's pre-authorized vs. gated); and for the vision-level fields (mission, target users, success vision), be a thought partner — propose a concrete draft from what you found + light research, ask me a few focused questions, and refine to my approval (help me sharpen it, don't just collect; don't invent product scope). Show me the filled MISSION.md for confirmation. Do NOT start building yet.

Launch to begin

Once MISSION.md looks right, start the build. Paste into a fresh agent session in the repo.

Read docs/KICKOFF.md (your operating instructions) and MISSION.md (this project's brief), then begin Phase 0. Work continuously until the current milestone's Definition of Done is met, then open the next-milestone Decision gate and continue on approval; only stop for a HUMAN-REQUIRED gate or when the project is complete.

Prefer a single paste? Use Set up and append: "…then, once I confirm MISSION.md, immediately read docs/KICKOFF.md and begin Phase 0."

Update maintain

Adopt a newer template version between sessions.

Fetch the latest autonomous-kickoff template from https://github.com/pedrofuentes/autonomous-kickoff — read its template/docs/VERSION and compare to my docs/VERSION. If I'm behind, show me the CHANGELOG.md entries between the two versions, then update docs/KICKOFF.md, docs/ORCHESTRATION.md, docs/CONTINUOUS-OPERATION.md, docs/BRIEFS.md and docs/VERSION from template/docs/* (they're generic — nothing project-specific to preserve) and run any Migration steps the changelog lists for those versions. Leave my MISSION.md untouched — but if a Migration step requires a MISSION.md change (a new section, or the §9 schema change in a MAJOR bump), don't edit it; hand me a checklist of those manual follow-ups and flag that the updated docs may reference brief sections/knobs I haven't added yet. Show me a diff summary before applying, then re-arm the continuous-operation watchdog (see CONTINUOUS-OPERATION.md) so work resumes.

Migrate maintain

Adopt a newer template version mid-run, while an agent is already building. Paste into the running session.

Migrate this project to the latest autonomous-kickoff template, safely and mid-run. (1) First read and record my current docs/VERSION (if it's absent, treat my version as pre-1.0 / unversioned). (2) Fetch https://github.com/pedrofuentes/autonomous-kickoff and overwrite docs/KICKOFF.md, docs/ORCHESTRATION.md, docs/CONTINUOUS-OPERATION.md, docs/BRIEFS.md and docs/VERSION from its template/docs/*; leave MISSION.md untouched. (3) Read CHANGELOG.md and follow the Migration steps from my recorded old version up to the new one — apply them additively, without disrupting in-flight work: keep all current cards, worktrees, and the open increment as they are; create any missing board Status options and labels; adopt the new comment/identity and decision rules; and apply new phase gates only to work not yet started. Any Migration step that needs a MISSION.md edit (a new section, or the §9 tier-matrix schema in a MAJOR bump) — don't touch MISSION.md; hand me a checklist of those manual follow-ups and flag that the new docs reference brief sections/knobs I must add for them to fully resolve. (4) Re-read the docs, record the new docs/VERSION in PLAN.md, re-arm the watchdog, then continue the build from where you left off — do this at the next safe point (after the current PR is opened) and report a one-line summary of what changed.

Continue steer

Fallback nudge for when no live session is open to catch a floated idea — after a stop or a closed CLI. (In a live session the agent auto-captures a new direction.)

Continue the autonomous build. Re-read docs/KICKOFF.md and MISSION.md, check the GitHub Project board, and if the watchdog isn't armed, re-arm it (see Starting & restarting the heartbeat in CONTINUOUS-OPERATION.md). If the current milestone still has ready or in-progress work, resume it. If a milestone just shipped (board empty, Definition of Done met), propose the next ROADMAP.md milestone as a DECISION: issue, @-mention me, and continue on my approval or the §9 time-box. If I've added a new direction in ROADMAP.md/MISSION.md, use that. Don't stop while ready work remains.

Status read-only

A "where are we?" check-in that changes nothing.

Status check — read-only, change nothing (no commits, no board edits, no gates). Give me a one-screen summary: the current milestone and its Definition-of-Done progress; board counts (Todo / In Progress / Blocked / Pending Decision / Done) and any cards waiting on me (needs:decision / blocked); open high/critical security alerts or detected secrets; what's in flight (worktrees / open PRs / latest Sentinel verdicts); the template version from docs/VERSION; and the single next action you'll take.

Pause control

Stop the autonomous loop on demand.

Pause the autonomous build. List active schedules and stop the watchdog (manage_schedule action=stop id=<id>); if Tier-2 is enabled, disable the agent-tick workflow (Actions tab → Disable). Record where you are in PLAN.md, leave open PRs, worktrees, and the board as-is, start no new work, and tell me exactly how to resume.

Resume control

Re-arm the heartbeat after a pause, crash, or closed CLI.

Resume the autonomous build. Re-read docs/KICKOFF.md and MISSION.md, restore any ready labels you froze, re-arm the Tier-1 watchdog (manage_schedule action=create interval=20m prompt=<the watchdog prompt in CONTINUOUS-OPERATION.md>) and confirm it's listed (manage_schedule action=list); re-enable the agent-tick workflow if you use Tier-2; then continue from the board.

Manual fallback no fetch

If the agent can't fetch, clone and copy the template by hand, then fill MISSION.md and paste Launch.

git clone https://github.com/pedrofuentes/autonomous-kickoff.git /tmp/ak
cp /tmp/ak/template/MISSION.md ./MISSION.md && cp -r /tmp/ak/template/docs ./docs && rm -rf /tmp/ak

Worked example: a tiny CLI

Proof it's product-agnostic: a minimal MISSION.md for a one-command CLI published to npm. Only the load-bearing fields are shown; the rest follow the template defaults.

slugify-cli MISSION.md

Then, in a fresh session: Read docs/KICKOFF.md + MISSION.md, begin Phase 0.

# MISSION — slugify-cli

## 1. Identity & mission
- Project name: slugify-cli
- Repo: yourname/slugify-cli
- Cofounder handle: @yourname
- One-line mission: A zero-dependency CLI that turns any text into a URL-safe slug.
- Target users & the problem: Devs who want consistent slugs in scripts/CI without a web tool.
- Success vision: the go-to npx one-liner for slugs.

## 2. Product shape
- Product type: CLI
- Hosting / distribution: npm package (npx slugify-cli "Hello World" → hello-world)
- Backend? None.

## 3. Tech stack
- Language: TypeScript · Package manager: npm · Test runner: Vitest

## 4. MVP scope (v1)
1. slugify "<text>" prints the slug
2. flags: --sep <char> (default -), --lower/--no-lower
3. reads from stdin when no argument is given

## 5. Security, privacy & data
- No auth, no network calls, no data collected. Network allowlist: N/A.

## 7. Harness pre-answers
- Coverage threshold: 90 · Sentinel: B (CI) + A (dev)
- Git identity / AI attribution: <fill in>
- NEVER: publish a release with failing tests.

## 8. Definition of Done
- npx slugify-cli "A B" prints a-b from the published package; README has usage + examples.

## 9. Authorization
- Tiers per template §9. auto: the §3 deps + the npm-publish CI workflow. human-required: the npm publish token + the first npm publish of each release. Default time-box 24h; risk tolerance balanced.

Vocabulary

The exact names the prompts depend on. Reuse them verbatim: the agent and the board both parse these, and synonyms break the contract.

Labels

Label	Meaning
needs:decision	A card is waiting for the cofounder to answer a `Decision:`.
decision:approved	The cofounder approved. Applied by the cofounder, never the agent.
decision:changes	The cofounder requested changes to a proposal.
blocked	A human must perform an action (a toggle, a token, a scope) before work proceeds.
security	A Dependabot / code-scanning / secret-scanning finding. High/critical preempt the queue.
claimed:∗	An agent has atomically claimed this card. Created on the fly when claiming.
ready	Dependencies are merged; the card is workable.
sentinel:important	A Sentinel 🟡 follow-up to resolve before the milestone signs off.
sentinel:minor	A Sentinel 🟢 nit.
flaky	A known-flaky test, tracked.
bug:confirmed	Intake triage: a reproduced, real defect.
polish	Intake triage: a real but non-blocking improvement.
stale	Intake triage: not reproducible / already fixed / out of scope.

Board Status

A Projects-v2 single-select, not labels. Setting it needs the project token scope.

Status	Means
Todo	Seeded on the board, not started.
In Progress	A worker has claimed it and is building.
Blocked	A human must act before it can move.
Pending Decision	Awaiting a `Decision:` answer.
Done	Merged / item complete; the issue is closed.

Authorization tiers

Every gated action carries one (MISSION.md §9). Most things are auto.

Tier	Behavior
auto	Do it now, no gate.
auto-with-audit	Do it, and record an ADR in `DECISIONS.md`.
time-boxed	Propose on the board, keep working elsewhere, auto-proceed after the window if no objection.
human-required	Do not implement until the cofounder approves.
never	Refuse: the NEVER list and the harness one-way doors.

Decision directives

The cofounder answers a gate with a comment whose first line is one of these.

First line	Effect
Decision: approved	Approve the proposal as-is.
Decision: option <X>	Pick a listed option.
Decision: changes — <…>	Request changes; the agent revises and re-posts.
Decision: hold	Stay paused.

Agent comment marker

The agent self-signs every issue/PR comment it posts with , and never applies decision:* labels. So a self-signed comment is the agent's own (not a directive), and a decision:* label is trusted via its labeled-event actor — fully under a distinct agent identity, and bounded-trusted in attended single-operator mode.

FAQ

Do I need to keep my laptop or CLI open?

Only for Tier 1. The in-session watchdog fires while your agent CLI session is open and resumes the build if it idles. For machine-off, fully unattended operation, enable Tier 2: a scheduled GitHub Actions cron dispatches the Copilot cloud coding agent with Sentinel-in-CI, so no laptop is required.

What exactly is Sentinel?

Sentinel is the independent code-review gate that ships inside agents-template, the harness this runs on. Its rule is coder ≠ reviewer: the agent that wrote a change never approves it. Sentinel returns APPROVED, CONDITIONAL (non-correctness, non-security follow-ups only), or REJECTED, and runs both as a dev-time sub-agent and as a required CI check.

How is this different from just prompting an agent to "build my app"?

A one-shot prompt has no review, no memory, and no follow-through. autonomous-kickoff adds the system around the agent: a fleet of specialists, a GitHub Project board as the work queue and heartbeat, artifact-gated phases, test-first development with an independent Sentinel gate on every PR, continuous operation across sessions, and a machine-verified Definition of Done. The agent keeps going until that is met.

Does it actually delegate, or does the Lead just do everything itself?

It delegates by construction. Every gate artifact — research, the PRD, UX, architecture, and the test/QA suites — is authored by a specialist sub-agent, never the Lead (producer ≠ Lead), and a different sub-agent red-teams it. A per-gate self-check records both before the gate passes, and the watchdog audits the delegation ledger and flags a Lead-solo collapse if the Lead authored its own work — so implementation is never the only phase that gets delegated.

What's the relationship to agents-template?

agents-template is the harness: the quality rules (TDD, worktrees, the Sentinel gate). autonomous-kickoff is the mission layer on top that turns a goal into a shipped product. Phase 0 of the kickoff bootstraps the harness, and that bootstrap is isolated to a single paragraph, so swapping to a different harness is a one-section change.

Is it safe to run unattended?

That's the design goal. Unattended runs use a distinct agent identity so a decision can't be forged; untrusted input (issues, PRs, comments, web pages, dependencies) is treated as data, never instructions; every action is bounded by an authorization tier; one-way actions (force-pushing main, weakening branch protection or a scanner, deleting data) are never; merges go through the Sentinel-in-CI gate; security scanners run continuously; and a kill switch stops it on demand.

Does it only build web apps?

No, it's product-agnostic. The operating manual assumes no product type, stack, host, or auth; everything specific lives in your MISSION.md. The same prompt builds a web app, a CLI, a library, a service, or a bot. See the slugify-cli example above.

Which AI model or agent does it need?

It's agent-agnostic: it runs in whatever capable agent runtime you launch it in, and uses the Copilot cloud coding agent for unattended Tier 2. In Phase 0 it probes its own delegation capability (full / flat / none) and degrades gracefully, falling back to Sentinel-in-CI as the enforced reviewer when it can't spawn a live sub-agent.

How do I keep a project up to date with the template?

Paste the Update prompt between runs, or Migrate mid-build. Both read your docs/VERSION, compare it to the latest, show you the changelog entries between the two, and apply the listed migration steps, leaving your MISSION.md to you. Versioning is SemVer mapped to the prompt contract; releases are tagged vX.Y.Z.

What do I actually have to do as the human?

Fill in MISSION.md (the Set up prompt does most of it with you), provision an agent identity or opt into attended mode, then answer gate decisions when you're @-mentioned. You're the cofounder and the unblock path; the agent does the building.

How do I steer it toward a new idea or goal?

Just talk to it. Float an idea in a live session — at a milestone boundary or mid-build — and the agent treats it as a first-class trigger: it shapes the idea with you, confirms it, records it to your ROADMAP.md / MISSION.md, and continues, with no special prompt to paste. Casual musing is shaped and confirmed before it becomes committed scope, and a mid-build idea is queued so it never derails the active milestone. When no live session is open to catch the idea, the Continue prompt is the fallback.