[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FY14JS2ZKTY7HFR6T66HHN":3,"skill-same:01M6FY14JS2ZKTY7HFR6T66HHN":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6FY14JS2ZKTY7HFR6T66HHN","eval-ideas",null,"Loop feature-interviews over a brainstorm idea set and consolidate survivors into the roadmap","GeorgeQLe\u002Fagentic-skills","GeorgeQLe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F21134126?v=4","01M6D2JP418S0VGJGF8M93EC3H","George Le","01M6D2JPBAKYD82TA5FS6HKQ3D",1,"MIT","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fcodex\u002Feval-ideas\u002Farchive\u002Fv0.0\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"eval ideas","ideas","eval","roadmap","interviews","feature","consolidate","idea","gate","alignment","tasks","v0","orchestrator","brainstorm","page","loop","SET","planning","2026-11-10 10:12:30",false,"---\nname: eval-ideas\ndescription: Loop feature-interviews over a brainstorm idea set and consolidate survivors into the roadmap\ntype: planning\ninvocation: orchestrator\nversion: v0.0\nrequired_conventions: [alignment-page]\nargument-hint: \"[optional brainstorm topic or tasks\u002Fideas.md ref] [--override-gate]\"\ncontext_intake: scoped\n---\n\n## Pack Availability Guard\n\nBefore telling the user to run a skill from another project-local pack, check `.agents\u002Fproject.json.enabled_packs`. If the target pack is not enabled, recommend `npx skillpacks install \u003Cpack>` from the project shell, instead of the target skill. After install, tell Codex users to start a fresh Codex CLI session if the skill remains unavailable. Only the currently running skill and skills verified available in the active session or project-local install state are directly recommendable. For unavailable pack skills, recommend `npx skillpacks install \u003Cpack-or-skill>`; for unavailable base skills, recommend `npx skillpacks init` before the skill.\n\n# Eval Ideas — Orchestrator\n\nInvoke as `$eval-ideas`.\n\nThis is a **self-advancing Pattern A orchestrator** (see `docs\u002Fresearch-session-loop-convention.md`). It bridges `$brainstorm` and the `$feature-interview` prompts that brainstorm proposes: it consumes an existing brainstorm idea set, loops one `$feature-interview` per fresh-context session over the ideas the user selects, then consolidates the survivors into a single prioritized handoff to `$roadmap`.\n\nIt is a **thin loop\u002Fmanifest\u002Fgate\u002Fconsolidation shell only**. The interview itself is `$feature-interview` followed **inline** within the loop session — `eval-ideas` must not re-implement interview logic, write specs directly, or phase the roadmap. It routes through `$feature-interview` (the writer) and `$roadmap` (the phaser).\n\n**Scope: bridge only.** `eval-ideas` does not generate ideas. `$brainstorm` stays the separate upstream generator; run it first if no idea set exists.\n\nWhy this loop exists (three gaps it closes):\n\n1. **Context bloat.** `$feature-interview` is `context_intake: deep`. Running several in one session degrades quality — exactly what the Research Session Loop convention prevents. The loop isolates one interview per fresh-context session.\n2. **No progress tracking.** A run manifest plus `pending = selected − completed` detection makes the loop resumable across fresh sessions.\n3. **No consolidation.** Each `feature-interview` independently picks its own destination and priority. The consolidation step rolls the survivors into one prioritized roadmap handoff.\n\n## Entry Soft Gate — Maturity Check (warn-and-override)\n\nOn a cold start (state E), before presenting the multi-select idea gate, check whether the product is mature enough to be adding features. This is a **soft gate**: surface a warning manifest when any condition is unmet and require an explicit override to proceed. It never blocks early exploration with `$brainstorm`; it only warns before committing interview effort.\n\nCheck three conditions:\n\n- **(a) Spec exists** — at least one product spec under `specs\u002F` (or `specs\u002F{slug}\u002F`), or `spec.md` \u002F `docs\u002Fspecifications\u002F`.\n- **(b) No open todos** — `tasks\u002Ftodo.md` (and `tasks\u002Fmanual-todo.md`) have no outstanding unchecked items.\n- **(c) Evidence backing** — at least one of: `research\u002Fcustomer-feedback.md` with findings, `research\u002Ficp.md`, `research\u002Fmvp-gap.md`, `research\u002Fcompetitive-analysis.md` (or their `{slug}\u002F` equivalents), or public-research notes that back the ideas.\n\nIf all three are met, proceed silently to the multi-select gate. If any are unmet, render a **Maturity Warning Manifest** inline as the final message text of its own turn (Manifest Visibility Rule, `docs\u002Finterview-convention.md`): list each unmet condition, what is missing, and why it matters (open todos suggest unfinished current work; no spec suggests the product is pre-specification; no evidence suggests the ideas are unvalidated). Then ask the user to confirm the override or stop and address the gap first. `--override-gate` in `$ARGUMENTS` pre-confirms the override but the warning manifest is still shown. Do not present the multi-select idea gate in the same turn as the warning — wait for the override confirmation.\n\n## Execution Model — Research Session Loop\n\nEach invocation starts cold, resolves its state from **pasted YAML + filesystem**, runs **exactly one heavy phase** (one `$feature-interview`, or the consolidation), emits the next gate, and stops. The user advances the loop by clearing context and re-invoking `$eval-ideas`. The user never invokes `$feature-interview` directly — the orchestrator follows it inline.\n\nWhen an idea is pending, the only user-facing continuation route is re-invoking `$eval-ideas` (with the same brainstorm topic \u002F product-path argument when present). The parent resolves the next pending idea from the run manifest and filesystem.\n\nState lives in **two places only**:\n\n1. **Run manifest** — `tasks\u002F_working\u002Feval-ideas-run.yaml` (flat) or `tasks\u002F{slug}\u002F_working\u002Feval-ideas-run.yaml` when a product-path scope is active. Records the **selected** idea ids, topics, and each idea's expected interview-log path. Written when the multi-select YAML is approved. Selection only, **not** per-idea status. Shape:\n\n   ```yaml\n   orchestrator: eval-ideas\n   slug: skills-showcase            # omit in flat mode\n   source: alignment\u002Fbrainstorm-{topic}.html   # or tasks\u002Fideas.md\n   selected_ideas:\n     - id: idea-1\n       topic: inline-pr-comments\n       interview_log: specs\u002Finline-pr-comments-feature-interview.md\n     - id: idea-2\n       topic: batch-export\n       interview_log: specs\u002Fbatch-export-feature-interview.md\n   ```\n\n2. **Progress = artifact existence.** A selected idea is *done* when its `feature-interview` interview log (`specs\u002F{topic}-feature-interview.md`, or the `docs\u002Fspecifications\u002F` equivalent) or a spec it produced exists. `pending = selected_ideas − ideas-with-a-written-log\u002Fspec`. The manifest stores selection only; status is derived.\n\n`tasks\u002Froadmap.md` \u002F `tasks\u002Ftodo.md` are **not** the state store for this loop — those belong to the implementation exec loop. This orchestrator keeps its state in the run manifest plus artifact existence.\n\n### State resolution (resolve the first match; YAML first, then most-progressed A→G)\n\n| State | Detected when | Heavy phase this session | Emits \u002F stops with |\n|---|---|---|---|\n| **0 — pasted YAML** | a compiled alignment YAML is pasted | branch on `approval_status`: an approved multi-select YAML records the run manifest (light) then falls through to state C; an approved consolidation YAML writes the survivor list and roadmap handoff (state B finalize); `not-approved` → amend the named page (refinement session) and stop | manifest written + proceeds ↓, written consolidation, or amended page |\n| **A — done** | run manifest exists, all selected ideas have an interview log\u002Fspec, **and** a consolidation survivor doc exists | — | done; emit `## Recommended Next Command: $roadmap` |\n| **B — consolidate** | run manifest exists, all selected ideas interviewed, no consolidation written | **build the consolidation `review` page** — prioritized survivor list + roadmap handoff | consolidation `review` page |\n| **C — run interview** | run manifest exists, ≥1 selected idea pending | **run next pending `$feature-interview` inline** (one heavy phase) | that interview's own checkpoint\u002Fhandoff, then stop |\n| **D — selection in review** | multi-select idea page in `review`, selection not yet recorded | — (waiting) | points the user to the page |\n| **E — build selection** | no run manifest, no multi-select page (cold) | resolve idea set → run **entry soft gate** → build multi-select idea `review` page | warning manifest (if gate unmet), else multi-select `review` page |\n\nResolution order is **YAML first, then most-progressed backward (A→E)**. There is no state F\u002FG: `eval-ideas` is `context_intake: scoped` with no deep interview and no interrogation page — it cold-starts at state E. \"Pending idea\" = a selected idea whose interview log\u002Fspec does not yet exist.\n\n**Light vs heavy.** Recording the approved selection into the run manifest (state 0→C head) and archiving a consumed source are *light* — they fold into the head of the next heavy session. The heavy phase (one `$feature-interview`, or the consolidation) is the only thing isolated per session. If the run is small (1–2 ideas) and a phase is trivially cheap, fold rather than spend a near-empty round-trip.\n\n### Terminal Handoff Contract\n\nEvery terminal response for this loop must end with `## Next Work` and one command section:\n\n- `## Invoke With YAML` — only while a `review` page (multi-select or consolidation) is waiting for compiled YAML. It names `$eval-ideas` (with the same argument when present) as the invocation to use with the compiled YAML. Keep review\u002Fcompile\u002Fpaste instructions in `## Next Work`.\n- `## Recommended Next Command` — only after approved YAML has been consumed and the artifact written\u002Fupdated. While ideas remain pending or consolidation is unwritten, it names `$eval-ideas`. After the consolidation is written, it names `$roadmap` — the one place cross-skill routing is allowed.\n\nDo not place any other section after the applicable command section. While running a `$feature-interview` inline (state C), the interview's own terminal checkpoints govern that session; when the interview's interview log is written and the loop stops, recalculate pending ideas from the manifest and filesystem, then end with the parent-owned `## Next Work` + the appropriate command section naming `$eval-ideas` (or `$eval-ideas --consolidate` when no ideas remain and consolidation is unwritten).\n\n### Self-Routing Continuation Payload\n\nEvery `review` alignment page this parent creates must include `agent_routing` in the bottom compiled YAML, routing a fresh agent back to this parent. Use this shape (preserve the current argument when present):\n\n```yaml\ncommand: \"$eval-ideas\"                  # include the brainstorm topic \u002F product-path arg when present\nagent_routing:\n  workflow: pattern-a-research-loop\n  parent_skill: eval-ideas\n  command: \"$eval-ideas\"\n  product_path: tasks\u002F{slug}            # omit in flat mode\n  gate_owner: parent-orchestrator\n  gate_type: idea-selection             # or consolidation\n  run_manifest: tasks\u002F_working\u002Feval-ideas-run.yaml\n  next_resolution: parent-resolves-from-yaml-and-filesystem\n```\n\n`agent_routing` is routing metadata, not execution authority. The parent validates `approval_status`, identifies the gate, derives progress from the run manifest plus interview-log existence, writes\u002Famends the artifact, archives consumed sources, and decides whether to load `$feature-interview` inline. Never put `$feature-interview`, `$roadmap`, `$exec`, or `\u002Fexec` in this mapping while a gate is pending.\n\n## Process\n\n### 0. Product-Path Scope Resolution\n\nResolve scope by product path before using code or app structure as a hint:\n\n1. If `$ARGUMENTS` names a non-archived `research\u002F{slug}\u002F` directory or a product-path ID whose `scope_path` points there, use that path. Treat `{slug}` as the product\u002Fapp name.\n2. If `$ARGUMENTS` names only `research\u002F_archive\u002F{slug}\u002F` or a manifest entry with `status: archived` (or legacy `abandoned`), stop and warn that the path is archived.\n3. Read `research\u002F.progress.yaml` when present. Normalize legacy `active_path` to `active_paths`; treat legacy `abandoned` as `archived`; exclude `archived`, `deferred`, `revisit_candidate`, `promoted`, and `research\u002F_archive\u002F` scopes from active target selection.\n4. If active product paths exist, use them. If multiple exist, ask which one to target.\n5. If no active manifest target exists, list non-archived product directories under `research\u002F` (excluding `research\u002F_archive\u002F` and dot dirs). Auto-select only when exactly one exists; ask when multiple exist.\n6. If no product directories exist, use flat single-product mode.\n7. Detect monorepo\u002Fapp\u002Fpackage structure only as a secondary hint.\n\nWhen product path `{slug}` is active, scope the run manifest to `tasks\u002F{slug}\u002F_working\u002Feval-ideas-run.yaml` and pass the `{slug}` argument through to each inline `$feature-interview`.\n\n### 1. State E — Resolve the Idea Set (cold start)\n\nResolve the brainstorm idea set to loop over, in this order:\n\n1. If `$ARGUMENTS` names a brainstorm alignment page (`alignment\u002Fbrainstorm-{topic}.html`) or a topic that resolves to one, read its **approved\u002Fcurated** idea cards (title, motivating signal, the per-idea `$feature-interview \u003Ctopic>` handoff).\n2. Else if `tasks\u002Fideas.md` exists, read its entries.\n3. Else if a brainstorm alignment page exists for the active scope, use the most recent approved one.\n4. If no idea set is found, stop and tell the user to run `$brainstorm` first (honor the Pack Availability Guard — `$brainstorm` is in this same `product-design` pack, so no cross-pack install is needed; if the pack is somehow not enabled, recommend `npx skillpacks install product-design`).\n\nCarry forward each idea's topic slug and the motivating context so it can seed the inline `$feature-interview`.\n\n### 2. State E — Entry Soft Gate\n\nRun the **Entry Soft Gate — Maturity Check** above. If conditions are unmet, render the warning manifest inline and stop for the override confirmation. Do not build the multi-select page until the gate passes or the user overrides.\n\n### 3. State E — Build the Multi-Select Idea Page\n\nBuild the multi-select idea `review` alignment page (`alignment\u002Feval-ideas-{topic}.html`) with:\n\n1. **Source summary**: which brainstorm idea set this loop draws from, and the maturity-gate result (met, or overridden with which conditions unmet).\n2. **Multi-select idea section**: a checkbox per idea with its title, motivating codebase\u002Fresearch signal, and one-line description. No pre-checks beyond what the brainstorm page already marked approved — the user curates which ideas reach an interview.\n3. **Loop explanation**: the selected set is the scope gate; each selected idea is then run through `$feature-interview` inline (one interview per session), the run advances by re-invoking `$eval-ideas`, and survivors are consolidated into a `$roadmap` handoff.\n4. **Approval gate**: idea-selection confirmation.\n\nThis multi-select approval **is** the scope approval for the whole selected set. Stop for compiled YAML. Do **not** write the run manifest or run any interview in this session — that is state C.\n\n### 4. State C — Run Next Pending Interview (inline)\n\nThis session consumes the approved multi-select YAML (state 0→C) or advances after a prior interview completed. At the **head** of the session, do the light bookkeeping first:\n\n1. **Write the run manifest** if it does not yet exist (`tasks\u002F_working\u002Feval-ideas-run.yaml` or the product-path equivalent), recording `selected_ideas` with each idea's `id`, `topic`, and expected `interview_log` path. Include only ideas the user selected.\n2. **Archive the consumed multi-select page \u002F brainstorm source** only at this selection-commit point, per the alignment-page archive-first rule.\n\nThen run the **one heavy phase**:\n\n3. **Determine the next pending idea** = the first idea in `selected_ideas` whose interview log\u002Fspec does not yet exist.\n4. **Load and follow `$feature-interview`'s `SKILL.md` inline**, seeding it with that idea's topic and motivating context (equivalent to `$feature-interview \u003Ctopic>`). Follow the full feature-interview flow — its evidence brief, assumptions manifest, Planning Destination + Priority Checkpoint, and its interview-log write — within this session. `eval-ideas` adds no interview logic of its own.\n5. When the interview's interview log is written, **recalculate pending ideas** from the manifest and filesystem, then stop with the parent-owned handoff.\n\n**Advance the loop by self-re-invocation.** If pending ideas remain, end with `## Next Work` reporting progress as \"k of N ideas interviewed\" and saying the next run interviews the next pending idea, followed by `## Recommended Next Command` naming `$eval-ideas`. If no ideas remain pending and no consolidation exists, end with `## Next Work` saying the next run builds the consolidation survivor page, followed by `## Recommended Next Command` naming `$eval-ideas --consolidate`. Do not emit `$roadmap` here — that happens only after consolidation.\n\n### 5. State B — Consolidation (auto-detected; also `$eval-ideas --consolidate`)\n\nEnter consolidation when the run manifest exists, **all** selected ideas have an interview log\u002Fspec, and no consolidation doc exists yet. `$eval-ideas --consolidate` also forces this state.\n\nRead every selected idea's interview log (and any spec it produced). For each, extract: the confirmed planning destination, the user-confirmed priority hypothesis, the scope to build now vs defer, and the recommended next command recorded in the log. **Do not re-interview and do not re-decide** — consolidation reconciles what the interviews already concluded.\n\nBuild the consolidation `review` page with:\n\n1. **Survivor list**: each interviewed idea, its planning destination (new spec \u002F add-on spec \u002F spec update \u002F roadmap-or-task edit \u002F no-action), the artifact path it produced, and its confirmed priority.\n2. **Cross-idea prioritization**: a single ordered list of the survivors that reach the roadmap, with dependencies, conflicts, and a recommended build sequence. Drop ideas whose interview concluded `no action` \u002F already-covered; note them as evaluated-and-parked.\n3. **Roadmap handoff**: the prioritized survivor set framed for `$roadmap` to phase — which items are spec-backed and ready to sequence, which need further planning first.\n4. **Approval gate**: consolidation confirmation.\n\nStop for compiled YAML. On approval, write the survivor\u002Fconsolidation doc to `tasks\u002Feval-ideas-survivors.md` (or `tasks\u002F{slug}\u002Feval-ideas-survivors.md`): the ordered survivor list, each item's destination + artifact path + priority, the parked\u002Fno-action ideas, and the recommended `$roadmap` handoff. Then **archive the run manifest** under `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-working-path>`, convert the consolidation page to `confirmed`, and emit the downstream route (`$roadmap`). Verify `$roadmap` availability per the Pack Availability Guard: it lives in the `agent-work-admin` pack — if that pack is not enabled, recommend `npx skillpacks install agent-work-admin` before `$roadmap`.\n\n## Constraints\n\n- **Bridge only.** Do not generate ideas (that is `$brainstorm`). Do not change `$feature-interview` or `$brainstorm`. Consume an existing idea set and loop to a roadmap handoff.\n- **Parent self-advances one phase per invocation** and follows `$feature-interview` inline. The run manifest records the selected idea set; progress is interview-log\u002Fspec existence. The loop advances by re-invoking `$eval-ideas` (clear context between sessions).\n- **Do not write specs directly.** `eval-ideas` routes through `$feature-interview` (the writer) and `$roadmap` (the phaser). Its only writes are the run manifest and the consolidation survivor doc.\n- **Reuse, don't duplicate.** The interview is `$feature-interview` followed inline; the handoff contract is copied from the Research Session Loop convention; the soft-gate manifest renders inline per the Manifest Visibility Rule.\n- **The soft gate is a warning, not a block.** Always allow an explicit override. Never silently proceed past an unmet gate, and never present the multi-select gate in the same turn as the warning.\n- **Consolidation does not re-decide.** It reconciles the interview conclusions into one prioritized handoff; it does not re-run interviews or override a user-confirmed destination\u002Fpriority.\n- **No cross-skill routing while a gate is pending.** During the multi-select and consolidation review gates, the only user-facing continuation command is `$eval-ideas`. Emit `$roadmap` only after the consolidation is written.\n- When recommending a skill from another pack, verify the pack is installed via `.agents\u002Fproject.json` `enabled_packs`. If not installed, recommend `npx skillpacks install \u003Cpack-name>` before the target skill.\n\n## Alignment Page\n\nWhen this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment\u002Feval-ideas-{topic}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","## Pack Availability Guard\n\nBefore telling the user to run a skill from another project-local pack, check `.agents\u002Fproject.json.enabled_packs`. If the target pack is not enabled, recommend `npx skillpacks install \u003Cpack>` from the project shell, instead of the target skill. After install, tell Codex users to start a fresh Codex CLI session if the skill remains unavailable. Only the currently running skill and skills verified available in the active session or project-local install state are directly recommendable. For unavailable pack skills, recommend `npx skillpacks install \u003Cpack-or-skill>`; for unavailable base skills, recommend `npx skillpacks init` before the skill.\n\n# Eval Ideas — Orchestrator\n\nInvoke as `$eval-ideas`.\n\nThis is a **self-advancing Pattern A orchestrator** (see `docs\u002Fresearch-session-loop-convention.md`). It bridges `$brainstorm` and the `$feature-interview` prompts that brainstorm proposes: it consumes an existing brainstorm idea set, loops one `$feature-interview` per fresh-context session over the ideas the user selects, then consolidates the survivors into a single prioritized handoff to `$roadmap`.\n\nIt is a **thin loop\u002Fmanifest\u002Fgate\u002Fconsolidation shell only**. The interview itself is `$feature-interview` followed **inline** within the loop session — `eval-ideas` must not re-implement interview logic, write specs directly, or phase the roadmap. It routes through `$feature-interview` (the writer) and `$roadmap` (the phaser).\n\n**Scope: bridge only.** `eval-ideas` does not generate ideas. `$brainstorm` stays the separate upstream generator; run it first if no idea set exists.\n\nWhy this loop exists (three gaps it closes):\n\n1. **Context bloat.** `$feature-interview` is `context_intake: deep`. Running several in one session degrades quality — exactly what the Research Session Loop convention prevents. The loop isolates one interview per fresh-context session.\n2. **No progress tracking.** A run manifest plus `pending = selected − completed` detection makes the loop resumable across fresh sessions.\n3. **No consolidation.** Each `feature-interview` independently picks its own destination and priority. The consolidation step rolls the survivors into one prioritized roadmap handoff.\n\n## Entry Soft Gate — Maturity Check (warn-and-override)\n\nOn a cold start (state E), before presenting the multi-select idea gate, check whether the product is mature enough to be adding features. This is a **soft gate**: surface a warning manifest when any condition is unmet and require an explicit override to proceed. It never blocks early exploration with `$brainstorm`; it only warns before committing interview effort.\n\nCheck three conditions:\n\n- **(a) Spec exists** — at least one product spec under `specs\u002F` (or `specs\u002F{slug}\u002F`), or `spec.md` \u002F `docs\u002Fspecifications\u002F`.\n- **(b) No open todos** — `tasks\u002Ftodo.md` (and `tasks\u002Fmanual-todo.md`) have no outstanding unchecked items.\n- **(c) Evidence backing** — at least one of: `research\u002Fcustomer-feedback.md` with findings, `research\u002Ficp.md`, `research\u002Fmvp-gap.md`, `research\u002Fcompetitive-analysis.md` (or their `{slug}\u002F` equivalents), or public-research notes that back the ideas.\n\nIf all three are met, proceed silently to the multi-select gate. If any are unmet, render a **Maturity Warning Manifest** inline as the final message text of its own turn (Manifest Visibility Rule, `docs\u002Finterview-convention.md`): list each unmet condition, what is missing, and why it matters (open todos suggest unfinished current work; no spec suggests the product is pre-specification; no evidence suggests the ideas are unvalidated). Then ask the user to confirm the override or stop and address the gap first. `--override-gate` in `$ARGUMENTS` pre-confirms the override but the warning manifest is still shown. Do not present the multi-select idea gate in the same turn as the warning — wait for the override confirmation.\n\n## Execution Model — Research Session Loop\n\nEach invocation starts cold, resolves its state from **pasted YAML + filesystem**, runs **exactly one heavy phase** (one `$feature-interview`, or the consolidation), emits the next gate, and stops. The user advances the loop by clearing context and re-invoking `$eval-ideas`. The user never invokes `$feature-interview` directly — the orchestrator follows it inline.\n\nWhen an idea is pending, the only user-facing continuation route is re-invoking `$eval-ideas` (with the same brainstorm topic \u002F product-path argument when present). The parent resolves the next pending idea from the run manifest and filesystem.\n\nState lives in **two places only**:\n\n1. **Run manifest** — `tasks\u002F_working\u002Feval-ideas-run.yaml` (flat) or `tasks\u002F{slug}\u002F_working\u002Feval-ideas-run.yaml` when a product-path scope is active. Records the **selected** idea ids, topics, and each idea's expected interview-log path. Written when the multi-select YAML is approved. Selection only, **not** per-idea status. Shape:\n\n   ```yaml\n   orchestrator: eval-ideas\n   slug: skills-showcase            # omit in flat mode\n   source: alignment\u002Fbrainstorm-{topic}.html   # or tasks\u002Fideas.md\n   selected_ideas:\n     - id: idea-1\n       topic: inline-pr-comments\n       interview_log: specs\u002Finline-pr-comments-feature-interview.md\n     - id: idea-2\n       topic: batch-export\n       interview_log: specs\u002Fbatch-export-feature-interview.md\n   ```\n\n2. **Progress = artifact existence.** A selected idea is *done* when its `feature-interview` interview log (`specs\u002F{topic}-feature-interview.md`, or the `docs\u002Fspecifications\u002F` equivalent) or a spec it produced exists. `pending = selected_ideas − ideas-with-a-written-log\u002Fspec`. The manifest stores selection only; status is derived.\n\n`tasks\u002Froadmap.md` \u002F `tasks\u002Ftodo.md` are **not** the state store for this loop — those belong to the implementation exec loop. This orchestrator keeps its state in the run manifest plus artifact existence.\n\n### State resolution (resolve the first match; YAML first, then most-progressed A→G)\n\n| State | Detected when | Heavy phase this session | Emits \u002F stops with |\n|---|---|---|---|\n| **0 — pasted YAML** | a compiled alignment YAML is pasted | branch on `approval_status`: an approved multi-select YAML records the run manifest (light) then falls through to state C; an approved consolidation YAML writes the survivor list and roadmap handoff (state B finalize); `not-approved` → amend the named page (refinement session) and stop | manifest written + proceeds ↓, written consolidation, or amended page |\n| **A — done** | run manifest exists, all selected ideas have an interview log\u002Fspec, **and** a consolidation survivor doc exists | — | done; emit `## Recommended Next Command: $roadmap` |\n| **B — consolidate** | run manifest exists, all selected ideas interviewed, no consolidation written | **build the consolidation `review` page** — prioritized survivor list + roadmap handoff | consolidation `review` page |\n| **C — run interview** | run manifest exists, ≥1 selected idea pending | **run next pending `$feature-interview` inline** (one heavy phase) | that interview's own checkpoint\u002Fhandoff, then stop |\n| **D — selection in review** | multi-select idea page in `review`, selection not yet recorded | — (waiting) | points the user to the page |\n| **E — build selection** | no run manifest, no multi-select page (cold) | resolve idea set → run **entry soft gate** → build multi-select idea `review` page | warning manifest (if gate unmet), else multi-select `review` page |\n\nResolution order is **YAML first, then most-progressed backward (A→E)**. There is no state F\u002FG: `eval-ideas` is `context_intake: scoped` with no deep interview and no interrogation page — it cold-starts at state E. \"Pending idea\" = a selected idea whose interview log\u002Fspec does not yet exist.\n\n**Light vs heavy.** Recording the approved selection into the run manifest (state 0→C head) and archiving a consumed source are *light* — they fold into the head of the next heavy session. The heavy phase (one `$feature-interview`, or the consolidation) is the only thing isolated per session. If the run is small (1–2 ideas) and a phase is trivially cheap, fold rather than spend a near-empty round-trip.\n\n### Terminal Handoff Contract\n\nEvery terminal response for this loop must end with `## Next Work` and one command section:\n\n- `## Invoke With YAML` — only while a `review` page (multi-select or consolidation) is waiting for compiled YAML. It names `$eval-ideas` (with the same argument when present) as the invocation to use with the compiled YAML. Keep review\u002Fcompile\u002Fpaste instructions in `## Next Work`.\n- `## Recommended Next Command` — only after approved YAML has been consumed and the artifact written\u002Fupdated. While ideas remain pending or consolidation is unwritten, it names `$eval-ideas`. After the consolidation is written, it names `$roadmap` — the one place cross-skill routing is allowed.\n\nDo not place any other section after the applicable command section. While running a `$feature-interview` inline (state C), the interview's own terminal checkpoints govern that session; when the interview's interview log is written and the loop stops, recalculate pending ideas from the manifest and filesystem, then end with the parent-owned `## Next Work` + the appropriate command section naming `$eval-ideas` (or `$eval-ideas --consolidate` when no ideas remain and consolidation is unwritten).\n\n### Self-Routing Continuation Payload\n\nEvery `review` alignment page this parent creates must include `agent_routing` in the bottom compiled YAML, routing a fresh agent back to this parent. Use this shape (preserve the current argument when present):\n\n```yaml\ncommand: \"$eval-ideas\"                  # include the brainstorm topic \u002F product-path arg when present\nagent_routing:\n  workflow: pattern-a-research-loop\n  parent_skill: eval-ideas\n  command: \"$eval-ideas\"\n  product_path: tasks\u002F{slug}            # omit in flat mode\n  gate_owner: parent-orchestrator\n  gate_type: idea-selection             # or consolidation\n  run_manifest: tasks\u002F_working\u002Feval-ideas-run.yaml\n  next_resolution: parent-resolves-from-yaml-and-filesystem\n```\n\n`agent_routing` is routing metadata, not execution authority. The parent validates `approval_status`, identifies the gate, derives progress from the run manifest plus interview-log existence, writes\u002Famends the artifact, archives consumed sources, and decides whether to load `$feature-interview` inline. Never put `$feature-interview`, `$roadmap`, `$exec`, or `\u002Fexec` in this mapping while a gate is pending.\n\n## Process\n\n### 0. Product-Path Scope Resolution\n\nResolve scope by product path before using code or app structure as a hint:\n\n1. If `$ARGUMENTS` names a non-archived `research\u002F{slug}\u002F` directory or a product-path ID whose `scope_path` points there, use that path. Treat `{slug}` as the product\u002Fapp name.\n2. If `$ARGUMENTS` names only `research\u002F_archive\u002F{slug}\u002F` or a manifest entry with `status: archived` (or legacy `abandoned`), stop and warn that the path is archived.\n3. Read `research\u002F.progress.yaml` when present. Normalize legacy `active_path` to `active_paths`; treat legacy `abandoned` as `archived`; exclude `archived`, `deferred`, `revisit_candidate`, `promoted`, and `research\u002F_archive\u002F` scopes from active target selection.\n4. If active product paths exist, use them. If multiple exist, ask which one to target.\n5. If no active manifest target exists, list non-archived product directories under `research\u002F` (excluding `research\u002F_archive\u002F` and dot dirs). Auto-select only when exactly one exists; ask when multiple exist.\n6. If no product directories exist, use flat single-product mode.\n7. Detect monorepo\u002Fapp\u002Fpackage structure only as a secondary hint.\n\nWhen product path `{slug}` is active, scope the run manifest to `tasks\u002F{slug}\u002F_working\u002Feval-ideas-run.yaml` and pass the `{slug}` argument through to each inline `$feature-interview`.\n\n### 1. State E — Resolve the Idea Set (cold start)\n\nResolve the brainstorm idea set to loop over, in this order:\n\n1. If `$ARGUMENTS` names a brainstorm alignment page (`alignment\u002Fbrainstorm-{topic}.html`) or a topic that resolves to one, read its **approved\u002Fcurated** idea cards (title, motivating signal, the per-idea `$feature-interview \u003Ctopic>` handoff).\n2. Else if `tasks\u002Fideas.md` exists, read its entries.\n3. Else if a brainstorm alignment page exists for the active scope, use the most recent approved one.\n4. If no idea set is found, stop and tell the user to run `$brainstorm` first (honor the Pack Availability Guard — `$brainstorm` is in this same `product-design` pack, so no cross-pack install is needed; if the pack is somehow not enabled, recommend `npx skillpacks install product-design`).\n\nCarry forward each idea's topic slug and the motivating context so it can seed the inline `$feature-interview`.\n\n### 2. State E — Entry Soft Gate\n\nRun the **Entry Soft Gate — Maturity Check** above. If conditions are unmet, render the warning manifest inline and stop for the override confirmation. Do not build the multi-select page until the gate passes or the user overrides.\n\n### 3. State E — Build the Multi-Select Idea Page\n\nBuild the multi-select idea `review` alignment page (`alignment\u002Feval-ideas-{topic}.html`) with:\n\n1. **Source summary**: which brainstorm idea set this loop draws from, and the maturity-gate result (met, or overridden with which conditions unmet).\n2. **Multi-select idea section**: a checkbox per idea with its title, motivating codebase\u002Fresearch signal, and one-line description. No pre-checks beyond what the brainstorm page already marked approved — the user curates which ideas reach an interview.\n3. **Loop explanation**: the selected set is the scope gate; each selected idea is then run through `$feature-interview` inline (one interview per session), the run advances by re-invoking `$eval-ideas`, and survivors are consolidated into a `$roadmap` handoff.\n4. **Approval gate**: idea-selection confirmation.\n\nThis multi-select approval **is** the scope approval for the whole selected set. Stop for compiled YAML. Do **not** write the run manifest or run any interview in this session — that is state C.\n\n### 4. State C — Run Next Pending Interview (inline)\n\nThis session consumes the approved multi-select YAML (state 0→C) or advances after a prior interview completed. At the **head** of the session, do the light bookkeeping first:\n\n1. **Write the run manifest** if it does not yet exist (`tasks\u002F_working\u002Feval-ideas-run.yaml` or the product-path equivalent), recording `selected_ideas` with each idea's `id`, `topic`, and expected `interview_log` path. Include only ideas the user selected.\n2. **Archive the consumed multi-select page \u002F brainstorm source** only at this selection-commit point, per the alignment-page archive-first rule.\n\nThen run the **one heavy phase**:\n\n3. **Determine the next pending idea** = the first idea in `selected_ideas` whose interview log\u002Fspec does not yet exist.\n4. **Load and follow `$feature-interview`'s `SKILL.md` inline**, seeding it with that idea's topic and motivating context (equivalent to `$feature-interview \u003Ctopic>`). Follow the full feature-interview flow — its evidence brief, assumptions manifest, Planning Destination + Priority Checkpoint, and its interview-log write — within this session. `eval-ideas` adds no interview logic of its own.\n5. When the interview's interview log is written, **recalculate pending ideas** from the manifest and filesystem, then stop with the parent-owned handoff.\n\n**Advance the loop by self-re-invocation.** If pending ideas remain, end with `## Next Work` reporting progress as \"k of N ideas interviewed\" and saying the next run interviews the next pending idea, followed by `## Recommended Next Command` naming `$eval-ideas`. If no ideas remain pending and no consolidation exists, end with `## Next Work` saying the next run builds the consolidation survivor page, followed by `## Recommended Next Command` naming `$eval-ideas --consolidate`. Do not emit `$roadmap` here — that happens only after consolidation.\n\n### 5. State B — Consolidation (auto-detected; also `$eval-ideas --consolidate`)\n\nEnter consolidation when the run manifest exists, **all** selected ideas have an interview log\u002Fspec, and no consolidation doc exists yet. `$eval-ideas --consolidate` also forces this state.\n\nRead every selected idea's interview log (and any spec it produced). For each, extract: the confirmed planning destination, the user-confirmed priority hypothesis, the scope to build now vs defer, and the recommended next command recorded in the log. **Do not re-interview and do not re-decide** — consolidation reconciles what the interviews already concluded.\n\nBuild the consolidation `review` page with:\n\n1. **Survivor list**: each interviewed idea, its planning destination (new spec \u002F add-on spec \u002F spec update \u002F roadmap-or-task edit \u002F no-action), the artifact path it produced, and its confirmed priority.\n2. **Cross-idea prioritization**: a single ordered list of the survivors that reach the roadmap, with dependencies, conflicts, and a recommended build sequence. Drop ideas whose interview concluded `no action` \u002F already-covered; note them as evaluated-and-parked.\n3. **Roadmap handoff**: the prioritized survivor set framed for `$roadmap` to phase — which items are spec-backed and ready to sequence, which need further planning first.\n4. **Approval gate**: consolidation confirmation.\n\nStop for compiled YAML. On approval, write the survivor\u002Fconsolidation doc to `tasks\u002Feval-ideas-survivors.md` (or `tasks\u002F{slug}\u002Feval-ideas-survivors.md`): the ordered survivor list, each item's destination + artifact path + priority, the parked\u002Fno-action ideas, and the recommended `$roadmap` handoff. Then **archive the run manifest** under `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-working-path>`, convert the consolidation page to `confirmed`, and emit the downstream route (`$roadmap`). Verify `$roadmap` availability per the Pack Availability Guard: it lives in the `agent-work-admin` pack — if that pack is not enabled, recommend `npx skillpacks install agent-work-admin` before `$roadmap`.\n\n## Constraints\n\n- **Bridge only.** Do not generate ideas (that is `$brainstorm`). Do not change `$feature-interview` or `$brainstorm`. Consume an existing idea set and loop to a roadmap handoff.\n- **Parent self-advances one phase per invocation** and follows `$feature-interview` inline. The run manifest records the selected idea set; progress is interview-log\u002Fspec existence. The loop advances by re-invoking `$eval-ideas` (clear context between sessions).\n- **Do not write specs directly.** `eval-ideas` routes through `$feature-interview` (the writer) and `$roadmap` (the phaser). Its only writes are the run manifest and the consolidation survivor doc.\n- **Reuse, don't duplicate.** The interview is `$feature-interview` followed inline; the handoff contract is copied from the Research Session Loop convention; the soft-gate manifest renders inline per the Manifest Visibility Rule.\n- **The soft gate is a warning, not a block.** Always allow an explicit override. Never silently proceed past an unmet gate, and never present the multi-select gate in the same turn as the warning.\n- **Consolidation does not re-decide.** It reconciles the interview conclusions into one prioritized handoff; it does not re-run interviews or override a user-confirmed destination\u002Fpriority.\n- **No cross-skill routing while a gate is pending.** During the multi-select and consolidation review gates, the only user-facing continuation command is `$eval-ideas`. Emit `$roadmap` only after the consolidation is written.\n- When recommending a skill from another pack, verify the pack is installed via `.agents\u002Fproject.json` `enabled_packs`. If not installed, recommend `npx skillpacks install \u003Cpack-name>` before the target skill.\n\n## Alignment Page\n\nWhen this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment\u002Feval-ideas-{topic}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":41,"version":47,"invocation":36,"description":7,"argument-hint":48,"context_intake":49,"required_conventions":50},"v0.0","[optional brainstorm topic or tasks\u002Fideas.md ref] [--override-gate]","scoped",[51],"alignment-page","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fproduct-design\u002Fcodex\u002Feval-ideas\u002Farchive\u002Fv0.0",0,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills","https:\u002F\u002Fagentic-skills-blush.vercel.app","https:\u002F\u002Fgithub.com\u002FGeorgeQLe","georgeqle.com","George Le is a futurist and serial tech entrepreneur who wants to work toward a world where humanity is free from robotic tasks.","2026-11-10 04:07:24",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill eval-ideas",{"tool":68,"command":69},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill eval-ideas",{"tool":71,"command":72},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill eval-ideas","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fcodex\u002Feval-ideas\u002Farchive\u002Fv0.0\u002FSKILL.md",true,[],[77,89,99,111,126,137],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":42},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[84,85,86,87,35,88],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":42},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[96,97,98,88,86,35],"deck install valid","deck","install",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":42},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[106,107,108,88,109,110,86,35],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":122,"publishedAt":42},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[123,124,88,109,35,125,86],"codex missing skill valid","missing","fallback",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":42},"01M6G0N7PC0EKFD40ZWQAXSAQ9","codex-base-skill-fallback-valid","Valid Codex base skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-base-skill-fallback\u002FSKILL.md",[132],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},[88,109,125,134,135,136,35,86],"base skill","codex base skill fallback valid","base",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":42},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[88,108,107,144,110,35,86],"claude pack guard valid"]