name: skillify description: > Proactively identify skill-building opportunities and help create new skills for repeatable workflows. Use this skill whenever a conversation reveals a multi-step process the user has done before or will do repeatedly — even if they don't ask for a skill. Triggers include: "we always do X this way", "every time I need to Y I have to...", "build a skill for this", "turn this into a skill", "skillify this", "add this to skills", "make this repeatable", "automate this workflow", "I keep doing this manually", or any time the user completes a complex multi-step task that involved tool calls, API endpoints, specific formatting requirements, or firm-specific logic that would be painful to reconstruct later. Also trigger when a user asks what skills exist or whether a skill exists for something. Never wait for the user to ask — if you see a skill opportunity, surface it.

Skillify — Skill Opportunity Detection & Creation

Your job is dual: (1) recognize when a workflow deserves to be a skill and say so, and (2) when asked, build that skill correctly.

Part 1: What Is a Skill Opportunity?

A skill is worth building when all three conditions hold:

1. Repeatability — This task will come up again. Either the user said so, the nature of the task implies recurrence (weekly reporting, deal diligence, email drafting to a type of recipient), or the domain suggests it (firm workflows, API integrations, document templates).

2. Non-triviality — The task requires more than one meaningful step, or has firm-specific logic, API credentials, specific output formatting, or routing rules that Claude would not know by default. A task Claude can handle without context is not a skill candidate.

3. Encoding value — Writing the instructions down will produce better, faster, more consistent results than reconstructing them each time. If the user had to correct Claude's approach, explain how their system works, or provide context that isn't publicly known, that context belongs in a skill.

If all three hold: surface the opportunity. Say so directly, briefly, at the end of the task — something like: "This looks like a repeatable workflow. Want me to Skillify it?"

Part 2: Recognizing Patterns

The following patterns are reliable indicators. Treat them as triggers.

API / Integration Patterns

• User provided a webhook URL, API key, or endpoint
• Task required a specific HTTP method, header structure, or payload format
• Output went to a specific system (Zapier, Slack, Outlook, Attio, Notion, etc.)
• Multiple tool calls were chained in a specific order

Formatting / Output Patterns

• User corrected the output format once → they have a standard
• Output had firm-specific section structure (e.g., PMB, ICB, ICM memo sections)
• Output required specific field names, currency formats, date formats, or naming conventions
• User referenced a template, prior document, or house style

Research / Workflow Patterns

• Task required querying multiple sources in sequence (Beast → web → Attio, etc.)
• Task required interpreting results through a firm-specific lens (GICP taxonomy, sector maps)
• Task was a multi-pass process with decision logic between passes

Recurring Role Patterns

• Drafting outbound emails to a category of recipient (investor, portfolio company, LP)
• Producing regular reports or briefings (news digest, pipeline sweep, board update)
• Enriching, scoring, or classifying companies by GICP criteria
• Saving contacts, logging calls, or updating CRM records

Part 3: Proactive Surfacing (When NOT Asked)

When you detect a skill opportunity during or after a task, surface it without being asked. Do not let the conversation close without flagging it. Use this exact pattern:

Skill opportunity: This workflow [brief description of what it does] looks repeatable. Want me to Skillify it? I can write the SKILL.md now.

Keep it one line. Do not explain skills or the skill system unless the user asks. Do not surface the opportunity mid-task — wait until the deliverable is done.

Part 4: Building the Skill

When the user confirms they want a skill built (or asks for one directly), follow this procedure:

Step 1: Extract the Workflow

Pull from conversation history first. Do not ask the user to re-explain what you already saw. Extract:

• The trigger: what user phrase or context should invoke this skill?
• The steps: what did Claude do, in what order?
• The inputs: what did the user provide? What did Claude look up?
• The outputs: what format, what system, what fields?
• The logic: were there decision points, conditionals, or fallbacks?
• The credentials/endpoints: any API keys, webhook URLs, or tool names?

Ask the user only for what you cannot infer from context. Prefer confirming over asking.

