| name | xmemo-plan-project |
| description | Design or revise an evidence-gated project plan and executable Markdown plan using XMemo context and available live artifacts. Use when starting a project, turning goals or a brainstorm into PROJECT_PLAN.md and EXECUTION_PLAN.md, decomposing work into phases and acceptance gates, assigning multi-agent ownership, or correcting a plan after review. Keep proposals distinct from approved decisions and implemented progress. |
Plan a Project with XMemo
Turn intent into reviewable, executable artifacts. Follow
discover → recall → frame → decompose → gate → write → approve → checkpoint.
1. Discover the planning surface
Inspect the live project or supplied artifacts before designing the plan.
Identify canonical documentation, existing plans, architecture, test and
release commands, ownership conventions, and dirty-worktree boundaries. If the
active surface cannot inspect them, label the baseline unverified instead of
inventing commands, paths, or completed work.
Clarify whether the request needs a strategic project plan, implementation or
migration plan, release plan, recovery plan, or both stable and executable
plans.
2. Recall relevant context
Use recall_context or get_project_summary for goals, constraints, decisions,
rejected approaches, risks, acceptance criteria, and latest verified state.
Use search_memory for exact decisions or lessons. Reconcile memory with live
evidence; do not use memory as proof.
3. Frame the project contract
Define:
- problem, users, and desired outcome;
- in-scope and explicitly out-of-scope work;
- current verified baseline;
- constraints and invariants;
- success measures and acceptance evidence;
- assumptions, dependencies, and unresolved choices.
Keep unresolved choices visible in the draft. Preserve them in update_state
only when they block active work; do not silently turn them into decisions.
4. Decompose executable work
For each independently reviewable phase include objective, rationale, exact
scope, artifacts, dependencies, owner, ordered steps, verification evidence,
acceptance gate, recovery path, and handoff condition. Keep implementation,
review, merge, deployment, and production verification as distinct states.
5. Design evidence gates
Map every requirement to tests, inspection, review, deployment evidence, or
user acceptance. Add security, privacy, compatibility, data-loss, migration,
and operational controls when applicable. Read
references/plan-quality-gates.md before producing a formal plan.
6. Write Markdown artifacts
Respect repository conventions. When none exist and the user requests files,
use:
PROJECT_PLAN.md for stable purpose, scope, architecture, milestones, risks,
and success criteria;EXECUTION_PLAN.md for ordered phases, status, evidence gates, ownership, and
the exact next action.
Adapt assets/project-plan-template.md and
assets/execution-plan-template.md; do not copy irrelevant sections.
7. Review and approve
Return files changed, unresolved choices, assumptions, critical risks, first
acceptance gate, and exact next action. Keep artifacts draft until approved.
Use $xmemo-review-plan for a formal review.
8. Preserve the approved state
After approval:
- save durable decisions and constraints with
remember or update_memory;
- create only concrete near-term actions with
todo;
- save the active phase, verified baseline, blocker, and next action with
update_state;
- record material approval or a phase transition with
record_event;
- create a formal XMemo project with
project only when explicitly requested.
Do not mirror the entire plan into XMemo or mark planned work as implemented.
Read ../xmemo-memory-steward/references/memory-policy.md,
../xmemo-memory-steward/references/workflows.md, and
../xmemo-memory-steward/references/tool-routing.md for write, checkpoint, and
routing rules.
