Product Capability
SkillDev toolsLoad when accepted product intent must become a concise, implementation-ready local capability specification with explicit constraints, non-goals, test seams, and unresolved decisions.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Product Capability skill
What this skill tells your AI
The instructions your AI receives, as published by jasonxzwen/harness-hub in skills/product-capability/SKILL.md and read by ahel’s review.
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:
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 existing canonical spec or planning location. Do not create a new planning stack when the repository already owns one.
Quality Gate
The result is ready only when:
- every required behavior traces to accepted source facts
- boundaries and failure behavior are explicit
- test seams demonstrate user/caller-visible outcomes rather than private structure
- non-goals prevent likely scope drift
- contradictions with current implementation are surfaced
- a competent implementer can proceed without rediscovering hidden product decisions
Use to-tickets only when the accepted spec needs project-owned execution slices. Do not publish an issue, apply a label, or mutate a remote tracker from this Skill.
Signals
- GitHub stars
- 72
- Last commit
- Jul 2026
Advanced
- Catalog kind
- skill
- Gateway key
product-capability-jasonxzwen- Source
- github.com/jasonxzwen/harness-hub