Vague Ideas to Shippable Tasks: issue-pool for Agents

Where this fits

A developer drops a half-formed idea into the chat: "We should add some export feature, maybe CSV." Without a process, that thought evaporates or spawns a ticket nobody can act on. issue-pool gives your agent a disciplined pipeline: capture the raw thought, merge duplicates, decompose ambiguity through conversation, and convert it into either a simple task or a multi-step plan — all tracked in a single ISSUES.md at the repo root. No new tools, no kanban board.

Why agents benefit

• Separates problem definition from solution implementation. The agent outputs a clear problem statement, not a premature design — avoiding the classic failure of "solving" a problem the user never had.
• Enforces a binary conversion rule. "Can one version deliver it?" Yes → a simple task with 3–5 acceptance points. No → a framework plan in docs/plan/ following a seven-step structure. No middle ground.
• Has an explicit failure mode: pending. If two discussion rounds leave the issue fuzzy, the agent records the blocker and returns the item to the pool — it cannot fabricate a fake plan to appear productive.
• Surfaces the real need. Instead of accepting a proposed solution at face value, the agent asks what problem it solves, revealing the underlying requirement.
• Scopes itself strictly. It knows what it's not for: UI design, PRD writing, live-feature changes, prioritization. This prevents scope creep and routes work to the right skill.

Practical scenarios

Scenario 1: Capturing a drive-by idea. User says "记个issue: 加个数据导出功能". The agent records the raw words verbatim, checks for related pool entries, and flags merge candidates before moving on.

Scenario 2: Decomposing a vague epic. User says "拆解 #12" — an issue about "improving onboarding". The agent asks targeted questions to reveal whether the real need is fewer form fields, better tooltips, or a faster first-run experience, then splits it into shippable tasks.

Scenario 3: Writing a framework plan. User asks for a "v1.0 计划" covering a multi-version feature. The agent determines it can't ship in one version, writes a framework plan to docs/plan/ covering why, what "done" means, and the step sequence — deliberately leaving the tail fuzzy for the next batch.

Add it to your agent workflow

Install it with:

npx skills add yunshu0909/yunshu_skillshub --skill issue-pool

Then trigger it naturally: "过一遍池子" (review the pool) or "这个 issue 怎么做" (how should we approach this). The agent loads ISSUES.md (creating it if missing), walks through the five actions, and produces tasks or plans. For the full workflow and edge cases, see the skill's page at https://www.openagentskill.com/skills/yunshu0909-issue-pool.

Compare before adopting

Before committing, compare: (1) Quality signals — does the skill actually enforce the five actions, or is it a thin prompt wrapper? (2) Maintenance freshness — check the repo's commit history; 753 stars don't guarantee activity. (3) Alternatives — kanban-style skills or generic project-manager agents may offer more UI but less discipline. (4) Workflow fit — this skill assumes a v1→v2→v3 paradigm; if your pipeline doesn't consume tasks in that shape, you'll need to adapt.

Why it is worth tracking

The 753-star count and the author's explicit philosophy — "the only currency is task" — signal a mature, opinionated tool rather than a weekend experiment. The skill encodes a genuinely hard agent capability: knowing when not to produce output and instead ask more questions. Track it if you're building agents that manage real product backlogs, and re-evaluate when your agent faces multi-version roadmaps where rushing to a plan creates more debt than clarity.