How do I install the Groom Roadmap skill?

Run npx skillmds@latest add talkincode/groom-roadmap in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Groom Roadmap safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Groom Roadmap?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Groom Roadmap free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Groom Roadmap?

talkincode (@talkincode) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Groom Roadmap by talkincode — Agent Skill

Name: Groom Roadmap
Author: talkincode

Groom Roadmap

Roadmap and development-plan self-iteration (grooming). After each subtask delivery, or during periodic maintenance, check off completed items, update milestone status, backfill / split / re-prioritize subtasks, and fold newly discovered needs in via the feature checklist to keep the plan self-consistent and aligned with the checklist.

talkincode 16861f1 2.9 KB Updated Sep 17, 2026

File contents

Skill: Roadmap / Plan Self-Iteration (Grooming)

Scope: TR-F022 | Usually invoked by ../orchestrate-roadmap/SKILL.md after delivery; can also run standalone.

When to use

After a milestone subtask is delivered (PR merged or ready).
During periodic roadmap maintenance, when a subtask is too large / outdated / already implicitly done.
When implementation surfaces a new gap, new dependency, or a change in requirement boundary.

Steps

Check off delivery: change the delivered subtask - [ ] M*.* to - [x]; sync the milestone overview table and the milestone section status (planned -> in progress -> delivered; delivery means merged to main + CI passing).
Backfill learnings: based on the round's PR result / blockers,
- split follow-up work discovered during implementation into new - [ ] M*.* subtasks (keep each independently deliverable, revertible, verifiable);
- split oversized subtasks; annotate removals with the reason;
- mark items with an external dependency / pending decision as blocked with the reason.
Re-prioritize: keep M1 -> M2 -> M3 by default; adjust only when dependencies / blockers / new delivery evidence change, and explain the reason in the PR.
Align scope: route newly discovered needs through ../align-feature-checklist/SKILL.md - schedule only what maps to a TR-F; reject anything hitting TR-N001-TR-N005; never silently expand the roadmap.
Consistency check: ensure the milestone overview status <-> subtask checkboxes <-> docs/feature-checklist.md status are consistent; keep the CN/EN checklists in sync; no dangling references to deleted files / skills.
Commit: plan-doc changes go through a PR - either folded into the delivery PR or as a small follow-up PR; reference the milestone ID.

Boundaries

Only edit plan / scope docs (docs/roadmap.md, docs/feature-checklist.md and its English version, the in-session plan); do not change product code in this skill.
Do not invent tasks: every new subtask must anchor to a TR-F and be a minimal closed loop.
Do not relax guardrails: non-goals, PR-only, and quality-gate requirements stay unchanged.

Acceptance

Delivered subtasks are checked off; the milestone status table is in sync
Added / split / blocked subtasks all anchor to a TR-F and are independently verifiable
New needs are aligned via the feature checklist (CN/EN in sync); no TR-N touched
Roadmap <-> feature checklist status are consistent; no dangling references

---name: groom-roadmapdescription: Roadmap and development-plan self-iteration (grooming). After each subtask delivery, or during periodic maintenance, check off completed items, update milestone status, backfill / split / re-prioritize subtasks, and fold newly discovered needs in via the feature checklist to keep the plan self-consistent and aligned with the checklist.---# Skill: Roadmap / Plan Self-Iteration (Grooming)> Scope: `TR-F022` | Usually invoked by `../orchestrate-roadmap/SKILL.md` after delivery; can also run standalone.## When to use- After a milestone subtask is delivered (PR merged or ready).- During periodic roadmap maintenance, when a subtask is too large / outdated / already implicitly done.- When implementation surfaces a new gap, new dependency, or a change in requirement boundary.## Steps1. **Check off delivery**: change the delivered subtask `- [ ] M*.*` to `- [x]`; sync the milestone overview table and the milestone section status (`planned -> in progress -> delivered`; delivery means merged to `main` + CI passing).2. **Backfill learnings**: based on the round's PR result / blockers, - split follow-up work discovered during implementation into new `- [ ] M*.*` subtasks (keep each independently deliverable, revertible, verifiable); - split oversized subtasks; annotate removals with the reason; - mark items with an external dependency / pending decision as `blocked` with the reason.3. **Re-prioritize**: keep `M1 -> M2 -> M3` by default; adjust only when dependencies / blockers / new delivery evidence change, and explain the reason in the PR.4. **Align scope**: route newly discovered needs through `../align-feature-checklist/SKILL.md` - schedule only what maps to a `TR-F`; reject anything hitting `TR-N001`-`TR-N005`; never silently expand the roadmap.5. **Consistency check**: ensure the milestone overview status <-> subtask checkboxes <-> `docs/feature-checklist.md` status are consistent; keep the CN/EN checklists in sync; no dangling references to deleted files / skills.6. **Commit**: plan-doc changes go through a PR - either folded into the delivery PR or as a small follow-up PR; reference the milestone ID.## Boundaries- Only edit **plan / scope docs** (`docs/roadmap.md`, `docs/feature-checklist.md` and its English version, the in-session plan); do not change product code in this skill.- Do not invent tasks: every new subtask must anchor to a `TR-F` and be a minimal closed loop.- Do not relax guardrails: non-goals, PR-only, and quality-gate requirements stay unchanged.## Acceptance- [ ] Delivered subtasks are checked off; the milestone status table is in sync- [ ] Added / split / blocked subtasks all anchor to a `TR-F` and are independently verifiable- [ ] New needs are aligned via the feature checklist (CN/EN in sync); no `TR-N` touched- [ ] Roadmap <-> feature checklist status are consistent; no dangling references

Frequently asked questions