define-outcome

Define observable acceptance criteria and success contracts for ambiguous feature requests.

2|Updated Sep 14, 2026
One-click install
npx skills add https://github.com/kwanpham2195/agent-stuff --skill define-outcome-kwanpham2195
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: define-outcome
Source: https://github.com/kwanpham2195/agent-stuff/tree/main/skills/define-outcome
Command: npx skills add https://github.com/kwanpham2195/agent-stuff --skill define-outcome-kwanpham2195

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a feature request or change has unclear goals, scope, or success criteria, teams risk building the wrong thing or arguing about done-ness later. This Skill turns ambiguous intent into a compact acceptance contract that any developer, agent, or reviewer can evaluate without the original conversation. ## Core Features & Use Cases - Outcome Clarification: Extracts the user, situation, problem, desired outcome, scope, and exclusions from requests and existing product artifacts, asking only questions that require human judgment. - Acceptance Contract Authoring: Produces Given/When/Then scenarios with stable criterion IDs, evidence requirements (automated test, demonstration, measurement, or human review), and identified decision owners. - Verification Discipline: Reports criteria as passed, failed, blocked, or awaiting human review, keeping required evidence distinct from collected evidence and preventing premature done claims. - Use Case: Before implementing a status-filtering feature, use this Skill to record the observable scenarios, boundary cases, and evidence plan in the owning issue so implementation and review share one definition of success. ## Quick Start Ask the agent to define the outcome and acceptance criteria for your feature request before any implementation begins.

Frequently Asked Questions about define-outcome

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I define acceptance criteria for a vague feature request?▼

Acceptance criteria start from the user, situation, problem, and desired outcome, then become observable Given/When/Then scenarios with evidence methods. This Skill extracts what is already agreed, asks only judgment questions, and records the contract in the owning issue or artifact.

How to write acceptance criteria without creating a full PRD?▼

Keep small contracts inline in the existing issue or plan rather than creating a standalone document. A separate PRD is only warranted when durable requirements genuinely need their own artifact; by default no standalone outcome file is created.

When should acceptance criteria be defined before implementation?▼

Define criteria whenever the outcome, scope, or success measures are ambiguous and the next step is consequential. Research and prototypes may proceed within authorized scope, but implementation should wait on unresolved consequential decisions.

What are the limitations of acceptance criteria workflows?▼

Defining acceptance does not authorize implementation or publishing, and subjective criteria still require a human decision owner. Criteria must not be weakened to match an implementation; changes need recorded decisions, rationale, and approval sources.

How do I verify work against acceptance criteria?▼

Evaluate each criterion as passed, failed, blocked, or awaiting human review with supporting evidence. Passing automated checks does not substitute for required human acceptance, and untested criteria should be reported rather than declaring the task done.