Product capability

Skill JasonxzWen/harness-hub/skills/product-capability

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

Install

npx -y skills add JasonxzWen/harness-hub --skill product-capability

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.5 KB, 430 tokens by cl100k_base, as published. Nobody here has run it

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:

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.

What ships with it: 1 file

1.0 KB alongside SKILL.md

LICENSE.txt1.0 KB