product-capability

Solid

Load when accepted product intent must become a concise, implementation-ready local capability specification with explicit constraints, non-goals, test seams, and unresolved decisions.

AI & Automation 84 stars 0 forks Updated 5 days ago

Install

View on GitHub

Quality Score: 78/100

Stars 20%
64
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
0
Description 5%
100

Skill Content

# Product Capability Turn accepted product intent into a local engineering contract. This Skill specifies one capability; it does not own implementation, ticketing, or delivery. Use `grill-me` first when consequential decisions remain. Use `grill-with-docs` when this work creates or changes a durable specification so the same decision graph is reconciled with repository evidence. ## Inputs Read only relevant sources: - accepted source facts from the user, current task, issues, PRDs, or roadmap notes - existing behavior, tests, schemas, interfaces, and durable docs - project instructions and ownership/security/rollout constraints Do not invent product truth. Label an inference or unresolved decision instead of smoothing over missing evidence. ## Specification Write the smallest artifact that makes implementation unambiguous: ```text CAPABILITY - actor, new behavior, and observable outcome ACCEPTED SOURCE FACTS - source anchor and fact CONSTRAINTS - invariants, ownership, trust, lifecycle, failure, migration, and rollout rules INTERFACES - inputs, outputs, states, errors, side effects, and compatibility boundaries TEST SEAMS - public behaviors and deterministic evidence that will prove acceptance OUT OF SCOPE - explicit non-goals and rejected expansion OPEN DECISIONS - unresolved choices that can still change implementation or acceptance HANDOFF - ready for implementation, needs alignment, or needs focused design review ``` Prefer updating the project's existin...

Details

Author
JasonxzWen
Repository
JasonxzWen/harness-hub
Created
4 months ago
Last Updated
5 days ago
Language
JavaScript
License
None

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Featured

product-capability

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.

234,363 Updated today
affaan-m
AI & Automation Solid

design-feature

Turn an idea or a feature request into an exhaustive, checkable product definition — the stage before engineering planning. The core mechanism is **capability closure**: a checklist that forces every entity, capability, and role a feature introduces to be walked to its full surface (CRUD + state transitions + UI entry point + API + test, or an explicit design-time `n/a`), so non-frontier executor models stop silently omitting the implicit work ("auth with dashboard management and ACLs" must not collapse to a users table + a list view). Closure has three fixed checklists: **entity closure** (each entity to full surface), **integration closure** (the feature reconciled against every subsystem in the project's capability inventory, `docs/CAPABILITIES.md` — auth, ACL, navigation, notifications, …), and the **role matrix** (every inventory role explicitly allowed/denied per capability) — plus an **expectation sweep** that forces what a competent human would implicitly assume ("a blog has drafts") into in-scope/out

19 Updated 1 weeks ago
gtrabanco
AI & Automation Listed

product-spec

Use when an ambiguous product feature, new product boundary, or named product fact source must become the smallest implementation-ready specification; owns product decisions and authorized spec artifacts, not selected-source UI specification or implementation.

2 Updated today
idaibin