product-capability

This skill turns product intent into explicit engineering constraints. Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?" If the repo has a durable product-context file such as PRODUCT.md , docs/product/ , or a program-spec directory, update it there. If no capability manifest exists yet, create one using the template at: The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable. Read only what is needed: Compress the ask into one precise statement: If this statement is weak, the implementation will drift. Extract the constraints that must hold before implementation: These are the things that often live only in senior-engineer memory. Produce an SRS-style capability plan with: End with the exact handoff: If useful, point to the next ECC-native lane: Return the result in this order: - A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit - A feature crosses multiple services, repos, or teams and needs a capability contract before coding - Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy - Senior engineers keep restating the same hidden assumptions during review - You need a reusable artifact that can survive across harnesses and sessions -...