[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70GPP3HWPZAM5W0CD3E0NE2":3,"skill-same:01M70GPP3HWPZAM5W0CD3E0NE2":78},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M70GPP3HWPZAM5W0CD3E0NE2","product-capability",null,"Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.","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\u002Fproduct-capability\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"product","capability","product capability","service","implementation","multi","decisions","use","lane","planning","invariants","intent","native","plan","work","vague","when","roadmap","translate","ready","2026-11-10 10:12:30",false,"---\nname: product-capability\ndescription: Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.\nmetadata:\n  origin: ECC\n---\n\n# Product Capability\n\nThis skill turns product intent into explicit engineering constraints.\n\nUse it when the gap is not \"what should we build?\" but \"what exactly must be true before implementation starts?\"\n\n## When to Use\n\n- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit\n- A feature crosses multiple services, repos, or teams and needs a capability contract before coding\n- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy\n- Senior engineers keep restating the same hidden assumptions during review\n- You need a reusable artifact that can survive across harnesses and sessions\n\n## Canonical Artifact\n\nIf the repo has a durable product-context file such as `PRODUCT.md`, `docs\u002Fproduct\u002F`, or a program-spec directory, update it there.\n\nIf no capability manifest exists yet, create one using the template at:\n\n- `docs\u002Fexamples\u002Fproduct-capability-template.md`\n\nThe goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.\n\n## Non-Negotiable Rules\n\n- Do not invent product truth. Mark unresolved questions explicitly.\n- Separate user-visible promises from implementation details.\n- Call out what is fixed policy, what is architecture preference, and what is still open.\n- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.\n- Prefer one reusable capability artifact over scattered ad hoc notes.\n\n## Inputs\n\nRead only what is needed:\n\n1. Product intent\n   - issue, discussion, PRD, roadmap note, founder message\n2. Current architecture\n   - relevant repo docs, contracts, schemas, routes, existing workflows\n3. Existing capability context\n   - `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs\n4. Delivery constraints\n   - auth, billing, compliance, rollout, backwards compatibility, performance, review policy\n\n## Core Workflow\n\n### 1. Restate the capability\n\nCompress the ask into one precise statement:\n\n- who the user or operator is\n- what new capability exists after this ships\n- what outcome changes because of it\n\nIf this statement is weak, the implementation will drift.\n\n### 2. Resolve capability constraints\n\nExtract the constraints that must hold before implementation:\n\n- business rules\n- scope boundaries\n- invariants\n- trust boundaries\n- data ownership\n- lifecycle transitions\n- rollout \u002F migration requirements\n- failure and recovery expectations\n\nThese are the things that often live only in senior-engineer memory.\n\n### 3. Define the implementation-facing contract\n\nProduce an SRS-style capability plan with:\n\n- capability summary\n- explicit non-goals\n- actors and surfaces\n- required states and transitions\n- interfaces \u002F inputs \u002F outputs\n- data model implications\n- security \u002F billing \u002F policy constraints\n- observability and operator requirements\n- open questions blocking implementation\n\n### 4. Translate into execution\n\nEnd with the exact handoff:\n\n- ready for direct implementation\n- needs architecture review first\n- needs product clarification first\n\nIf useful, point to the next ECC-native lane:\n\n- `project-flow-ops`\n- `workspace-surface-audit`\n- `api-connector-builder`\n- `dashboard-builder`\n- `tdd-workflow`\n- `verification-loop`\n\n## Output Format\n\nReturn the result in this order:\n\n```text\nCAPABILITY\n- one-paragraph restatement\n\nCONSTRAINTS\n- fixed rules, invariants, and boundaries\n\nIMPLEMENTATION CONTRACT\n- actors\n- surfaces\n- states and transitions\n- interface\u002Fdata implications\n\nNON-GOALS\n- what this lane explicitly does not own\n\nOPEN QUESTIONS\n- blockers or product decisions still required\n\nHANDOFF\n- what should happen next and which ECC lane should take it\n```\n\n## Good Outcomes\n\n- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.\n- Engineering review has a durable artifact instead of relying on memory or Slack context.\n- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.\n","# Product Capability\n\nThis skill turns product intent into explicit engineering constraints.\n\nUse it when the gap is not \"what should we build?\" but \"what exactly must be true before implementation starts?\"\n\n## When to Use\n\n- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit\n- A feature crosses multiple services, repos, or teams and needs a capability contract before coding\n- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy\n- Senior engineers keep restating the same hidden assumptions during review\n- You need a reusable artifact that can survive across harnesses and sessions\n\n## Canonical Artifact\n\nIf the repo has a durable product-context file such as `PRODUCT.md`, `docs\u002Fproduct\u002F`, or a program-spec directory, update it there.\n\nIf no capability manifest exists yet, create one using the template at:\n\n- `docs\u002Fexamples\u002Fproduct-capability-template.md`\n\nThe goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.\n\n## Non-Negotiable Rules\n\n- Do not invent product truth. Mark unresolved questions explicitly.\n- Separate user-visible promises from implementation details.\n- Call out what is fixed policy, what is architecture preference, and what is still open.\n- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.\n- Prefer one reusable capability artifact over scattered ad hoc notes.\n\n## Inputs\n\nRead only what is needed:\n\n1. Product intent\n   - issue, discussion, PRD, roadmap note, founder message\n2. Current architecture\n   - relevant repo docs, contracts, schemas, routes, existing workflows\n3. Existing capability context\n   - `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs\n4. Delivery constraints\n   - auth, billing, compliance, rollout, backwards compatibility, performance, review policy\n\n## Core Workflow\n\n### 1. Restate the capability\n\nCompress the ask into one precise statement:\n\n- who the user or operator is\n- what new capability exists after this ships\n- what outcome changes because of it\n\nIf this statement is weak, the implementation will drift.\n\n### 2. Resolve capability constraints\n\nExtract the constraints that must hold before implementation:\n\n- business rules\n- scope boundaries\n- invariants\n- trust boundaries\n- data ownership\n- lifecycle transitions\n- rollout \u002F migration requirements\n- failure and recovery expectations\n\nThese are the things that often live only in senior-engineer memory.\n\n### 3. Define the implementation-facing contract\n\nProduce an SRS-style capability plan with:\n\n- capability summary\n- explicit non-goals\n- actors and surfaces\n- required states and transitions\n- interfaces \u002F inputs \u002F outputs\n- data model implications\n- security \u002F billing \u002F policy constraints\n- observability and operator requirements\n- open questions blocking implementation\n\n### 4. Translate into execution\n\nEnd with the exact handoff:\n\n- ready for direct implementation\n- needs architecture review first\n- needs product clarification first\n\nIf useful, point to the next ECC-native lane:\n\n- `project-flow-ops`\n- `workspace-surface-audit`\n- `api-connector-builder`\n- `dashboard-builder`\n- `tdd-workflow`\n- `verification-loop`\n\n## Output Format\n\nReturn the result in this order:\n\n```text\nCAPABILITY\n- one-paragraph restatement\n\nCONSTRAINTS\n- fixed rules, invariants, and boundaries\n\nIMPLEMENTATION CONTRACT\n- actors\n- surfaces\n- states and transitions\n- interface\u002Fdata implications\n\nNON-GOALS\n- what this lane explicitly does not own\n\nOPEN QUESTIONS\n- blockers or product decisions still required\n\nHANDOFF\n- what should happen next and which ECC lane should take it\n```\n\n## Good Outcomes\n\n- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.\n- Engineering review has a durable artifact instead of relying on memory or Slack context.\n- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.\n",{"name":5,"metadata":54,"description":7},{"origin":55},"ECC","main","74715deacdc69119d739f38916f8ee4f0f979ebf","skills\u002Fstorage\u002Faffaan-m_ECC\u002Fproduct-capability",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":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add mdnaimul22\u002Fhuman-skills --skill product-capability",{"tool":70,"command":71},"bunx","bunx skills add mdnaimul22\u002Fhuman-skills --skill product-capability",{"tool":73,"command":74},"pnpm","pnpm dlx skills add mdnaimul22\u002Fhuman-skills --skill product-capability","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Faffaan-m_ECC\u002Fproduct-capability\u002FSKILL.md",true,[],[79,87,110,131,150,165],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":86},"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":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":103,"publishedAt":49},"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",[93,96,99,100],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":97,"categoryName":98,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[104,105,106,107,36,108,109,45,43],"writing","writing skills","editing","deployment","Existing","new",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":121,"publishedAt":49},"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",[116,117,118],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":97,"categoryName":98,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":119,"categoryName":120,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",[104,122,123,124,45,125,126,36,127,128,34,129,130],"writing plans","plans","you","code","for","requirements","task","spec","multi-step task",{"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":49},"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",[],[138,139,140,141,142,143,36,144,145,146,45,147,43,148,149],"verification","verification before completion","complete","about","output","assertions","prs","evidence","claim","claims","commands","running",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":157,"publishedAt":49},"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",[156],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[158,159,160,161,36,45,162,163,164],"using superpowers","superpowers","conversation","how to","how","find","questions",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":49},"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",[],[172,173,174,175,176,33,45,43,177,178,41,179,180,181,182,123,36,183,184],"using git worktrees","Using git","git","worktrees","git worktrees","git worktree","worktree","Tools","isolation","fallback","feature","via","workspace"]