ideating

name	ideating
description	Grounded improvement idea generation for the current project. Use when asking what to improve, requesting idea generation, exploring surprising improvements, or wanting proactive project direction suggestions. Triggers: 'what should I improve', 'give me ideas', 'ideate on this project', 'surprise me', 'what would you change', 改进建议, 想法生成.
argument-hint	[feature, focus area, or constraint]

Generate Improvement Ideas

Use the current date from session context when dating ideation documents and checking recent ideation artifacts.

When to Use

• Asking what to improve or requesting idea generation
• Exploring surprising improvements or proactive project directions
• Before brainstorming — identifies which ideas are worth exploring in depth

When NOT to use: When the user already has a specific feature idea (use brainstorming instead).

ideating precedes brainstorming.

• ideating answers: "What are the strongest ideas worth exploring?"
• brainstorming answers: "What exactly should one chosen idea mean?"
• writing-arch-plans answers: "How should it be built?"

This workflow produces a ranked ideation artifact in docs/ideation/. It does not produce requirements, plans, or code.

Interaction Method

Use AskQuestion as the primary blocking question tool when choosing direction.

Ask one question at a time. Prefer concise single-select choices when natural options exist.

Focus Hint

#$ARGUMENTS

Interpret any provided argument as optional context. It may be:

• a concept such as DX improvements
• a path such as .cursor/skills/compound-engineering/
• a constraint such as low-complexity quick wins
• a volume hint such as top 3, 100 ideas, or raise the bar

If no argument is provided, proceed with open-ended ideation.

Core Principles

1. Ground before ideating - Scan the actual codebase first. Do not generate abstract product advice detached from the repository.
2. Generate many -> critique all -> explain survivors only - The quality mechanism is explicit rejection with reasons, not optimistic ranking. Do not let extra process obscure this pattern.
3. Route action into brainstorming - Ideation identifies promising directions; brainstorming defines the selected one precisely enough for planning. Do not skip to planning from ideation output.

Execution Flow

Create TodoWrite todos from this workflow:

TodoWrite todos:
  - id: "ideate-0", content: "Phase 0: Resume and scope", status: "pending"
  - id: "ideate-1", content: "Phase 1: Codebase scan", status: "pending"
  - id: "ideate-2", content: "Phase 2: Divergent ideation", status: "pending"

Phase 0: Resume and Scope

0.1 Check for Recent Ideation Work

Look in docs/ideation/ for ideation documents created within the last 30 days.

Treat a prior ideation doc as relevant when:

• the topic matches the requested focus
• the path or subsystem overlaps the requested focus
• the request is open-ended and there is an obvious recent open ideation doc
• the issue-grounded status matches: do not offer to resume a non-issue ideation when the current argument indicates issue-tracker intent, or vice versa — treat these as distinct topics

If a relevant doc exists, ask whether to:

1. continue from it
2. start fresh

If continuing:

• read the document
• summarize what has already been explored
• preserve previous idea statuses and session log entries
• update the existing file instead of creating a duplicate

0.2 Interpret Focus and Volume

Infer three things from the argument:

• Focus context - concept, path, constraint, or open-ended
• Volume override - any hint that changes candidate or survivor counts
• Issue-tracker intent - whether the user wants issue/bug data as an input source

Issue-tracker intent triggers when the argument's primary intent is about analyzing issue patterns: bugs, github issues, open issues, issue patterns, what users are reporting, bug reports, issue themes.

Do NOT trigger on arguments that merely mention bugs as a focus: bug in auth, fix the login issue, the signup bug — these are focus hints, not requests to analyze the issue tracker.

When combined (e.g., top 3 bugs in authentication): detect issue-tracker intent first, volume override second, remainder is the focus hint. The focus narrows which issues matter; the volume override controls survivor count.

Default volume:

• each ideation sub-agent generates about 8-10 ideas (yielding ~30 raw ideas across agents, ~20-25 after dedupe)
• keep the top 5-7 survivors

Honor clear overrides such as:

• top 3
• 100 ideas
• go deep
• raise the bar

Use reasonable interpretation rather than formal parsing.

Phase 1: Codebase Scan

Before generating ideas, gather codebase context.

Run agents in parallel in the foreground (do not use background dispatch — the results are needed before proceeding):

1. Quick context scan — dispatch a general-purpose sub-agent using model: "fast" with this prompt:

