agentleFS
richkuorichkuo/rk-skills/skills/milestoneplan/SKILL.md

milestoneplan

Skill50 starsChanged 6 days agoMITView on GitHub

Use when the user wants a milestone's execution plan shown as a table — "milestoneplan v1", "/milestoneplan", "show the plan for v1". Read-only - reads every issue in the milestone and renders one table of issue number, description, complexity, dependencies, validate/build model and effort, plan, plan effort, and first-review trigger. Never edits an issue and never launches a run. Stage 6 of the new-app-pipeline.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Every absent field renders *missing*, never blank or a guessed default.

    line 40
  2. Distinctive:

    After the table, offer in one line each only the actions that apply, and launch neither unprompted:

    line 48

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

milestoneplan

Show a milestone's execution plan as one table. This skill never writes: no issue edits, comments, PRs, or Workflow runs. Fixes belong to execution-plan-review; the run belongs to milestone-workflow.

Input

A milestone title (v1, v1-Desktop-core-call-loop), matched loosely on prefix, and an optional skip list: issue numbers the user plans to pass to milestone-workflow as skipValidate (or "all"). Existing titles with spaces still match; quote them in every gh call and in any milestone: filter link, and when you name a milestone filter to the user, quote a title that has spaces. With no input, or when two titles match, list the open milestones with open/closed counts and ask which.

Steps

1. Read the milestone

gh api "repos/{owner}/{repo}/milestones?state=all&per_page=100" --paginate --jq '.[] | "\(.title) [\(.state)] — open:\(.open_issues) closed:\(.closed_issues)"'
gh issue list --milestone "<title>" --state all --limit 500 --json number,title,state,body

state=all and --paginate with per_page=100 are required. If the issue count equals --limit, re-fetch at a higher limit until a fetch returns strictly below its own limit. Strip \r from bodies, then parse the [C<score>] title prefix and the ## Execution block: Depends on, Runs after, build model, effort, plan first: (also read the legacy fableplan first:), PR review:, and the optional Validate model:, Validate effort:, Plan model:, and Plan effort: lines.

2. Render the table

Output is exactly one pipe-delimited markdown table, one row per issue ordered by number, capped at these 8 columns:

#DescriptionCDeps/AfterValidateBuildPlanReview
  • Description — the title with the [C<score>] prefix stripped, truncated to ~30 characters.
  • C — the score from the title prefix.
  • Deps/After — <depends> / <after>, issue numbers without #, none rendered as — (e.g. 12, 13 / —); never infer edges from prose. When every Runs after is none, drop the / — suffix and say so in the note.
  • Validate — <model> · <effort>. The model comes from the score band unless a Validate model: line stamps Fable 5.1, Opus 5.5, or a Codex CLI harness; the effort is the band default unless a Validate effort: line stamps one. A Codex CLI validate renders like a CLI build, e.g. Astra · low (Codex CLI, gpt-6-astra); a Cursor CLI validate stamp renders blocked (validate runs only on the Codex CLI). Band defaults: Opus 5.5 · medium at [C0]–[C24], Opus 5.5 · high at [C25] and above (validate-issue step 6 is the authority; a missing prefix routes as Opus high). A stamped model or tier renders as the effective value plus (stamped), e.g. Fable 5.1 · low (stamped); the clamp follows the effective model and validate-issue step 6, so the pipeline clamps an Opus validate at low to Opus 5.5 · high (stamped low → high: Fable-only tier), runs an Opus validate at medium, high, or xhigh as stamped or as the band default, and applies no clamp to a Fable validate at any tier. With a skip list, a listed issue renders skipped (run arg) when no open in-milestone predecessor (Depends on or Runs after), missing [C..] prefix, or missing Execution block predicts a fallback; otherwise it keeps the route with (listed; validates: <reason>).
  • Build — the stamped <model> · <effort>, e.g. Opus 5.5 · high. An external harness renders as <Name> · <effort> (<harness>), e.g. Luna · max (Codex CLI) or Grok · high (Cursor CLI, cursor-grok-4.6-high) when the stamp carries a model id. max is Codex CLI-only, so a Cursor row stamped max renders the clamp the pipeline applies, e.g. Grok · xhigh (Cursor CLI, stamped max → xhigh). A Claude build runs only at high, so a Claude row stamped any other tier renders the clamp, e.g. Opus 5.5 · high (stamped xhigh → high: Claude builds run at high only).
  • Plan — Yes · <model> · <effort> when plan first: is Yes: the model is the stamped Plan model: with (stamped), else Opus 5.5; the effort is the stamped Plan effort: tier with (stamped), else the default: xhigh on Opus 5.5 when the score is 85 or higher (or the title has no score) and high below 85. A Fable plan always renders high; a Fable plan stamped another tier renders high (stamped <tier> → high: a Fable plan runs only at high). An Opus plan stamped low renders the clamp the pipeline applies, high (stamped low → high: Fable-only tier). Plain No when stamped No; a Plan model: or Plan effort: line on a No issue renders No · <stamp> (inert — no plan stage runs).
  • Review — the first-review trigger from the validate-issue step 6 first-review table (a missing prefix takes its heaviest row), unless PR review: stamps an explicit @claude <model> review effort:<tier> trigger. Render a stamped bare @claude review effort:<tier> as @claude opus review effort:<tier>; a stamped bare @claude review with no tier, and a stamped @claude opus review with no tier, render as @claude review (stamped); a line that names the standard @claude trigger in prose takes the band. Render a stamped haiku as @claude sonnet review. A stamp that matches no admitted row of fix-pr-review-loop step 1 renders as the band trigger with (ignored stamp: <stamp>). Append a parenthetical only for a real caveat (e.g. may close with no PR).

Every absent field renders missing, never blank or a guessed default. An issue with no ## Execution block is missing across the Execution-derived cells, with a note line that the pipeline builds it from the validated score band's defaults (no prefix routes as band 3).

After the table, print one note line covering: the Validate factoring above (validate-issue step 6 is the authority); rows whose stamped Validate effort or Plan effort was clamped; a run started with keepStamps: true keeps every stamp and skips the rescore raise below; with a skip list, that skipped (run arg) is a prediction: the run's skip-check still checks the evidence, the edit history, and the base branch at run time, and validates the issue normally when any check fails; rows built on an external CLI harness (the pipeline drives them through cli-dispatch under an Opus driver, and a rescore keeps the harness); rows whose stamped Build model or Effort diverges from the band default, naming the band value (informational: when validation confirms a higher score at run time, the pipeline raises each line below the new band default, keeps every stamp at or above it (a Fable 5.1 build or a CLI harness keeps model and effort) per validate-issue/issue-editing.md, and the orchestrating session restamps those merged values); and anything uniform that was dropped.

Print nothing else: no verdict, findings, wave plan, or cost projection.

3. Hand off

After the table, offer in one line each only the actions that apply, and launch neither unprompted:

  • Stamps missing or wrong → execution-plan-review (it owns Execution-block edits).
  • Ready to run → milestone-workflow (it presents its own run plan before dispatching).

Failure modes

SituationDo this
Milestone has no issuesSay so; there is nothing to tabulate
Milestone is closedStill render

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.