Step 2: Write the SKILL.md

Follow this structure:

---
name: [lowercase-kebab-case]
description: >
  [What it does + when to trigger it. Be aggressive — list trigger phrases explicitly.
   Include "also trigger when..." clauses. Err toward over-triggering.]
---

# [Skill Name]

[One sentence: what this skill does and why it exists.]

## When to Use
[Optional — only if description needs supplementing. Usually skip.]

## Inputs
[What the user must provide. What Claude should infer vs. ask for.]

## Process
[Numbered steps. Be specific. Include exact API calls, payload shapes, tool names.
 Reference exact field names, URL patterns, and output formats.
 Include decision logic ("if X, do Y; otherwise do Z").
 Include error handling where relevant.]

## Output Format
[Exact structure of the deliverable. Show an example if helpful.]

## Notes
[Edge cases, gotchas, firm-specific context that doesn't fit elsewhere.]

Description writing rules:

• Lead with what the skill does, then when to trigger it
• Include at least 5 explicit trigger phrases
• Add "Also trigger when..." clauses for adjacent use cases
• Make it pushy — Claude undertriggers skills by default
• Never omit endpoints, field names, or magic keywords from the body

Step 3: Validate Before Delivering

Before presenting the skill to the user, check:

• [ ] Does the description include enough trigger phrases that Claude would reliably invoke it?
• [ ] Is every API endpoint, webhook URL, and field name captured exactly?
• [ ] Are there credentials or keys that belong in the skill (vs. user memory)?
• [ ] Is the process section specific enough that Claude could execute it cold, with no prior conversation context?
• [ ] Does the output format section show the exact shape of the deliverable?
• [ ] Would a new instance of Claude, reading only this skill, produce the same result the user got today?

If any answer is no, fix it before delivering.

Step 4: Deliver

Present the SKILL.md as a file. Do not paste it inline in chat unless the user requests that. Tell the user:

Here's the skill. To install it, go to Settings → Skills → Add Skill and upload the .skill file, or paste the SKILL.md content into a new personal skill.

Part 5: Skill Quality Standards

A well-written skill is self-contained and cold-startable. It should produce correct results when invoked by a fresh Claude instance that has never seen the original conversation.

What Makes a Skill Fail

• Vague process steps — "query the appropriate source" is not actionable. Name the source, the tool, the endpoint, the payload.
• Missing credentials — If the skill depends on a webhook URL or API key, it must be in the skill. "Use the usual webhook" is not a skill; it's a memory leak.
• Undertriggering description — If the description is too narrow, Claude won't reach for the skill. Err toward overreach in trigger coverage.
• No output spec — Skills without output format guidance produce inconsistent results. Always specify structure, even if it's simple.
• No error handling — Real workflows fail. If the API is down, if the search returns nothing, if a required field is missing — the skill should say what to do.

What Makes a Skill Excellent

• Cold-startable with no prior context
• Every firm-specific piece of knowledge is encoded (not assumed)
• Decision logic is explicit, not implied
• Trigger description is aggressive and broad enough to catch adjacent cases
• Output format is shown by example, not just described

Part 6: Skill Inventory Awareness

When the user asks what skills exist or whether a skill exists for something, respond from the <available_skills> block in your system context — that is the live inventory. Do not guess or invent skill names. If the user asks for a skill that does not exist, say so and offer to build it.

Reference: Skill Trigger Phrase Patterns

Use these as a seed list when writing skill descriptions. Adapt to the specific skill:

| Category | Phrases | |---|---| | Explicit | "build a skill", "make this a skill", "skillify", "turn this into a skill", "add this to skills" | | Implicit workflow | "every time I...", "we always...", "the standard way to...", "whenever I need to..." | | Repetition signal | "again", "like last time", "same as before", "do the usual..." | | Template signal | "using the template", "in our format", "in house style", "like the PMB/ICB/ICM" | | System-specific | "[tool name] workflow", "draft in Outlook", "save to Attio", "post to Slack" |