[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JDCTRG0FE7AWPSRQMFGMFX":3,"skill-same:01M6JDCTRG0FE7AWPSRQMFGMFX":76},{"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":27,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6JDCTRG0FE7AWPSRQMFGMFX","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.","S3YED\u002Fappie-kit","S3YED","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F62743867?v=4","01M6JBKBRRVP6KMS0VWZ27T3R6","01M6JBKBX0KG30284PW1DBYJT1",14,"MIT","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fecc\u002Fproduct-capability\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"product","product capability","roadmap","vague","invariants","native","multi","service","prose","intent","implementation","translate","ready","use","decisions","work","plan","prd","lane","planning","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.\norigin: 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,"origin":53,"description":7},"ECC","master","8ec37df6d71fb664ea19d32c079e7d3ff931a8e0","skills\u002Fecc\u002Fproduct-capability",3,"https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit","https:\u002F\u002Fweblyfe.ai","https:\u002F\u002Fgithub.com\u002FS3YED","2026-08-27 01:54:02",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add S3YED\u002Fappie-kit --skill product-capability",{"tool":68,"command":69},"bunx","bunx skills add S3YED\u002Fappie-kit --skill product-capability",{"tool":71,"command":72},"pnpm","pnpm dlx skills add S3YED\u002Fappie-kit --skill product-capability","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fecc\u002Fproduct-capability\u002FSKILL.md",true,[],[77,109,142,167,198,223],{"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":90,"publishedAt":48},"01M6JFD4M6N4DSGC7TXEJ5R3J2","ai-music","AI music generation and audio tools: HeartMuLa lyrics-to-music generation, songwriting craft (+ Suno prompts), and audio spectrogram\u002Ffeature visualization.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fwethlete\u002Fai-music\u002FSKILL.md",[83,86,89],{"categoryNo":84,"categoryName":85,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":87,"categoryName":88,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108],"music","ai music","humanizer","visualization","Tools","Audio","hermes","hermes agent","songwriting","suno","lyrics","prompts","heartmula","craft","generation","feature","ai music generation","music generation",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":121,"publishedAt":48},"01M6JFCZE4XNFQFMNZDHKHT5V5","agentic-webdesign-design-system-ingestion","Use v0 Design Systems 2.0, Bolt Design System Agents, or Lovable to generate production UI from a client's real design system components — not generic Tailwind. Use when building a client website where brand consistency matters.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fweb-design\u002Fagentic-webdesign-design-system-ingestion\u002FSKILL.md",[115,118],{"categoryNo":116,"categoryName":117,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":119,"categoryName":120,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师",[122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141],"design","agentic","design system","system","ingestion","webdesign","agentic webdesign design system ingestion","components","generate","design systems","website","ui","Tailwind","bolt","lovable","v0","design-system","wed","design system components","appie",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":150,"publishedAt":48},"01M6JFCVPX3913CFAS6QQJ33ZB","agentic-webdesign-agent-elements","Use 21st.dev Agent Elements — 25 shadcn\u002Fui components purpose-built for AI agent UIs. Tool cards (Bash, Edit, Search, Plan, Subagent, MCP), chat, input, streaming. Open source, shadcn-registry install, no runtime lock-in.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fweb-design\u002Fagentic-webdesign-agent-elements\u002FSKILL.md",[148,149],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":119,"categoryName":120,"taxonomyType":25,"taxonomyTypeDesc":26},[123,151,127,152,153,154,129,155,156,157,158,159,160,44,161,162,163,164,165,166],"elements","agentic webdesign agent elements","MCP","ai agent","registry","search","streaming","open source","open","Bash","subagent","edit","install","input","lock","source",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":177,"publishedAt":48},"01M6JFCQC7H65M9QJ6TRE71BS1","vercel-deployment","Deploy static sites and frontends to Vercel — handles both CLI and REST API paths, including the CLI token sanitization workaround.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Fvercel-deployment\u002FSKILL.md",[173,176],{"categoryNo":174,"categoryName":175,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197],"deployment","vercel deployment","vercel","macos","cli","linux","windows","deploy","vercel deploy","REST","api","site","deploy to vercel","token","rest api","host","sites","paths","sanitization","static site",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":205,"publishedAt":48},"01M6JFCM4SMTXBM5A01BK2YQG1","software-quality-workflows","Umbrella workflow for TDD, debugging, code simplification, spikes, pre-commit review, and debugger-assisted investigation.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Fsoftware-quality-workflows\u002FSKILL.md",[204],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222],"workflows","quality","software","software quality workflows","review","tdd","workflow","commit","debugging","code","debugger","pre-commit","investigation","code simplification","user","simplification","for",{"skillNo":224,"name":225,"nameZh":6,"description":226,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":227,"categories":228,"keywords":236,"publishedAt":48},"01M6JFCGD0M6CEATY01W7YN6DB","react-component-refactoring","Safely refactor large React components into smaller, maintainable pieces using proven patterns","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Freact-component-refactoring\u002FSKILL.md",[229,232,235],{"categoryNo":230,"categoryName":231,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":233,"categoryName":234,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[237,238,239,240,241,242,243,244,181,245,246,129,247,184,248,215,249,250,251,252],"react","component","refactoring","component refactoring","react component","react component refactoring","frontend","writing","safe","typescript","react components","modular","refactor","simplify","patterns","test-driven-development"]