clarify

Converts vague tasks into measurable requirements and testable acceptance-criteria documents.

3|Updated Jun 17, 2026
One-click install
npx skills add https://github.com/ronaknnathani/relay --skill clarify-ronaknnathani
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: clarify
Source: https://github.com/ronaknnathani/relay/tree/main/skills/clarify
Command: npx skills add https://github.com/ronaknnathani/relay --skill clarify-ronaknnathani

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Vague or underspecified tasks like "make it faster" or "add validation" force planners to guess what success looks like, leading to rework and misaligned implementations. This Skill closes the gap between what was asked and what is actually wanted by producing a crisp requirements and acceptance-criteria artifact before any planning begins. ## Core Features & Use Cases - Codebase-first resolution: Answers discoverable questions by exploring the code before ever asking the user, so interviews only cover genuinely unknown decisions. - Structured one-at-a-time interviewing: Each question carries a visible hypothesis and recommended default, making it easy for users to confirm with a single word. - Measurable reframing: Converts fuzzy language into testable criteria, such as turning "make it faster" into "p95 < 200ms on the cold path under N concurrent requests". - Use Case: Before planning a change like "add request validation to the API", run this Skill to pin down edge cases, error handling, scope boundaries, and backward compatibility, then hand the resulting artifact directly to the plan phase. ## Quick Start Ask the agent to clarify the requirements and acceptance criteria for your task before it starts planning the implementation.

Frequently Asked Questions about clarify

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

FAQPage Schema
How do I turn a vague task into clear requirements?▼

Walk a coverage checklist of edge cases, error handling, integration points, scope, compatibility, and performance, then interview the user one question at a time with a recommended default. Reframe every vague phrase into a measurable, checkable criterion.

When should I clarify requirements before planning?▼

Clarify at the start of any non-trivial task when the goal is fuzzy, such as "make it faster" or "add validation", or when you cannot predict how the user would judge done. For tidying existing code, use a simplify pass instead.

Should I ask the user questions answerable from the codebase?▼

No. Resolve anything discoverable in the code first, such as existing conventions or integration points, by exploring the repository. Only ask the user what genuinely cannot be determined from the code.

What makes a good acceptance criterion?▼

A good acceptance criterion is testable by a test, command, or unambiguous observation, stated as an observable outcome rather than an implementation mechanism. Avoid vague adjectives like fast, clean, or robust.

How do I handle users who say "whatever you think"?▼

Treat vague delegation as an unanswered question, not sign-off. Restate your concrete recommendation and get an explicit yes, or record the deferral as a resolved assumption with your chosen default and reasoning.

When should I stop asking clarifying questions?▼

Stop when you reach roughly 95 percent confidence, meaning you can predict the user's answers to your next three questions and they would not change the artifact. Do not stop while a checklist dimension remains genuinely open.