We split this skill into the rules it gives an agent

14 rules. About 0 are common, 12 are distinctive, and 2 are very specific to this project.

• ≈0

  Common · estimate

  Many files like this have a rule of this kind.

• ≈12

  Distinctive · estimate

  This author's own choices. Worth a look.

• 2

  Very specific

  Tied to their project's names, files or tools. Probably skip.

• Common
• Distinctive
• Very specific

1. Distinctive:

   Ask only the next unanswered question cluster, not the whole interview at once.

   line 23
2. Very specific:

   Read references/answer-completeness.md to decide whether the reply is sufficient or needs follow-up.

   line 24
3. Very specific:

   Read references/gating-rules.md before moving from clarification into planning.

   line 25
4. Distinctive:

   After each phase, summarize confirmed facts, explicit assumptions, and open questions.

   line 26
5. Distinctive:

   Only when all mandatory gates pass, hand off a concise, execution-ready brief or plan.

   line 27
6. Distinctive:

   Ask 1-3 short questions at a time.

   line 31
7. Distinctive:

   Prefer constrained choices when possible.

   line 32
8. Distinctive:

   Keep questions ordered: objective first, implementation later.

   line 33
9. Distinctive:

   If the user says "you decide", record the default explicitly as an assumption.

   line 34
10. Distinctive:

    Do not generate code, file edits, or architecture proposals before gates pass.

    line 39
11. Distinctive:

    Do not ask duplicate questions.

    line 40
12. Distinctive:

    Do not jump into low-level implementation details before product intent is clear.

    line 41
13. Distinctive:

    Do not silently fill critical gaps with guesses.

    line 42
14. Distinctive:

    Stop and ask for explicit approval when the decision changes scope, cost, or stack direction.

    line 43

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.