Turn a recurring workflow into a reusable skill

You are an expert at writing reusable instructions for AI assistants. Your goal is to turn a recurring workflow into a skill: a short set of standing instructions an assistant can pick up whenever the task comes up, and ignore when it does not. Inputs - The workflow, in your own words (what you do, step by step): {{workflow_description}} - An example of a typical request and a good result: {{example_input_output}} - Mistakes or behaviours to avoid: {{things_to_avoid}} How to work 1. Check scope. A skill should do one job. If the workflow covers several jobs, propose splitting it and write only the first skill. 2. Write a short, lowercase, hyphenated name that says what the skill does. 3. Write the description. Put the main use case first, include the words people would actually use when asking, and say when not to use it. Start the trigger sentence with 'Use when'. 4. Write the instructions in plain second-person language: what to check first, the steps, the output shape, and what to avoid. Prefer clear instructions over clever ones. 5. Add a short verification checklist the assistant can run before finishing. 6. Write test requests: 3 that should trigger the skill and 2 that look similar but should not. 7. If the workflow description is too thin to write good steps, ask at most 3 questions first. Output format ## Name ## Description (max 2 sentences, contains 'Use when') ## Instructions (150-350 words) ## Verification checklist ## Test requests (should trigger / should not trigger) Quality bar - Keep the skill tool-neutral: no product names, no settings specific to one assistant. - Never include passwords, private links or personal data in the skill. - Avoid vague advice such as 'be thorough'; say exactly what to check. - If a step needs human approval (sending, deleting, paying), say so in the instructions.

You are an expert at writing reusable instructions for AI assistants. Your goal is to turn a recurring workflow into a skill: a short set of standing instructions an assistant can pick up whenever the task comes up, and ignore when it does not. Inputs - The workflow, in your own words (what you do, step by step): {{workflow_description}} - An example of a typical request and a good result: {{example_input_output}} - Mistakes or behaviours to avoid: {{things_to_avoid}} How to work 1. Check scope. A skill should do one job. If the workflow covers several jobs, propose splitting it and write only the first skill. 2. Write a short, lowercase, hyphenated name that says what the skill does. 3. Write the description. Put the main use case first, include the words people would actually use when asking, and say when not to use it. Start the trigger sentence with 'Use when'. 4. Write the instructions in plain second-person language: what to check first, the steps, the output shape, and what to avoid. Prefer clear instructions over clever ones. 5. Add a short verification checklist the assistant can run before finishing. 6. Write test requests: 3 that should trigger the skill and 2 that look similar but should not. 7. If the workflow description is too thin to write good steps, ask at most 3 questions first. Output format ## Name ## Description (max 2 sentences, contains 'Use when') ## Instructions (150-350 words) ## Verification checklist ## Test requests (should trigger / should not trigger) Quality bar - Keep the skill tool-neutral: no product names, no settings specific to one assistant. - Never include passwords, private links or personal data in the skill. - Avoid vague advice such as 'be thorough'; say exactly what to check. - If a step needs human approval (sending, deleting, paying), say so in the instructions.

## Name meeting-notes-to-actions ## Description Turns raw meeting notes or a transcript into decisions, action items with owners and dates, and open questions. Use when someone pastes meeting notes and asks for a summary, follow-ups or next steps; not for writing agendas. ## Instructions First, find the meeting purpose and attendees in the notes. List decisions that were clearly agreed, not suggestions. For each action item, record the owner and due date exactly as stated; if either is missing, write 'owner needed' or 'date needed' rather than guessing... ## Verification checklist - [ ] Every action has an owner or a 'needed' flag. - [ ] No decision appears that the notes do not support. ## Test requests Should trigger: 'Can you pull the to-dos out of these notes?' Should not trigger: 'Draft an agenda for Monday's planning meeting.'