[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D3VC9ZTFRWSNJ1W6SPCC98":3,"skill-same:01M6D3VC9ZTFRWSNJ1W6SPCC98":83},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6D3VC9ZTFRWSNJ1W6SPCC98","idea-scope-brief",null,"Shape a rough product or project idea into a scoped brief before customer discovery, market research, specifications, UX, UI, or implementation planning","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\u002Fbase\u002Fcodex\u002Fidea-scope-brief\u002Farchive\u002Fv0.21\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,42],"idea scope brief","idea","brief","page","project","deep","alignment","Market","implementation","shape","v0","research","market research","discovery","ui","ux","product","planning","customer","2026-11-10 10:12:30",false,"---\nname: idea-scope-brief\ndescription: Shape a rough product or project idea into a scoped brief before customer discovery, market research, specifications, UX, UI, or implementation planning\ntype: planning\nversion: v0.21\nrequired_conventions: [alignment-page, interrogation-page]\nargument-hint: \"[optional rough idea, product thought, or product-path scope]\"\ncontext_intake: deep\n---\n\n# Idea Scope Brief\n\nInvoke as `$idea-scope-brief`.\n\nUse this skill when the user has a half-formed idea and needs it cleaned up enough to enter the normal research and planning workflow. This skill is intentionally pre-customer-discovery: it clarifies the concept, problem hypothesis, beneficiary hypothesis, value wedge, constraints, non-goals, and unknowns, but does not select a validated target-customer segment, analyze competitors, define UX\u002FUI, choose architecture, decide platform fit, or write implementation specs.\n\n## Process\n\n### 0. Product-Path Scope Resolution\n\nResolve research 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, not the customer, audience, or segment label.\n2. If `$ARGUMENTS` names only `research\u002F_archive\u002F{slug}\u002F` or a manifest entry with `status: archived` or legacy `status: abandoned`, stop and warn that the path is archived; do not write or update scoped outputs there.\n3. Read `research\u002F.progress.yaml` when present. Normalize legacy `active_path` to `active_paths` on read and write back `active_paths` on manifest updates. Treat legacy `abandoned` as `archived`; exclude `archived`, `abandoned`, `deferred`, `revisit_candidate`, `promoted`, and any `scope_path` under `research\u002F_archive\u002F` from active target selection.\n4. If active product paths exist in the manifest, use those paths. If multiple active paths exist, ask which one to target unless this skill explicitly supports cross-path output.\n5. If no active manifest target exists, list non-archived product directories under `research\u002F`, excluding `research\u002F_archive\u002F` and dot directories. Auto-select only when exactly one exists; ask when multiple exist.\n6. If no product directories exist, use flat `research\u002F` single-product mode.\n7. Detect monorepo\u002Fapp\u002Fpackage structure only as a secondary hint. Suggest creating a missing `research\u002F{slug}\u002F` product path when code clearly exposes an app, but do not require code or monorepo detection before using `research\u002F{slug}\u002F`.\n\nWhen product path `{slug}` is active, read and write research under `research\u002F{slug}\u002F`, specs under `specs\u002F{slug}\u002F`, and treat top-level `research\u002F*.md` files as flat-mode documents or cross-path summaries.\n\n1. **Resolve context**\n   - Read `.agents\u002Fproject.json` if it exists.\n   - **BIP Suggestion Gate** (advisory; never blocks this skill's work). After reading `.agents\u002Fproject.json`: if `alignment.build_in_public === true`, skip only the enablement prompt and remember that post-confirmation BIP output is required. Else if `alignment.bip_prompt_dismissed === true`, skip enablement and do not generate BIP unless the user explicitly invoked `--bip`. Otherwise ask the user once, concisely — explain that Build-In-Public mode generates source-safe social post candidates from your alignment pages and shipped work, and ask whether to enable it for this project. On **yes**: run `scripts\u002Fpack.sh set-bip on` (or `npx skillpacks set-bip on`) **and** `scripts\u002Fpack.sh set-bip-prompt dismiss` (or the `npx` equivalent), remember that post-confirmation BIP output is required, then continue. On **no**: run `scripts\u002Fpack.sh set-bip-prompt dismiss` (or the `npx` equivalent) and do not ask again. Do not create a separate pre-approval BIP page during kickoff; enabled BIP generates `alignment\u002Fbip-idea-scope-brief.html` only after approved canonical `idea-brief.md` artifacts are written and the alignment page is confirmed.\n   - Read canonical deck metadata from `docs\u002Fdecks.md` when present and from skillpacks manifest `decks[]` metadata when available. Use deck fields such as `name`, `title`, `domain`, `tempo`, `default_packs`, and `full_packs` as routing evidence.\n   - Read repo-saved deck candidates from `.agents\u002Fproject.json` before canonical fallbacks. Recognize top-level `saved_decks` and `decks` fields when present; entries may be strings or objects with fields such as `name`, `slug`, `title`, `domain`, `tempo`, `packs`, `install`, `install_command`, `description`, or `notes`.\n   - Read README, CLAUDE.md, AGENTS.md, existing `research\u002F`, `specs\u002F`, and task docs when present.\n   - Determine whether the current directory is already a bootstrapped project. Treat it as bootstrapped when it has meaningful `README.md` plus `AGENTS.md` or `CLAUDE.md`; treat it as unbootstrapped when those are missing, placeholder-only, or the user is describing an idea outside any project repo.\n   - If `$ARGUMENTS` contains a rough idea, use it as the starting draft.\n   - If `$ARGUMENTS` names a non-archived `research\u002F{slug}\u002F` product path, use that path. If it names only `research\u002F_archive\u002F{slug}\u002F`, stop and warn that the path is archived.\n   - Determine the concept identity and a normalized concept slug as soon as either is known from `$ARGUMENTS`, repo context, or the interview. Normalize by lowercasing, removing URL suffix noise, replacing non-alphanumeric runs with `-`, trimming leading\u002Ftrailing `-`, and dropping only project-wide brand prefixes when the remaining word is the actual scoped concept (for example, `poketo.work` -> `work`; `Poketo Core` -> `poketo-core`).\n   - If existing research or the prompt suggests multiple related concepts may exist, prefer slugged output paths over generic filenames. Reserve generic `idea-brief.md` only for a single unambiguous project-level concept.\n   - If no rough idea is available from arguments or repo context, ask the user for the idea in plain language.\n   - Read `research\u002F.progress.yaml` when present. Normalize `active_path` (singular legacy) to `active_paths` (plural list) when reading; treat legacy `abandoned` as `archived` and exclude archived\u002Fdeferred\u002Frevisit\u002Fpromoted paths plus `research\u002F_archive\u002F` scopes from active target selection. Treat `active_paths` as the current product\u002Fapp\u002Fcustomer focuses and `product_paths[]` as parked, archived, or promoted product-path state, not git branch state.\n   - When the prompt, repo context, interview, or pivot history surfaces multiple related concepts, apps, product lines, or future pivots, update or propose updates to `research\u002F.progress.yaml` with product-path entries instead of merging them into one generic concept. Use fields: `id`, `label`, `scope_path`, `status`, `source_skill`, `reason`, `archive_reason`, `archived_at`, `promoted_at`, `evidence_refs`, `revisit_trigger`, `next_skill`, `pipeline_stage`, and `last_touched`. Set `pipeline_stage: idea-scope-brief` on entries created by this skill.\n   - Keep the central concept in `active_paths` when it is the current focus. Record related or future concepts as `status: deferred` or `status: revisit_candidate` with a concrete revisit trigger and a likely next skill such as `$customer-discovery \u003Cpath\u002Faudience>`; if `business-research` is not enabled, recommend `npx skillpacks install business-research` from the project shell, before `$customer-discovery`.\n   - When 3+ product paths exist in the manifest, recommend `$product-line review` to the user for portfolio management; if `business-ops` is not enabled, recommend `npx skillpacks install business-ops` from the project shell, before `$product-line`.\n\n2. **Keep the boundary clear**\n   - Do not run customer discovery, competitive analysis, journey mapping, UX variation, UI interview, roadmap, or implementation planning inside this skill.\n   - Do not validate the market with broad web research. Use light repo\u002Fcontext inspection only; downstream research skills own evidence gathering.\n   - Treat every user claim as a hypothesis unless supported by existing project files.\n\nSteps 3–5 are the **stage-zero interrogation loop** (see `## Interrogation Page` \u002F `INTERROGATION-PAGE.md`): elicit the concept in HTML interrogation rounds before the stage-two alignment preview in step 6. Round 1 is the Idea Assumptions Manifest, rounds 2..N are adaptive follow-ups, and the step-5 coverage checkpoint is the loop's confidence-gate exit. This skill **cannot advance to the alignment preview until** the confidence gate passes with at least one completed round and every area covered or waived. Terminal questioning is the degraded fallback only when an HTML page cannot be opened.\n\n3. **Surface an Idea Assumptions Manifest (interrogation round 1)**\n   - Before deep questioning, present what you think the concept is.\n   - Tag assumptions as `[from prompt]`, `[from repo]`, `[from research]`, or `[inferred]`.\n   - Cover:\n     - concept summary\n     - problem hypothesis\n     - target beneficiary or user hypothesis\n     - product\u002Fcategory guess\n     - early platform hints as hypotheses only, when the prompt clearly suggests web, mobile, CLI, API, SDK, extension, marketplace, integration, desktop, game, or other platform shape\n     - value wedge\n     - constraints\n     - non-goals\n     - riskiest unknowns\n   - Render the assumptions as confirm\u002Fcorrect\u002Fflag controls in `interrogation\u002Fidea-scope-brief-r1-{branch}.html`, alongside the first batch of genuinely open questions (each marked `data-open-input`) where no assumption is derivable. Set `data-interrogation-round=\"1\"`, `data-interrogation-gate=\"continue\"`, and the answer sidecar `research\u002F_working\u002Finterrogation-idea-scope-brief-r1.yaml`, open the page, and stop for the compiled round YAML.\n   - Terminal fallback only: deliver the manifest inline as the final message text of its own turn; ask the confirmation question in the next turn (consistent with the one-question-per-turn cadence). Never emit it only as mid-turn text in a turn that ends with a tool or command call — harness rendering does not guarantee mid-turn text is shown. A confirmation question must never reference content the user has not been shown.\n\n### Market Structure Handoff\n\nDuring the Idea Assumptions Manifest, if the concept appears marketplace\u002Fplatform\u002FB2B2C\u002Fmulti-sided, add a compact `Market Structure Handoff` note:\n\n- Name the apparent sides and the expected value exchange between them.\n- Mark those sides and exchanges as hypotheses, not validated customer segments; do not decide which side is the customer, buyer, or primary target segment here.\n- Keep the source tag for each side as `[from prompt]`, `[from repo]`, or `[inferred]` unless the user provides a correction.\n- If the concept appears single-sided, omit the handoff or state that no marketplace\u002Fplatform\u002FB2B2C\u002Fmulti-sided handoff is apparent.\n\n### Platform Hint Handoff\n\nDuring the Idea Assumptions Manifest, record early platform hints only as hypotheses. Name the apparent platform shape when the prompt or repo context clearly suggests it, but do not rank platforms, choose a primary platform, or reject alternatives here. The **Platform Fit Workshop** in `$user-flow-map` owns the broad candidate set, platform ranking, platform probes, and production-platform recommendation.\n\n### Deck Fit Handoff\n\nDuring the Idea Assumptions Manifest and final idea brief, add a compact `Deck Fit Handoff` that routes the concept to the closest workflow deck when confidence is high:\n\n1. **Build candidates**\n   - Prefer saved repo candidates from `.agents\u002Fproject.json` `saved_decks` or `decks` when present. Rank them against the concept before canonical fallbacks.\n   - Fall back to the canonical deck set from `docs\u002Fdecks.md` or skillpacks manifest metadata: `vard`, `ord`, `business-afps`, `devtool-afps`, and `game-afps`.\n   - Treat a saved deck as canonical only when its `name` or `slug` preserves one of the canonical slugs and the entry does not materially override its packs or install command.\n2. **Rank by domain, tempo, and concept signals**\n   - Domain: route video games, prototypes, playable entertainment, game engines, store-page tests, playtests, and game assets to `game-afps`; route SDKs, CLIs, APIs, libraries, npm packages, OSS utilities, infrastructure products, developer platforms, and documentation-first developer workflows to developer decks; route SaaS, marketplaces, productivity apps, internal\u002Fadmin tools, business workflows, and consumer apps to business\u002Fconsumer decks.\n   - Tempo: route day\u002Fweek experiments, quick viral app tests, lightweight npm\u002FCLI\u002Flibrary ideas, and low-investment distribution probes to rapid decks; route products, platforms, SDK\u002FAPI strategies, SaaS\u002Fbusiness concepts, lifecycle\u002Fgrowth work, or anything needing weeks\u002Fmonths of validation to deliberate decks.\n   - Evidence priority: user prompt and interview corrections outrank repo defaults; existing research\u002Fspec\u002Ftask files outrank inferred code shape; `.agents\u002Fproject.json project_type` is a tie-breaker, not the primary signal.\n   - Confidence is high only when domain and tempo both match and no strong contrary signal remains. If confidence is not high, do not force a deck as the primary command; use the fallback routing rules in `## Next Steps`.\n3. **Default canonical examples**\n   - Game or playable entertainment concept -> `game-afps`.\n   - Lightweight OSS\u002Fdevtool\u002Fnpm\u002FCLI\u002Flibrary idea -> `ord`.\n   - Deliberate devtool\u002Fplatform\u002FSDK\u002FAPI product -> `devtool-afps`.\n   - Rapid consumer\u002Fbusiness experiment -> `vard`.\n   - Deliberate business\u002FSaaS\u002Fconsumer product -> `business-afps`.\n4. **Render the handoff**\n   - Include deck slug\u002Ftitle, source (`saved_decks`, `decks`, `docs\u002Fdecks.md`, or manifest), domain fit, tempo fit, confidence, key evidence signals, and the install command.\n   - For canonical decks, the primary install command is `npx skillpacks install-deck \u003Cdeck>`.\n   - For customized saved decks, do not use `install-deck` unless they preserve a canonical slug as described above. Use the saved `install_command` \u002F `install` when present, or explicit package-install guidance such as `npx skillpacks install \u003Cpack...>` when the saved entry lists packs.\n   - After a deck recommendation exists, keep downstream skill routing as secondary context only. For example, after `business-afps` installs the `business-research` pack, name the likely first post-install skill (`$customer-discovery`, `$devtool-positioning`, `$ord-scan`, `$vard-scan`, or `$game-audience`) without making it the primary command.\n\n4. **Interrogate until concept-ready (adaptive rounds 2..N)**\n   - Build adaptive follow-up interrogation rounds (`interrogation\u002Fidea-scope-brief-r{N}-{branch}.html`) seeded by the prior round's compiled answers, each with at least one open input (`data-open-input`) and its own answer sidecar.\n   - Terminal fallback cadence is one primary decision question per turn by default. Use short follow-up bullets only when they clarify the same decision, not to batch unrelated questions.\n   - Resolve only concept-level ambiguity:\n     - what problem exists\n     - who might care\n     - what outcome changes for them\n     - what makes the idea different enough to investigate\n     - what must stay out of scope\n     - what constraints are real now\n   - When unsure, recommend a practical default and clearly mark it as an assumption.\n\n5. **Coverage checkpoint**\n   - This checkpoint is the interrogation loop's **confidence-gate exit**: build the exit interrogation round with `data-interrogation-gate=\"coverage-checkpoint\"` presenting the final concept summary, unknowns, and readiness for customer discovery. Do not advance to step 6 until the user confirms completeness or every area is waived; flagging a gap raises the round number and continues the loop. (Terminal fallback: present the checkpoint inline per the Manifest Visibility Rule.)\n   - Restate the resolved concept identity, slug, and exact output paths before writing.\n   - If the conversation pivoted from the initial concept to a different central concept, write the pivoted concept to its own slugged brief and preserve the initial concept as a related or future concept in the brief and interview log. Do not merge both concepts into one generic project-level brief.\n   - Ask whether any core premise, constraint, or non-goal is wrong before writing.\n\n6. **Build pre-approval alignment preview**\n   - Before writing any canonical `research\u002F**\u002Fidea-brief.md`, `research\u002F**\u002Fidea-brief-interview.md`, legacy flat `research\u002Fidea-brief-{slug}.md` variant, or `research\u002F.progress.yaml`, build `alignment\u002Fidea-scope-brief-{topic}.html` as the review artifact.\n   - The HTML page must render the Idea\u002FConcept Assumptions Manifest, artifact destinations, proposed file changes, coverage checkpoint, and approval gates, including any Market Structure Handoff and Deck Fit Handoff.\n   - Attempt to open the page in the browser and point the user at the repo-relative path.\n   - Treat coverage-checkpoint confirmation as non-final; it only confirms the draft scope is ready to preview. Only final compiled YAML from the alignment page authorizes canonical writes.\n   - Before compiled YAML approval, the next action is review or revision of the HTML alignment page. Do not include `Recommended next skill`, `Recommended next command`, or downstream routing language until after final compiled YAML approval has been provided and the approved artifacts below have been written or updated.\n   - When feedback-only YAML is provided, revise the alignment page and ask again; do not write canonical artifacts until final compiled YAML approval is provided.\n\n### Review-Only Product Path Approval\n\nWhen the user approves a product-path fork or split at the alignment page level but explicitly withholds canonical-write approval (e.g., \"review only, do not write canonical files\"):\n\n1. **Do not write canonical files.** Keep `research\u002F.progress.yaml`, `research\u002F{slug}\u002Fidea-brief.md`, and `research\u002F{slug}\u002Fidea-brief-interview.md` unchanged.\n2. **Render fully in the alignment page.** The proposed manifest entry, idea brief sections, and interview log for the review-only path must be rendered in full in the alignment page HTML — not summarized, linked, or embedded.\n3. **Mark the page as review-only-approved.** Set `approval_status: review-only-approved` in the alignment page status block. This is distinct from `confirmed` (canonical artifacts written) and `review` (awaiting any approval).\n4. **Downstream treatment.** Downstream skills must treat a review-only-approved path as provisional: it may be referenced as concept context, but it is not a canonical product path until manifest approval is later granted via a subsequent alignment cycle. See the provisional-path evidence rule in customer-discovery and competitive-analysis contracts.\n\n## Output\n\nBefore writing anything in this section, verify the alignment page has final compiled YAML approval. Do not write canonical idea briefs, interview logs, or `research\u002F.progress.yaml` until `alignment\u002Fidea-scope-brief-{topic}.html` has been reviewed and the user has provided final compiled YAML approval. Coverage-checkpoint confirmation is not final approval and does not authorize these writes.\n\nWrite:\n\n- For one unambiguous project-level concept only: `research\u002Fidea-brief.md` and `research\u002Fidea-brief-interview.md`.\n- When a product identity is known, multiple concepts exist or may exist, or a pivot occurs: prefer `research\u002F{slug}\u002Fidea-brief.md` and `research\u002F{slug}\u002Fidea-brief-interview.md`; preserve flat `research\u002Fidea-brief-{slug}.md` only as legacy compatibility when no product path is being introduced.\n- If `$ARGUMENTS` names a non-archived product path, use unsuffixed scoped files under `research\u002F{slug}\u002F`: `research\u002F{slug}\u002Fidea-brief.md` and `research\u002F{slug}\u002Fidea-brief-interview.md`.\n- `research\u002F.progress.yaml` — create or update only when multiple concepts, product paths, product lines, product-path scopes, or pivots are present. Use `product_paths` terminology instead of branch terminology.\n\nIf BIP is enabled by project config, explicit `--bip`, or this run's BIP Suggestion Gate yes-response, then after approved canonical idea-brief artifacts are written and `alignment\u002Fidea-scope-brief-{topic}.html` is confirmed, generate the read-only post-confirmation BIP page at `alignment\u002Fbip-idea-scope-brief.html`. Archive any previous page at that path before replacement, include it in `alignment\u002Findex.html`, load every bundled social post and video convention, rank exhaustive source-safe candidates for every bundled channel, and open the page after the skill concludes. This BIP page is help\u002Freview content only; it does not publish posts, write social-ledger records, or require another approval before downstream routing.\n\nThe idea brief must include:\n\n- `## Summary`\n- `## Problem Hypothesis`\n- `## Beneficiary Hypothesis`\n- `## Product Category Guess`\n- `## Value Wedge`\n- `## Constraints`\n- `## Non-Goals`\n- `## Assumptions And Unknowns`\n- `## Customer Discovery Readiness`\n- `## Deck Fit Handoff`\n- `## Next Steps`\n\nThe `## Customer Discovery Readiness` section must state whether the concept is ready for `$customer-discovery`, what inputs `$customer-discovery` should use, and which assumptions should be tested first. If a Market Structure Handoff exists, include the apparent sides and value exchange as explicit inputs for `$customer-discovery` to validate or refute. If a high-confidence Deck Fit Handoff exists, explain that deck installation is the primary next command and customer discovery or other first workflow skills are secondary post-install context.\n\nThe `## Deck Fit Handoff` section must state the best candidate deck, whether it came from saved repo config or canonical fallback metadata, the confidence level, the domain\u002Ftempo signals, the install command, and the likely first post-install skill. If no deck has high confidence, state the strongest candidates and why fallback routing is safer.\n\nThe `## Next Steps` section must recommend exactly one primary command:\n\n- If Deck Fit Handoff confidence is high for a canonical deck: `npx skillpacks install-deck \u003Cdeck>`.\n- If Deck Fit Handoff confidence is high for a customized saved deck with an explicit install command: use that exact saved install command.\n- If Deck Fit Handoff confidence is high for a customized saved deck with a pack list but no install command: `npx skillpacks install \u003Cpack...>`.\n- If no deck has high confidence and the concept appears to be a business app or user-facing product while the business research lane is not enabled: `npx skillpacks install business-research` from the project shell — this installs the research skills (customer discovery, competitive analysis, value prop, positioning, lean canvas) needed before any repo bootstrapping or development.\n- If no deck has high confidence and `business-research` or the compatibility `business-app` alias is enabled: `$customer-discovery`.\n- If no deck has high confidence and the concept already has customer-discovery\u002Fmarket evidence but needs journey, onboarding, conversion, or retention planning: `npx skillpacks install customer-lifecycle` from the project shell.\n- If no deck has high confidence and project type is unclear: `scripts\u002Fpack.sh recommend`.\n\nWhen a deck primary command is available, downstream research, discovery, or first-workflow skill routing must appear only as secondary context, not as the primary command.\n\nInclude 1-3 other options only when they are materially useful.\n\n### Alignment Page\n\nFollow `ALIGNMENT-PAGE.md` in this skill's directory for alignment-page requirements and output path.\n\n## Constraints\n\n- Keep the skill short and pre-research.\n- Do not write specs, UX variants, UI specs, roadmap phases, or implementation tasks.\n- Do not recommend `$scaffold` unless the user explicitly asks to create a package\u002Fapp shell before research; normal product flow scaffolds after research, prototype consolidation, spec, roadmap, and phase planning identify the first implementation target. `$scaffold` requires the monorepo pack (`npx skillpacks install monorepo` from the project shell).\n- Do not update `tasks\u002Ftodo.md`.\n- New files do not need archive snapshots. Before replacing an existing idea brief, including slugged briefs, archive it to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-relative-path>`.\n- Migration: if a project already has `research\u002Fconcept-brief.md`, `research\u002Fconcept-brief-interview.md`, or any `research\u002F{slug}\u002Fconcept-brief*.md` \u002F `research\u002Fconcept-brief-{slug}*.md` from a prior run, rename it to the `idea-brief` equivalent before re-running. Write only the `idea-brief` names and no longer recognizes the legacy `concept-brief` filenames.\n\n## Interrogation Page\n\nBefore producing research, run the stage-zero interrogation loop following `INTERROGATION-PAGE.md` in this skill's directory. Build one HTML page per round at `interrogation\u002Fidea-scope-brief-r{N}-{branch}.html`, starting with the assumptions manifest as round 1, and loop until the confidence gate passes. This skill **cannot advance to stage one until** the confidence gate passes with at least one completed interrogation round and every interview area covered or waived. Each round page must contain at least one genuinely open input (`data-open-input`).\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","# Idea Scope Brief\n\nInvoke as `$idea-scope-brief`.\n\nUse this skill when the user has a half-formed idea and needs it cleaned up enough to enter the normal research and planning workflow. This skill is intentionally pre-customer-discovery: it clarifies the concept, problem hypothesis, beneficiary hypothesis, value wedge, constraints, non-goals, and unknowns, but does not select a validated target-customer segment, analyze competitors, define UX\u002FUI, choose architecture, decide platform fit, or write implementation specs.\n\n## Process\n\n### 0. Product-Path Scope Resolution\n\nResolve research 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, not the customer, audience, or segment label.\n2. If `$ARGUMENTS` names only `research\u002F_archive\u002F{slug}\u002F` or a manifest entry with `status: archived` or legacy `status: abandoned`, stop and warn that the path is archived; do not write or update scoped outputs there.\n3. Read `research\u002F.progress.yaml` when present. Normalize legacy `active_path` to `active_paths` on read and write back `active_paths` on manifest updates. Treat legacy `abandoned` as `archived`; exclude `archived`, `abandoned`, `deferred`, `revisit_candidate`, `promoted`, and any `scope_path` under `research\u002F_archive\u002F` from active target selection.\n4. If active product paths exist in the manifest, use those paths. If multiple active paths exist, ask which one to target unless this skill explicitly supports cross-path output.\n5. If no active manifest target exists, list non-archived product directories under `research\u002F`, excluding `research\u002F_archive\u002F` and dot directories. Auto-select only when exactly one exists; ask when multiple exist.\n6. If no product directories exist, use flat `research\u002F` single-product mode.\n7. Detect monorepo\u002Fapp\u002Fpackage structure only as a secondary hint. Suggest creating a missing `research\u002F{slug}\u002F` product path when code clearly exposes an app, but do not require code or monorepo detection before using `research\u002F{slug}\u002F`.\n\nWhen product path `{slug}` is active, read and write research under `research\u002F{slug}\u002F`, specs under `specs\u002F{slug}\u002F`, and treat top-level `research\u002F*.md` files as flat-mode documents or cross-path summaries.\n\n1. **Resolve context**\n   - Read `.agents\u002Fproject.json` if it exists.\n   - **BIP Suggestion Gate** (advisory; never blocks this skill's work). After reading `.agents\u002Fproject.json`: if `alignment.build_in_public === true`, skip only the enablement prompt and remember that post-confirmation BIP output is required. Else if `alignment.bip_prompt_dismissed === true`, skip enablement and do not generate BIP unless the user explicitly invoked `--bip`. Otherwise ask the user once, concisely — explain that Build-In-Public mode generates source-safe social post candidates from your alignment pages and shipped work, and ask whether to enable it for this project. On **yes**: run `scripts\u002Fpack.sh set-bip on` (or `npx skillpacks set-bip on`) **and** `scripts\u002Fpack.sh set-bip-prompt dismiss` (or the `npx` equivalent), remember that post-confirmation BIP output is required, then continue. On **no**: run `scripts\u002Fpack.sh set-bip-prompt dismiss` (or the `npx` equivalent) and do not ask again. Do not create a separate pre-approval BIP page during kickoff; enabled BIP generates `alignment\u002Fbip-idea-scope-brief.html` only after approved canonical `idea-brief.md` artifacts are written and the alignment page is confirmed.\n   - Read canonical deck metadata from `docs\u002Fdecks.md` when present and from skillpacks manifest `decks[]` metadata when available. Use deck fields such as `name`, `title`, `domain`, `tempo`, `default_packs`, and `full_packs` as routing evidence.\n   - Read repo-saved deck candidates from `.agents\u002Fproject.json` before canonical fallbacks. Recognize top-level `saved_decks` and `decks` fields when present; entries may be strings or objects with fields such as `name`, `slug`, `title`, `domain`, `tempo`, `packs`, `install`, `install_command`, `description`, or `notes`.\n   - Read README, CLAUDE.md, AGENTS.md, existing `research\u002F`, `specs\u002F`, and task docs when present.\n   - Determine whether the current directory is already a bootstrapped project. Treat it as bootstrapped when it has meaningful `README.md` plus `AGENTS.md` or `CLAUDE.md`; treat it as unbootstrapped when those are missing, placeholder-only, or the user is describing an idea outside any project repo.\n   - If `$ARGUMENTS` contains a rough idea, use it as the starting draft.\n   - If `$ARGUMENTS` names a non-archived `research\u002F{slug}\u002F` product path, use that path. If it names only `research\u002F_archive\u002F{slug}\u002F`, stop and warn that the path is archived.\n   - Determine the concept identity and a normalized concept slug as soon as either is known from `$ARGUMENTS`, repo context, or the interview. Normalize by lowercasing, removing URL suffix noise, replacing non-alphanumeric runs with `-`, trimming leading\u002Ftrailing `-`, and dropping only project-wide brand prefixes when the remaining word is the actual scoped concept (for example, `poketo.work` -> `work`; `Poketo Core` -> `poketo-core`).\n   - If existing research or the prompt suggests multiple related concepts may exist, prefer slugged output paths over generic filenames. Reserve generic `idea-brief.md` only for a single unambiguous project-level concept.\n   - If no rough idea is available from arguments or repo context, ask the user for the idea in plain language.\n   - Read `research\u002F.progress.yaml` when present. Normalize `active_path` (singular legacy) to `active_paths` (plural list) when reading; treat legacy `abandoned` as `archived` and exclude archived\u002Fdeferred\u002Frevisit\u002Fpromoted paths plus `research\u002F_archive\u002F` scopes from active target selection. Treat `active_paths` as the current product\u002Fapp\u002Fcustomer focuses and `product_paths[]` as parked, archived, or promoted product-path state, not git branch state.\n   - When the prompt, repo context, interview, or pivot history surfaces multiple related concepts, apps, product lines, or future pivots, update or propose updates to `research\u002F.progress.yaml` with product-path entries instead of merging them into one generic concept. Use fields: `id`, `label`, `scope_path`, `status`, `source_skill`, `reason`, `archive_reason`, `archived_at`, `promoted_at`, `evidence_refs`, `revisit_trigger`, `next_skill`, `pipeline_stage`, and `last_touched`. Set `pipeline_stage: idea-scope-brief` on entries created by this skill.\n   - Keep the central concept in `active_paths` when it is the current focus. Record related or future concepts as `status: deferred` or `status: revisit_candidate` with a concrete revisit trigger and a likely next skill such as `$customer-discovery \u003Cpath\u002Faudience>`; if `business-research` is not enabled, recommend `npx skillpacks install business-research` from the project shell, before `$customer-discovery`.\n   - When 3+ product paths exist in the manifest, recommend `$product-line review` to the user for portfolio management; if `business-ops` is not enabled, recommend `npx skillpacks install business-ops` from the project shell, before `$product-line`.\n\n2. **Keep the boundary clear**\n   - Do not run customer discovery, competitive analysis, journey mapping, UX variation, UI interview, roadmap, or implementation planning inside this skill.\n   - Do not validate the market with broad web research. Use light repo\u002Fcontext inspection only; downstream research skills own evidence gathering.\n   - Treat every user claim as a hypothesis unless supported by existing project files.\n\nSteps 3–5 are the **stage-zero interrogation loop** (see `## Interrogation Page` \u002F `INTERROGATION-PAGE.md`): elicit the concept in HTML interrogation rounds before the stage-two alignment preview in step 6. Round 1 is the Idea Assumptions Manifest, rounds 2..N are adaptive follow-ups, and the step-5 coverage checkpoint is the loop's confidence-gate exit. This skill **cannot advance to the alignment preview until** the confidence gate passes with at least one completed round and every area covered or waived. Terminal questioning is the degraded fallback only when an HTML page cannot be opened.\n\n3. **Surface an Idea Assumptions Manifest (interrogation round 1)**\n   - Before deep questioning, present what you think the concept is.\n   - Tag assumptions as `[from prompt]`, `[from repo]`, `[from research]`, or `[inferred]`.\n   - Cover:\n     - concept summary\n     - problem hypothesis\n     - target beneficiary or user hypothesis\n     - product\u002Fcategory guess\n     - early platform hints as hypotheses only, when the prompt clearly suggests web, mobile, CLI, API, SDK, extension, marketplace, integration, desktop, game, or other platform shape\n     - value wedge\n     - constraints\n     - non-goals\n     - riskiest unknowns\n   - Render the assumptions as confirm\u002Fcorrect\u002Fflag controls in `interrogation\u002Fidea-scope-brief-r1-{branch}.html`, alongside the first batch of genuinely open questions (each marked `data-open-input`) where no assumption is derivable. Set `data-interrogation-round=\"1\"`, `data-interrogation-gate=\"continue\"`, and the answer sidecar `research\u002F_working\u002Finterrogation-idea-scope-brief-r1.yaml`, open the page, and stop for the compiled round YAML.\n   - Terminal fallback only: deliver the manifest inline as the final message text of its own turn; ask the confirmation question in the next turn (consistent with the one-question-per-turn cadence). Never emit it only as mid-turn text in a turn that ends with a tool or command call — harness rendering does not guarantee mid-turn text is shown. A confirmation question must never reference content the user has not been shown.\n\n### Market Structure Handoff\n\nDuring the Idea Assumptions Manifest, if the concept appears marketplace\u002Fplatform\u002FB2B2C\u002Fmulti-sided, add a compact `Market Structure Handoff` note:\n\n- Name the apparent sides and the expected value exchange between them.\n- Mark those sides and exchanges as hypotheses, not validated customer segments; do not decide which side is the customer, buyer, or primary target segment here.\n- Keep the source tag for each side as `[from prompt]`, `[from repo]`, or `[inferred]` unless the user provides a correction.\n- If the concept appears single-sided, omit the handoff or state that no marketplace\u002Fplatform\u002FB2B2C\u002Fmulti-sided handoff is apparent.\n\n### Platform Hint Handoff\n\nDuring the Idea Assumptions Manifest, record early platform hints only as hypotheses. Name the apparent platform shape when the prompt or repo context clearly suggests it, but do not rank platforms, choose a primary platform, or reject alternatives here. The **Platform Fit Workshop** in `$user-flow-map` owns the broad candidate set, platform ranking, platform probes, and production-platform recommendation.\n\n### Deck Fit Handoff\n\nDuring the Idea Assumptions Manifest and final idea brief, add a compact `Deck Fit Handoff` that routes the concept to the closest workflow deck when confidence is high:\n\n1. **Build candidates**\n   - Prefer saved repo candidates from `.agents\u002Fproject.json` `saved_decks` or `decks` when present. Rank them against the concept before canonical fallbacks.\n   - Fall back to the canonical deck set from `docs\u002Fdecks.md` or skillpacks manifest metadata: `vard`, `ord`, `business-afps`, `devtool-afps`, and `game-afps`.\n   - Treat a saved deck as canonical only when its `name` or `slug` preserves one of the canonical slugs and the entry does not materially override its packs or install command.\n2. **Rank by domain, tempo, and concept signals**\n   - Domain: route video games, prototypes, playable entertainment, game engines, store-page tests, playtests, and game assets to `game-afps`; route SDKs, CLIs, APIs, libraries, npm packages, OSS utilities, infrastructure products, developer platforms, and documentation-first developer workflows to developer decks; route SaaS, marketplaces, productivity apps, internal\u002Fadmin tools, business workflows, and consumer apps to business\u002Fconsumer decks.\n   - Tempo: route day\u002Fweek experiments, quick viral app tests, lightweight npm\u002FCLI\u002Flibrary ideas, and low-investment distribution probes to rapid decks; route products, platforms, SDK\u002FAPI strategies, SaaS\u002Fbusiness concepts, lifecycle\u002Fgrowth work, or anything needing weeks\u002Fmonths of validation to deliberate decks.\n   - Evidence priority: user prompt and interview corrections outrank repo defaults; existing research\u002Fspec\u002Ftask files outrank inferred code shape; `.agents\u002Fproject.json project_type` is a tie-breaker, not the primary signal.\n   - Confidence is high only when domain and tempo both match and no strong contrary signal remains. If confidence is not high, do not force a deck as the primary command; use the fallback routing rules in `## Next Steps`.\n3. **Default canonical examples**\n   - Game or playable entertainment concept -> `game-afps`.\n   - Lightweight OSS\u002Fdevtool\u002Fnpm\u002FCLI\u002Flibrary idea -> `ord`.\n   - Deliberate devtool\u002Fplatform\u002FSDK\u002FAPI product -> `devtool-afps`.\n   - Rapid consumer\u002Fbusiness experiment -> `vard`.\n   - Deliberate business\u002FSaaS\u002Fconsumer product -> `business-afps`.\n4. **Render the handoff**\n   - Include deck slug\u002Ftitle, source (`saved_decks`, `decks`, `docs\u002Fdecks.md`, or manifest), domain fit, tempo fit, confidence, key evidence signals, and the install command.\n   - For canonical decks, the primary install command is `npx skillpacks install-deck \u003Cdeck>`.\n   - For customized saved decks, do not use `install-deck` unless they preserve a canonical slug as described above. Use the saved `install_command` \u002F `install` when present, or explicit package-install guidance such as `npx skillpacks install \u003Cpack...>` when the saved entry lists packs.\n   - After a deck recommendation exists, keep downstream skill routing as secondary context only. For example, after `business-afps` installs the `business-research` pack, name the likely first post-install skill (`$customer-discovery`, `$devtool-positioning`, `$ord-scan`, `$vard-scan`, or `$game-audience`) without making it the primary command.\n\n4. **Interrogate until concept-ready (adaptive rounds 2..N)**\n   - Build adaptive follow-up interrogation rounds (`interrogation\u002Fidea-scope-brief-r{N}-{branch}.html`) seeded by the prior round's compiled answers, each with at least one open input (`data-open-input`) and its own answer sidecar.\n   - Terminal fallback cadence is one primary decision question per turn by default. Use short follow-up bullets only when they clarify the same decision, not to batch unrelated questions.\n   - Resolve only concept-level ambiguity:\n     - what problem exists\n     - who might care\n     - what outcome changes for them\n     - what makes the idea different enough to investigate\n     - what must stay out of scope\n     - what constraints are real now\n   - When unsure, recommend a practical default and clearly mark it as an assumption.\n\n5. **Coverage checkpoint**\n   - This checkpoint is the interrogation loop's **confidence-gate exit**: build the exit interrogation round with `data-interrogation-gate=\"coverage-checkpoint\"` presenting the final concept summary, unknowns, and readiness for customer discovery. Do not advance to step 6 until the user confirms completeness or every area is waived; flagging a gap raises the round number and continues the loop. (Terminal fallback: present the checkpoint inline per the Manifest Visibility Rule.)\n   - Restate the resolved concept identity, slug, and exact output paths before writing.\n   - If the conversation pivoted from the initial concept to a different central concept, write the pivoted concept to its own slugged brief and preserve the initial concept as a related or future concept in the brief and interview log. Do not merge both concepts into one generic project-level brief.\n   - Ask whether any core premise, constraint, or non-goal is wrong before writing.\n\n6. **Build pre-approval alignment preview**\n   - Before writing any canonical `research\u002F**\u002Fidea-brief.md`, `research\u002F**\u002Fidea-brief-interview.md`, legacy flat `research\u002Fidea-brief-{slug}.md` variant, or `research\u002F.progress.yaml`, build `alignment\u002Fidea-scope-brief-{topic}.html` as the review artifact.\n   - The HTML page must render the Idea\u002FConcept Assumptions Manifest, artifact destinations, proposed file changes, coverage checkpoint, and approval gates, including any Market Structure Handoff and Deck Fit Handoff.\n   - Attempt to open the page in the browser and point the user at the repo-relative path.\n   - Treat coverage-checkpoint confirmation as non-final; it only confirms the draft scope is ready to preview. Only final compiled YAML from the alignment page authorizes canonical writes.\n   - Before compiled YAML approval, the next action is review or revision of the HTML alignment page. Do not include `Recommended next skill`, `Recommended next command`, or downstream routing language until after final compiled YAML approval has been provided and the approved artifacts below have been written or updated.\n   - When feedback-only YAML is provided, revise the alignment page and ask again; do not write canonical artifacts until final compiled YAML approval is provided.\n\n### Review-Only Product Path Approval\n\nWhen the user approves a product-path fork or split at the alignment page level but explicitly withholds canonical-write approval (e.g., \"review only, do not write canonical files\"):\n\n1. **Do not write canonical files.** Keep `research\u002F.progress.yaml`, `research\u002F{slug}\u002Fidea-brief.md`, and `research\u002F{slug}\u002Fidea-brief-interview.md` unchanged.\n2. **Render fully in the alignment page.** The proposed manifest entry, idea brief sections, and interview log for the review-only path must be rendered in full in the alignment page HTML — not summarized, linked, or embedded.\n3. **Mark the page as review-only-approved.** Set `approval_status: review-only-approved` in the alignment page status block. This is distinct from `confirmed` (canonical artifacts written) and `review` (awaiting any approval).\n4. **Downstream treatment.** Downstream skills must treat a review-only-approved path as provisional: it may be referenced as concept context, but it is not a canonical product path until manifest approval is later granted via a subsequent alignment cycle. See the provisional-path evidence rule in customer-discovery and competitive-analysis contracts.\n\n## Output\n\nBefore writing anything in this section, verify the alignment page has final compiled YAML approval. Do not write canonical idea briefs, interview logs, or `research\u002F.progress.yaml` until `alignment\u002Fidea-scope-brief-{topic}.html` has been reviewed and the user has provided final compiled YAML approval. Coverage-checkpoint confirmation is not final approval and does not authorize these writes.\n\nWrite:\n\n- For one unambiguous project-level concept only: `research\u002Fidea-brief.md` and `research\u002Fidea-brief-interview.md`.\n- When a product identity is known, multiple concepts exist or may exist, or a pivot occurs: prefer `research\u002F{slug}\u002Fidea-brief.md` and `research\u002F{slug}\u002Fidea-brief-interview.md`; preserve flat `research\u002Fidea-brief-{slug}.md` only as legacy compatibility when no product path is being introduced.\n- If `$ARGUMENTS` names a non-archived product path, use unsuffixed scoped files under `research\u002F{slug}\u002F`: `research\u002F{slug}\u002Fidea-brief.md` and `research\u002F{slug}\u002Fidea-brief-interview.md`.\n- `research\u002F.progress.yaml` — create or update only when multiple concepts, product paths, product lines, product-path scopes, or pivots are present. Use `product_paths` terminology instead of branch terminology.\n\nIf BIP is enabled by project config, explicit `--bip`, or this run's BIP Suggestion Gate yes-response, then after approved canonical idea-brief artifacts are written and `alignment\u002Fidea-scope-brief-{topic}.html` is confirmed, generate the read-only post-confirmation BIP page at `alignment\u002Fbip-idea-scope-brief.html`. Archive any previous page at that path before replacement, include it in `alignment\u002Findex.html`, load every bundled social post and video convention, rank exhaustive source-safe candidates for every bundled channel, and open the page after the skill concludes. This BIP page is help\u002Freview content only; it does not publish posts, write social-ledger records, or require another approval before downstream routing.\n\nThe idea brief must include:\n\n- `## Summary`\n- `## Problem Hypothesis`\n- `## Beneficiary Hypothesis`\n- `## Product Category Guess`\n- `## Value Wedge`\n- `## Constraints`\n- `## Non-Goals`\n- `## Assumptions And Unknowns`\n- `## Customer Discovery Readiness`\n- `## Deck Fit Handoff`\n- `## Next Steps`\n\nThe `## Customer Discovery Readiness` section must state whether the concept is ready for `$customer-discovery`, what inputs `$customer-discovery` should use, and which assumptions should be tested first. If a Market Structure Handoff exists, include the apparent sides and value exchange as explicit inputs for `$customer-discovery` to validate or refute. If a high-confidence Deck Fit Handoff exists, explain that deck installation is the primary next command and customer discovery or other first workflow skills are secondary post-install context.\n\nThe `## Deck Fit Handoff` section must state the best candidate deck, whether it came from saved repo config or canonical fallback metadata, the confidence level, the domain\u002Ftempo signals, the install command, and the likely first post-install skill. If no deck has high confidence, state the strongest candidates and why fallback routing is safer.\n\nThe `## Next Steps` section must recommend exactly one primary command:\n\n- If Deck Fit Handoff confidence is high for a canonical deck: `npx skillpacks install-deck \u003Cdeck>`.\n- If Deck Fit Handoff confidence is high for a customized saved deck with an explicit install command: use that exact saved install command.\n- If Deck Fit Handoff confidence is high for a customized saved deck with a pack list but no install command: `npx skillpacks install \u003Cpack...>`.\n- If no deck has high confidence and the concept appears to be a business app or user-facing product while the business research lane is not enabled: `npx skillpacks install business-research` from the project shell — this installs the research skills (customer discovery, competitive analysis, value prop, positioning, lean canvas) needed before any repo bootstrapping or development.\n- If no deck has high confidence and `business-research` or the compatibility `business-app` alias is enabled: `$customer-discovery`.\n- If no deck has high confidence and the concept already has customer-discovery\u002Fmarket evidence but needs journey, onboarding, conversion, or retention planning: `npx skillpacks install customer-lifecycle` from the project shell.\n- If no deck has high confidence and project type is unclear: `scripts\u002Fpack.sh recommend`.\n\nWhen a deck primary command is available, downstream research, discovery, or first-workflow skill routing must appear only as secondary context, not as the primary command.\n\nInclude 1-3 other options only when they are materially useful.\n\n### Alignment Page\n\nFollow `ALIGNMENT-PAGE.md` in this skill's directory for alignment-page requirements and output path.\n\n## Constraints\n\n- Keep the skill short and pre-research.\n- Do not write specs, UX variants, UI specs, roadmap phases, or implementation tasks.\n- Do not recommend `$scaffold` unless the user explicitly asks to create a package\u002Fapp shell before research; normal product flow scaffolds after research, prototype consolidation, spec, roadmap, and phase planning identify the first implementation target. `$scaffold` requires the monorepo pack (`npx skillpacks install monorepo` from the project shell).\n- Do not update `tasks\u002Ftodo.md`.\n- New files do not need archive snapshots. Before replacing an existing idea brief, including slugged briefs, archive it to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-relative-path>`.\n- Migration: if a project already has `research\u002Fconcept-brief.md`, `research\u002Fconcept-brief-interview.md`, or any `research\u002F{slug}\u002Fconcept-brief*.md` \u002F `research\u002Fconcept-brief-{slug}*.md` from a prior run, rename it to the `idea-brief` equivalent before re-running. Write only the `idea-brief` names and no longer recognizes the legacy `concept-brief` filenames.\n\n## Interrogation Page\n\nBefore producing research, run the stage-zero interrogation loop following `INTERROGATION-PAGE.md` in this skill's directory. Build one HTML page per round at `interrogation\u002Fidea-scope-brief-r{N}-{branch}.html`, starting with the assumptions manifest as round 1, and loop until the confidence gate passes. This skill **cannot advance to stage one until** the confidence gate passes with at least one completed interrogation round and every interview area covered or waived. Each round page must contain at least one genuinely open input (`data-open-input`).\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":41,"version":48,"description":7,"argument-hint":49,"context_intake":29,"required_conventions":50},"v0.21","[optional rough idea, product thought, or product-path scope]",[51,52],"alignment-page","interrogation-page","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fbase\u002Fcodex\u002Fidea-scope-brief\u002Farchive\u002Fv0.21",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":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill idea-scope-brief",{"tool":69,"command":70},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill idea-scope-brief",{"tool":72,"command":73},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill idea-scope-brief","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fbase\u002Fcodex\u002Fidea-scope-brief\u002Farchive\u002Fv0.21\u002FSKILL.md",true,[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"resources\u002Fimplementation-playbook.md","REFERENCE","参考文档",34899,"https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcursor\u002Ferror-debugging-error-analysis\u002Fresources\u002Fimplementation-playbook.md",[84,96,106,118,133,144],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":43},"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",[],[91,92,93,94,34,95],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":43},"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",[],[103,104,105,95,93,34],"deck install valid","deck","install",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":43},"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",[],[113,114,115,95,116,117,93,34],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":129,"publishedAt":43},"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",[124],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[130,131,95,116,34,132,93],"codex missing skill valid","missing","fallback",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":43},"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",[139],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[95,116,132,141,142,143,34,93],"base skill","codex base skill fallback valid","base",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":43},"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",[],[95,115,114,151,117,34,93],"claude pack guard valid"]