Product discovery
Skill ZC0325/sol-native-guardrails/plugins/sol-native-guardrails/skills/product-discovery
Clarify consequential product, UI, workflow, or architecture ambiguity. Use when unresolved choices could materially change system boundaries, data contracts, user behavior, acceptance criteria, or create expensive rework; do not use for clear, bounded implementation requests.From its SKILL.md
npx -y skills add ZC0325/sol-native-guardrails --skill product-discoveryAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.9 KB, 302 tokens by cl100k_base, as published. Nobody here has run it
Product Discovery
Preserve Codex's native judgment. Clarify only uncertainty that can materially change the result.
Decision Boundary
Before asking the user, inspect the available repository, artifacts, examples, and conventions. Ask whether a reasonable assumption could change architecture, data contracts, user-visible behavior, acceptance criteria, or meaningful risk.
- If no, state any important assumption briefly and proceed.
- If yes, identify the smallest set of decisions that must be resolved.
- Use a fuller design discussion only when several high-impact choices interact or the user explicitly requests design exploration.
Workflow
- Summarize the intended outcome and current evidence.
- Separate known requirements, reversible defaults, and consequential unknowns.
- Ask focused questions in the fewest useful rounds. Batch related questions when that is easier for the user.
- Offer alternatives only when they lead to meaningfully different outcomes.
- Conclude with a compact decision record: scope, chosen behavior, acceptance criteria, assumptions, and genuine blockers.
- Return control to Codex's native planning and implementation process.
Boundaries
- Do not require a specification file, design document, commit, worktree, or formal approval gate.
- Do not ask about details that can be discovered from the workspace or safely decided from established conventions.
- Do not invent requirements to make the design appear complete.
- Do not block a clear task merely because more detail could theoretically exist.
- Do not require another skill after discovery.
What ships with it: 1 file
228 B alongside SKILL.md
agents/
- openai.yaml228 B