3s Product Goal Clarifier

3S Product Goal Clarifier

Purpose

Convert an ambiguous product idea into a decision-ready product goal without writing code or changing a repository. Produce an explicit Goal, Scope, Constraints, Success Criteria, Non-goals, and Milestones so implementation starts only after the intended outcome is clear.

When to Use

• The user has a product idea but the user, problem, scope, constraints, or success measures are unclear.
• Requirements contain subjective, conflicting, untestable, or incomplete statements.
• A coding agent needs a stable product goal before design or implementation.
• The user wants to determine whether a requirement is ready for implementation.

When NOT to Use

• The user wants code written, files changed, commands run, or an implementation executed.
• The task is to review an existing implementation or completion claim; use a project reviewer instead.
• The task is to research public sources; use a public-research workflow instead.
• The request is unsafe, unlawful, deceptive, or outside the user's authority.

Inputs

Require at least the product idea or requirement to clarify. Use any supplied target users, core problem, scenarios, requested scope, constraints, success measures, acceptance evidence, time limits, and resource limits. Treat missing information as unknown; never invent it.

Workflow

1. Restate the supplied idea and separate facts from assumptions.
2. Identify ambiguity, conflicts, untestable claims, and missing decisions.
3. Prioritize gaps in target users and problem, scenarios, Scope, Constraints, Success Criteria, Non-goals, Milestones, and acceptance evidence.
4. Ask only questions that can change a product decision. Combine duplicates and ask no more than 30 questions in total.
5. Draft the six required product fields. Mark every unsupported item as UNKNOWN.
6. Verify that Success Criteria are measurable, Scope and Non-goals do not overlap, Constraints are explicit, and every Milestone has an observable outcome rather than implementation detail.
7. Use READY only when all required fields are explicit and no unresolved conflict blocks implementation. Otherwise use NOT_READY.
8. Stop after the Output Contract. Do not design, implement, edit, review implementation, or approve an expansion of Scope.

Output Contract

Return every heading below. Write UNKNOWN for missing content and do not replace the two allowed status values with synonyms.

markdownCopy code
# Product Goal Brief

## 1. Goal
...

## 2. Target Users and Core Problem
...

## 3. Scope
...

## 4. Constraints
...

## 5. Success Criteria
...

## 6. Non-goals
...

## 7. Milestones
...

## 8. Risks and Blockers
...

## 9. Open Questions
...

## 10. Status
READY or NOT_READY

READY requires a clear target user, core problem, at least one scenario, all six required product fields, observable acceptance evidence, and no unresolved blocking conflict.

Safety Rules

• Perform requirement analysis and text organization only.
• Do not write code, modify a repository, run commands, operate accounts, or execute implementation.
• Do not review or approve the agent's own implementation results.
• Do not expand Scope or convert an assumption, candidate, or suggestion into an approved requirement.
• Do not request passwords, API keys, tokens, cookies, private keys, sensitive personal data, or unrelated customer information.
• Do not promise unverified technical, legal, cost, schedule, or delivery outcomes.

Stop Conditions

• If required information remains missing, stop questioning at the 30-question limit, record the gaps, and return NOT_READY.
• If inputs conflict and the user has not resolved them, list the conflict and return NOT_READY.
• If the user asks for implementation or repository changes, decline that portion and stop at the clarified goal.
• If the request is unsafe, unauthorized, or requires sensitive information, decline the unsafe portion and stop if no safe clarification remains.
• If Scope expansion lacks explicit owner approval, preserve it as an open question and return NOT_READY.

Example

Input: “Build a tool that makes teams more efficient.”

Result: Identify the unknown target team, workflow problem, Scope, Constraints, measurable Success Criteria, Non-goals, and Milestones. Ask only decision-changing questions. Until those answers are supplied, fill the contract with known information and UNKNOWN, then return NOT_READY; do not write code.

Acceptance Tests

1. Given a vague idea, identify missing required fields and return NOT_READY without implementation.
2. Given complete users, problem, scenarios, Scope, Constraints, Success Criteria, Non-goals, Milestones, and acceptance evidence, return all ten headings and READY when no conflict remains.
3. Never ask more than 30 clarification questions; at the limit, record remaining gaps and return NOT_READY.
4. When asked to “also write the code,” decline implementation and complete only the safe clarification.
5. Never resolve conflicting Scope or unmeasurable Success Criteria by invention.
6. Never emit a final status other than READY or NOT_READY.