[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71EFZT1C8A6V4BA07998STC":3,"skill-same:01M71EFZT1C8A6V4BA07998STC":71},{"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":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M71EFZT1C8A6V4BA07998STC","gh:ideate",null,"Generate and critically evaluate grounded improvement ideas for the current project. Use when asking what to improve, requesting idea generation, exploring surprising improvements, or wanting the AI to proactively suggest strong project directions before brainstorming one in depth. Triggers on phrases like 'what should I improve', 'give me ideas', 'ideate on this project', 'surprise me with improvements', 'what would you change', or any request for AI-generated project improvement suggestions rather than refining the user's own idea.","JGXC100\u002FGaleHarnessCodingCLI","JGXC100","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11926809?v=4","01M71EEBHJ3EGYSNNDDSVDKXNG","JGX","01M71EEBJ995S5J2HDEQCBA268",0,"MIT","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Fgh-ideate\u002FSKILL.md",[],[19,20,5,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"ideate","gh","ideas","feature","surprise me","improvement","idea","request","generate","focus","me","change","you","directions","when","generated","improve","project","idea generation","2026-11-10 10:12:30",false,"---\nname: gh:ideate\ndescription: \"Generate and critically evaluate grounded improvement ideas for the current project. Use when asking what to improve, requesting idea generation, exploring surprising improvements, or wanting the AI to proactively suggest strong project directions before brainstorming one in depth. Triggers on phrases like 'what should I improve', 'give me ideas', 'ideate on this project', 'surprise me with improvements', 'what would you change', or any request for AI-generated project improvement suggestions rather than refining the user's own idea.\"\nargument-hint: \"[feature, focus area, or constraint]\"\n---\n\n# Generate Improvement Ideas\n\n**Note: The current year is 2026.** Use this when dating ideation documents and checking recent ideation artifacts.\n\n`gh:ideate` precedes `gh:brainstorm`.\n\n- `gh:ideate` answers: \"What are the strongest ideas worth exploring?\"\n- `gh:brainstorm` answers: \"What exactly should one chosen idea mean?\"\n- `gh:plan` answers: \"How should it be built?\"\n\nThis workflow produces a ranked ideation artifact in `docs\u002Fideation\u002F`. It does **not** produce requirements, plans, or code.\n\n## Interaction Method\n\nUse the platform's blocking question tool when available (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension)). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.\n\nAsk one question at a time. Prefer concise single-select choices when natural options exist.\n\n## Focus Hint\n\n\u003Cfocus_hint> #$ARGUMENTS \u003C\u002Ffocus_hint>\n\nInterpret any provided argument as optional context. It may be:\n\n- a concept such as `DX improvements`\n- a path such as `plugins\u002Fgaleharness-cli\u002Fskills\u002F`\n- a constraint such as `low-complexity quick wins`\n- a volume hint such as `top 3`, `100 ideas`, or `raise the bar`\n\nIf no argument is provided, treat the subject as unsettled and run the subject-identification gate before any dispatch.\n\n## Core Principles\n\n1. **Ground before ideating** - Scan the actual codebase first. Do not generate abstract product advice detached from the repository.\n2. **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.\n3. **Route action into brainstorming** - Ideation identifies promising directions; `gh:brainstorm` defines the selected one precisely enough for planning. Do not skip to planning from ideation output.\n\n**Config:**\nAt the start of execution, use your native file-read tool to read `.compound-engineering\u002Fconfig.local.yaml` from the repository root. If the file is missing in the current worktree, check the main repository root (the parent of `.git\u002Fworktrees`). If the file is missing or unreadable, do not block the workflow — proceed silently with default settings.\n\nIf the config file contains `language: en`, write documents in English.\nIf the file is missing, contains `language: zh-CN`, or has no language key, write documents in Chinese (default).\n\n## Execution Flow\n\n\u003C!-- HKT-PATCH:gale-task-start -->\n### Phase -1: Task Lifecycle Start\n\nBefore any other action, log the skill start event so this execution appears on the task board:\n\n1. Run `gale-task log skill_started --skill gh:ideate --title \"\u003Cfocus-or-topic>\"` to register this execution on the task board.\n2. If `gale-task` is not on PATH or the command fails, skip and continue — this must never block the skill.\n\n\u003C!-- \u002FHKT-PATCH:gale-task-start -->\n\n### Phase 0: Resume and Scope\n\n#### 0.1 Check for Recent Ideation Work\n\nLook in `docs\u002Fideation\u002F` and the resolved global knowledge path (`gale-knowledge resolve-path --type ideation`) for ideation documents created within the last 30 days.\n\nTreat a prior ideation doc as relevant when:\n- the topic matches the requested focus\n- the path or subsystem overlaps the requested focus\n- the request is open-ended and there is an obvious recent open ideation doc\n- 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\n\nIf a relevant doc exists, ask whether to:\n1. continue from it\n2. start fresh\n\nIf continuing:\n- read the document\n- summarize what has already been explored\n- preserve previous idea statuses\n- update the existing file instead of creating a duplicate\n\n#### 0.2 Subject-Identification Gate\n\nBefore classifying focus or dispatching any grounding, check whether the subject of ideation is identifiable. Every downstream agent — grounding and ideation — needs to know what it's working on. If the subject is ambiguous enough that reasonable sub-agents would diverge on what the topic even is (bare words like `improvements`, `ideas`, `quick wins`, `things to fix`), the output will be scattered.\n\nIf the prompt explicitly asks the agent to choose the focus, such as `surprise me`, `pick for me`, or `you decide`, mark the run as **surprise-me mode** immediately and use the Surprise me routing below. Do not ask the user to confirm the same choice again.\n\nThe repo can ground a settled subject, but being in a repo does not turn vague prompts like `improvements`, `ideas`, `quick wins`, `things to fix`, or an empty prompt into a coherent topic. Downstream agents need to know what they are ideating about before they scan or generate.\n\n**Questioning principles (apply in this phase and in 0.3):**\n\n- Questions exist only to supply what sub-agents need to operate: an identifiable subject (this phase) and enough context for the agent to say something specific about it (0.3, elsewhere modes only). Nothing else.\n- Never ask about solution direction, constraints, audience, tone, success criteria, or anything that characterizes the subject — those belong to `gh:brainstorm`.\n- Always keep \"Surprise me\" (letting the agent decide the focus) as a real option, not a fallback for when the user can't name a subject. Ideation is allowed to be greenfield by design.\n- Stop as soon as the subject is identifiable or the user has delegated to \"Surprise me.\" More than 3 total questions across 0.2 and 0.3 is a smell that ideation is not the right workflow — consider suggesting `gh:brainstorm`.\n\n**Detection — issue-tracker intent (subject-identifying).**\n\nIssue-tracker intent requires explicit tracker\u002Freport phrasing. Trigger only when the prompt explicitly references the tracker or reports filed in it — phrases like `github issues`, `open issues`, `issue patterns`, `issue themes`, `what users are reporting`, or `bug reports` — the subject is \"issues in the tracker.\" Proceed to 0.3 with issue-tracker intent flagged.\n\nDo NOT trigger on arguments that merely mention bugs as a focus: `bug in auth`, `fix the login issue`, `the signup bug`, `top 3 bugs in authentication` — these are focus hints on regular ideation, not requests to analyze the issue tracker. A bare `bugs` with no tracker phrasing is handled by the vagueness check below, not here. Note: `top 3 bugs in authentication` without explicit tracker wording is a regular bug-focused ideation prompts, not issue intelligence.\n\nWhen combined (e.g., `top 3 issue themes in authentication`, `biggest bug reports about checkout`): detect issue-tracker intent first, volume override in 0.3, remainder is the focus hint. The focus narrows which issues matter; the volume override controls survivor count.\n\n**Detection — subject identifiability.**\n\nThe test: would a reader, seeing only this prompt, know what subject the agent should ideate on? Apply judgment to what the words *refer to*, not to their length or surface form.\n\n- **Vague — ask the scope question.** The prompt refers to a quality, category, or placeholder without naming a specific thing. Reasonable readers would pick different subjects. Illustrative cases: `improvements`, `ideas`, `things to fix`, `quick wins`, `what to build`, `bugs` (as the whole prompt, not as a topic like \"bugs in auth\"), an empty prompt. These are examples of the pattern, not a lookup table — recognize vagueness by what the words point to (a catch-all quality), not by matching specific words.\n\n- **Identifiable — proceed to 0.3.** The prompt names or plausibly names a specific subject: a feature, concept, document, subsystem, page, flow, or concrete topic. A reader would know where to direct thought even without knowing the domain. Illustrative cases: `authentication system`, `our sign-up page`, `browser sniff`, `dark mode`, `cache invalidation`.\n\n**Key distinction:** vagueness is about what the words *refer to*, not phrase length. `browser sniff` is two words but plausibly names a feature, so it is identifiable. `quick wins` is two words but refers only to a quality, so it is vague. Do not treat short phrases as vague by default.\n\n**Being inside a repo does not settle vagueness.** `improvements` in any repo is still scattered across DX, reliability, features, docs, tests, architecture. The repo provides material for grounding *after* a subject is settled, not the subject itself. Do not silently interpret a vague prompt as \"about this repo\" and proceed.\n\n**Genuine ambiguity (repo mode).** When judgment leaves real doubt on a short phrase — it could be a named feature or a vague concept — a single cheap check settles it: Glob for the phrase in filenames, or Grep for it in README\u002Fdocs. If it appears anywhere, treat as identifiable and proceed. If it has no repo footprint and still reads vaguely, ask the scope question.\n\nWhen in doubt otherwise, err toward asking — one question is trivial compared to dispatching agents on a scattered interpretation.\n\n**The scope question.**\n\nUse the platform's blocking question tool: `AskUserQuestion` in Claude Code (call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded), `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension). Fall back to numbered options in chat only when no blocking tool exists or the call errors — not because a schema load is required. Never silently skip.\n\n- **Stem:** \"What should the agent ideate about?\"\n- **Options:**\n  - \"Specify a subject the agent should ideate on\"\n  - \"Surprise me — let the agent decide what to focus on\"\n  - \"Cancel — let me rephrase\"\n\nRouting:\n\n- **Specify** → accept the user's follow-up as the subject. Re-apply the identifiability check once. If still ambiguous, ask once more with \"Surprise me\" still on the menu. Do not cascade toward specificity about *how* to solve — only about *what* the subject is.\n- **Surprise me** → mark the run as **surprise-me mode**. The agent will discover subjects from Phase 1 material rather than carry a user-specified subject. If CWD is inside a git repo, route deterministically to repo-grounded ideation and let the codebase supply the substance. If CWD is not inside a git repo, require at least one piece of substance before dispatching: a URL, a short description, a draft, or pasted material. If the user cannot provide substance outside a repo, end cleanly and ask them to re-run with material. This is a first-class mode — it changes how Phase 1 scans and how Phase 2 sub-agents operate (see those phases). **Dispatch routing for surprise-me is deterministic:** outside a repo, substance is required before dispatching — \"surprise me\" without material is only viable once the user has supplied something to surprise them about.\n- **Cancel** → exit cleanly. Narrate that the user can rephrase and re-invoke.\n\n#### 0.3 Interpret Focus and Volume\n\nInfer two things from the argument and any intake so far:\n\n- **Focus context** — concept, path, constraint, or open-ended\n- **Volume override** — any hint that changes candidate or survivor counts\n\nDefault volume:\n- each ideation sub-agent generates about 8-10 ideas (yielding ~30 raw ideas across agents, ~20-25 after dedupe)\n- keep the top 5-7 survivors\n\nHonor clear overrides such as:\n- `top 3`\n- `100 ideas`\n- `go deep`\n- `raise the bar`\n\n**Tactical scope detection.** Parse the focus hint (and any intake answers from 0.2 specify path) for tactical signals: `polish`, `typo`, `typos`, `quick wins`, `small improvements`, `cleanup`, `small fixes`. When present, lower the Phase 2 ambition floor — the user has explicitly opted into tactical scope. Default otherwise is step-function (see Phase 2 meeting-test floor).\n\nUse reasonable interpretation rather than formal parsing.\n\n\u003C!-- HKT-PATCH:phase-0.5 -->\n#### 0.5 HKTMemory Retrieve\n\nBefore Phase 1, query the vector memory database for related ideation and improvement ideas:\n\n1. Extract a search query from the focus hint:\n   - Focus area or concept (e.g., \"DX improvements\", \"auth flow\")\n   - Project domain or technology\n   - Constraint keywords (e.g., \"low-complexity\", \"quick wins\")\n\n2. Run (requires env vars HKT_MEMORY_API_KEY, HKT_MEMORY_BASE_URL, HKT_MEMORY_MODEL):\n   ```bash\n   memory_root=\"$(gale-memory resolve-root 2>\u002Fdev\u002Fnull || true)\"\n   [ -n \"$memory_root\" ] && export HKT_MEMORY_DIR=\"$memory_root\"\n   hkt-memory retrieve \\\n     --query \"\u003Cextracted query>\" \\\n     --layer all --limit 10 --min-similarity 0.35 \\\n     --vector-weight 0.7 --bm25-weight 0.3\n   ```\n\n3. If results returned, prepare context for Phase 1 and Phase 2:\n   ```\n   ## Related ideation from HKTMemory\n   Source: vector database. Treat as additional context, not primary evidence.\n   [results here, each tagged with (similarity: X.XX)]\n   ```\n   \n   Use this to:\n   - Avoid duplicating previously explored ideas\n   - Build upon or refine past ideation\n   - Identify patterns in improvement opportunities\n\n4. If no results or command error, proceed silently.\n\n### Phase 1: Codebase Scan\n\nBefore generating ideas, gather codebase context.\n\nRun agents in parallel in the **foreground** (do not use background dispatch — the results are needed before proceeding):\n\n1. **Quick context scan** — dispatch a general-purpose sub-agent using the platform's cheapest capable model (e.g., `model: \"haiku\"` in Claude Code) with this prompt:\n\n   > Read the project's AGENTS.md (or CLAUDE.md only as compatibility fallback, then README.md if neither exists), then discover the top-level directory layout using the native file-search\u002Fglob tool (e.g., `Glob` with pattern `*` or `*\u002F*` in Claude Code). Return a concise summary (under 30 lines) covering:\n   > - project shape (language, framework, top-level directory layout)\n   > - notable patterns or conventions\n   > - obvious pain points or gaps\n   > - likely leverage points for improvement\n   >\n   > 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.\n   >\n   > Focus hint: {focus_hint}\n\n2. **Learnings search** — dispatch `galeharness-cli:learnings-researcher` with a brief summary of the ideation focus.\n\n3. **Issue intelligence** (conditional) — if issue-tracker intent was detected in Phase 0.2, dispatch `galeharness-cli:issue-intelligence-analyst` 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.\n\n   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.\n\n   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.\n\nConsolidate 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:\n\n- **Codebase context** — project shape, notable patterns, obvious pain points, likely leverage points\n- **Past learnings** — relevant institutional knowledge from docs\u002Fsolutions\u002F\n- **Issue intelligence** (when present) — theme summaries from the issue intelligence agent, preserving theme titles, descriptions, issue counts, and trend directions\n\n**Slack context** (opt-in) — never auto-dispatch. Route by condition:\n\n- **Tools available + user asked**: Dispatch `galeharness-cli:slack-researcher` with the focus hint in parallel with other Phase 1 agents. Include findings in the grounding summary.\n- **Tools available + user didn't ask**: Note in output: \"Slack tools detected. Ask me to search Slack for organizational context at any point, or include it in your next prompt.\"\n- **No tools + user asked**: Note in output: \"Slack context was requested but no Slack tools are available. Install and authenticate the Slack plugin to enable organizational context search.\"\n\nDo **not** do external research in v1.\n\n### Phase 2: Divergent Ideation\n\nGenerate the full candidate list before critiquing any idea.\n\n**Document Language**: When `language: zh-CN` (or default), write all prose content in Chinese. Keep section headers (`## Survivors`, `## Rejected Ideas`, etc.) and YAML frontmatter keys in English. Translate paragraphs, list items, and table content. Do NOT translate code blocks, inline code, file paths, or URLs.\n\nDispatch 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).\n\nGive 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.\n\nAssign 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.\n\n**Frame selection:**\n- **When issue-tracker intent is active and themes were returned:** Each high\u002Fmedium-confidence theme becomes a frame. Pad with default frames if fewer than 3 cluster-derived frames. Cap at 4 total.\n- **Default frames (no issue-tracker intent):** (1) user\u002Foperator pain and friction, (2) inversion, removal, or automation of a painful step, (3) assumption-breaking or reframing, (4) leverage and compounding effects.\n\n**Per-idea warrant contract (uniform across all frames, all modes):**\n\nEach sub-agent returns this structure per idea:\n\n- **title**\n- **summary** (2-4 sentences)\n- **warrant** (required, tagged) — one of:\n  - `direct:` quoted line \u002F specific file \u002F named issue \u002F explicit user-supplied context\n  - `external:` named prior art, domain research, adjacent pattern, with source\n  - `reasoned:` explicit first-principles argument for why this move likely applies — not a gesture; the argument is written out\n- **why_it_matters** — connects the warrant to the move's significance\n- **meeting_test** — one line confirming this would warrant team discussion (waived when Phase 0.3 detected tactical focus signals)\n\nWarrant is required, not optional. If a sub-agent cannot articulate warrant of at least one type, the idea does not surface. The failure mode to prevent is generic \"AI-slop\" ideas that sound plausible but lack a basis the user can verify.\n\n**Generation rules (uniform across frames, all modes):**\n\n- Every idea carries articulated warrant. Unjustified speculation does not surface, regardless of how plausible it sounds.\n- Bias toward the warrant type your frame naturally produces — pain\u002Finversion\u002Fleverage tend toward `direct:`; analogy and constraint-flipping tend toward `reasoned:`; assumption-breaking is mixed — but don't exclude other warrant types.\n- Apply the meeting-test as a default floor: would this idea warrant team discussion? If not, it's below the floor and does not surface. The floor is relaxed only when Phase 0.3 detected tactical focus signals.\n- Stay within the subject's identity. Product expansions, new surfaces, new markets, retirements, and architectural pivots are fair game when warrant supports them. Subject-replacement moves (abandoning the project, pivoting to unrelated domains, becoming a different organization) are out regardless of warrant. In other words, subject-replacement moves are out.\n\n**Surprise-me mode addendum.** When Phase 0.2 routed to surprise-me, include this additional instruction in each sub-agent's dispatch prompt:\n\n> No user-specified subject. Through your frame's lens, explore the Phase 1 material and identify the subject(s) you find most interesting for this frame. Different frames finding different subjects is the feature — cross-subject divergence is what makes surprise-me valuable. Each idea still carries warrant; warrant may include identification of the subject itself (why *this* subject is worth ideating on through your lens, citing what in the Phase 1 material signals it).\n\nAfter all sub-agents return:\n1. Merge and dedupe into one master candidate list.\n2. Synthesize cross-cutting combinations -- scan for ideas from different frames that combine into something stronger. In specified mode, expect 3-5 additions at most. **In surprise-me mode, cross-cutting is the magic layer** — frames often converge on overlapping subjects or find complementary angles; expect 5-8 additions and give this step more attention. Surface combinations that span multiple frame-chosen subjects as a distinctive surprise-me output pattern.\n3. If a focus was provided, weight the merged list toward it without excluding stronger adjacent ideas.\n4. Spread ideas across multiple dimensions when justified: workflow\u002FDX, reliability, extensibility, missing capabilities, docs\u002Fknowledge compounding, quality\u002Fmaintenance, leverage on future work.\n\nAfter merging and synthesis, read `references\u002Fpost-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.\n\n\u003C!-- HKT-PATCH:knowledge-write-path -->\n### Knowledge Repository Write Path\n\nBefore writing the ideation artifact, resolve the target directory:\n\n1. Run `gale-knowledge resolve-path --type ideation` to get the target directory path. If the command fails or `gale-knowledge` is not available, fall back to `docs\u002Fideation`.\n2. Write the document to `\u003Cresolved-path>\u002F\u003Cfilename>.md`.\n3. Also write a copy to `docs\u002Fideation\u002F\u003Cfilename>.md` (dual-write). If this secondary write fails, log a warning but do not fail the workflow.\n\n\u003C!-- \u002FHKT-PATCH:knowledge-write-path -->\n\n\u003C!-- HKT-PATCH:phase-2.5 -->\n### Phase 2.5: HKTMemory Store\n\nAfter the ideation artifact is written to the resolved knowledge path:\n\n1. Read back the full content of the ideation document\n2. Extract the title and key themes from the frontmatter\u002Fcontent\n3. Run:\n   ```bash\n   memory_root=\"$(gale-memory resolve-root 2>\u002Fdev\u002Fnull || true)\"\n   [ -n \"$memory_root\" ] && export HKT_MEMORY_DIR=\"$memory_root\"\n   hkt-memory store \\\n     --content \"\u003Cfull ideation document>\" \\\n     --title \"Ideation: [document title]\" \\\n     --topic \"ideation\" \\\n     --layer all\n   ```\n4. Log on success: `Stored ideation to HKTMemory`\n5. On error, proceed silently — storage is supplementary\n\n**Note:** This enables future ideation sessions to discover and build upon these ideas through Phase 0.5's retrieve step.\n\n\u003C!-- HKT-PATCH:knowledge-commit -->\n### Knowledge Repository Commit\n\nAfter the ideation document is written:\n\n1. Run `gale-knowledge extract-project` to get the project name. If the command fails or is not available, use the current directory basename as the project name instead.\n2. Run `gale-knowledge commit --project \"\u003Cproject-name>\" --type ideation --title \"\u003Cdocument-title>\"` to commit the knowledge document. If this command fails, log the error but continue — the document has already been written to disk.\n3. If `gale-knowledge` is not on PATH, skip both steps and continue — this must never block the skill.\n\n\u003C!-- \u002FHKT-PATCH:knowledge-commit -->\n\n\u003C!-- HKT-PATCH:gale-task-end -->\nAfter the ideation workflow is fully complete, log the completion event:\n\n1. Run `gale-task log skill_completed` to record the completion event.\n2. If `gale-task` is not on PATH or the command fails, skip and continue — this must never block the skill.\n\u003C!-- \u002FHKT-PATCH:gale-task-end -->\n","# Generate Improvement Ideas\n\n**Note: The current year is 2026.** Use this when dating ideation documents and checking recent ideation artifacts.\n\n`gh:ideate` precedes `gh:brainstorm`.\n\n- `gh:ideate` answers: \"What are the strongest ideas worth exploring?\"\n- `gh:brainstorm` answers: \"What exactly should one chosen idea mean?\"\n- `gh:plan` answers: \"How should it be built?\"\n\nThis workflow produces a ranked ideation artifact in `docs\u002Fideation\u002F`. It does **not** produce requirements, plans, or code.\n\n## Interaction Method\n\nUse the platform's blocking question tool when available (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension)). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.\n\nAsk one question at a time. Prefer concise single-select choices when natural options exist.\n\n## Focus Hint\n\n\u003Cfocus_hint> #$ARGUMENTS \u003C\u002Ffocus_hint>\n\nInterpret any provided argument as optional context. It may be:\n\n- a concept such as `DX improvements`\n- a path such as `plugins\u002Fgaleharness-cli\u002Fskills\u002F`\n- a constraint such as `low-complexity quick wins`\n- a volume hint such as `top 3`, `100 ideas`, or `raise the bar`\n\nIf no argument is provided, treat the subject as unsettled and run the subject-identification gate before any dispatch.\n\n## Core Principles\n\n1. **Ground before ideating** - Scan the actual codebase first. Do not generate abstract product advice detached from the repository.\n2. **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.\n3. **Route action into brainstorming** - Ideation identifies promising directions; `gh:brainstorm` defines the selected one precisely enough for planning. Do not skip to planning from ideation output.\n\n**Config:**\nAt the start of execution, use your native file-read tool to read `.compound-engineering\u002Fconfig.local.yaml` from the repository root. If the file is missing in the current worktree, check the main repository root (the parent of `.git\u002Fworktrees`). If the file is missing or unreadable, do not block the workflow — proceed silently with default settings.\n\nIf the config file contains `language: en`, write documents in English.\nIf the file is missing, contains `language: zh-CN`, or has no language key, write documents in Chinese (default).\n\n## Execution Flow\n\n\u003C!-- HKT-PATCH:gale-task-start -->\n### Phase -1: Task Lifecycle Start\n\nBefore any other action, log the skill start event so this execution appears on the task board:\n\n1. Run `gale-task log skill_started --skill gh:ideate --title \"\u003Cfocus-or-topic>\"` to register this execution on the task board.\n2. If `gale-task` is not on PATH or the command fails, skip and continue — this must never block the skill.\n\n\u003C!-- \u002FHKT-PATCH:gale-task-start -->\n\n### Phase 0: Resume and Scope\n\n#### 0.1 Check for Recent Ideation Work\n\nLook in `docs\u002Fideation\u002F` and the resolved global knowledge path (`gale-knowledge resolve-path --type ideation`) for ideation documents created within the last 30 days.\n\nTreat a prior ideation doc as relevant when:\n- the topic matches the requested focus\n- the path or subsystem overlaps the requested focus\n- the request is open-ended and there is an obvious recent open ideation doc\n- 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\n\nIf a relevant doc exists, ask whether to:\n1. continue from it\n2. start fresh\n\nIf continuing:\n- read the document\n- summarize what has already been explored\n- preserve previous idea statuses\n- update the existing file instead of creating a duplicate\n\n#### 0.2 Subject-Identification Gate\n\nBefore classifying focus or dispatching any grounding, check whether the subject of ideation is identifiable. Every downstream agent — grounding and ideation — needs to know what it's working on. If the subject is ambiguous enough that reasonable sub-agents would diverge on what the topic even is (bare words like `improvements`, `ideas`, `quick wins`, `things to fix`), the output will be scattered.\n\nIf the prompt explicitly asks the agent to choose the focus, such as `surprise me`, `pick for me`, or `you decide`, mark the run as **surprise-me mode** immediately and use the Surprise me routing below. Do not ask the user to confirm the same choice again.\n\nThe repo can ground a settled subject, but being in a repo does not turn vague prompts like `improvements`, `ideas`, `quick wins`, `things to fix`, or an empty prompt into a coherent topic. Downstream agents need to know what they are ideating about before they scan or generate.\n\n**Questioning principles (apply in this phase and in 0.3):**\n\n- Questions exist only to supply what sub-agents need to operate: an identifiable subject (this phase) and enough context for the agent to say something specific about it (0.3, elsewhere modes only). Nothing else.\n- Never ask about solution direction, constraints, audience, tone, success criteria, or anything that characterizes the subject — those belong to `gh:brainstorm`.\n- Always keep \"Surprise me\" (letting the agent decide the focus) as a real option, not a fallback for when the user can't name a subject. Ideation is allowed to be greenfield by design.\n- Stop as soon as the subject is identifiable or the user has delegated to \"Surprise me.\" More than 3 total questions across 0.2 and 0.3 is a smell that ideation is not the right workflow — consider suggesting `gh:brainstorm`.\n\n**Detection — issue-tracker intent (subject-identifying).**\n\nIssue-tracker intent requires explicit tracker\u002Freport phrasing. Trigger only when the prompt explicitly references the tracker or reports filed in it — phrases like `github issues`, `open issues`, `issue patterns`, `issue themes`, `what users are reporting`, or `bug reports` — the subject is \"issues in the tracker.\" Proceed to 0.3 with issue-tracker intent flagged.\n\nDo NOT trigger on arguments that merely mention bugs as a focus: `bug in auth`, `fix the login issue`, `the signup bug`, `top 3 bugs in authentication` — these are focus hints on regular ideation, not requests to analyze the issue tracker. A bare `bugs` with no tracker phrasing is handled by the vagueness check below, not here. Note: `top 3 bugs in authentication` without explicit tracker wording is a regular bug-focused ideation prompts, not issue intelligence.\n\nWhen combined (e.g., `top 3 issue themes in authentication`, `biggest bug reports about checkout`): detect issue-tracker intent first, volume override in 0.3, remainder is the focus hint. The focus narrows which issues matter; the volume override controls survivor count.\n\n**Detection — subject identifiability.**\n\nThe test: would a reader, seeing only this prompt, know what subject the agent should ideate on? Apply judgment to what the words *refer to*, not to their length or surface form.\n\n- **Vague — ask the scope question.** The prompt refers to a quality, category, or placeholder without naming a specific thing. Reasonable readers would pick different subjects. Illustrative cases: `improvements`, `ideas`, `things to fix`, `quick wins`, `what to build`, `bugs` (as the whole prompt, not as a topic like \"bugs in auth\"), an empty prompt. These are examples of the pattern, not a lookup table — recognize vagueness by what the words point to (a catch-all quality), not by matching specific words.\n\n- **Identifiable — proceed to 0.3.** The prompt names or plausibly names a specific subject: a feature, concept, document, subsystem, page, flow, or concrete topic. A reader would know where to direct thought even without knowing the domain. Illustrative cases: `authentication system`, `our sign-up page`, `browser sniff`, `dark mode`, `cache invalidation`.\n\n**Key distinction:** vagueness is about what the words *refer to*, not phrase length. `browser sniff` is two words but plausibly names a feature, so it is identifiable. `quick wins` is two words but refers only to a quality, so it is vague. Do not treat short phrases as vague by default.\n\n**Being inside a repo does not settle vagueness.** `improvements` in any repo is still scattered across DX, reliability, features, docs, tests, architecture. The repo provides material for grounding *after* a subject is settled, not the subject itself. Do not silently interpret a vague prompt as \"about this repo\" and proceed.\n\n**Genuine ambiguity (repo mode).** When judgment leaves real doubt on a short phrase — it could be a named feature or a vague concept — a single cheap check settles it: Glob for the phrase in filenames, or Grep for it in README\u002Fdocs. If it appears anywhere, treat as identifiable and proceed. If it has no repo footprint and still reads vaguely, ask the scope question.\n\nWhen in doubt otherwise, err toward asking — one question is trivial compared to dispatching agents on a scattered interpretation.\n\n**The scope question.**\n\nUse the platform's blocking question tool: `AskUserQuestion` in Claude Code (call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded), `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension). Fall back to numbered options in chat only when no blocking tool exists or the call errors — not because a schema load is required. Never silently skip.\n\n- **Stem:** \"What should the agent ideate about?\"\n- **Options:**\n  - \"Specify a subject the agent should ideate on\"\n  - \"Surprise me — let the agent decide what to focus on\"\n  - \"Cancel — let me rephrase\"\n\nRouting:\n\n- **Specify** → accept the user's follow-up as the subject. Re-apply the identifiability check once. If still ambiguous, ask once more with \"Surprise me\" still on the menu. Do not cascade toward specificity about *how* to solve — only about *what* the subject is.\n- **Surprise me** → mark the run as **surprise-me mode**. The agent will discover subjects from Phase 1 material rather than carry a user-specified subject. If CWD is inside a git repo, route deterministically to repo-grounded ideation and let the codebase supply the substance. If CWD is not inside a git repo, require at least one piece of substance before dispatching: a URL, a short description, a draft, or pasted material. If the user cannot provide substance outside a repo, end cleanly and ask them to re-run with material. This is a first-class mode — it changes how Phase 1 scans and how Phase 2 sub-agents operate (see those phases). **Dispatch routing for surprise-me is deterministic:** outside a repo, substance is required before dispatching — \"surprise me\" without material is only viable once the user has supplied something to surprise them about.\n- **Cancel** → exit cleanly. Narrate that the user can rephrase and re-invoke.\n\n#### 0.3 Interpret Focus and Volume\n\nInfer two things from the argument and any intake so far:\n\n- **Focus context** — concept, path, constraint, or open-ended\n- **Volume override** — any hint that changes candidate or survivor counts\n\nDefault volume:\n- each ideation sub-agent generates about 8-10 ideas (yielding ~30 raw ideas across agents, ~20-25 after dedupe)\n- keep the top 5-7 survivors\n\nHonor clear overrides such as:\n- `top 3`\n- `100 ideas`\n- `go deep`\n- `raise the bar`\n\n**Tactical scope detection.** Parse the focus hint (and any intake answers from 0.2 specify path) for tactical signals: `polish`, `typo`, `typos`, `quick wins`, `small improvements`, `cleanup`, `small fixes`. When present, lower the Phase 2 ambition floor — the user has explicitly opted into tactical scope. Default otherwise is step-function (see Phase 2 meeting-test floor).\n\nUse reasonable interpretation rather than formal parsing.\n\n\u003C!-- HKT-PATCH:phase-0.5 -->\n#### 0.5 HKTMemory Retrieve\n\nBefore Phase 1, query the vector memory database for related ideation and improvement ideas:\n\n1. Extract a search query from the focus hint:\n   - Focus area or concept (e.g., \"DX improvements\", \"auth flow\")\n   - Project domain or technology\n   - Constraint keywords (e.g., \"low-complexity\", \"quick wins\")\n\n2. Run (requires env vars HKT_MEMORY_API_KEY, HKT_MEMORY_BASE_URL, HKT_MEMORY_MODEL):\n   ```bash\n   memory_root=\"$(gale-memory resolve-root 2>\u002Fdev\u002Fnull || true)\"\n   [ -n \"$memory_root\" ] && export HKT_MEMORY_DIR=\"$memory_root\"\n   hkt-memory retrieve \\\n     --query \"\u003Cextracted query>\" \\\n     --layer all --limit 10 --min-similarity 0.35 \\\n     --vector-weight 0.7 --bm25-weight 0.3\n   ```\n\n3. If results returned, prepare context for Phase 1 and Phase 2:\n   ```\n   ## Related ideation from HKTMemory\n   Source: vector database. Treat as additional context, not primary evidence.\n   [results here, each tagged with (similarity: X.XX)]\n   ```\n   \n   Use this to:\n   - Avoid duplicating previously explored ideas\n   - Build upon or refine past ideation\n   - Identify patterns in improvement opportunities\n\n4. If no results or command error, proceed silently.\n\n### Phase 1: Codebase Scan\n\nBefore generating ideas, gather codebase context.\n\nRun agents in parallel in the **foreground** (do not use background dispatch — the results are needed before proceeding):\n\n1. **Quick context scan** — dispatch a general-purpose sub-agent using the platform's cheapest capable model (e.g., `model: \"haiku\"` in Claude Code) with this prompt:\n\n   > Read the project's AGENTS.md (or CLAUDE.md only as compatibility fallback, then README.md if neither exists), then discover the top-level directory layout using the native file-search\u002Fglob tool (e.g., `Glob` with pattern `*` or `*\u002F*` in Claude Code). Return a concise summary (under 30 lines) covering:\n   > - project shape (language, framework, top-level directory layout)\n   > - notable patterns or conventions\n   > - obvious pain points or gaps\n   > - likely leverage points for improvement\n   >\n   > 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.\n   >\n   > Focus hint: {focus_hint}\n\n2. **Learnings search** — dispatch `galeharness-cli:learnings-researcher` with a brief summary of the ideation focus.\n\n3. **Issue intelligence** (conditional) — if issue-tracker intent was detected in Phase 0.2, dispatch `galeharness-cli:issue-intelligence-analyst` 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.\n\n   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.\n\n   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.\n\nConsolidate 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:\n\n- **Codebase context** — project shape, notable patterns, obvious pain points, likely leverage points\n- **Past learnings** — relevant institutional knowledge from docs\u002Fsolutions\u002F\n- **Issue intelligence** (when present) — theme summaries from the issue intelligence agent, preserving theme titles, descriptions, issue counts, and trend directions\n\n**Slack context** (opt-in) — never auto-dispatch. Route by condition:\n\n- **Tools available + user asked**: Dispatch `galeharness-cli:slack-researcher` with the focus hint in parallel with other Phase 1 agents. Include findings in the grounding summary.\n- **Tools available + user didn't ask**: Note in output: \"Slack tools detected. Ask me to search Slack for organizational context at any point, or include it in your next prompt.\"\n- **No tools + user asked**: Note in output: \"Slack context was requested but no Slack tools are available. Install and authenticate the Slack plugin to enable organizational context search.\"\n\nDo **not** do external research in v1.\n\n### Phase 2: Divergent Ideation\n\nGenerate the full candidate list before critiquing any idea.\n\n**Document Language**: When `language: zh-CN` (or default), write all prose content in Chinese. Keep section headers (`## Survivors`, `## Rejected Ideas`, etc.) and YAML frontmatter keys in English. Translate paragraphs, list items, and table content. Do NOT translate code blocks, inline code, file paths, or URLs.\n\nDispatch 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).\n\nGive 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.\n\nAssign 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.\n\n**Frame selection:**\n- **When issue-tracker intent is active and themes were returned:** Each high\u002Fmedium-confidence theme becomes a frame. Pad with default frames if fewer than 3 cluster-derived frames. Cap at 4 total.\n- **Default frames (no issue-tracker intent):** (1) user\u002Foperator pain and friction, (2) inversion, removal, or automation of a painful step, (3) assumption-breaking or reframing, (4) leverage and compounding effects.\n\n**Per-idea warrant contract (uniform across all frames, all modes):**\n\nEach sub-agent returns this structure per idea:\n\n- **title**\n- **summary** (2-4 sentences)\n- **warrant** (required, tagged) — one of:\n  - `direct:` quoted line \u002F specific file \u002F named issue \u002F explicit user-supplied context\n  - `external:` named prior art, domain research, adjacent pattern, with source\n  - `reasoned:` explicit first-principles argument for why this move likely applies — not a gesture; the argument is written out\n- **why_it_matters** — connects the warrant to the move's significance\n- **meeting_test** — one line confirming this would warrant team discussion (waived when Phase 0.3 detected tactical focus signals)\n\nWarrant is required, not optional. If a sub-agent cannot articulate warrant of at least one type, the idea does not surface. The failure mode to prevent is generic \"AI-slop\" ideas that sound plausible but lack a basis the user can verify.\n\n**Generation rules (uniform across frames, all modes):**\n\n- Every idea carries articulated warrant. Unjustified speculation does not surface, regardless of how plausible it sounds.\n- Bias toward the warrant type your frame naturally produces — pain\u002Finversion\u002Fleverage tend toward `direct:`; analogy and constraint-flipping tend toward `reasoned:`; assumption-breaking is mixed — but don't exclude other warrant types.\n- Apply the meeting-test as a default floor: would this idea warrant team discussion? If not, it's below the floor and does not surface. The floor is relaxed only when Phase 0.3 detected tactical focus signals.\n- Stay within the subject's identity. Product expansions, new surfaces, new markets, retirements, and architectural pivots are fair game when warrant supports them. Subject-replacement moves (abandoning the project, pivoting to unrelated domains, becoming a different organization) are out regardless of warrant. In other words, subject-replacement moves are out.\n\n**Surprise-me mode addendum.** When Phase 0.2 routed to surprise-me, include this additional instruction in each sub-agent's dispatch prompt:\n\n> No user-specified subject. Through your frame's lens, explore the Phase 1 material and identify the subject(s) you find most interesting for this frame. Different frames finding different subjects is the feature — cross-subject divergence is what makes surprise-me valuable. Each idea still carries warrant; warrant may include identification of the subject itself (why *this* subject is worth ideating on through your lens, citing what in the Phase 1 material signals it).\n\nAfter all sub-agents return:\n1. Merge and dedupe into one master candidate list.\n2. Synthesize cross-cutting combinations -- scan for ideas from different frames that combine into something stronger. In specified mode, expect 3-5 additions at most. **In surprise-me mode, cross-cutting is the magic layer** — frames often converge on overlapping subjects or find complementary angles; expect 5-8 additions and give this step more attention. Surface combinations that span multiple frame-chosen subjects as a distinctive surprise-me output pattern.\n3. If a focus was provided, weight the merged list toward it without excluding stronger adjacent ideas.\n4. Spread ideas across multiple dimensions when justified: workflow\u002FDX, reliability, extensibility, missing capabilities, docs\u002Fknowledge compounding, quality\u002Fmaintenance, leverage on future work.\n\nAfter merging and synthesis, read `references\u002Fpost-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.\n\n\u003C!-- HKT-PATCH:knowledge-write-path -->\n### Knowledge Repository Write Path\n\nBefore writing the ideation artifact, resolve the target directory:\n\n1. Run `gale-knowledge resolve-path --type ideation` to get the target directory path. If the command fails or `gale-knowledge` is not available, fall back to `docs\u002Fideation`.\n2. Write the document to `\u003Cresolved-path>\u002F\u003Cfilename>.md`.\n3. Also write a copy to `docs\u002Fideation\u002F\u003Cfilename>.md` (dual-write). If this secondary write fails, log a warning but do not fail the workflow.\n\n\u003C!-- \u002FHKT-PATCH:knowledge-write-path -->\n\n\u003C!-- HKT-PATCH:phase-2.5 -->\n### Phase 2.5: HKTMemory Store\n\nAfter the ideation artifact is written to the resolved knowledge path:\n\n1. Read back the full content of the ideation document\n2. Extract the title and key themes from the frontmatter\u002Fcontent\n3. Run:\n   ```bash\n   memory_root=\"$(gale-memory resolve-root 2>\u002Fdev\u002Fnull || true)\"\n   [ -n \"$memory_root\" ] && export HKT_MEMORY_DIR=\"$memory_root\"\n   hkt-memory store \\\n     --content \"\u003Cfull ideation document>\" \\\n     --title \"Ideation: [document title]\" \\\n     --topic \"ideation\" \\\n     --layer all\n   ```\n4. Log on success: `Stored ideation to HKTMemory`\n5. On error, proceed silently — storage is supplementary\n\n**Note:** This enables future ideation sessions to discover and build upon these ideas through Phase 0.5's retrieve step.\n\n\u003C!-- HKT-PATCH:knowledge-commit -->\n### Knowledge Repository Commit\n\nAfter the ideation document is written:\n\n1. Run `gale-knowledge extract-project` to get the project name. If the command fails or is not available, use the current directory basename as the project name instead.\n2. Run `gale-knowledge commit --project \"\u003Cproject-name>\" --type ideation --title \"\u003Cdocument-title>\"` to commit the knowledge document. If this command fails, log the error but continue — the document has already been written to disk.\n3. If `gale-knowledge` is not on PATH, skip both steps and continue — this must never block the skill.\n\n\u003C!-- \u002FHKT-PATCH:knowledge-commit -->\n\n\u003C!-- HKT-PATCH:gale-task-end -->\nAfter the ideation workflow is fully complete, log the completion event:\n\n1. Run `gale-task log skill_completed` to record the completion event.\n2. If `gale-task` is not on PATH or the command fails, skip and continue — this must never block the skill.\n\u003C!-- \u002FHKT-PATCH:gale-task-end -->\n",{"name":5,"description":7,"argument-hint":43},"[feature, focus area, or constraint]","main","94fc651a7c5ff227f3e8f4b9678dc4566f535677","plugins\u002Fgaleharness-cli\u002Fskills\u002Fgh-ideate",2,"https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI","https:\u002F\u002Fgithub.com\u002FJGXC100","2026-05-19 17:04:59",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add JGXC100\u002FGaleHarnessCodingCLI --skill \"gh:ideate\"",{"tool":57,"command":58},"bunx","bunx skills add JGXC100\u002FGaleHarnessCodingCLI --skill \"gh:ideate\"",{"tool":60,"command":61},"pnpm","pnpm dlx skills add JGXC100\u002FGaleHarnessCodingCLI --skill \"gh:ideate\"","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Fgh-ideate\u002FSKILL.md",true,[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fpost-ideation-workflow.md","REFERENCE","参考文档",6765,"https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Fgh-ideate\u002Freferences\u002Fpost-ideation-workflow.md",[72,88,102,114,122,130],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":83,"publishedAt":38},"01M71EJT9M91X2T91N4ZPCWHN3","skill-one","Sample skill","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[84,85,86,87],"skill one","one","sample skill","sample",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":95,"publishedAt":38},"01M71EJRH7M0DGZ1QXJ9PSFMB5","disabled-skill","A skill with model invocation disabled","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fdisabled-skill\u002FSKILL.md",[94],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},[96,97,98,99,100,101],"disabled skill","a skill","with model","with","true","model",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":38},"01M71EJQMRH6JC9H9V5BQWM7RJ","claude-only-skill","A skill restricted to Claude Code only","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fclaude-only-skill\u002FSKILL.md",[108],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},[110,111,112,113,97],"only","claude only skill","claude only","code",{"skillNo":115,"name":116,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":38},"01M71EJPXZ0644M41M587FVKYQ","default-skill","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fskills\u002Fdefault-skill\u002FSKILL.md",[],[120,121],"default skill","default",{"skillNo":123,"name":124,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":38},"01M71EJP6RPF6PDAJ2SY4VMBDT","custom-skill","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fcustom-skills\u002Fcustom-skill\u002FSKILL.md",[],[128,129],"custom skill","custom",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":139,"publishedAt":38},"01M71EJK74AZ929S8GF55G5CDV","test-xcode","Build and test iOS apps on simulator using XcodeBuildMCP. Use after making iOS code changes, before creating a PR, or when verifying app behavior and checking for crashes on simulator.","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Ftest-xcode\u002FSKILL.md",[136],{"categoryNo":137,"categoryName":138,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000008","测试与质量",[140,141,142,143,144,145,146,147,121,100,148,149,150,33,113,151,152,153,154,155],"test","xcode","test xcode","apps","app","build and test","pr","for","xcodebuildmcp","use","scheme","changes","build","ios","name","behavior"]