Skip to content

Template: Execute A Roadmap Slice

Status: Reference

Use this prompt when starting or resuming roadmap work. It keeps the agent inside one executable slice and prevents broad "keep going" requests from turning into opportunistic release tooling, docs cleanup, or adjacent refactors.

If the personal Codex skill $twomore-slice-mode is installed, prefer invoking that skill instead of pasting the full template. Use the template below when the skill is unavailable or when handing work to an agent that cannot load local skills.

For attended work, use the one-slice prompt. For away-mode R1 work, use the unattended R1 closure prompt below; it loops through bounded one-blocker slices until R1 is accepted or the remaining work is externally blocked.

Copyable Prompt

text
We are executing <slice id> from docs/architecture/implementation-plan.md.

Mode:
- <closure-only | implementation | investigation-only | docs-only>

Goal:
- <one-sentence outcome>

Read first:
- AGENTS.md
- docs/architecture/implementation-plan.md#<track-anchor>
- docs/architecture/roadmap.md#<track-anchor>
- docs/workflows/change-routing.md
- <slice-specific source pack, spec, or evidence doc>

Current blocker:
- <the exact blocker this session should remove>

Allowed scope:
- <paths, commands, external systems, or product surfaces>

Blocked scope:
- <explicit non-goals>
- Do not take adjacent improvements unless they block the current acceptance
  proof.

Start evidence:
- Run <targeted report/check> before editing and summarize only the relevant
  blockers.

Acceptance proof:
- <what must be true before this slice/session is done>

Verification:
- During iteration: <targeted commands>
- Before handoff: <final commands>

Stop rules:
- If the blocker is external or owner/vendor-controlled, stop after documenting
  exact evidence and next owner action.
- If a new useful issue appears but does not block this acceptance proof, add it
  to the follow-up backlog instead of implementing it.
- If the slice needs a second primary artifact, stop and propose a split before
  editing more files.

Handoff:
- Report changed files, checks run, accepted/deferred/blocker status, and the
  next exact slice or owner action.

Current R1 Closure Prompt

text
We are closing R1-3/R1-4 from docs/architecture/implementation-plan.md.

Mode:
- closure-only

Goal:
- Remove one current R1 release-readiness blocker or prove that it is external.

Read first:
- AGENTS.md
- docs/architecture/implementation-plan.md#r1-club-growth-loop-active
- docs/architecture/r1-activation-source-pack.md
- docs/workflows/release-versioning-and-ota.md
- docs/release-evidence.md

Current blocker:
- <choose exactly one blocker from yarn report:r1-release-readiness>

Allowed scope:
- Only files, EAS/env/domain actions, or evidence docs required to close that
  blocker.

Blocked scope:
- No docs reorganization.
- No generic release-tool improvements.
- No product polish, performance work, R2/R3 planning, or opportunistic
  refactors.

Start evidence:
- Run yarn report:r1-release-readiness before editing.

Acceptance proof:
- The chosen blocker disappears from yarn report:r1-release-readiness, or the
  report proves it is owner/vendor/deployment-controlled and the exact next
  action is documented.

Verification:
- Targeted command for the blocker.
- yarn report:r1-release-readiness after the change.
- yarn check only if source code changed or before pushing source changes.

Stop rules:
- Stop after one blocker is closed or proven external.
- Add adjacent findings to follow-up instead of implementing them.

Handoff:
- Include current blocker status, exact report output summary, artifact IDs if
  any, docs updated, and next owner action.

Current R1 Unattended Closure Prompt

text
Use $twomore-slice-mode for unattended R1 closure.

Work autonomously in /home/sungkyu08/Dev/twomore-v2 through the R1 closure
sequence while I am away. Start with the required startup docs, git status, and
yarn report:r1-release-readiness. Treat R1 as closure-only.

Loop rule:
- Pick one current R1 readiness blocker that can be advanced without my input.
- State the session contract for that blocker before editing.
- Only change files, preview-build/OTA state, EAS/env actions, or evidence docs
  directly required to close, prove external, split, or document that blocker.
- Run targeted verification plus yarn report:r1-release-readiness.
- Commit and push explicit paths after each completed slice when checks pass.
- Re-run the readiness report and continue to the next blocker.

Blocked scope:
- No R2/R3 work.
- No docs reorganization.
- No product polish, performance work, generic refactors, or opportunistic
  release-tool improvements.
- No production OTA, production store build, or backend deploy without explicit
  owner approval.

Hard stops:
- Stop if all remaining blockers require owner credentials, vendor-console
  changes, MFA/login, device access I have not provided, DNS/app-link hosting
  changes, App Store/Play Store action, or other external authority.
- Stop if a command asks for secrets or paid external action.
- Stop if the next step would be destructive, production-affecting, or broader
  than the active R1 blocker.
- Stop if unrelated dirty files appear and cannot be safely preserved.
- Stop if the same blocker fails three times for the same root cause.

Handoff when stopped:
- Include final R1 readiness status, each slice completed, commits pushed,
  checks run, artifact IDs or "no artifact", remaining blockers, and the next
  exact owner action.

Avoid

Do not use prompts like:

text
Keep going with the goal.
Make release readiness better.
Continue R1 until it is done.
Clean up anything you notice.

Those prompts are too semantic unless paired with the unattended R1 closure loop above. They let the agent decide scope during execution, which makes it harder to distinguish accepted work from useful but non-blocking improvements.

Markdown remains the source of truth. Run yarn docs:check before handoff.