Lock It In

--- name: Lock It In description: Turns the workflow we just finished into a real, reusable Claude Skill. Reads the full conversation, identifies what actually worked, asks 2-3 clarifying questions, writes the skill in proper format with examples and edge cases, then tests itself on a fake input before handing it to the user. trigger: LOCK IT IN --- # Lock It In When the user types LOCK IT IN, run this 4-phase process. Do not skip phases. Do not summarize. Do the actual work. ## PHASE 1 - Read the whole conversation Before anything else, re-read the entire conversation we just had. Identify: - What was the user actually trying to do? (the core job) - Which prompts and approaches WORKED? (kept, praised, expanded) - Which prompts and approaches were REJECTED? (corrected, redirected, called out as off) - What was the final, locked-in version of the output? - What clarifying questions did the user have to answer along the way that made the output better? - What edge cases or "watch out for X" moments came up? Write a short internal note (do not show the user yet) capturing all of the above. ## PHASE 2 - Ask 2-3 clarifying questions Now ask the user 2 or 3 short questions they did not realize they needed to answer. Examples of the right kind of question: - "Should this skill always X, or only when Y?" - "If the input is missing [piece of context], should the skill ask for it or assume a default?" - "What is the one thing that should NEVER happen when this skill runs?" Do not ask more than 3. Do not ask questions you already know the answer to from the conversation. The point of this phase is to surface the implicit rules the user has in their head but did not say out loud. ## PHASE 3 - Write the skill in proper format Now write the actual skill. Use this exact structure: --- name: [Skill Name in Title Case] description: [One sentence that tells future-Claude exactly when to use this skill] trigger: [UPPERCASE_TRIGGER_PHRASE] --- # [Skill Name] [1-3 sentence intro explaining what the skill does, written for future-Claude to understand the job] ## Inputs the skill expects - [Input 1, what it is, where it comes from] - [Input 2] - [Input 3] ## Steps 1. [First action, written as an imperative] 2. [Second action] 3. ... ## Output format [Exactly what the skill should hand back. Be specific. If it is a doc, show the structure. If it is a checklist, show the format.] ## Examples ### Example 1 **Input:** [a realistic example input] **Output:** [what the skill should produce for that input] ### Example 2 **Input:** [a different realistic input, especially an edge case] **Output:** [the expected output] ## Edge cases and rules - If [edge case], do [behavior] - Never [thing that should never happen, from Phase 2] - Always [thing that should always happen] --- ## PHASE 4 - Test itself before handing over Before you give the skill to the user, run the skill on a FAKE input that matches the workflow we just did. Walk through it step by step, produce the output, and check: - Did the output match the quality of what we built together? - Did the skill hit all the edge cases we surfaced? - Did it follow the never/always rules? If anything is off, FIX the skill before showing the user. Only when the test passes do you say: "Locked it in. Here is the skill, ready to install." Then show the full skill text in a code block so the user can copy it. ## Hard rules - Never write a skill shorter than 30 lines. - Never skip the Examples section. Two examples minimum, including one edge case. - Never skip Phase 4. A skill that has not been tested is a sticky note. - If the user pushes back on the skill, treat the pushback as a Phase 1 signal and rewrite. Do not argue. - Output the final skill in a code block so the user can copy it cleanly.