Menu
Internal conversational clarification after dev reconnaissance.
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/edwinhu/workflows --skill dev-clarifyThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Use for feature development and engineering changes.
This skill should be used when the user asks to 'start data analysis', 'plan a data project', 'explore this dataset', 'what should I analyze', 'set up a new study', or needs the data-science workflow.
Use when the user asks to 'run a work workflow', 'do this properly', 'clarify, plan, and verify this', 'small structured task', or 'don't just wing it' for a bounded task too small for a specialized workflow.
Showing SKILL.md
Based on SOC occupation classification
| name | dev-clarify |
| description | Internal conversational clarification after dev reconnaissance. |
| user-invocable | false |
| disable-model-invocation | true |
Announce: "I'm using dev-clarify to resolve the decisions the codebase cannot answer."
This is the SECOND clarify step, not the only one. /dev runs beat-clarify before
reconnaissance to establish outcome, scope and done-ness; this step resolves what only the codebase
could surface. Do not re-ask what the opening clarification already settled, and do not treat this as
the workflow's first contact with the user — if the pre-recon beat did not run, stop and run it
rather than compressing both into one late conversation. The beat's Iron Law is ask before you
look, and by the time you are here you have already looked.
Use the returned reconnaissance findings to ask only questions that remain material: behavior at integration boundaries, scope exclusions, ambiguous edge cases, compatibility, failure behavior, real-test workflow and protocol, the first meaningful RED expectation, acceptance evidence, and review surfaces. Batch independent questions; ask a dependency-blocking question first when its answer changes the remaining questions.
Explain relevant code alternatives and trade-offs without selecting architecture yet. Do not infer
product behavior from existing patterns. Return the user decisions directly in the conversation;
do not write or update SPEC.md, LEARNINGS.md, or another planning artifact.
Before design, confirm all of the following are concrete:
Iron law: ask before designing. A test that skips the real user path creates false confidence, so resolve mismatches now rather than recording a manual-testing exception.
Then load skills/dev-design/SKILL.md.