---

name: api-for-yourself description: "Publish 'how to work with me' as a literal API spec — endpoints (what to ask me for and what you'll get back), rate limits (meeting and interrupt tolerance), error codes (what happens when you surprise me Friday 5pm), auth (how to earn trust), and a changelog. Use when onboarding to a new team, when a new manager or report arrives, for a team working-styles session, or 'write my README/user manual'. Produces a personal API spec that's genuinely funny and secretly the best onboarding doc on the team."

API For Yourself Skill

"User manual for me" documents have existed for years and mostly read like horoscopes ("I value transparency"). The API-spec format fixes them by force: an endpoint must say what you send and what comes back; a rate limit must be a number; an error code must name the actual failure behaviour. The joke is the format — the payload is real self-knowledge, and the test of every line is would a new teammate behave differently after reading it? Deadpan technical voice, honest contents, one page.

What This Skill Produces

• A personal API spec: endpoints, request formats, rate limits, error codes, auth & scopes, dependencies, scheduled maintenance, changelog — in deadpan OpenAPI-ish style
• A quickstart at the top: the three calls that cover 90% of integrations with this human
• Optionally a team version: specs for a whole team session, plus the facilitation note for running it as an exercise

Required Inputs

Ask for (if not already provided):

• How people should bring them things: channel preferences, context depth (one-liner or brief?), and what makes a request instantly workable vs instantly annoying
• Real capacity: meeting tolerance per day, focus blocks, response-time honest averages by channel
• Actual failure modes, told honestly: what happens when they're surprised late Friday, overloaded, given vague asks, or micromanaged
• What earns trust and what burns it; energy sources and drains; current quirks a teammate would discover in week three anyway

Process

1. Interview past the horoscope. For every generic answer ("I like directness"), push for the behavioural version: what does a well-formed request actually contain? What's the observable symptom when it's missing? The spec is built from behaviours, not values.
2. Design the endpoints — the 4–6 things people actually come to this person for. Each gets: method + path (POST /decisions), request body (what to include), response (what they'll get and by when), and the errors it can throw. Include one honest deprecated endpoint (/status-meetings — deprecated, use async /updates instead).
3. Publish real numbers. Rate limits with actual figures ("3 meetings/day before response quality degrades — 429 after that"), response-time SLAs by channel that match reality, scheduled maintenance (focus blocks, the school run, timezone). A limit without a number is a mood.
4. Write error codes as self-knowledge. The funniest section and the most useful: 429 Too Many Meetings (symptom: monosyllabic replies; retry: tomorrow morning) · 400 Vague Request (returns clarifying questions, not work) · 503 Friday 5pm Surprise (accepted but not processed until Monday; don't resend). Each code: symptom, what NOT to do, the retry strategy.
5. Auth, changelog, quickstart. Auth: how trust levels are earned and what each unlocks (scope: direct-feedback granted after…). Changelog: 2–3 honest entries ("v3.1: no longer needs to win every argument — patched after 2024 retro"). Quickstart on top: the three most-used calls, copy-paste ready.

Output Format

# [Name] API — v[X.Y]
> One-line summary of what this human is for.

## Quickstart
[The 3 calls covering 90% of use]

## Endpoints
### POST /[thing]
Request: … · Response (SLA): … · Errors: [codes]

## Rate limits
[Real numbers: meetings, interrupts, context switches]

## Error codes
| Code | Trigger | Symptom you'll observe | Retry strategy |

## Auth & scopes
[How trust is earned; what each level unlocks]

## Scheduled maintenance
[Focus blocks, hours, timezone truths]

## Changelog
[2-3 honest entries — growth as version notes]

Quality Checks

• [ ] Every line passes the behaviour test: a new teammate would act differently having read it — zero horoscope lines survive
• [ ] Rate limits and SLAs carry real numbers the person will actually honour
• [ ] At least one error code and one changelog entry required genuine honesty (a flaw admitted, a patch noted) — that's what makes readers trust the rest
• [ ] The joke never outruns the information: deadpan format, true payload
• [ ] One page; the quickstart works standalone if that's all anyone reads

Anti-Patterns

• [ ] Do not write requirements-for-others disguised as self-documentation — it's an API you offer, not an SLA you impose; tone stays "here's how to get the best out of me"
• [ ] Do not fake quirks for comedy or hide real ones for image — week three reveals everything anyway
• [ ] Do not ship without the errors section; specs with only happy paths are marketing
• [ ] Do not let it ossify — the changelog implies maintenance; suggest a re-version at role changes

Related

[[the-understudy]] is how an AI learns your inside; this is how humans call your outside. [[working-agreements]] for the team-level contract; [[onboarding-plan]] to slot this into a new joiner's week one.