How do I install the Resume Mission skill?

Run npx skillmds@latest add cyberuni/resume-mission in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Resume Mission safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Resume Mission?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Resume Mission free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Resume Mission?

cyberuni (@cyberuni) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Resume Mission by cyberuni — Agent Skill

Name: Resume Mission
Author: cyberuni

Resume Mission

Resume an in-progress SDD mission from its plan brief. Use when asked to 'load the plan', 'resume the mission', 'continue github-NN', or otherwise pick up an SDD .plan.md where it left off — re-establish the working method and spec context, find the next todo, and continue without relitigating settled ground.

cyberuni Updated Sep 17, 2026

File contents

Resume an SDD mission from its plan

An SDD mission is carried by a single tracked plan brief at .agents/plans/<cr-ref>.plan.md (the portable handoff artifact). The plan is the state; this skill is one convenient procedure for picking it up — any session that reads the plan can continue without it. It re-establishes context from the brief and continues the Mission Loop where it left off.

Procedure

Open the plan — create it if missing. Open .agents/plans/<cr-ref>.plan.md and read it in full: the frontmatter todos (the ordered task list; status: pending | in_progress | completed) and the body (working method, resolved decisions, findings, ## NEXT). If no plan exists (the mission was never intook), scaffold a minimal one from a basic template (frontmatter todos + a ## NEXT anchor) and start the mission from there.
Find the next action. Resume the single in_progress todo if one exists; otherwise the first pending todo whose prerequisites are met. The body's ## NEXT section names the live frontier and any blocking decisions — honor it over guessing.
Reload the working method — do not relearn or relitigate it. The plan records how this mission is run (its phase model, per-step rhythm, suite/impl conventions, which plugin or spec dirs are baseline vs fresh). Treat resolved decisions (the ## Resolved decisions block) as settled; reopen one only on new evidence, and say so.
Load only the spec context the next todo needs. For a capability sub-mission, read that capability's README.md under .agents/specs/<project>/<cap>/ plus the SDD design rules and governances it references — not the whole tree.
Continue, committing per unit. Work in the plan's stated rhythm; commit each coherent unit (Conventional Commits, one concern, tests green). Update the todo status and record any new finding or decision back into the plan as you go, so the next resume is clean.
Surface blocking decisions; never guess past them. If ## NEXT names an open decision (a scope call, an unresolved  marker), raise it before proceeding past it.

Guardrails (carried across sessions)

Reason to the correct answer, not a vote. On a contradiction, reason from the design's intent; corroboration, implementation, and recency are evidence to weigh, not ballots to tally. Fix the side that is wrong.
Spec the behavior, then build. A skill or governance is a testable capability — spec it (prose + a per-unit .feature) before or alongside building its implementation; never hand-edit an implementation as a shortcut around its spec.
Respect the baseline. Build fresh where the plan says fresh; never mutate a directory the plan marks as the untouched reference baseline.
Commit boundary. The unit of work is one co-committable change (clear message, green tests) — not the whole CR. A CR's mission lands as many commits.

---name: resume-missiondescription: Resume an in-progress SDD mission from its plan brief. Use when asked to 'load the plan', 'resume the mission', 'continue github-NN', or otherwise pick up an SDD .plan.md where it left off — re-establish the working method and spec context, find the next todo, and continue without relitigating settled ground.---# Resume an SDD mission from its planAn SDD mission is carried by a single tracked **plan brief** at`.agents/plans/<cr-ref>.plan.md` (the portable handoff artifact). The plan is the **state**;this skill is one convenient **procedure** for picking it up — any session that reads the plancan continue without it. It re-establishes context from the brief and continues the Mission Loopwhere it left off.## Procedure1. **Open the plan — create it if missing.** Open `.agents/plans/<cr-ref>.plan.md` and read it in full: the frontmatter `todos` (the ordered task list; `status: pending | in_progress | completed`) and the body (working method, resolved decisions, findings, `## NEXT`). **If no plan exists** (the mission was never intook), scaffold a minimal one from a basic template (frontmatter `todos` + a `## NEXT` anchor) and start the mission from there.2. **Find the next action.** Resume the single `in_progress` todo if one exists; otherwise the first `pending` todo whose prerequisites are met. The body's `## NEXT` section names the live frontier and any blocking decisions — honor it over guessing.3. **Reload the working method — do not relearn or relitigate it.** The plan records *how this mission is run* (its phase model, per-step rhythm, suite/impl conventions, which plugin or spec dirs are baseline vs fresh). Treat resolved decisions (the `## Resolved decisions` block) as settled; reopen one only on new evidence, and say so.4. **Load only the spec context the next todo needs.** For a capability sub-mission, read that capability's `README.md` under `.agents/specs/<project>/<cap>/` plus the SDD design rules and governances it references — not the whole tree.5. **Continue, committing per unit.** Work in the plan's stated rhythm; commit each coherent unit (Conventional Commits, one concern, tests green). Update the todo `status` and record any new finding or decision **back into the plan** as you go, so the next resume is clean.6. **Surface blocking decisions; never guess past them.** If `## NEXT` names an open decision (a scope call, an unresolved `` marker), raise it before proceeding past it.## Guardrails (carried across sessions)- **Reason to the correct answer, not a vote.** On a contradiction, reason from the design's *intent*; corroboration, implementation, and recency are evidence to weigh, not ballots to tally. Fix the side that is wrong.- **Spec the behavior, then build.** A skill or governance is a testable capability — spec it (prose + a per-unit `.feature`) before or alongside building its implementation; never hand-edit an implementation as a shortcut around its spec.- **Respect the baseline.** Build fresh where the plan says fresh; never mutate a directory the plan marks as the untouched reference baseline.- **Commit boundary.** The unit of work is one co-committable change (clear message, green tests) — not the whole CR. A CR's mission lands as many commits.

Frequently asked questions