M plan
Claude Code plugin: m_* toolkit (m_plan plan->execute->verify, deploy/infra commands, Playwright full-test loop, m_code quality framework)
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.
One thing 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.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
9.5 KB, 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)