[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70GMTW38RJSMVKVC59W9F7P":3,"skill-same:01M70GMTW38RJSMVKVC59W9F7P":69},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M70GMTW38RJSMVKVC59W9F7P","parallel-execution-optimizer",null,"Speed up a task by turning it into a dependency graph of parallel lanes with a lane matrix, batched reads and checks, write surfaces isolated by file, worktree, branch, or service, and a final verification table. Use when the user wants a task done much faster through parallel work, concurrent agents, batched tool calls, isolated worktrees, many independent verification lanes, or bounded homogeneous work that reuses shared preparation while record operations remain sequential, without losing correctness.","mdnaimul22\u002Fhuman-skills","mdnaimul22","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F64520358?v=4","01M70FH95MH2H796Q01TYSFZ03","Naimul","01M70FH96798CQR4YHA13F17GA",3,"MIT","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Faffaan-m_ECC\u002Fparallel-execution-optimizer\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"parallel","parallel execution optimizer","execution","parallel execution","optimizer","write","surfaces","read","worktrees","dependency","worktree","work","verification","Bash","done","when","task done","up","dependency graph","branch","2026-11-10 10:12:30",false,"---\nname: parallel-execution-optimizer\ndescription: Speed up a task by turning it into a dependency graph of parallel lanes with a lane matrix, batched reads and checks, write surfaces isolated by file, worktree, branch, or service, and a final verification table. Use when the user wants a task done much faster through parallel work, concurrent agents, batched tool calls, isolated worktrees, many independent verification lanes, or bounded homogeneous work that reuses shared preparation while record operations remain sequential, without losing correctness.\nlicense: MIT\nmetadata:\n  origin: ECC\ntools: Read, Write, Edit, Bash, Grep, Glob\n---\n\n# Parallel Execution Optimizer\n\nUse this skill when speed comes from doing independent work at the same time:\nrepo inspection, file reads, API checks, browser checks, build\u002Ftest lanes,\ndeploy readbacks, or multi-worktree implementation passes. Also use it when\nhomogeneous work repeats unchanged preparation between records, even if the\nrecord operations must remain sequential.\n\n## Core Pattern\n\nTurn urgency into a dependency graph before acting.\n\n1. Define the objective and done signal.\n2. Split work into lanes.\n3. Mark each lane as parallel, sequential, or gated.\n4. Run independent reads\u002Fchecks together.\n5. Keep writes isolated by file, worktree, branch, service, or dataset.\n6. Merge only after evidence shows the lanes are compatible.\n7. End with a verification table, not a vague speed claim.\n\n## Lane Matrix\n\nBefore a large push, write a compact matrix:\n\n```text\nLane | Can run in parallel? | Write surface | Risk | Verification\nRepo scan | yes | none | low | rg\u002Fgit status outputs\nBackend patch | maybe | src\u002Fapi | medium | unit tests\nFrontend patch | maybe | app\u002Fcomponents | medium | browser screenshot\nDeploy readback | after build | remote service | high | live URL + logs\n```\n\nOnly run lanes in parallel when their write surfaces do not collide.\n\n## Execution Rules\n\n- Batch file reads, searches, status checks, and metadata queries.\n- Use isolated worktrees for large unrelated implementation lanes.\n- Start long-running tests, builds, backfills, and deploys in separate sessions,\n  then poll them deliberately.\n- If a lane discovers a blocker that changes the plan, pause dependent lanes\n  and update the matrix.\n- Never let a background process outlive the turn unless the user explicitly\n  asked for a continuing service.\n- Do not parallelize destructive commands, migrations, writes to the same table,\n  or live customer-impacting deploys without an explicit gate.\n\n## Bounded Homogeneous Work\n\nReuse preparation when a finite group of records shares accepted invariant\ninputs, such as a mapping and tool contract. This reduces repeated discovery\nand task setup; it does not require concurrent writes.\n\n1. Define the bounded record set, owner-defined completion unit, ordering,\n   exclusions, done signal, accepted mapping\u002Fcontract version, and replanning\n   conditions. Check selection coverage against the accepted source criteria;\n   validating selected records alone does not prove the set is complete.\n2. Discover shared sources and prepare invariant inputs once. Record their\n   versions and validity conditions; reuse them only while those conditions hold.\n3. Before each record's effect, check its current version, permissions,\n   prerequisites, and exact intended effect. Shared preparation is not shared\n   authorization. Require a conditional write against the checked version, a\n   transaction that detects intervening changes, or a lock held across the check\n   and write. Stop on a conflict; if no such protection is available, do not write.\n4. Verify the actual outcome for that record. Carry forward its evidence and\n   the remaining-work set after each verified success. An attempted write is\n   not a verified success; reconcile an uncertain outcome before any retry.\n5. Keep a group with one executor where the actual admission contract permits\n   it. If admission requires separate write kinds or stages, preserve those\n   boundaries and prepare the next permitted stage from verified returned keys\n   and versions; do not widen an assignment or bypass an approval for speed.\n6. Continue within the same bounded task while the contract and prerequisites\n   remain valid. Create a separate task or review when a real dependency,\n   changed contract, or risk requires it, rather than after every success.\n\n### Planner\u002FExecutor Example\n\nThe following is a synthetic walkthrough, not a measured runtime benchmark or\nan executed connector test. Records A, B, and C are independent and use the\nsame accepted mapping M1 and tool contract T1. Writes stay sequential.\n\n```text\nPlanner:\n  group = [A, B, C]\n  shared = accepted mapping M1 + tool contract T1 + source references\n  verified = {}\n  remaining = [A, B, C]\n\nExecutor for A:\n  confirm shared inputs are still valid\n  read A's current version; check permission and prerequisites\n  determine exact effect; apply with the same conflict protection; verify outcome\n  carry forward verified = {A: outcome evidence}, remaining = [B, C]\n\nExecutor for B, then C:\n  reuse shared preparation and carried state\n  repeat each record's version, permission, prerequisite, effect, outcome checks\n  remove a record from remaining only after verifying its success\n\nReplan:\n  if T1 changes to T2, pause dependent work and review the changed contract\n  if B's prerequisite fails, leave B unresolved and review that dependency\n  preserve A's verified evidence; refresh only inputs invalidated by the change\n```\n\nCarry-forward state should identify the group, shared input versions and\nvalidity conditions, per-record verified outcomes, unresolved\u002Funcertain effects,\nremaining records, completed-work exclusions, and the next required check. On\nresumption, revalidate inputs that may have changed; do not replay completed effects merely because a new\nexecutor takes over. Treat a new user request or changed scope as a new contract.\n\n### Resume After a Connector Change\n\nFor a synthetic handoff, suppose A is completed and excluded from further\nchanges, B failed with a confirmed absence of effects, C was never attempted, and D has an\nambiguous outcome. Carry those per-operation states and evidence into the new\nconnector route. Keep A excluded. Reconcile D before considering a retry;\nrebuild the executable set from unresolved work that is still authorized,\nincluding B and C only after their checks pass. Validate the new tool contract\nand preserve the exact intended effects. Do not rebuild the original batch as\nexecutable or erase earlier deviations because a later attempt succeeds.\n\n### Evaluation Criteria\n\nUse the walkthrough to check that ordinary successes advance A → B → C without\nrepeating unchanged source discovery or full task preparation. Confirm that a\nchanged contract or failed prerequisite still triggers the relevant review,\nper-record checks remain intact, and unverified outcomes stay unresolved. On a\nconnector change, confirm completed exclusions survive, failed\u002Funattempted work\nrequires current authorization, and ambiguous effects are reconciled first. Report\nwhat was actually executed separately from this proposed evaluation. Do not infer\nlatency improvements or ECC\u002Fconnector fault attribution from this example.\n\nFor an already-ready group, retain readiness, handoff, and first-action times\nin the existing journal. Separate required checks and approval waits from\ncoordinator waiting; client-side call overlap does not prove backend concurrency\nor throughput improvement. If a dependent step in GROUP_A is denied, hold it\nwhile authorized independent GROUP_B can proceed. Preserve chronological ordering\nwithin the owner's completion unit and all excluded records\u002Fintervals. Test a\nselection spelling variant and an excluded record against the accepted criteria;\nretain omitted eligible work and overflow before any unprepared write. Check\nthat a version conflict or unavailable conflict protection produces no write.\nThese remain proposed synthetic checks, not executed live-system results.\n\n## Output Shape\n\nUse this when reporting:\n\n```text\nParallel execution result:\n- Lanes run: 5\n- Lanes completed: 4\n- Blocked lane: deploy readback, waiting on DNS propagation\n- Fast path found: batched repo scan + focused tests\n- Verification: lint pass, unit pass, live smoke pass\n```\n\n## Failure Modes\n\n- More concurrency that creates conflicting edits.\n- Benchmarking the tool instead of the task.\n- Treating \"fast\" as done before correctness is proven.\n- Forgetting to poll running sessions.\n- Hiding skipped checks behind a success summary.\n","# Parallel Execution Optimizer\n\nUse this skill when speed comes from doing independent work at the same time:\nrepo inspection, file reads, API checks, browser checks, build\u002Ftest lanes,\ndeploy readbacks, or multi-worktree implementation passes. Also use it when\nhomogeneous work repeats unchanged preparation between records, even if the\nrecord operations must remain sequential.\n\n## Core Pattern\n\nTurn urgency into a dependency graph before acting.\n\n1. Define the objective and done signal.\n2. Split work into lanes.\n3. Mark each lane as parallel, sequential, or gated.\n4. Run independent reads\u002Fchecks together.\n5. Keep writes isolated by file, worktree, branch, service, or dataset.\n6. Merge only after evidence shows the lanes are compatible.\n7. End with a verification table, not a vague speed claim.\n\n## Lane Matrix\n\nBefore a large push, write a compact matrix:\n\n```text\nLane | Can run in parallel? | Write surface | Risk | Verification\nRepo scan | yes | none | low | rg\u002Fgit status outputs\nBackend patch | maybe | src\u002Fapi | medium | unit tests\nFrontend patch | maybe | app\u002Fcomponents | medium | browser screenshot\nDeploy readback | after build | remote service | high | live URL + logs\n```\n\nOnly run lanes in parallel when their write surfaces do not collide.\n\n## Execution Rules\n\n- Batch file reads, searches, status checks, and metadata queries.\n- Use isolated worktrees for large unrelated implementation lanes.\n- Start long-running tests, builds, backfills, and deploys in separate sessions,\n  then poll them deliberately.\n- If a lane discovers a blocker that changes the plan, pause dependent lanes\n  and update the matrix.\n- Never let a background process outlive the turn unless the user explicitly\n  asked for a continuing service.\n- Do not parallelize destructive commands, migrations, writes to the same table,\n  or live customer-impacting deploys without an explicit gate.\n\n## Bounded Homogeneous Work\n\nReuse preparation when a finite group of records shares accepted invariant\ninputs, such as a mapping and tool contract. This reduces repeated discovery\nand task setup; it does not require concurrent writes.\n\n1. Define the bounded record set, owner-defined completion unit, ordering,\n   exclusions, done signal, accepted mapping\u002Fcontract version, and replanning\n   conditions. Check selection coverage against the accepted source criteria;\n   validating selected records alone does not prove the set is complete.\n2. Discover shared sources and prepare invariant inputs once. Record their\n   versions and validity conditions; reuse them only while those conditions hold.\n3. Before each record's effect, check its current version, permissions,\n   prerequisites, and exact intended effect. Shared preparation is not shared\n   authorization. Require a conditional write against the checked version, a\n   transaction that detects intervening changes, or a lock held across the check\n   and write. Stop on a conflict; if no such protection is available, do not write.\n4. Verify the actual outcome for that record. Carry forward its evidence and\n   the remaining-work set after each verified success. An attempted write is\n   not a verified success; reconcile an uncertain outcome before any retry.\n5. Keep a group with one executor where the actual admission contract permits\n   it. If admission requires separate write kinds or stages, preserve those\n   boundaries and prepare the next permitted stage from verified returned keys\n   and versions; do not widen an assignment or bypass an approval for speed.\n6. Continue within the same bounded task while the contract and prerequisites\n   remain valid. Create a separate task or review when a real dependency,\n   changed contract, or risk requires it, rather than after every success.\n\n### Planner\u002FExecutor Example\n\nThe following is a synthetic walkthrough, not a measured runtime benchmark or\nan executed connector test. Records A, B, and C are independent and use the\nsame accepted mapping M1 and tool contract T1. Writes stay sequential.\n\n```text\nPlanner:\n  group = [A, B, C]\n  shared = accepted mapping M1 + tool contract T1 + source references\n  verified = {}\n  remaining = [A, B, C]\n\nExecutor for A:\n  confirm shared inputs are still valid\n  read A's current version; check permission and prerequisites\n  determine exact effect; apply with the same conflict protection; verify outcome\n  carry forward verified = {A: outcome evidence}, remaining = [B, C]\n\nExecutor for B, then C:\n  reuse shared preparation and carried state\n  repeat each record's version, permission, prerequisite, effect, outcome checks\n  remove a record from remaining only after verifying its success\n\nReplan:\n  if T1 changes to T2, pause dependent work and review the changed contract\n  if B's prerequisite fails, leave B unresolved and review that dependency\n  preserve A's verified evidence; refresh only inputs invalidated by the change\n```\n\nCarry-forward state should identify the group, shared input versions and\nvalidity conditions, per-record verified outcomes, unresolved\u002Funcertain effects,\nremaining records, completed-work exclusions, and the next required check. On\nresumption, revalidate inputs that may have changed; do not replay completed effects merely because a new\nexecutor takes over. Treat a new user request or changed scope as a new contract.\n\n### Resume After a Connector Change\n\nFor a synthetic handoff, suppose A is completed and excluded from further\nchanges, B failed with a confirmed absence of effects, C was never attempted, and D has an\nambiguous outcome. Carry those per-operation states and evidence into the new\nconnector route. Keep A excluded. Reconcile D before considering a retry;\nrebuild the executable set from unresolved work that is still authorized,\nincluding B and C only after their checks pass. Validate the new tool contract\nand preserve the exact intended effects. Do not rebuild the original batch as\nexecutable or erase earlier deviations because a later attempt succeeds.\n\n### Evaluation Criteria\n\nUse the walkthrough to check that ordinary successes advance A → B → C without\nrepeating unchanged source discovery or full task preparation. Confirm that a\nchanged contract or failed prerequisite still triggers the relevant review,\nper-record checks remain intact, and unverified outcomes stay unresolved. On a\nconnector change, confirm completed exclusions survive, failed\u002Funattempted work\nrequires current authorization, and ambiguous effects are reconciled first. Report\nwhat was actually executed separately from this proposed evaluation. Do not infer\nlatency improvements or ECC\u002Fconnector fault attribution from this example.\n\nFor an already-ready group, retain readiness, handoff, and first-action times\nin the existing journal. Separate required checks and approval waits from\ncoordinator waiting; client-side call overlap does not prove backend concurrency\nor throughput improvement. If a dependent step in GROUP_A is denied, hold it\nwhile authorized independent GROUP_B can proceed. Preserve chronological ordering\nwithin the owner's completion unit and all excluded records\u002Fintervals. Test a\nselection spelling variant and an excluded record against the accepted criteria;\nretain omitted eligible work and overflow before any unprepared write. Check\nthat a version conflict or unavailable conflict protection produces no write.\nThese remain proposed synthetic checks, not executed live-system results.\n\n## Output Shape\n\nUse this when reporting:\n\n```text\nParallel execution result:\n- Lanes run: 5\n- Lanes completed: 4\n- Blocked lane: deploy readback, waiting on DNS propagation\n- Fast path found: batched repo scan + focused tests\n- Verification: lint pass, unit pass, live smoke pass\n```\n\n## Failure Modes\n\n- More concurrency that creates conflicting edits.\n- Benchmarking the tool instead of the task.\n- Treating \"fast\" as done before correctness is proven.\n- Forgetting to poll running sessions.\n- Hiding skipped checks behind a success summary.\n",{"name":5,"tools":44,"license":15,"metadata":45,"description":7},"Read, Write, Edit, Bash, Grep, Glob",{"origin":46},"ECC","main","7092b664627bf326748a6fcbf27fee6a34c4da1d","skills\u002Fstorage\u002Faffaan-m_ECC\u002Fparallel-execution-optimizer",0,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills","https:\u002F\u002Fgithub.com\u002Fmdnaimul22","AI Agents Workflows Automation | Specializing in Python, FastAPI, MCP Agents & Custom ERP.","2026-11-11 21:16:57",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add mdnaimul22\u002Fhuman-skills --skill parallel-execution-optimizer",{"tool":61,"command":62},"bunx","bunx skills add mdnaimul22\u002Fhuman-skills --skill parallel-execution-optimizer",{"tool":64,"command":65},"pnpm","pnpm dlx skills add mdnaimul22\u002Fhuman-skills --skill parallel-execution-optimizer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Faffaan-m_ECC\u002Fparallel-execution-optimizer\u002FSKILL.md",true,[],[70,78,108,130,148,163],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":77},"01M72JT3YP1SQHD0MANGDXQ4RT","higgsfield-websites","Build, edit, and deploy full-stack websites, apps and games via the Higgsfield CLI (`higgsfield website …`). Each is a React 19 + TanStack Start SSR app in one Cloudflare Worker (D1\u002FR2\u002FKV\u002FDO\u002FContainers). THREE product types, picked via `--type` on create: `website` (standalone, no Higgsfield integration — references\u002Fwebsite-flow.md), `app` (Sign in with Higgsfield + fnf SDK, Quanta — references\u002Fapp-flow.md), `game` (realtime multiplayer rooms — references\u002Fgame-flow.md). Routes to the right flow; each carries its own rules and deploy\u002Fpublish gates.\nUse when: \"build me a website\", \"make a landing page\", \"create a web app\", \"build a SaaS dashboard \u002F portfolio\", \"make me a game\", \"deploy this site\", \"publish\". Also owns GAME ART: \"make a spritesheet\", \"tileable texture\", \"animate a 3D character\", game music\u002FSFX — see the game-* references.\nNOT for: single image\u002Fvideo\u002Faudio generation (higgsfield-generate), product photos (higgsfield-product-photoshoot), marketplace cards (higgsfield-marketplace-cards).","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fhiggsfield-ai_skills\u002Fhiggsfield-websites\u002FSKILL.md",[],[],"2026-11-10 22:39:42",{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":100,"publishedAt":39},"01M70JPK8HAXXA85P7Q8NKZZYG","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fwriting-skills\u002FSKILL.md",[84,89,94,97],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":95,"categoryName":96,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":98,"categoryName":99,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000008","测试与质量",[101,102,103,104,105,106,107,34,30],"writing","writing skills","editing","deployment","use","Existing","new",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":119,"publishedAt":39},"01M70JP4PHBH1CQVVDWZ94W159","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fwriting-plans\u002FSKILL.md",[114,115,116],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":117,"categoryName":118,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000030","开发工程师",[101,120,121,122,34,123,124,105,125,126,127,128,129],"writing plans","plans","you","code","for","requirements","task","multi","spec","multi-step task",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":39},"01M70JNTYVGXFZT8PASZ844TH8","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fverification-before-completion\u002FSKILL.md",[],[31,137,138,139,140,141,105,142,143,144,34,145,30,146,147],"verification before completion","complete","about","output","assertions","prs","evidence","claim","claims","commands","running",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":39},"01M70JNGVSQDESWN0Q5BPJ875V","using-superpowers","Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fusing-superpowers\u002FSKILL.md",[154],{"categoryNo":95,"categoryName":96,"taxonomyType":87,"taxonomyTypeDesc":88},[156,157,158,159,105,34,160,161,162],"using superpowers","superpowers","conversation","how to","how","find","questions",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":39},"01M70JN57CE588NPYPYTWH1DWG","using-git-worktrees","Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fusing-git-worktrees\u002FSKILL.md",[],[170,171,172,27,173,174,34,30,175,29,176,177,178,179,180,121,105,181,182],"using git worktrees","Using git","git","git worktrees","implementation","git worktree","native","Tools","isolation","fallback","feature","via","workspace"]