[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C2EEH79QEPAKDMXYXT5GZT":3,"skill-same:01M6C2EEH79QEPAKDMXYXT5GZT":61},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":46,"install":47,"resources":60},"01M6C2EEH79QEPAKDMXYXT5GZT","superpowers-quick",null,"Use when the user explicitly invokes \u002Fsuperpowers-quick and wants an idea turned into a complete design specification and implementation plan without interactive choice or review pauses.","jleechanorg\u002Fjleechan-skills","jleechanorg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F221404966?v=4","01M6C1VJ99XG950X1DWPEBCBGX","01M6C1VJDK5YVDNT3362RT5WSB",6,"MIT","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsuperpowers-quick\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"quick","superpowers quick","superpowers","when","design","implementation plan","complete","false","idea","specification","implementation","use","user","interactive","choice","plan","review","2026-11-10 10:12:30",false,"---\nname: superpowers-quick\ndescription: Use when the user explicitly invokes \u002Fsuperpowers-quick and wants an idea turned into a complete design specification and implementation plan without interactive choice or review pauses.\ndisable-model-invocation: false\n---\n\n# Superpowers Quick\n\n## Contract\n\nRun the full design-to-plan workflow autonomously. For this invocation, select recommended choices and approve each recommended design and specification checkpoint. Do not pause for routine questions or review; resolve ordinary ambiguity from available evidence and record assumptions and recommended defaults.\n\nThis authorization covers planning decisions and the `\u002Fadvice` review below, not implementation, destructive actions, credentials, or expanded scope. The caller's existing authorization for implementation or execution continues after this planning report; `\u002Fsq` does not grant it. Standing authorization covers the required `\u002Fweb-advice` plan submission unless the current request explicitly prohibits external submissions.\n\n## Owners and boundaries\n\n- Use the installed `superpowers:brainstorming` and `superpowers:writing-plans` skills when available; otherwise follow `..\u002Fsuperpowers-brainstorming\u002FSKILL.md` and `..\u002Fsuperpowers-writing-plans\u002FSKILL.md`. Those skills own their detailed design and plan-writing methods. Always produce both architectural documents, including for work otherwise classified as bounded.\n- Use the active `\u002Fadvice` and `\u002Fweb-advice` skills for reviewer selection, transport, quorum, and recovery. Read their definitions before invocation. This wrapper owns the required `\u002Fsq` review scope and artifacts below; it does not duplicate their procedures.\n- Follow the active artifact owner for durable Markdown. Under the shared policy, save both documents in `~\u002Froadmap\u002F` as `sq-\u003Ctopic>-design-YYYY-MM-DD.md` and `sq-\u003Ctopic>-plan-YYYY-MM-DD.md`.\n\nDo not commit, push, or mutate Git as a planning side effect. Documents may be committed, staged, modified, or untracked; `\u002Fsq` has no commit-state prerequisite. Do not ask the user to clean unrelated work. Do not create product artifacts during planning. For a user-visible change, run `\u002Fuser-story` in audit-only mode and include required story\u002Findex work in the plan. Do not offer or wait for the visual companion.\n\n## Workflow\n\n1. Inspect project context and existing decisions. Resolve routine uncertainties from evidence; explore useful alternatives, select the recommended design, and record considered questions, selected answers, and reasons under `Assumptions and Recommended Defaults` in the specification. Do not ask preference or approval questions.\n2. Complete and self-review the architectural design. Save it to the roadmap path above; remove placeholders, contradictions, and ambiguous requirements.\n3. Complete and self-review the implementation plan at its roadmap path. Include concrete files, tests, commands, and implementation steps.\n4. **TDD plan check, before advice:** inspect every plan task. For each behavior change, require the writing-plans sequence: failing test, run to verify the expected failure, minimal implementation, passing test and relevant regressions, then commit. Name exact test and implementation paths, runnable commands, and behavior-specific RED\u002FGREEN outcomes. For tasks that do not change behavior, record `TDD: N\u002FA`, a concrete reason, and a specific verification check. Record each task's check under `TDD Plan Check`; make unavailable facts, tools, or authority explicit preconditions and affected steps conditional. This is plan inspection only: do not run tests, edit implementation code, or commit during this check.\n5. **Review the exact saved documents:** resolve `SPEC_PATH` and `PLAN_PATH`. Resolve and validate the roadmap repository before deriving repository-relative names:\n     ```bash\n     if ! ROADMAP_REPO=\"$(git -C \"$HOME\u002Froadmap\" rev-parse --show-toplevel)\" ||\n         [ -z \"$ROADMAP_REPO\" ]; then\n       echo \"The roadmap directory is unavailable or is not a Git repository.\" >&2\n       exit 1\n     fi\n     case \"$SPEC_PATH\" in\n       \"$ROADMAP_REPO\"\u002F*) SPEC_DOCUMENT=\"${SPEC_PATH#\"$ROADMAP_REPO\"\u002F}\" ;;\n       *) echo \"Specification is outside the roadmap repository\" >&2; exit 1 ;;\n     esac\n     case \"$PLAN_PATH\" in\n       \"$ROADMAP_REPO\"\u002F*) PLAN_DOCUMENT=\"${PLAN_PATH#\"$ROADMAP_REPO\"\u002F}\" ;;\n       *) echo \"Plan is outside the roadmap repository\" >&2; exit 1 ;;\n     esac\n     ```\n   Both paths must exist there as non-ignored, non-symlink Markdown files. Use `\u002Fadvice` document-review mode on both relative paths, with normal reviewer selection and authorization constraints. Record each file's SHA256 and the bundle hash; reviewers must assess the exact current bytes regardless of Git status. The checkout HEAD is context only. A document verdict never approves code, HEAD, or dirty state. Do not use revision mode or a bundled runner.\n6. Run `\u002Fweb-advice` for the `\u002Fsq` plan review under standing authorization unless the current request explicitly prohibits external submission. It is separate from `\u002Fadvice` lanes. Reuse a `\u002Fadvice` browser submission only when it covers both exact document hashes; otherwise submit through `\u002Fweb-advice`. Bind any review after a document edit to its new hash. Follow both review owners for failures and recovery, preserve completed valid votes, and record every attempt and exact verdict. Do not impose wrapper attempt caps or duplicate completed verdicts. If all supported browser routes and owner-defined recovery are unavailable, report `\u002Fweb-advice: UNAVAILABLE` and continue independent caller work. Use `SKIPPED` only when the current request prohibits submission or the workflow does not call for it. Report `\u002Fadvice` and `\u002Fweb-advice` states separately.\n7. Report both actual absolute document paths, the considered questions and auto-picked answers with rationale, and separate review states: `\u002Fadvice: RAN | FAILED` with verdict or reason; `\u002Fweb-advice: RAN | SKIPPED | UNAVAILABLE | FAILED` with verdict or reason and whether it came from `\u002Fadvice` submission or standalone review. Do not ask which execution mode to use.\n\n## Terminal condition\n\nFinish this planning workflow when both complete documents exist, pass their self-reviews, the TDD plan check is recorded, contain no `TBD`, `TODO`, or deferred decision, and required advice attempts and status records are complete. For planning-only requests, stop without implementation or execution handoff. If implementation was already authorized by the live request or ongoing caller workflow, return to that workflow after the report and continue under its existing authorization without requesting it again. If a new authority or user-specific fact is needed, still finish both documents, record the exact precondition under `Implementation Preconditions`, and make affected steps conditional.\n","# Superpowers Quick\n\n## Contract\n\nRun the full design-to-plan workflow autonomously. For this invocation, select recommended choices and approve each recommended design and specification checkpoint. Do not pause for routine questions or review; resolve ordinary ambiguity from available evidence and record assumptions and recommended defaults.\n\nThis authorization covers planning decisions and the `\u002Fadvice` review below, not implementation, destructive actions, credentials, or expanded scope. The caller's existing authorization for implementation or execution continues after this planning report; `\u002Fsq` does not grant it. Standing authorization covers the required `\u002Fweb-advice` plan submission unless the current request explicitly prohibits external submissions.\n\n## Owners and boundaries\n\n- Use the installed `superpowers:brainstorming` and `superpowers:writing-plans` skills when available; otherwise follow `..\u002Fsuperpowers-brainstorming\u002FSKILL.md` and `..\u002Fsuperpowers-writing-plans\u002FSKILL.md`. Those skills own their detailed design and plan-writing methods. Always produce both architectural documents, including for work otherwise classified as bounded.\n- Use the active `\u002Fadvice` and `\u002Fweb-advice` skills for reviewer selection, transport, quorum, and recovery. Read their definitions before invocation. This wrapper owns the required `\u002Fsq` review scope and artifacts below; it does not duplicate their procedures.\n- Follow the active artifact owner for durable Markdown. Under the shared policy, save both documents in `~\u002Froadmap\u002F` as `sq-\u003Ctopic>-design-YYYY-MM-DD.md` and `sq-\u003Ctopic>-plan-YYYY-MM-DD.md`.\n\nDo not commit, push, or mutate Git as a planning side effect. Documents may be committed, staged, modified, or untracked; `\u002Fsq` has no commit-state prerequisite. Do not ask the user to clean unrelated work. Do not create product artifacts during planning. For a user-visible change, run `\u002Fuser-story` in audit-only mode and include required story\u002Findex work in the plan. Do not offer or wait for the visual companion.\n\n## Workflow\n\n1. Inspect project context and existing decisions. Resolve routine uncertainties from evidence; explore useful alternatives, select the recommended design, and record considered questions, selected answers, and reasons under `Assumptions and Recommended Defaults` in the specification. Do not ask preference or approval questions.\n2. Complete and self-review the architectural design. Save it to the roadmap path above; remove placeholders, contradictions, and ambiguous requirements.\n3. Complete and self-review the implementation plan at its roadmap path. Include concrete files, tests, commands, and implementation steps.\n4. **TDD plan check, before advice:** inspect every plan task. For each behavior change, require the writing-plans sequence: failing test, run to verify the expected failure, minimal implementation, passing test and relevant regressions, then commit. Name exact test and implementation paths, runnable commands, and behavior-specific RED\u002FGREEN outcomes. For tasks that do not change behavior, record `TDD: N\u002FA`, a concrete reason, and a specific verification check. Record each task's check under `TDD Plan Check`; make unavailable facts, tools, or authority explicit preconditions and affected steps conditional. This is plan inspection only: do not run tests, edit implementation code, or commit during this check.\n5. **Review the exact saved documents:** resolve `SPEC_PATH` and `PLAN_PATH`. Resolve and validate the roadmap repository before deriving repository-relative names:\n     ```bash\n     if ! ROADMAP_REPO=\"$(git -C \"$HOME\u002Froadmap\" rev-parse --show-toplevel)\" ||\n         [ -z \"$ROADMAP_REPO\" ]; then\n       echo \"The roadmap directory is unavailable or is not a Git repository.\" >&2\n       exit 1\n     fi\n     case \"$SPEC_PATH\" in\n       \"$ROADMAP_REPO\"\u002F*) SPEC_DOCUMENT=\"${SPEC_PATH#\"$ROADMAP_REPO\"\u002F}\" ;;\n       *) echo \"Specification is outside the roadmap repository\" >&2; exit 1 ;;\n     esac\n     case \"$PLAN_PATH\" in\n       \"$ROADMAP_REPO\"\u002F*) PLAN_DOCUMENT=\"${PLAN_PATH#\"$ROADMAP_REPO\"\u002F}\" ;;\n       *) echo \"Plan is outside the roadmap repository\" >&2; exit 1 ;;\n     esac\n     ```\n   Both paths must exist there as non-ignored, non-symlink Markdown files. Use `\u002Fadvice` document-review mode on both relative paths, with normal reviewer selection and authorization constraints. Record each file's SHA256 and the bundle hash; reviewers must assess the exact current bytes regardless of Git status. The checkout HEAD is context only. A document verdict never approves code, HEAD, or dirty state. Do not use revision mode or a bundled runner.\n6. Run `\u002Fweb-advice` for the `\u002Fsq` plan review under standing authorization unless the current request explicitly prohibits external submission. It is separate from `\u002Fadvice` lanes. Reuse a `\u002Fadvice` browser submission only when it covers both exact document hashes; otherwise submit through `\u002Fweb-advice`. Bind any review after a document edit to its new hash. Follow both review owners for failures and recovery, preserve completed valid votes, and record every attempt and exact verdict. Do not impose wrapper attempt caps or duplicate completed verdicts. If all supported browser routes and owner-defined recovery are unavailable, report `\u002Fweb-advice: UNAVAILABLE` and continue independent caller work. Use `SKIPPED` only when the current request prohibits submission or the workflow does not call for it. Report `\u002Fadvice` and `\u002Fweb-advice` states separately.\n7. Report both actual absolute document paths, the considered questions and auto-picked answers with rationale, and separate review states: `\u002Fadvice: RAN | FAILED` with verdict or reason; `\u002Fweb-advice: RAN | SKIPPED | UNAVAILABLE | FAILED` with verdict or reason and whether it came from `\u002Fadvice` submission or standalone review. Do not ask which execution mode to use.\n\n## Terminal condition\n\nFinish this planning workflow when both complete documents exist, pass their self-reviews, the TDD plan check is recorded, contain no `TBD`, `TODO`, or deferred decision, and required advice attempts and status records are complete. For planning-only requests, stop without implementation or execution handoff. If implementation was already authorized by the live request or ongoing caller workflow, return to that workflow after the report and continue under its existing authorization without requesting it again. If a new authority or user-specific fact is needed, still finish both documents, record the exact precondition under `Implementation Preconditions`, and make affected steps conditional.\n",{"name":5,"description":7,"disable-model-invocation":36},"main","d57b06df00b496fc5debe2002b49987696f02a8c",".claude\u002Fskills\u002Fsuperpowers-quick",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-11 22:19:36",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill superpowers-quick",{"tool":53,"command":54},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill superpowers-quick",{"tool":56,"command":57},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill superpowers-quick","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsuperpowers-quick\u002FSKILL.md",true,[],[62,77,99,113,127,143],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":35},"01M716Y5MTJ6GYJZ2ATXCJK8G4","instinct","Use when the user invokes \u002Finstinct or \u002Fin, or asks to \"message Instinct\", \"ask Instinct\", \"tell Instinct\", \"check Instinct\", or read replies from the configured peer assistant. iMessage first, WhatsApp Web as fallback.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finstinct\u002FSKILL.md",[],[64,30,21,69,70,29,71,72,73,74,75,76],"replies","check","identity","whatsapp","gmail","read","message","ask",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":88,"publishedAt":35},"01M716Y4HF7FVVMJSA2CCVN5VF","hr","Compatibility alias for history-resume; produce the same fresh-state, provenance-aware resume briefing.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhr\u002FSKILL.md",[83],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[79,89,90,91,92,93,94,95,96,97,98],"resume","compatibility","provenance","for","history","produce","alias","briefing","state","fresh",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"publishedAt":35},"01M716Y1FFNFKFJYYKF8HQA6T8","history-resume","Resume briefing for the current repository branch or worktree using fresh state and admitted history sources.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhistory-resume\u002FSKILL.md",[105],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[93,89,107,108,30,109,96,110,92,111,112,97,98],"history resume","branch","analysis","repository","worktree","sources",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":35},"01M716XWXJ8EPHK4RH9T14TR85","grok","Alias for the canonical grokbot browser conversation workflow; \u002Fgrok talks to the Grok bot the same way \u002Fdot talks to Dot.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgrok\u002FSKILL.md",[],[115,120,121,122,92,123,95,124,125,126],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":35},"01M70N9Q07DTE0EW5KFXMMMSJ0","codexa-bench","Compare `codexa` and normal `codex` on a fair split of comparable work by default; use `--strict` for duplicate runs of the exact same task.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodexa-bench\u002FSKILL.md",[],[134,135,136,29,137,92,138,139,140,141,142],"codexa bench","work","split","default","duplicate","task","compare","normal","codex",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":147,"licenseFileUrl":148,"sourceHtmlUrl":149,"categories":150,"keywords":162,"publishedAt":35},"01M6C24S2X60SP8BBFGAEKPEGW","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[151,156,159],{"categoryNo":152,"categoryName":153,"taxonomyType":154,"taxonomyTypeDesc":155},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":157,"categoryName":158,"taxonomyType":154,"taxonomyTypeDesc":155},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":160,"categoryName":161,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000032","设计师",[163,22,164,29,165,166,167,30,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,21,186],"frontend","frontend design","generic","ui design","react","html","components","code","artifacts","ui","aesthetics","Production","web components","landing","applications","quality","web","css","create","examples","with","react components","web ui","pages"]