agentsclimarketplace

M plan

Skill mapuamap/denys-fast-mskills/skills/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

Install
npx -y skills add mapuamap/denys-fast-mskills --skill m_plan

Assembled 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)

  1. 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 the m_code-context-scout agent and keep only its map.

  2. 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.
    • 08 is 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 is 01, 04, 05, 07, 08, 09. Skipped artifacts are not written09_verification.md only lists sections for files that exist.
  3. Deploy & E2E go/no-go probe. Run this whenever the task is deployable (size ≥ medium) or adds an externally-callable / browser-observable surface (the 08 trigger). 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 08 applies): 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 in 09 (and is reflected in 03/06 when 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.

  4. 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 via AskUserQuestion in 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, the Deploy & E2E readiness, Environments, Secrets & credentials, and (if 08) Browser / UI verification questions the probe could not answer on its own are MANDATORY, not optional — never assume deploy or browser access exists.

  5. Pick a kebab-case slug (max 40 chars). Echo: Slug: <slug>. Size: <tiny|small|medium|large>. Will write: <list>. If the probe found any open V-READY-* blocker, also echo: Deploy/E2E blockers: <list> so it's visible before any artifact is written.

  6. Gitignore. If .m_plan/ not in .gitignore, ask explicitly: Append .m_plan/ to .gitignore? (yes / no — I'll commit artifacts). Default yes. 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.

#FileAlways?
01architectureyes
02code requirementssize ≥ medium
03infra requirementssize = large
04implementation requirementsyes
05step planyes
06deploy plansize ≥ medium
07test plansize ≥ small
08e2e plansize = large, or task adds externally-callable surface (HTTP endpoint, UI page, CLI command, Telegram command) that integration tests cannot fully cover
09verificationyes — 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.md in dependency order. Per-step check → flip V-STEP-Sxx via Edit. Retry once on failure; second failure → [!] + stop.
  • After steps: build → test → (if 08) e2e → (if 06 and user types deploy) walk 06 like steps walk 05.
  • Log every deviation from 01–08 immediately under ## Deviations in 09 — 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–08 to shrink scope.
  • Never delete a V-* row from 09 to make it pass.
  • [~] skip needs one-line reason inline.
  • [!] blocker needs blocker description inline + row under "Blockers".
  • Commit policy follows 06_deploy_plan.md if it exists; otherwise one commit per step.
  • Deploy steps run only after the user types deploy AND all non-deploy V-* 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 05 is non-optional. A step without one = bug in the plan; fix the plan first.
  • Architecture (01) must obey .claude/rules/m_code_core.md if present, else the generic rules in templates/02_code_requirements.md.

Files in this skill

  • SKILL.md — this file
  • BLOCKERS.md — blocker question bank
  • templates/01..09 — artifact templates (use only those the size calls for)

What ships with it: 11 files

29.4 KB alongside SKILL.md

evals/

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.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.