• Location:

  ISSUES.md

  at the repository root; if not found, glob

  **/ISSUES.md

  ; if neither exists → create it at the repository root.
• Ultra-minimal format — one issue per entry, decomposed outputs are indented under the entry, no kanban or new carriers introduced:

undefined

💭 Un-discussed · ⏸ Discussed but not converged · 📋 Ready for development · 🚧 In development · ✅ Released

1. 💭 Statistics of tokens and TPM peaks
2. ⏸ Handling of permission management issues
   • Bottleneck: Does it refer to backend login permission or API authentication? The pain point is unclear, discuss next time
3. 📋 Daily report multi-account merged push → Target version v1.2
   • Task: Merge multiple accounts into one message per customer
   • Acceptance criteria: ① Merged into one message ② Consistent sum of amounts ③ Single-account customers are not affected

undefined

• User's one-sentence idea → record the original content into the pool, mark with 💭. No processing or in-depth discussion, finish after recording (except if the user requests breakdown on the spot).
• Relevance check is mandatory when adding to pool: Scan existing entries in the pool, point out similar/duplicate/related ones immediately — "This is similar to #3, merge or keep separate?" Blindly appending is unqualified recording.

• If multiple issues are found to stem from the same requirement → provide reasons and suggest merging. Merge only after user confirmation; retain original sentences after merging (note sources under the merged entry).

1. Do homework before asking questions: Documents and code are all materials, no fixed order, judge what to read based on the actual situation of this repository — for repositories with thick documents (with PRD / plan / launch records), usually build a map from documents first, then verify with code; for repositories with thin documents, read code directly. Key check: Is this issue an extension of an existing PRD / plan? Inconsistencies between documents and code are discoveries themselves and should be marked.
2. Guide users to reveal real needs: The content written in issues is often a "solution" rather than a "need" (behind "create a unified entry" may be "tired of remembering three addresses", or "need to share with others" — the correct solutions are different). Only ask users questions that cannot be answered by homework (intent / pain points / boundaries); ≤3 questions per round, usually converge within 2 rounds.
3. Judge type, with only one criterion — whether it can be delivered in one version:
   • Yes → simple task
   • No → complex plan (rolling)
   • Deliverable is not code (tutorial / document / process) → document-type task, still write a paragraph plus acceptance criteria, except the output in v3 is replaced with documents

• Simple task: Write a paragraph plus 3~5 acceptance criteria directly under the pool entry, mark with 📋 → guide: "Start development directly (v3)" or "Go through the trio first (v2)".
• Complex plan: "One-sentence direction + break down into tasks for the next batch (1~3 versions) + leave a few lines of follow-up direction intentionally unbroken down". Place it in

  docs/plan/

  as a file, and link it in the pool. The end of the plan must remain vague — break down the next batch only after delivering one batch, avoid planning all at once.
  • Large-scale projects (rolling in multiple batches, need to clarify "why to do it / what constitutes completion / what steps to take") → read

    references/plan-writing.md

    of this skill (seven-step framework plan process, original plan-report has been merged and retired), write the content according to it; conclusions clarified in this round of decomposition (real needs, direction, next batch of tasks, draft version number) are directly used as input for its Stage 1, do not re-ask answered questions. Use this skill's

    tools/md2html.py

    to convert md to HTML.
  • Lightweight projects (can be broken down in 2~3 versions) can directly use the small project skeleton in plan-writing to create a simplified version, no need to go through all seven steps of confirmation.
  • Double-check: If the Stage 0 scale screening in plan-writing identifies "small" (<1 week and only one phase), it means the type judgment is wrong — exit the plan process, and switch to simple task delivery.
• Draft version numbers are assigned in this action (which task goes to which version), follow the repository's existing versioning convention (learn from plans / launch records); branch creation (v3 development start) and tagging (v3 release) are not included.
• Trio grading: Simple tasks do not need the full set, acceptance criteria are sufficient; complex tasks with interfaces need to enter v2 (prd-test-writer; interface exploration is handled separately by design-exploration).

• If the issue is still vague after two rounds of discussion, stop forcing decomposition: Record the bottleneck questions under the entry, mark with ⏸ and put it back into the pool.
• The goal is to solve problems, pending if decomposition is incorrect, avoid making fake plans to wrap up.

• The call is only completed after the pool status is updated.
• End with a guiding sentence: Which entry is ready for development / which entry goes to v2 / which entry is pending for the user to clarify.

• ❌ Do not write PRD / test cases / design drafts — that's v2's work, this skill's output is v2's input
• ❌ Do not write code, create branches, release versions, or tag
• ❌ Do not set priorities — the user always decides which to do first, you only present facts (dependencies, approximate scale)
• ❌ Stop digging into technical solutions when it's "enough for type judgment and boundary definition", further details are v2's work
• ❌ Do not introduce new management carriers (kanban / database / new formats) — the pool is just one markdown file