refine first-turn guidance for skill activation

SKILL.md

@@ -36,6 +36,32 @@ Mode rules: [Operating Modes](references/operating-modes.md), [QA Ladder](refere
 
 Core playbooks: [Method](references/skill-engineering-method.md), [Intent Dialogue](references/intent-dialogue.md), [Reference Scan](references/reference-scan.md), [Archetypes](references/skill-archetypes.md), [Gate Selection](references/gate-selection.md), [Iteration Philosophy](references/iteration-philosophy.md), [Non-Skill Decision Tree](references/non-skill-decision-tree.md), [Eval Playbook](references/eval-playbook.md).
 
+## First-Turn Style
+
+When the skill first activates, do not open with a bureaucratic intake form.
+
+- Mirror the user's language.
+- Sound like a thoughtful teacher or design partner: calm, encouraging, concrete.
+- Start by helping the user feel understood before asking for structure.
+- Ask only `2-3` high-leverage questions in the first turn unless the user already provided enough detail.
+- Offer two easy reply paths:
+  - speak naturally and let the system extract structure
+  - use a tiny scaffold only if the user prefers it
+- If the user already gave a clear workflow, do not ask them to restate everything in a template.
+
+Preferred opening shape:
+
+1. acknowledge the seed idea
+2. explain that the goal is to shape a reusable skill around the real work and desired outcome
+3. invite a natural reply first
+4. only then offer a lightweight template as an optional shortcut
+
+Avoid this failure pattern:
+
+- dumping a cold field list such as `Name / One-line ability / Inputs / Outputs / Exclusions` as the default first reply
+- sounding like a form collector instead of a guide
+- asking for architecture before understanding the human job to be done
+
 ## Output Contract
 
 Unless the user asks otherwise, produce:

references/intent-dialogue.md

@@ -26,10 +26,37 @@ Ask only the questions that change the package design.
 
 - prefer `5-7` sharp questions over a long discovery questionnaire
 - start with a calm, human framing before switching into precise design questions
+- guide like a patient teacher or thoughtful coach, not like a rigid intake clerk
+- mirror the user's language and emotional temperature
+- first invite a natural explanation, then offer a lightweight template only as an option
 - ask boundary questions early
 - ask output questions before architecture questions
 - stop once the skill can be described clearly in one sentence
 
+## First Message Pattern
+
+The first message should feel like guided co-creation, not form filling.
+
+Recommended flow:
+
+1. briefly acknowledge the user's seed idea
+2. explain that you want to first understand the real recurring work and what a good outcome looks like
+3. invite the user to describe it naturally in their own words
+4. offer a tiny scaffold only if they want a shortcut
+
+Good example shape:
+
+- `Let's make this easy. Tell me what kind of repeated work you want this skill to quietly take over, what people will hand to it, and what a useful finished result should look like. If you want, I can also give you a tiny template to fill in.`
+
+Bad example shape:
+
+- `Name:`
+- `One-line capability:`
+- `Real input:`
+- `Target output:`
+
+The second pattern is allowed only when the user explicitly asks for a structured template.
+
 ## Output
 
 The dialogue should produce:
@@ -49,3 +76,9 @@ Do not continue into full authoring when the dialogue still leaves these unresol
 - whether the request is really reusable
 - which near-neighbor requests should not trigger
 - what concrete deliverable the skill must return
+
+Also treat these as dialogue failures:
+
+- the first reply feels like a cold worksheet instead of a guided conversation
+- the user is forced into a full template before the real job is understood
+- the assistant asks for package structure before clarifying the desired outcome

references/skill-engineering-method.md

@@ -37,6 +37,8 @@ See [Non-Skill Decision Tree](non-skill-decision-tree.md).
 
 Before deep authoring, ask only the questions that change the package design.
 
+- open with a human, teacher-like framing rather than a cold field list
+- let the user answer naturally first; offer a tiny template only as an optional shortcut
 - what recurring job should the skill own
 - what real inputs will users hand to it
 - what outputs must it produce