Product Capability

SkillDev tools

Load 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.

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