plan-todo-research

name	plan-todo-research
description	Run deep research for a PLAN/TODO/TESTING workflow, create or update all workflow docs, and persist research context under temp-research/. Use when the user invokes research mode.

Plan Todo Workflow: Research

Preferred slash command in Claude/Puku: /plan-todo-research.

You are in research mode for the Plan Todo Workflow plugin.

Start by running:

./bin/planflow research
./bin/planflow prompt research

Then create or update PLAN.md, TODO.md, and TESTING.md from the research. Identify the next open checklist item unless the user names a specific task.

Research mode must produce durable research context in temp-research/:

1. research-log.md: findings, evidence, commands run, source links, and decisions.
2. assumptions.md: assumptions, risks, unknowns, and open questions.
3. web-searches.md: search queries, source URLs, dates, and relevance notes.
4. context-summary.md: compact summary for later agent turns so raw notes do not need to be reread.

Research mode must also produce implementation-ready workflow docs:

1. PLAN.md: goal, scope, approach, references, assumptions, risks, and decisions.
2. TODO.md: granular checklist items with PLAN.md references and TESTING.md gates, ordered so an agent can complete them unattended in the sequential loop.
3. TESTING.md: verification criteria, commands, manual checks, and closing gates that are executable by the agent whenever possible.

Rules:

• Never produce git-write workflow content unless the user explicitly asks for git work. PLAN.md, TODO.md, TESTING.md, and temp-research/ notes must not instruct, script, or gate on mutating git commands such as git add, git commit, git push, git stash, git reset, git rebase, branch creation, checkout, or merge. Verification gates must depend on code, tests, imports, runtime checks, and read-only inspection, not staging or commit state.
• Design the workflow for unattended completion by the sequential loop. Avoid gates that require the user unless external credentials, production access, or an unavoidable manual approval is truly required; record those as explicit blockers.
• Do not edit implementation code in research mode unless the user explicitly asks.
• Use web search when current external facts, APIs, docs, changelogs, package behavior, or examples matter.
• Keep private chain-of-thought out of files. Save concise rationale, evidence, assumptions, and decisions instead.
• Keep temp-research/ useful but compact; summarize aggressively in context-summary.md.
• End by stating whether the item is ready for implement.