[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D3VP2FP996PAAESWSDWJ5D":3,"skill-same:01M6D3VP2FP996PAAESWSDWJ5D":70},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6D3VP2FP996PAAESWSDWJ5D","concept-exploration",null,"Shape a rough product or project idea into an actionable concept brief before ICP, 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.3\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],"exploration","concept exploration","research","planning","product","ux","ui","brief","market research","v0","shape","implementation","Market","idea","project","2026-11-10 10:12:30",false,"---\nname: concept-exploration\ndescription: Shape a rough product or project idea into an actionable concept brief before ICP, market research, specifications, UX, UI, or implementation planning\ntype: planning\nversion: v0.3\nargument-hint: \"[optional rough idea, product thought, or app scope]\"\n---\n\n# Concept Exploration\n\nInvoke as `$concept-exploration`.\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-ICP: it clarifies the concept, problem hypothesis, beneficiary hypothesis, value wedge, constraints, non-goals, and unknowns, but does not select an ICP, analyze competitors, define UX\u002FUI, choose architecture, or write implementation specs.\n\n## Workflow\n\n1. **Resolve context**\n   - Read `.agents\u002Fproject.json` if it exists.\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 an app that matches `research\u002F{app}\u002F`, use app-scoped output paths. Otherwise use top-level `research\u002F`.\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 `concept-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. Treat `active_path` as the current product\u002Fapp\u002FICP focus and `product_paths[]` as parked 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`, `source_skill`, `scope_path`, `status`, `reason`, `evidence_refs`, `revisit_trigger`, `next_skill`, and `last_touched`.\n   - Keep the central concept as `active_path` 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 `$icp \u003Cpath\u002Faudience>`.\n\n2. **Keep the boundary clear**\n   - Do not run ICP, 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\n3. **Surface a Concept Assumptions Manifest**\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     - value wedge\n     - constraints\n     - non-goals\n     - riskiest unknowns\n   - Ask the user to confirm, correct, or flag assumptions before writing.\n\n4. **Interview until concept-ready**\n   - Codex interview 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   - Present the final concept summary, unknowns, and readiness for ICP.\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\n## Output\n\nWrite:\n\n- For one unambiguous project-level concept only: `research\u002Fconcept-brief.md` and `research\u002Fconcept-brief-interview.md`.\n- When a concept identity is known, multiple concepts exist or may exist, or a pivot occurs: `research\u002Fconcept-brief-{slug}.md` and `research\u002Fconcept-brief-{slug}-interview.md`.\n- If `$ARGUMENTS` names an app that matches `research\u002F{app}\u002F`, use the same filenames under `research\u002F{app}\u002F`: `research\u002F{app}\u002Fconcept-brief-{slug}.md` and `research\u002F{app}\u002Fconcept-brief-{slug}-interview.md`, or unsuffixed app-scoped files only when that app has one unambiguous concept.\n- `research\u002F.progress.yaml` — create or update only when multiple concepts, product paths, product lines, app scopes, or pivots are present. Use `product_paths` terminology instead of branch terminology.\n\nThe concept 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- `## ICP Readiness`\n- `## Next Steps`\n\nThe `## ICP Readiness` section must state whether the concept is ready for `$icp`, what inputs `$icp` should use, and which assumptions should be tested first.\n\nThe `## Next Steps` section must recommend exactly one primary command:\n\n- If the concept appears to be a business app or user-facing product and the business discovery lane is not enabled: `$pack install business-discovery` — this installs the research skills (ICP, competitive analysis, value prop, positioning, lean canvas) needed before any repo bootstrapping or development.\n- If `business-discovery` or the compatibility `business-app` alias is enabled: `$icp`\n- If the concept already has ICP\u002Fmarket evidence but needs journey, onboarding, conversion, or retention planning: `$pack install customer-lifecycle`\n- If project type is unclear: `$pack recommend`\n\nInclude 1-3 other options only when they are materially useful.\n\n### Alignment Page\n\nFollow the shared Alignment Page convention in CLAUDE.md. Output: `alignment\u002Fconcept-exploration-{topic}.html`.\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.\n- Do not update `tasks\u002Ftodo.md`.\n- New files do not need archive snapshots. Before replacing an existing concept brief, including slugged briefs, archive it to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-relative-path>`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","# Concept Exploration\n\nInvoke as `$concept-exploration`.\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-ICP: it clarifies the concept, problem hypothesis, beneficiary hypothesis, value wedge, constraints, non-goals, and unknowns, but does not select an ICP, analyze competitors, define UX\u002FUI, choose architecture, or write implementation specs.\n\n## Workflow\n\n1. **Resolve context**\n   - Read `.agents\u002Fproject.json` if it exists.\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 an app that matches `research\u002F{app}\u002F`, use app-scoped output paths. Otherwise use top-level `research\u002F`.\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 `concept-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. Treat `active_path` as the current product\u002Fapp\u002FICP focus and `product_paths[]` as parked 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`, `source_skill`, `scope_path`, `status`, `reason`, `evidence_refs`, `revisit_trigger`, `next_skill`, and `last_touched`.\n   - Keep the central concept as `active_path` 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 `$icp \u003Cpath\u002Faudience>`.\n\n2. **Keep the boundary clear**\n   - Do not run ICP, 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\n3. **Surface a Concept Assumptions Manifest**\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     - value wedge\n     - constraints\n     - non-goals\n     - riskiest unknowns\n   - Ask the user to confirm, correct, or flag assumptions before writing.\n\n4. **Interview until concept-ready**\n   - Codex interview 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   - Present the final concept summary, unknowns, and readiness for ICP.\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\n## Output\n\nWrite:\n\n- For one unambiguous project-level concept only: `research\u002Fconcept-brief.md` and `research\u002Fconcept-brief-interview.md`.\n- When a concept identity is known, multiple concepts exist or may exist, or a pivot occurs: `research\u002Fconcept-brief-{slug}.md` and `research\u002Fconcept-brief-{slug}-interview.md`.\n- If `$ARGUMENTS` names an app that matches `research\u002F{app}\u002F`, use the same filenames under `research\u002F{app}\u002F`: `research\u002F{app}\u002Fconcept-brief-{slug}.md` and `research\u002F{app}\u002Fconcept-brief-{slug}-interview.md`, or unsuffixed app-scoped files only when that app has one unambiguous concept.\n- `research\u002F.progress.yaml` — create or update only when multiple concepts, product paths, product lines, app scopes, or pivots are present. Use `product_paths` terminology instead of branch terminology.\n\nThe concept 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- `## ICP Readiness`\n- `## Next Steps`\n\nThe `## ICP Readiness` section must state whether the concept is ready for `$icp`, what inputs `$icp` should use, and which assumptions should be tested first.\n\nThe `## Next Steps` section must recommend exactly one primary command:\n\n- If the concept appears to be a business app or user-facing product and the business discovery lane is not enabled: `$pack install business-discovery` — this installs the research skills (ICP, competitive analysis, value prop, positioning, lean canvas) needed before any repo bootstrapping or development.\n- If `business-discovery` or the compatibility `business-app` alias is enabled: `$icp`\n- If the concept already has ICP\u002Fmarket evidence but needs journey, onboarding, conversion, or retention planning: `$pack install customer-lifecycle`\n- If project type is unclear: `$pack recommend`\n\nInclude 1-3 other options only when they are materially useful.\n\n### Alignment Page\n\nFollow the shared Alignment Page convention in CLAUDE.md. Output: `alignment\u002Fconcept-exploration-{topic}.html`.\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.\n- Do not update `tasks\u002Ftodo.md`.\n- New files do not need archive snapshots. Before replacing an existing concept brief, including slugged briefs, archive it to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-relative-path>`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":27,"version":44,"description":7,"argument-hint":45},"v0.3","[optional rough idea, product thought, or app scope]","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fbase\u002Fcodex\u002Fidea-scope-brief\u002Farchive\u002Fv0.3",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":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill concept-exploration",{"tool":62,"command":63},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill concept-exploration",{"tool":65,"command":66},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill concept-exploration","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fbase\u002Fcodex\u002Fidea-scope-brief\u002Farchive\u002Fv0.3\u002FSKILL.md",true,[],[71,83,93,105,120,131],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":39},"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",[],[78,79,80,81,33,82],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":39},"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",[],[90,91,92,82,80,33],"deck install valid","deck","install",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":39},"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",[],[100,101,102,82,103,104,80,33],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":116,"publishedAt":39},"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",[111],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[117,118,82,103,33,119,80],"codex missing skill valid","missing","fallback",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":127,"publishedAt":39},"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",[126],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},[82,103,119,128,129,130,33,80],"base skill","codex base skill fallback valid","base",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":39},"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",[],[82,102,101,138,104,33,80],"claude pack guard valid"]