# Assignment 2 — Author & Invoke a Skill

**Released after:** Session 1 (referenced again in Session 3)
**Do it during:** the Wed–Thu build period
**Time:** ~40 min · **Tools:** Claude (web is fine; Claude Code if you have it)

## Why this matters

A **skill** is the simplest, highest-leverage way to make AI useful in your organization.
It's just *context, packaged*: the instructions, standards, and know-how for one
repeatable task, written down once so the model applies it consistently every time —
instead of you re-explaining it in every conversation.

In the language of Session 1: **a skill adds context to the window.** That's the whole
idea. You're not training a model; you're handing it the playbook.

## What to do

### Part 1 — Pick the task (5 min)

Use the repeatable task you brought in pre-work (or pick a new one). Good candidates:

- A weekly status update or board summary in your house style
- A first-pass review checklist (contract, vendor, hiring, security)
- A standard customer reply or onboarding message
- A meeting-prep brief from a calendar invite + context

It should be something done **the same way repeatedly**, with rules you can articulate.

### Part 2 — Write the skill (20 min)

Write a clear instruction block that captures the procedure. A good skill names:

- **When to use it** — the trigger ("when I paste raw notes from a customer call…").
- **The steps** — what to do, in order.
- **The format** — exactly what the output should look like.
- **The standards / guardrails** — tone, length, what to never include, when to ask first.

Write it as if onboarding a sharp new hire who knows nothing about your context.
Keep it tight — remember the context window is a budget. A page is usually plenty.

> **If you use Claude Code:** save it as a real skill file (a `SKILL.md` with a name and
> description) so it can be invoked by name. **If you use the web app:** keep it as a
> reusable prompt block you paste in, or save it as a Project's custom instructions.

### Part 3 — Invoke it, twice (15 min)

1. Give the skill a realistic input and run it. Check the output against your standards.
2. Now give it a *different* input. Did it hold the format and rules without you
   re-explaining? Where did it drift?
3. Tighten the skill based on what you saw. Run a third time.

## Deliverable

- The skill text itself (the instruction block / `SKILL.md`).
- Two example outputs (different inputs).
- Two or three sentences: what improved between the first run and the last, and one
  task in your org you'd turn into a skill next.

## What "good" looks like

- A colleague could read your skill and produce the same output you do.
- The output is consistent across different inputs — the format doesn't wander.
- It's specific to *your* context, not generic advice the model already knew.

## Going further (optional)

- Add a "if you're missing X, ask me before proceeding" rule and test that it triggers.
- Chain two skills (e.g., "draft" then "critique against our checklist").