AgentMarketMCP / SKILL 资产档案馆

目录 / 通信协作 / todo-plan

SKILL 未评级 已上架

todo-plan

--- name: todo-plan description: Plan or re-plan the work in the TODO.md task tree. Use for /todo-plan [<goal>] [--revise [<reason>]]. Turns a goal into a plan doc (docs/plans/PROJECT.md) and a proposed tree with lanes, or revises the plan at any time when it no longer fits. Only open [ ] nodes are changed; started or finished work is never touched. Shows the change and waits for confirmation. Never starts work. argument-hint: "[<goal>] [--revise [<reason>]]" --- # /todo-plan First load the `todo` core skill (tree format, scope rule and complexity, IDs, lanes, invariants), and read `../todo-add/SKILL.md` and `../todo/reference/verification.md` for how nodes are split, rated and written. If the core is not a skill, read `../todo/SKILL.md`. Never starts work and never touches code. Without `--revise` it plans; with it, it re-plans. Check git (core "Git mode"). In git mode read claims from `git show <base>:TODO.md`: the nodes of a claimed tree may be changed only from that tree's branch; anywhere else, list them as locked and leave them unchanged. Dates are `date +%F`. New roots, and changes to unclaimed trees, are written only on the base: on a `todo/` branch, show the proposal but refuse to write it and name the base. Show every proposal in full before asking for confirmation. ## Plan (default) 1. Run the invariant check. Read README.md, `docs/`, `TODO.md`, `CHANGELOG.md`, and `docs/plans/PROJECT.md` if it exists. 2. **Ask once**, at most 3 short questions, only for what the repo does not answer: the goal and its done-state, what is out of scope, and which parts can run in parallel (independent tracks). Skip any that are answered. When the goal is still unclear, read `../todo/reference/clarify.md` and apply its checklist and stop triggers. 3. Draft the plan doc `docs/plans/PROJECT.md` (not written yet; ask first before creating `docs/` if it is absent; if the doc exists, propose edits to it instead of a new draft). Keep it short, sections as `##` headings in this order: - **Goal**, **Scope**, **Out of scope**. - **Lanes**: one line each, `<name>: <what it covers>; independent of <lanes>`. A lane is a track one agent can work alone. Use `main` when there is only one. - **Decisions** and **Open questions**. - **Revisions**: empty until the first revise. 4. With an existing tree, propose only new roots (and children under open `[ ]` roots in unclaimed trees); changes to existing nodes go through `--revise`. Propose the tree with the `/todo-add` rules (scope, complexity, `Done when`, 3 levels; if it would pass 120 lines, propose roots and first levels only, with `next: decompose` where a node still needs children): each root gets `Ref: docs/plans/PROJECT.md` (only when that doc exists or is written in the same confirmation) (with a section anchor when one fits) and, unless its lane is `main`, a `Lane:` in `Links:`. Order roots so independent lanes do not `Depends:` on each other. Show IDs, complexity, lanes and one-line titles. If an RTM exists (`../todo/reference/rtm.md`: `docs/RTM.md`, else README `## RTM`), link roots that implement a listed requirement with `Ref: <rtm path>#<Req>` and show the RTM row changes with the tree; with no RTM, skip this and do not offer one more than once. 5. **Wait for confirmation.** Then write the plan doc and the tree, only what the user confirms. Lint. Do not commit; the next tree claim commits them (core "Backlog files"). ## Revise (`--revise`) Use when the user thinks the plan is not proper, at any time, even mid-tree. 1. Run the invariant check. Read the plan doc (missing: propose creating it with only `## Revisions`, asking before creating `docs/`) and the whole tree. Take the reason from the argument, or ask one question: "what is wrong with the plan?". 2. Only `[ ]` nodes change. `[/]`, `[x]` and `[!]` nodes, and anything drained to CHANGELOG, are never edited. If the change needs an active node to change, say so and offer `/todo-update <ID> --status ready` first. 3. Propose the change as a diff: nodes added, dropped, split, merged, re-rated, re-ordered or moved to another lane, and plan-doc lines changed. IDs are kept; new IDs follow the core rules; a dropped node is deleted from `TODO.md` and its ID is never reused (the Revisions line names it, which the ID rule counts). A plan-doc section the change needs (for example **Out of scope** for dropped work) is created if missing, at its place in the Plan step 3 order; other missing sections are left alone. A node with any descendant that is not `[ ]` is not dropped, merged or moved; say why. Every `Depends:` or `From:` on a dropped ID is removed or re-pointed in the same diff (I7). 4. **Wait for confirmation.** Apply, append a bullet to **Revisions** in the plan doc (`- <date +%F> · <the user's reason, verbatim> · <what changed, naming every added, dropped or moved ID>`), lint, and report the new tree. Do not commit, as in Plan step 5. The plan doc and `TODO.md` must agree afterwards. With an RTM, remove a dropped ID from its Tasks cell in the same diff and keep the IDs of moved or re-rated nodes unchanged. ## Independent design review (optional, never a required stage) For a `high` root, or one that touches security, data migration, concurrency or a public interface, offer once a design review before the first build node starts; read `../todo/reference/review.md` ("Design review") only then. Never ask for it on other roots and never block a plan on it.

模型生成摘要(rules/v1 · 2026-11-13 07:47):---
这是模型对公开材料的总结,不是官方声明,请以原链内容为准。

存档时间线

版本存档时间内容哈希内容
v12026-11-13 07:473e8ee1a5 可取

版本索引永久保留;内容副本只保留最新 1 份,更早版本仅留索引与哈希(存档时间线的证据链不会因此断裂)。

下载存档内容副本

相关资产

MCP 需 API Key

Jus MCP

# Jus MCP

任务管理
原作者:mcp-dir 来源:Smithery 仅卡片存档
MCP 需 API Key

CNVS

Free, no-signup real-time collaborative whiteboard (draw, todo, kanban) in the browser

任务管理
原作者:coderai 来源:Smithery 仅卡片存档
MCP 需 API Key

Omnier

A sales todo list that runs itself

任务管理CRM
原作者:omnier 来源:Smithery 仅卡片存档
MCP 需 API Key

Pinpal Todo

A quiet to-do list your AI can work with too

任务管理
原作者:pinpal 来源:Smithery 仅卡片存档
MCP 需 API Key

mcp-server-gitlab

基于MCP框架构建的GitLab集成服务器,提供多种GitLab RESTful API工具,支持项目搜索、任务管理、合并请求创建与审核等功能,帮助开发团队高效协作

任务管理
原作者:@ZephyrDeng 来源:ModelScope MCP 仅卡片存档
MCP 鉴权未知

mcp-github-issue

启用大型语言模型(LLM)与GitHub问题进行交互,通过将详情提供为任务,从而实现通过GitHub平台的无缝集成和任务管理

任务管理
原作者:@sammcj 来源:ModelScope MCP 仅卡片存档
纠错与举报(发现条目失效、署名有误或涉及侵权?)
提交举报 / 纠错

侵权举报经核验成立后,我们会即时下线该条目并删除已存的内容副本。