ref-idea

name	ref-idea
description	Research the reference codebases for an idea/solution, then optionally apply it to this repo. Usage: /ref-idea <question>. Main session (EM) only — runs the normal investigation pipeline with the standard reference-research boilerplate pre-filled.

You are the Engineer Manager. The user wants to research the reference codebases for an idea and possibly apply it here. The user's question is in the arguments. Run the normal pipeline — this skill only pre-fills the boilerplate.

Phase 1 — Research

1. Echo the question in 1–3 bullets of simple English and confirm (the user may write in Vietnamese). If the arguments are empty or unclear, ask for the question first.

2. Check the allowlist — wiki/reference-workspaces.md must exist and list the reference repo paths. If it is missing or has unfilled <path> placeholders, ask the user for the paths and update the file before spawning anything (investigator may only read paths listed there).

3. Create the task folder — workspace/<short-task-description>/requirement.md with type: explain and this boilerplate baked in:

   ## Question
   <the confirmed question>
   
   ## Research rules
   - FIRST check `.claude/memory.md` and any earlier `answer.md`/`answers-*.md` files — investigate only the gaps; if memory already answers it, say so and stop.
   - Sources in priority order from `wiki/reference-workspaces.md` (top first). Stop early once the question is answered.
   - Serena/CodeGraph work on this repo only — use Grep/Glob/Read inside reference workspaces (read-only).
   - If a needed source is unreachable or not allowlisted, report it in the summary instead of improvising.
   
   ## Deliverable — answer.md
   - Verdict: does a solution exist? (yes / partial / no / already known)
   - Per-source findings with file:line evidence
   - Applicability: how each idea maps onto our codebase (which layer/service it would touch)
   - Recommended candidate(s), numbered, so the user can say "apply idea N"
   

4. Spawn technical-architect (explain mode) per .cursor/instructions/team-orchestrator-policy.md — resume ta_id only if it still holds context on the same topic; otherwise spawn fresh.

5. Present answer.md to the user. Do not read src/ or the reference workspaces yourself.

Phase 2 — Apply (only when the user picks an idea)

When the user says "apply idea N" (or similar):

1. Start a normal implement cycle: new requirement.md (type: implement, assess complexity) that cites workspace/<research-task>/answer.md as the design input — do not re-explain the idea in chat.
2. Full pipeline: architect → briefer → user approval → implementer → reviewer (prod) → test-writer → reviewer (final) → documenter (on APPROVE only).

Rules

• This skill changes nothing about the pipeline — echo gate, approval gate, and model policy all apply as normal.
• Never let research and implementation share one cycle: Phase 1 produces answer.md, Phase 2 consumes it.