M plan
Plan + Execute + Verify pipeline for a user-supplied task. Asks blocker/architectural questions upfront via AskUserQuestion and probes deploy/e2e readiness (real target, access, secrets, browser tooling) before generating artifacts so those blockers surface at plan time, not deploy time, right-sizes the artifact set (4–9 docs depending on task class — tiny/small/medium/large), generates plans under .m_plan/<task-slug>/, then walks them step-by-step updating verification as it goes. /goal mode is opt-in. Use when user invokes /m_plan, says "spec this out and build it", "full plan + execute", asks to plan-and-execute a substantial change, or wants a complete architect → implement → deploy → verify cycle in one skill.From its SKILL.md
npx -y skills add mapuamap/denys-fast-mskills --skill m_planAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
- runs commandsInstructs the agent to run 3 commands, including `git status` and 2 more.
SKILL.md
9.5 KB, ~2.4k tokens by cl100k_base, as published. Nobody here has run it
m_plan
Plan → execute → verify. Right-sizes the plan to the task, runs blocker questions in a single batch, executes by default (no /goal ceremony unless asked). Done is decided by 09_verification.md, not by the agent's judgement.
Inputs
$ARGUMENTS: task description. If empty, ask once and wait.
Phase 0 — Blockers + sizing (one round)
-
Scan in parallel (read-only):
git status,git log --oneline -10,CLAUDE.md,AGENTS.md,.claude/rules/*.md,infra.md,deploy.md, top-level tree, package/build manifests, existing.m_plan/. For a large or unfamiliar repo, delegate the codebase portion of this scan to them_code-context-scoutagent and keep only its map. -
Pre-classify task size by these classes:
- tiny (one file, < 50 LOC, no infra, no migration) → files
01, 04, 05, 09. - small (one module, tests required, no infra/deploy delta) → files
01, 04, 05, 07, 09. - medium (multi-module, deploy delta, no infra change) → files
01, 02, 04, 05, 06, 07, 09. - large (touches infra, migrations, or external contracts) → all 9.
08is added on top of ANY size when the task adds an externally-callable or browser-observable surface (HTTP endpoint, UI page, CLI command, Telegram command) that integration tests can't fully cover — this is the one artifact that crosses size bins (see the Phase 1 table). So a small UI change is01, 04, 05, 07, 08, 09. Skipped artifacts are not written —09_verification.mdonly lists sections for files that exist.
- tiny (one file, < 50 LOC, no infra, no migration) → files
-
Deploy & E2E go/no-go probe. Run this whenever the task is deployable (size ≥ medium) or adds an externally-callable / browser-observable surface (the
08trigger). The point is to surface the blockers that otherwise only appear at deploy/e2e time — after the code is already built — and pull them to now. Do not merely ask; actively check what you can, read-only and non-destructive, then turn every unmet precondition into an upfront[!]blocker:- Real deploy target. Identify it from
06/infra.md/deploy.md/repo ops docs/CI/compose/service files. None unambiguously identifiable for a deployable runtime → blocker. →V-READY-01. - Deploy access. Cheaply verify reachability without changing anything: host resolves (DNS), SSH host configured (
ssh -G <host>/ ssh config entry), CI/deploy command exists, registry/login reachable. Missing → blocker. →V-READY-02. - Secrets/credentials. Are the secrets the deploy + e2e login need present in the env (check presence, never values)? Missing → blocker. →
V-READY-03. - E2E vantage + browser tooling (only if
08applies): is a browser MCP actually available here (Playwright/Chrome, or macOS computer-use)? Is the target URL reachable from here (VPN/allowlist — probe with a cheap HEAD/GET if safe)? Missing → blocker. →V-READY-04,V-READY-05.
For anything you cannot safely probe from here, ask it as a mandatory question in step 4 instead of assuming it will work. Every unmet item becomes a
[!]V-READY-*row in09(and is reflected in03/06when those exist). A deployable plan with an unresolved deploy/e2e blocker is not "ready" — it ships with the[!]visible and the user must clear it or accept it as a known blocker; never plan around it silently or downgrade deploy/e2e to a localhost check. - Real deploy target. Identify it from
-
Compose blocker questions from
BLOCKERS.md. Pick only those whose answer is not obvious from the scan or already settled by the step-3 probe. Include the size confirmation as one of the questions (preset the agent's pre-classification as the recommended option). Ask viaAskUserQuestionin batches of up to 4 (if that tool is unavailable in this harness, ask in chat as one numbered list with lettered options + a recommended default, then stop and wait). Aim for ONE batch; open a second only if an answer surfaces a new blocker. When step 3 ran, theDeploy & E2E readiness,Environments,Secrets & credentials, and (if08)Browser / UI verificationquestions the probe could not answer on its own are MANDATORY, not optional — never assume deploy or browser access exists. -
Pick a kebab-case slug (max 40 chars). Echo:
Slug: <slug>. Size: <tiny|small|medium|large>. Will write: <list>.If the probe found any openV-READY-*blocker, also echo:Deploy/E2E blockers: <list>so it's visible before any artifact is written. -
Gitignore. If
.m_plan/not in.gitignore, ask explicitly:Append .m_plan/ to .gitignore? (yes / no — I'll commit artifacts). Defaultyes. Never silent.
Phase 1 — Generate artifacts
Write under .m_plan/<slug>/ using templates/. Fill from Phase 0 answers — do not leave <…> placeholders unresolved; replace with content or delete the section.
| # | File | Always? |
|---|---|---|
| 01 | architecture | yes |
| 02 | code requirements | size ≥ medium |
| 03 | infra requirements | size = large |
| 04 | implementation requirements | yes |
| 05 | step plan | yes |
| 06 | deploy plan | size ≥ medium |
| 07 | test plan | size ≥ small |
| 08 | e2e plan | size = large, or task adds externally-callable surface (HTTP endpoint, UI page, CLI command, Telegram command) that integration tests cannot fully cover |
| 09 | verification | yes — sections only for files that exist |
Single source of truth for commands: build/test commands live in 07_test_plan.md (or in CLAUDE.md if there's no 07). Every other file references — never duplicates.
Carry the probe's blockers into the artifacts. Any open V-READY-* from Phase 0 step 3 must be written into 09's ## Readiness section as [!] (and into 03/06 blockers when those files exist) — not dropped. The plan is allowed to proceed with open readiness blockers, but they stay visible and block DONE.
After writing, list paths + one-line summary each. If any V-READY-* is [!], restate those deploy/e2e blockers right above the approval line so the user sees them before approving. Ask: Approve? (yes / edit <file> / stop). Max 2 edit rounds; on the 3rd, ask Continue editing or accept and move on?.
Phase 2 — Execute (default: direct walk; /goal opt-in)
Execution semantics are identical to m_plan_implement Phase B. Single source of truth — re-read that skill's Phase B section. Summary:
- Walk
05_step_plan.mdin dependency order. Per-step check → flipV-STEP-SxxviaEdit. Retry once on failure; second failure →[!]+ stop. - After steps: build → test → (if
08) e2e → (if06and user typesdeploy) walk06like steps walk05. - Log every deviation from
01–08immediately under## Deviationsin09— do not reconstruct at end. - Before declaring DONE: final V- sweep.* For every still-
[ ]row, attempt a deterministic check from current state; flip what passes.
Opt-in /goal mode — if the user said "use /goal" or task is large + multi-session, emit the line:
/goal Complete every checkbox in .m_plan/<slug>/09_verification.md. For each, run the cited command, paste output into the transcript, flip [ ]→[x]. Stop after <N> turns and explain residual blockers.
…and let the user run it.
Rules during execution
- Never edit
01–08to shrink scope. - Never delete a
V-*row from09to make it pass. [~]skip needs one-line reason inline.[!]blocker needs blocker description inline + row under "Blockers".- Commit policy follows
06_deploy_plan.mdif it exists; otherwise one commit per step. - Deploy steps run only after the user types
deployAND all non-deployV-*are[x]/[~].
Phase 3 — Final report
When execution stops (success or partial), re-read 09_verification.md from disk (including ## Deviations) and emit:
Changed: <files touched, grouped>
Verification: <commands + results>
Deviations: <copy verbatim from 09's ## Deviations — or "none">
Skipped checks: <list with reasons>
Risks: <residual>
Next smallest step: <one action>
Plan: .m_plan/<slug>/
Sized as: <tiny|small|medium|large>
Files written: <comma list>
Intentionally skipped (by sizing): <comma list — covered by CLAUDE.md / m_code_core.md / deploy.md>
If any V-* is [ ] or [!]: status is NOT DONE. Report the specific blocker. Never close the goal by lying.
Rules
- No secrets / real tokens / prod hostnames in any artifact.
- Never overwrite an existing
.m_plan/<slug>/without confirming in-turn. - Per-step check in
05is non-optional. A step without one = bug in the plan; fix the plan first. - Architecture (01) must obey
.claude/rules/m_code_core.mdif present, else the generic rules intemplates/02_code_requirements.md.
Files in this skill
SKILL.md— this fileBLOCKERS.md— blocker question banktemplates/01..09— artifact templates (use only those the size calls for)
What ships with it: 11 files
29.4 KB alongside SKILL.md
evals/
- evals.json2.2 KB
templates/
- 01_architecture.md1.6 KB
- 02_code_requirements.md2.1 KB
- 03_infra_requirements.md1.6 KB
- 04_implementation_requirements.md2.5 KB
- 05_step_plan.md1.5 KB
- 06_deploy_plan.md2.2 KB
- 07_test_plan.md2.2 KB
- 08_e2e_plan.md3.7 KB
- 09_verification.md5.1 KB
- BLOCKERS.md4.6 KB
Gives 0 of the 12 instructions most quality gates skills give in ~2.4k tokens
Counted across 1,524 of the 2,830 authors here whose files we hold, read 2026-09-06
- Read full output and check exit codein 45 of 1524, across 40 files
- Verify output confirms the claimin 44 of 1524, across 39 files
- Identify the command that proves the claimin 43 of 1524, across 39 files
- Execute the full verification commandin 36 of 1524, across 30 files
- Produce a verification reportin 34 of 1524, across 18 files
- Review git diff changesin 30 of 1524, across 16 files
- Fix build failures immediatelyin 29 of 1524, across 9 files
- Group findings by severityin 28 of 1524
- State claim only with evidencein 27 of 1524, across 22 files
- Verify regression tests with red-green cyclein 26 of 1524, across 22 files
- Run the full test suitein 26 of 1524, across 25 files
- Run test suite with coveragein 25 of 1524, across 10 files
Said here and by no other author read
- Walk step plan in dependency order
- Log deviations immediately in verification file
- Perform final verification sweep before reporting
- Scan codebase and manifests in parallel
- Pre-classify task size to determine required artifacts
- Probe deploy and e2e readiness before writing artifacts
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.