[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73F7GESS6HWW8W75YPJ720N":3,"skill-same:01M73F7GESS6HWW8W75YPJ720N":49},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M73F7GESS6HWW8W75YPJ720N","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.","Horonomos-laps\u002FYana-AI","Horonomos-laps","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F355299122?v=4","01M76B3QPXE88ET2SQPDPVATZT"," Horonomos-laps","01M72ZQRJPCYPSSWT4D00VJR2A",13,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fproduct-capability\u002FSKILL.md",[],[],"2026-11-11 15:11:14",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":24,"description":7},"ECC","main","481dcd7dd2e288b9d627a2bd017db70e64e6c6fa","core\u002Fskills\u002Fproduct-capability",1,"https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI","https:\u002F\u002Fyana.vutam.link\u002F","https:\u002F\u002Fgithub.com\u002FHoronomos-laps","https:\u002F\u002Fyana.vutam.link","An open-source governed runtime & execution environment for multi-agent AI systems.","2026-11-11 23:56:26",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add Horonomos-laps\u002FYana-AI --skill product-capability",{"tool":41,"command":42},"bunx","bunx skills add Horonomos-laps\u002FYana-AI --skill product-capability",{"tool":44,"command":45},"pnpm","pnpm dlx skills add Horonomos-laps\u002FYana-AI --skill product-capability","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fproduct-capability\u002FSKILL.md",true,[],[50,58,65,73,81,89],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":54,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":19},"01M735GKET5YVYKAY62W2P5YXB","openai--sentry--sentry","Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry API; perform read-only queries with the bundled script and require `SENTRY_AUTH_TOKEN`.","MIT","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopenai--sentry--sentry\u002FSKILL.md",[],[],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M73DCAP83T17HY7SMGK7MGFE","ito-basket-compare","Compare Itô prediction-market baskets against a user's knowledge base, portfolio notes, financial context, watchlist, or research thesis. Use for read-only basket comparison and gap analysis without investment advice or live trading.","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fito-basket-compare\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":69,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":19},"01M734CYEMZFDR3KH6SW0JP8TD","implementing-network-traffic-baselining","Build network traffic baselines from NetFlow\u002FIPFIX data using Python pandas for statistical analysis, z-score anomaly detection, and hourly\u002Fdaily traffic pattern profiling","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":77,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M73ASZ6NJRJM44Z2P84NGQ3Q","detecting-evasion-techniques-in-endpoint-logs","Detects defense evasion techniques used by adversaries in endpoint logs including log tampering, timestomping, process injection, and security tool disabling. Use when investigating suspicious endpoint behavior, building detection rules for evasion tactics, or conducting threat hunting for stealthy adversary activity. Activates for requests involving evasion detection, defense evasion analysis, log tampering detection, or MITRE ATT&CK TA0005.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":85,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M734AFNXD06Z78QRK0VKGT7Q","implementing-microsegmentation-with-guardicore","Implementing microsegmentation using Akamai Guardicore Segmentation to map application dependencies, create granular network policies, visualize east-west traffic flows, and enforce least-privilege communication between workloads across data centers and cloud.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":19},"01M736TK27QMCXK0DVCH25SJN5","ramdisk-tmpfs-patterns","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Framdisk-tmpfs-patterns\u002FSKILL.md",[],[]]