3.13 -- Building a Custom Skill (Steinberg Method)

Context

Built-in skills (calendar, email, tasks) cover generic needs. But your business has specific requirements. A consultant wants to query their CRM. An e-commerce seller wants to track their orders. A developer wants to monitor deployments.

This is where custom skills come in. A custom skill is a module that the agent uses to interact with a data source or external service specific to your context.

The 4 Parts of a Skill

Each custom skill contains exactly 4 parts:

1. Authentication

How the agent connects to the service.

## Authentication
- Type: API key / OAuth / token
- Storage: vault (never in plain text in the skill)
- Rotation: every 90 days
- Fallback: if the token expires, notify the user

2. Requests

What the agent can ask the service to do.

## Authorized Requests
- GET /clients: list of active clients
- GET /clients/{id}/history: client history
- GET /invoices/pending: unpaid invoices
- POST /notes: add a client note (with validation)

3. Scope

The skill's boundaries: what it can see, what it cannot see.

## Scope
- Accessible data: active clients only (not archives)
- Period: last 12 months
- Sensitive fields excluded: banking details, IBAN
- Max results per request: 50

4. Safeguards

Security rules and usage limits.

## Safeguards
- Never modify data without user validation
- Never do bulk exports (more than 100 records)
- Never access deleted data
- Rate limit: 10 requests per minute max
- On API error: notify, do not auto-retry

The Golden Rule: Read the Generated SKILL.md

When you create a skill with the generic prompt (below), the agent generates a SKILL.md file in your workspace. READ IT.

The agent interprets your request and translates it into rules. These rules don't always match your intent. Verify:

• Are the authorized requests complete? (not too many, not too few)
• Is the scope correct? (no access to sensitive data)
• Are the safeguards strict enough?

Remove Decision Rules

A skill must NOT contain decision rules. A skill connects, retrieves data, and presents it. Decision-making belongs in CONSTITUTION.md.

Wrong (in the skill):

If the client hasn't paid in 30 days, send a reminder.

Right (in CONSTITUTION.md):

When a client has an unpaid invoice for more than 30 days,
flag it for me and propose a draft reminder. Do not send.

The skill provides information. CONSTITUTION.md says what to do with it.

Generic Prompt to Create a Skill

I want to create a custom skill for [service name].

Context:
- Service: [service description, API URL if available]
- Usage: [what I want to use it for, 2-3 sentences]
- Frequency: [how many times per day/week I need it]

Constraints:
- Authentication: [available auth type]
- Sensitive data: [what must never be exposed]
- Forbidden actions: [what the skill must never do]

Generate the skill with the 4 parts:
authentication, requests, scope, safeguards.

Show me the SKILL.md before installing it.

Complete Example: "client-pulse" Skill (Adapted from Steinberg)

Steinberg's "client-pulse" is a skill that gives a quick view of client relationship health. Here's an adaptation:

# SKILL.md -- client-pulse

## Description
Gives a quick overview of the relationship with a client:
last interaction, pending invoices, satisfaction.

## Authentication
- Source: CRM via REST API
- Auth: Bearer token (stored in vault)
- Rotation: 90 days

## Requests
- GET /clients/{id}/last-interaction
  > Returns: date, type (email/call/meeting), summary
- GET /clients/{id}/invoices
  > Returns: invoices from last 6 months, status
- GET /clients/{id}/satisfaction
  > Returns: latest NPS score, trend

## Scope
- Active clients only
- 6 months of history
- No access to detailed financial data (amounts yes, margins no)
- No access to internal notes marked "confidential"

## Safeguards
- Read-only (no CRM modifications)
- Maximum 5 clients queried per session
- No comparison between clients (isolated data)
- On API unavailability: flag it, do not invent data

## Typical Usage
"Give me the pulse of ClientAlpha"
> Last interaction: call on 28/03, quote topic
> Invoices: 1 pending (2,800 EUR, due 05/04)
> Satisfaction: NPS 8/10 (stable)

Step by Step

1. Identify the service you want to connect
2. Verify that the API is available and documented
3. Use the generic prompt above
4. Read the SKILL.md generated by the agent
5. Verify the 4 parts (auth, requests, scope, safeguards)
6. Remove any decision rules (they go in CONSTITUTION.md)
7. Test the skill with a simple request
8. Validate for 3-5 days before integrating it into the daily briefing

Advanced Prompt Template

For cases where you need more control:

Create a custom skill with these exact specifications:

NAME: [skill-name]
SERVICE: [name and URL]
AUTH: [authentication method]

AUTHORIZED REQUESTS:
1. [method] [endpoint] -- [description] -- [usage frequency]
2. [method] [endpoint] -- [description] -- [usage frequency]

FORBIDDEN REQUESTS:
- [method] [endpoint] -- [reason for prohibition]

SCOPE:
- Visible data: [list]
- Excluded data: [list]
- Period: [duration]

SAFEGUARDS:
- [rule 1]
- [rule 2]

Generate the SKILL.md. Do not install it until I validate.

Common Mistakes

Not reading the generated SKILL.md: The agent may have added requests you don't want, or missed safeguards. Always read it.

Putting decision rules in the skill: A skill retrieves data. It doesn't decide what to do with it. Decision-making goes in CONSTITUTION.md.

Skill too broad: A skill with 15 different requests is probably 3 skills. Break it up.

No safeguards: A skill without safeguards is direct access to an external service. Always define limits.

Forgetting token rotation: An API token that never expires is a security risk. Plan for rotation.

Verification

• [ ] The target service has a documented API
• [ ] The skill contains the 4 parts (auth, requests, scope, safeguards)
• [ ] The generated SKILL.md has been read and validated
• [ ] No decision rules in the skill
• [ ] Safeguards are defined and explicit
• [ ] Token is stored in vault (not in plain text)
• [ ] Test with a simple request successful