Read the project's AGENTS.md (or README.md if not present), then discover the top-level directory layout using Glob with pattern * or */*. Return a concise summary (under 30 lines) covering:

• project shape (language, framework, top-level directory layout)
• notable patterns or conventions
• obvious pain points or gaps
• likely leverage points for improvement

Keep the scan shallow — read only top-level documentation and directory structure. Do not analyze GitHub issues, templates, or contribution guidelines. Do not do deep code search.

Focus hint: {focus_hint}

2. Learnings search — dispatch learnings-researcher (.cursor/agents/learnings-researcher.md) with a brief summary of the ideation focus.

3. Issue intelligence (conditional) — if issue-tracker intent was detected in Phase 0.2, dispatch issue-intelligence-analyst (.cursor/agents/issue-intelligence-analyst.md) with the focus hint. If a focus hint is present, pass it so the agent can weight its clustering toward that area. Run this in parallel with agents 1 and 2.

If the agent returns an error (gh not installed, no remote, auth failure), log a warning to the user ("Issue analysis unavailable: {reason}. Proceeding with standard ideation.") and continue with the existing two-agent grounding.

If the agent reports fewer than 5 total issues, note "Insufficient issue signal for theme analysis" and proceed with default ideation frames in Phase 2.

Consolidate all results into a short grounding summary. When issue intelligence is present, keep it as a distinct section so ideation sub-agents can distinguish between code-observed and user-reported signals:

• Codebase context — project shape, notable patterns, obvious pain points, likely leverage points
• Past learnings — relevant institutional knowledge from docs/solutions/
• Issue intelligence (when present) — theme summaries from the issue intelligence agent, preserving theme titles, descriptions, issue counts, and trend directions

Feishu context (opt-in) — never auto-dispatch. Route by condition:

• Tools available + user asked: Dispatch feishu-researcher (.cursor/agents/feishu-researcher.md) with the focus hint in parallel with other Phase 1 agents. Include findings in the grounding summary.
• Tools available + user didn't ask: Note in output: "Feishu tools detected. Ask me to search Feishu for organizational context at any point, or include it in your next prompt."
• No tools + user asked: Note in output: "Feishu context was requested but no Feishu tools are available. Install and authenticate the Feishu (Lark) plugin to enable organizational context search."

Do not do external research in v1.

Phase 2: Divergent Ideation

Generate the full candidate list before critiquing any idea.

Dispatch 3-4 parallel ideation sub-agents on the inherited model (do not tier down -- creative ideation needs the orchestrator's reasoning level). Omit the mode parameter so the user's configured permission settings apply. Each targets ~8-10 ideas (yielding ~30 raw ideas, ~20-25 after dedupe). Adjust per-agent targets when volume overrides apply (e.g., "100 ideas" raises it, "top 3" may lower the survivor count instead).

Give each sub-agent: the grounding summary, the focus hint, the per-agent volume target, and an instruction to generate raw candidates only (not critique). Each agent's first few ideas tend to be obvious -- push past them. Ground every idea in the Phase 1 scan.

Assign each sub-agent a different ideation frame as a starting bias, not a constraint. Prompt each to begin from its assigned perspective but follow any promising thread -- cross-cutting ideas that span multiple frames are valuable.

Frame selection:

• When issue-tracker intent is active and themes were returned: Each high/medium-confidence theme becomes a frame. Pad with default frames if fewer than 3 cluster-derived frames. Cap at 4 total.
• Default frames (no issue-tracker intent): (1) user/operator pain and friction, (2) inversion, removal, or automation of a painful step, (3) assumption-breaking or reframing, (4) leverage and compounding effects.

Ask each sub-agent to return a compact structure per idea: title, summary, why_it_matters, evidence/grounding hooks, optional boldness or focus_fit signal.

After all sub-agents return:

1. Merge and dedupe into one master candidate list.
2. Synthesize cross-cutting combinations -- scan for ideas from different frames that combine into something stronger (expect 3-5 additions at most).
3. If a focus was provided, weight the merged list toward it without excluding stronger adjacent ideas.
4. Spread ideas across multiple dimensions when justified: workflow/DX, reliability, extensibility, missing capabilities, docs/knowledge compounding, quality/maintenance, leverage on future work.

After merging and synthesis, read post-ideation-workflow.md for the adversarial filtering rubric, presentation format, artifact template, handoff options, and quality bar. Do not load this file before Phase 2 agent dispatch completes.