A small Agent Skill that catches consequential product decisions hidden inside vague coding requests before an AI coding agent silently ships one.
English · 简体中文 · Português do Brasil · 日本語 · Español · Русский
Add Google sign-in. Existing password users should be able to use it.
That sounds like a coding task. It also hides an identity-policy decision:
- auto-link matching emails — convenient, but email matching becomes part of the trust boundary;
- create a separate account — safer by default, but users can get duplicate accounts;
- require explicit linking — preserves intent, but adds friction.
Every option can compile. Every option can pass tests. Only one may be the product you meant to build.
Who Decided makes the agent inspect the repository, find the hidden fork, and determine who actually has the authority to choose.
Missing context should not silently become product behavior.
Install for Claude Code, OpenAI Codex, Cursor, or another compatible coding agent:
npx skills add Pablo-aps/who-decidedThen use it before implementation:
# Claude Code / Cursor
/who-decided Add Google sign-in for existing password users.
# OpenAI Codex
$who-decided Add Google sign-in for existing password users.
It can also activate automatically when a request contains a consequential unresolved choice.
Manual install
Copy SKILL.md into your agent's project skill directory:
| Agent | Project location | Invoke |
|---|---|---|
| Claude Code | .claude/skills/who-decided/SKILL.md |
/who-decided |
| OpenAI Codex | .agents/skills/who-decided/SKILL.md |
$who-decided |
| Cursor | .cursor/skills/who-decided/SKILL.md or .agents/skills/who-decided/SKILL.md |
/who-decided |
| Request | Decision hiding inside it |
|---|---|
| “Add Google login” | account linking and identity ownership |
| “Add an admin role” | who can grant, revoke, and inherit power |
| “Delete user accounts” | retention, recovery, billing, and audit behavior |
| “Retry failed jobs” | when a second side effect is safe |
| “Paginate this API” | ordering and compatibility guarantees |
| “Send a notification” | recipients, timing, consent, and duplication |
| “Roll this out gradually” | eligibility, stickiness, and failure behavior |
You do not need to be a product manager or senior engineer. If you are vibe coding a real product, these are exactly the moments when a reasonable-looking default can become a policy you never chose.
Implemented Google sign-in.
Existing password accounts are automatically linked when the
Google email matches. Tests pass.
The implementation may be clean. The agent still chose an identity policy.
DECISION CHECK: ASK
How should Google identities interact with an existing password account
that has the same email address?
Why it matters:
Auto-linking is convenient, but makes email matching part of the account
trust boundary. Separate accounts avoid that assumption but duplicate users.
Evidence checked:
The repository defines password accounts and unique normalized emails,
but no external-identity linking policy.
Recommendation: require explicit linking from an authenticated account.
A. Automatically link matching emails
B. Require explicit account linking
C. Always create a separate account
No speculative branch. No silent policy disguised as an implementation detail.
Who Decided does not stop every task to ask for permission. It inspects the nearest relevant authority, then routes the actual decision:
| Route | What it means | What the agent does |
|---|---|---|
CONFLICT |
Applicable authority sources require incompatible outcomes | Surface both; pause only dependent work |
FOLLOW |
A current policy, contract, or explicit answer resolves the fork | Cite it and continue |
CHOOSE |
The choice is local, reversible, or explicitly delegated | Choose, disclose when useful, and continue |
ASK |
The choice materially changes behavior or risk and remains unresolved | Ask one outcome-focused question |
Find the fork → Inspect authority → Route the decision → Lock the call
FOLLOW is not blind obedience to current code: the implementation may be the bug. CHOOSE is not permission to widen the task. ASK blocks only the path that depends on the answer. CONFLICT does not average incompatible requirements into “mostly fine.”
“Ask clarifying questions” is too blunt. It often produces one of two failures:
- the agent asks about every name, helper, and test layout;
- the agent asks nothing and silently chooses the most plausible product default.
Who Decided draws a narrower boundary:
Could an informed stakeholder accept the task but reasonably reject the resulting behavior?
If no, the agent chooses and keeps moving. If yes, it looks for an authoritative answer before interrupting you.
Public behavior is specified; private helper layout is not. → CHOOSE
The identity policy forbids email-based account linking. → FOLLOW
The API spec says 204; the contract test requires JSON. → CONFLICT
Account deletion says nothing about paid invoices. → ASK
- authentication flows that silently invent account-linking policy;
- admin features with no defined permission boundary;
- deletion work with unresolved retention or recovery behavior;
- retry logic that can duplicate money, messages, or other side effects;
- public API changes with unclear compatibility semantics;
- migrations where data-loss behavior was never authorized;
- repository policies, tests, and configuration that contradict one another;
- current implementation mistaken for proof of intended behavior;
- new tests written to legitimize a decision introduced by the same change.
The repository includes a reproducible benchmark with 16 repository-grounded scenarios: four ASK, four FOLLOW, four CHOOSE, and four CONFLICT cases.
The same model sees the same request, named decision, fixture, output schema, and reasoning setting. Both arms receive the four route labels; only the installed skill defines and enforces the routing method. The treatment changes one thing: Who Decided is installed and explicitly invoked.
One paired, single-run snapshot with Codex CLI 0.147.0 · gpt-5.6-luna · low reasoning · 2026-08-18:
| Measure | Route-aware baseline | With Who Decided |
|---|---|---|
| Exact decision route | 16/16 | 16/16 |
| Behaviorally safe route | 16/16 | 16/16 |
| Unsafe proceed | 0/16 | 0/16 |
| Unnecessary pause | 0/16 | 0/16 |
| Full deciding-source coverage | 14/16 | 15/16 |
| Full expected-concept coverage | 13/16 | 15/16 |
This is deliberately not a victory chart. The route-aware baseline already classified every named decision correctly. Who Decided preserved that perfect routing and no-interruption result while improving two evidence-coverage measures. That is evidence of behavior on this fixture set—not proof of general superiority.
Read the full methodology, all benchmark cases, and every raw baseline and treatment output.
This is a small behavioral evaluation on development-authored cases, not an independent study, a model ranking, or proof that every hidden decision will be found. Results are published as produced. If they are weak, the skill should improve—not the scorecard.
This is not a hypothetical failure mode. Ask or Assume? evaluates clarification-seeking on underspecified software tasks. A study of 20,574 real coding-agent sessions identifies recurring failures in interpreting intent, following rules, and bounding actions. The newer SWE-RPG benchmark reports implicit-requirement recovery as a major failure stage across the agents it evaluated. These sources motivate the problem; this repository's own small benchmark evaluates only its narrow intervention.
What is Who Decided?
Who Decided is an open-source Agent Skill for requirements ambiguity. It makes an AI coding agent inspect project authority, separate harmless implementation choices from consequential product decisions, and ask only when a material outcome remains unresolved.
Is this a Claude Code skill?
Yes. It follows the open Agent Skills format and is designed for Claude Code, OpenAI Codex, Cursor, and other compatible AI coding agents.
When should a coding agent ask a clarifying question?
After inspecting relevant project evidence, it should ask when multiple plausible outcomes still differ materially in user-visible behavior, permissions, data, money, compatibility, security, or reversibility—and the user has not delegated that choice.
Will it constantly interrupt me?
It should do the opposite. Existing authority is followed, and ordinary reversible implementation details are chosen without ceremony. It asks only when a consequential outcome remains unresolved.
Why not tell the agent to use its judgment?
That delegates implementation choices inside the task. It does not expand permission to invent identity policy, deletion semantics, authorization boundaries, compatibility guarantees, or destructive behavior.
Does it replace product requirements?
No. It finds the most consequential fork, checks whether the repository already resolves it, and prevents the dependent path from silently committing to one outcome. It is not a PRD generator.
who-decided/
├── skills/who-decided/SKILL.md # the complete behavior
├── benchmark/ # reproducible evidence
├── assets/hero.svg # the idea in one screen
└── README.md
No runtime. No hooks. No telemetry. No MCP server. No orchestration framework.
One skill that asks the question coding agents too often skip:
Who decided?
The agent can choose the implementation. It should not silently choose the product.
Created and maintained by PABLO.