# Dev Resume

> Use only on explicit request to resume or take over work when the next task is undecided. Use mak:dev-kickoff for a decided task, mak:reverse-engineering when project docs are absent, and mak:doc-audit for document-consistency audits.

- Skill: `blueclover22/dev-resume` (Agent Skill)
- Install (CLI): `npx skillmds@latest add blueclover22/dev-resume`
- Raw SKILL.md: https://api.skillmd.com/api/skills/blueclover22/dev-resume/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: blueclover22 (https://skillmd.com/u/blueclover22)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/blueclover22/dev-resume

---


# mak:dev-resume — Work Re-Entry Point

Derives, from what project documents already show, (a) how far work has progressed, (b) problems in that state, (c) one concrete next step — each backed by evidence. Owns the **inbound** side of session handoff: finding out what to do, not doing it.

Report and all user-facing output in the user's conversation language (or the project's documented language policy).

<HARD-GATE>
Diagnose, report, and route only.

Allowed: Read / Grep / Glob, read-only git commands, reproducing only the verification commands the documents actually claim (§Procedure step 3).
Forbidden: creating/modifying/deleting any file, any code change. Found defects go on the next-step candidate list — never fixed here.
</HARD-GATE>

## When to Use

Resuming in-progress work, or picking up a handed-off session, when the next concrete task itself is undecided.

Route elsewhere:

| Situation | Go to |
| :--- | :--- |
| No project documents at all | `mak:reverse-engineering` |
| Document drift dominates over "what's next" | `mak:doc-audit` |
| The roadmap/phase structure itself is stale | `mak:roadmap-planning` |
| The task is already decided | `mak:dev-kickoff` |

## Scope Rule

Fixed entry points only — inherits `mak:doc-audit` §Scope Rule; never a full codebase scan.

Entry points: the roadmap's SSOT status (located per the `mak:roadmap-planning` save-path priority), design docs (located per the `mak:design-doc-template` save-path rule) — their meta `Status` values and §5.0 `Step → verify` status column, recent commits, uncommitted changes — plus the paths/symbols those documents cite.

## Procedure

1. **Confirm current position** — read the entry points above. The design doc's §5.0 status column is the stated progress: read it first and treat it as a claim, not as truth. Infer position from commits and code only where that column is missing, or where step 3 shows it contradicts the observed state
2. **Collect entry points** — trace cited paths/symbols per §Scope Rule
3. **Verify claims** — reproduce only commands that verify a claim the documents actually make (stated test counts, "clean" lint/build, etc.); read only cited code. No claim → no command
4. **Report diagnosis** — see §Report
5. **Present next steps** — 2–3 candidates, ask the user to choose. If a document already designates a next item, it must be one of the candidates

## Report

Reuse `mak:review-report` grades — 🔴 Critical / 🟡 Warning / 🟢 Pass / 📝 Note — no new grades. Every finding pairs a document's claim with the observed fact. Distinguish "no issue found" from "could not verify".

| Grade | Item | Location | Evidence (claim vs. observed) |
| :--- | :--- | :--- | :--- |

## Core Principles

- **Never fix** — defects become next-step candidates, not edits
- **No unsupported findings** — every finding cites its evidence
- **Candidates are always plural** — never present a single forced next step
- **Respect existing designations** — a next item the documents already name is never displaced by newly found issues; present it alongside them