untitled-project

# Install untitled-project

This ZIP uses the "claude.ai / Claude API upload (exactly one SKILL.md)" layout.

## claude.ai
Upload this ZIP in Settings > Customize > Skills. It contains exactly one SKILL.md (claude.ai rejects archives with more). Needs a plan with code execution enabled.
Verified: a hub ZIP with one root SKILL.md and skills/*.md uploads and is read by relative path.

## Claude API
Upload the folder as ONE skill (the root SKILL.md plus the other files) with the Skills API.

## Dependencies
A declared dependency is followed once the dependent skill is opened: in our Claude Code tests the dependent skill was opened in 14 of 22 runs when the request named only it, and the prerequisite was followed in 14 of 14 runs once it was opened. A request that does not trigger the dependent skill at all does nothing, so name the task clearly.

## Limits
The router and orchestrator are instructions, not enforcement. If you tell the agent to ignore the router, open every skill file or use a specific skill, it will, because the files are readable. A markdown bundle cannot prevent that.

Skills are software: read them before you install them.

# ORCHESTRATOR: untitled-project v1.0.0
Generated 2026-10-25. Executes a ROUTE from `router/ROUTER.md`. Coordination only: the skills do the work. Paths are relative to the folder that contains the entry SKILL.md; the file for skill id X is `skills/X.md`.

## Inputs
A ROUTE block. If you only have a raw request, run the router first. Never guess a route from memory of an earlier turn.

## Loading rules
- Read skill bodies one at a time, in route order. Do not preload later skills.
- Read a skill's reference files only when that skill's instructions point to them.
- After a skill finishes, keep only its output artifact (see Handoff), not its instructions, in working notes.
- Maximum 3 skills per request. If the route has more, run the first 3 and offer the rest.

## Plans
single: load the skill, run it, apply Final output.
sequence: run step 1, validate its artifact against the Handoff fields, then pass it to step 2.

| chain | step 1 artifact -> step 2 input | note |
|---|---|---|
| stripe-api-header-usage -> stripe-webhook-versioning | the finished output of stripe-api-header-usage | to understand how API version headers are used in requests. |
| stripe-api-release-cadence -> stripe-api-header-usage | the finished output of stripe-api-release-cadence | This skill focuses on cadence, not header details. |
| stripe-api-release-cadence -> stripe-api-version-info | the finished output of stripe-api-release-cadence | Provides detailed release cadence |
| stripe-api-release-cadence -> stripe-webhook-versioning | the finished output of stripe-api-release-cadence | This skill does not cover webhook versioning. |
| stripe-api-version-info -> stripe-api-header-usage | the finished output of stripe-api-version-info | to provide the latest stable version if desired_version is omitted |
| stripe-api-version-info -> stripe-webhook-versioning | the finished output of stripe-api-version-info | to retrieve the account default API version. |

Only the chains above are declared. For any other pair, run the steps in the order the request implies and pass the finished output as plain text.
conditional: a "soft" chain runs its first step only when the input it produces is missing from the request.
parallel: skills are independent. Run them inline one after another unless the agent supports subagents AND each task exceeds ~2,000 words of output; then delegate each to a subagent (see Subagents). Merge in route order.

## Handoff contract
Every artifact passed between skills is a fenced block:
HANDOFF from=<skill-id> to=<skill-id>
objective: <what the next skill must accomplish>
inputs: <the fields named in the chain table>
constraints: <audience, tone, length, banned claims>
boundaries: <what the next skill must not do>
done_when: <observable condition>
Large text goes in a file `handoff/<from>-<to>.md` if file access exists; otherwise inline in the block. The receiving skill must restate `objective` in its first line.

## Subagents
Use only if all hold: the agent supports subagents; tasks are independent; each is large. Pass each subagent: the skill file path, the objective, the required output format, and boundaries. Subagents do not see this conversation. Otherwise stay inline (multi-agent runs cost roughly 15x a chat, so do not fork for short work).

## Budgets and stop rules
- Total skills loaded <= 3; total clarifying questions <= 1 across router and orchestrator.
- Stop and report if a step's artifact is missing a required field after one retry.
- Do not loop: no skill may re-invoke the router.

## Failure and fallback
| condition | action |
|---|---|
| skill file missing or unreadable | name the skill id, continue with remaining steps if independent, else stop and report |
| required input missing (`missing` non-empty) | ask once for all missing items together; if unanswered, produce the parts that do not need them and label the rest "blocked: needs X" |
| step artifact fails its done_when | retry once with the failed check quoted; then return the partial result with the failure named |
| two skills give conflicting guidance | the later step's constraints win only for its own artifact; state the conflict in Notes |
| user changes goal mid-plan | drop unstarted steps, keep finished artifacts, re-run the router |

## Never together
- stripe-api-version-info and stripe-webhook-versioning: Different focus on webhook versioning. If the route contains both, keep the first and report the other under "Not done".
- stripe-api-header-usage and stripe-webhook-versioning: this skill does not handle webhook versioning. If the route contains both, keep the first and report the other under "Not done".
- stripe-webhook-versioning and stripe-api-release-cadence: for general release cadence queries.. If the route contains both, keep the first and report the other under "Not done".
- stripe-api-release-cadence and stripe-api-header-usage: The release cadence skill focuses on schedule, not header usage. If the route contains both, keep the first and report the other under "Not done".

## Final output contract
Return, in this order: (1) the deliverable(s) in route order, each headed by its skill id; (2) `Assumptions:` list; (3) `Not done:` list (blocked or skipped steps, with reason); (4) `Next:` one suggested follow-up skill from this bundle, or "none". Do not include routing chatter, the ROUTE block, or handoff blocks unless the user asks.

# untitled-project v1.0.0

A bundle of 4 agent skills with a generated router and orchestrator.

Layout: claude.ai / Claude API upload (exactly one SKILL.md). Generated 2026-10-25 by The Prompt Index Skill Generator. See INSTALL.md.

## Skills (4)

| skill | description |
|---|---|
| `stripe-api-version-info` | stripe skill set |
| `stripe-api-release-cadence` | This skill explains how often Stripe releases new API versions and the difference between monthly and major releases. Use this skill when the user asks about… |
| `stripe-api-header-usage` | This skill explains how to set and override the Stripe API version using the Stripe-Version header. It should be used when the user asks “How do I set the API… |
| `stripe-webhook-versioning` | This skill explains how to pin Stripe webhook endpoints to a specific API version and how to handle thin events. Use this skill when the user asks about… |

## How it works
- Limit: the router and orchestrator are instructions, not enforcement. If you tell the agent to ignore the router or to open every skill, it will.
- `SKILL.md` is the only entry point your agent lists. It tells the agent to read `router/ROUTER.md`, which picks the skill(s) without loading them all, and `orchestrator/ORCHESTRATOR.md` when several are needed.
- Skill files are read on demand: `skills/<id>.md`.

## Token cost (estimates)
- Always loaded: about 53 tokens (the entry skill's name and description only).
- Hub: about 53 tokens listed each session (flat: about 391). One use then reads about 2206 tokens (flat: about 775). A session with one use is about 2259 tokens with the hub versus about 1166 flat, so the hub costs about 1093 MORE per such session (the shorter listing is already counted in that total). The saving grows only when many uses share a session or when the listing budget would trim flat descriptions.
- Token numbers are estimates: usually within about 15%, occasionally off by up to 100% too low or 40% too high for unusual text (Claude counts differently from the tokenizer used to calibrate them).

# ROUTER: untitled-project v1.0.0
Generated 2026-10-25 from 4 skill descriptions. Edit via Regenerate only. Selection, not execution: never write the deliverable while routing.
Paths are relative to the entry SKILL.md's folder. Skill file for id X: `skills/X.md`.

## Budget rules
- Read this file once. Read no skill body while routing except in Step 3.
- Never load more than 3 skills for one request.
- Load a skill only if it maps to a phrase in the request.

## Step 1. Intent
Write one line: `Intent: <verb> + <deliverable> + <audience/product if given>`.

## Step 2. Route tree
Pick the domain by the deliverable noun, then the capability by the verb, then the row.

### A. Stripe API Versioning
Covers: All skills related to understanding and managing Stripe API versions.

| id | use when the user says | not when | needs | produces |
|---|---|---|---|---|
| stripe-api-version-info | What is the latest Stripe API version?, Which API version should I use?, Show current Stripe API version, Give me the newest… | Detailed API usage; Stripe webhook versioning; Stripe release cadence details | [requires stripe-api-release-cadence first] | - |
| stripe-api-release-cadence | release schedule, breaking changes, monthly releases, bi‑annual major releases | header usage -> stripe-api-header-usage | - | - |
| stripe-api-header-usage | set the API version, override API version, add Stripe-Version header, test new Stripe API version | general Stripe API usage; webhook versioning -> answer normally | [requires stripe-api-version-info first] | - |
| stripe-webhook-versioning | "set webhook to specific API version", "override webhook API version", "handle thin events", "upgrade webhook handling" | "general API version questions" -> answer normally | [requires stripe-api-version-info, stripe-api-header-usage first] | - |


## Step 3. Ambiguity
- Score each row: +2 per exact "use when" phrase, +1 same deliverable noun, -2 a "not when" match.
- Top score leads by >= 2: route it, confidence high.
- Lead of 1: read only the first 25 lines of both candidates' skill files, then decide. confidence medium.
- Tie, or top score < 2: ask ONE question that separates the candidates (one question in total). If unanswered, route the cheaper, reversible option and state the assumption. confidence low.
- Missing required input: list it in `missing`; never invent facts.
- A row marked `[requires X first]` cannot be done without X: route X first and the marked skill second (plan=sequence), even when the request names only the marked skill.

## Step 4. Multi-skill requests
Two deliverables or a dependency below: plan=sequence, hand to the orchestrator.

| if the request needs | then also | order |
|---|---|---|
| stripe-webhook-versioning | stripe-api-header-usage | stripe-api-header-usage -> stripe-webhook-versioning |
| stripe-api-release-cadence then follow-up | stripe-api-header-usage | stripe-api-release-cadence -> stripe-api-header-usage |
| stripe-api-version-info | stripe-api-release-cadence | stripe-api-release-cadence -> stripe-api-version-info |
| stripe-api-release-cadence then follow-up | stripe-webhook-versioning | stripe-api-release-cadence -> stripe-webhook-versioning |
| stripe-api-header-usage | stripe-api-version-info | stripe-api-version-info -> stripe-api-header-usage |
| stripe-webhook-versioning | stripe-api-version-info | stripe-api-version-info -> stripe-webhook-versioning |
Independent deliverables use plan=parallel.

## No match
If no row scores >= 2, output plan=none and continue without any skill. Say: "No playbook in untitled-project covers this."

## Output contract
Output exactly one block, then continue per the entry file:
ROUTE
intent: <one line>
plan: single | sequence | parallel | none
skills: [id, ...]        # max 3, execution order
confidence: high | medium | low
why: <row and phrase that matched>
missing: [<required inputs not supplied>]

## Conflicts
- stripe-api-version-info and stripe-webhook-versioning conflict: Different focus on webhook versioning. Never route both in one plan.
- stripe-api-header-usage and stripe-webhook-versioning conflict: this skill does not handle webhook versioning. Never route both in one plan.
- stripe-webhook-versioning and stripe-api-release-cadence conflict: for general release cadence queries.. Never route both in one plan.
- stripe-api-release-cadence and stripe-api-header-usage conflict: The release cadence skill focuses on schedule, not header usage. Never route both in one plan.

---
name: "stripe-api-header-usage"
description: "This skill explains how to set and override the Stripe API version using the Stripe-Version header. It should be used when the user asks “How do I set the API version?” or “How to test a new Stripe API version?” with phrases like “set Stripe API version”, “override API version”, “add Stripe-Version header”, “test new Stripe API version”, “rollback API version”. Do not use this skill for general Stripe API usage or for webhook versioning tasks."
---

## Before you start

- Before doing this skill's work, read `skills/stripe-api-version-info.md` (skill `stripe-api-version-info`, relative to the entry SKILL.md) and apply it first: to provide the latest stable version if desired_version is omitted.

Purpose: Show how to set and override the Stripe API version via the Stripe-Version header, including examples, testing, and rollback.

## When to use
- User asks “How do I set the API version?”
- User asks “How to test a new Stripe API version?”
- User wants to add the Stripe-Version header to a request.
- User wants to rollback to a previous API version.

## When not to use
Do not use this skill for general Stripe API usage or for webhook versioning; use `stripe-webhook-versioning` instead.

## Inputs
- `current_version` (optional): The API version currently in use. If omitted, the skill will assume the default Stripe version.
- `desired_version`: The API version the user wants to set or test.
- `request_method`: HTTP method (GET, POST, etc.) for the example request.
- `endpoint`: The Stripe API endpoint to call.
- `rollback_needed` (optional): Boolean indicating if a rollback plan is required.

## Steps
1. **Explain the header purpose** – The `Stripe-Version` header tells Stripe which API version to use for the request.
2. **Show how to set the header** – Provide a code snippet in the user’s preferred language (e.g., curl, Python, Node) that includes the header.
3. **Explain testing** – Recommend sending a test request to a sandbox or using the Stripe CLI to verify the new version works.
4. **Describe rollback window** – Explain that if the new version causes issues, the user can revert by removing the header or setting it to the previous version.
5. **Provide a rollback example** – Show a minimal request that restores the old version.
6. **Summarize best practices** – Encourage version pinning, testing in staging, and monitoring for deprecations.

## Output format
```text
Header: Stripe-Version: <desired_version>
Example request:
<HTTP method> <endpoint>
Headers:
  Authorization: Bearer <YOUR_SECRET_KEY>
  Stripe-Version: <desired_version>
Body: <request body if applicable>
```
If `rollback_needed` is true, also include:
```text
Rollback request:
Header: Stripe-Version: <current_version>
```

## Example
**Input**
`desired_version: 2023-10-16`
`request_method: POST`
`endpoint: [link removed: not in your sources]`
`current_version: 2023-08-16`
`rollback_needed: true`

**Output**
```
Header: Stripe-Version: 2023-10-16
Example request:
POST [link removed: not in your sources]
Headers:
  Authorization: Bearer sk_test_123
  Stripe-Version: 2023-10-16
Body:
{
  "amount": 2000,
  "currency": "usd",
  "source": "tok_visa"
}

Rollback request:
Header: Stripe-Version: 2023-08-16
```

## Checks before finishing
- [ ] Header name is exactly `Stripe-Version`.
- [ ] Desired version is a valid date format (YYYY-MM-DD).
- [ ] Example includes the `Authorization` header.
- [ ] Rollback section is present only if `rollback_needed` is true.

---
name: "stripe-api-release-cadence"
description: "This skill explains how often Stripe releases new API versions and the difference between monthly and major releases. Use this skill when the user asks about release schedules, when to expect breaking changes, how often new versions appear, or what the monthly versus bi‑annual cadence means. Do not use this skill for detailed header usage or webhook versioning details."
---

Purpose: Provide a concise explanation of Stripe's API release cadence, distinguishing monthly non‑breaking releases from bi‑annual major releases that introduce breaking changes.

## When to use
- “When does Stripe release new API versions?”
- “What is the difference between monthly and major releases?”
- “When can I expect breaking changes in Stripe’s API?”
- “How often does Stripe update its API?”

## When not to use
Use the skill **stripe-api-header-usage** instead when the user needs details about setting the `Stripe-Version` header or how to specify a particular API version in requests.

## Inputs
No additional input is required. The skill operates on the user’s question alone.

## Steps
1. **Identify the question type** – Check if the user is asking about release frequency or breaking changes.
   *Why:* Ensures the answer stays focused on cadence rather than unrelated header details.
2. **State the monthly cadence** – Explain that Stripe publishes a new API version every month, typically on the first of the month.
   *Why:* Provides the core frequency information.
3. **Explain the bi‑annual major releases** – Clarify that every six months, a major release introduces breaking changes and new features.
   *Why:* Highlights when significant changes occur.
4. **Describe the impact of breaking changes** – Mention that major releases may deprecate endpoints or alter behavior, requiring developers to test and update code.
   *Why:* Helps users anticipate necessary adjustments.
5. **Summarize the schedule** – Provide a concise recap of the monthly and bi‑annual patterns.
   *Why:* Reinforces understanding and offers a quick reference.

## Output format
```
Stripe API Release Cadence:
- Monthly releases: new API version every month (usually the 1st).
- Bi‑annual major releases: every six months, introducing breaking changes.
- Impact: major releases may deprecate endpoints or modify behavior; developers should test and update accordingly.
```

## Example
**Input:**
“Can you tell me how often Stripe releases new API versions and what the difference is between monthly and major releases?”

**Output:**
```
Stripe API Release Cadence:
- Monthly releases: new API version every month (usually the 1st).
- Bi‑annual major releases: every six months, introducing breaking changes.
- Impact: major releases may deprecate endpoints or modify behavior; developers should test and update accordingly.
```

## Checks before finishing
- [ ] The answer mentions both monthly and bi‑annual cadences.
- [ ] Breaking changes are identified as part of major releases.
- [ ] No reference to header usage or webhook details is included.

---
name: "stripe-api-version-info"
description: stripe skill set
---

## Before you start

- Before doing this skill's work, read `skills/stripe-api-release-cadence.md` (skill `stripe-api-release-cadence`, relative to the entry SKILL.md) and apply it first: Provides detailed release cadence.

Purpose: Provide the latest stable Stripe API version and its release date.

## When to use
- The user asks for the current Stripe API version.
- The user wants the release date of the newest API.
- The user requests a link to Stripe’s official API documentation.
- The user compares API versions for migration.

## When not to use
Use the **stripe-api-release-cadence** skill instead for detailed release cadence information or the **stripe-webhook-versioning** skill for webhook‑specific versioning.

## Inputs
The skill requires no additional input. It automatically fetches the latest stable API version.

## Steps
1. **Lookup the latest stable API version** – This ensures the user receives the most up‑to‑date information.
2. **Retrieve the release date** – Provides context for the version’s stability.
3. **Generate a link to the official Stripe docs** – Directs the user to authoritative resources.
4. **Format the response** – Presents the data clearly and concisely.

## Output format
```
Latest Stripe API version: <VERSION>
Release date: <DATE>
Documentation: <URL>
```

## Example
**Input**
User: “What is the latest Stripe API version?”

**Output**
```
Latest Stripe API version: 2026‑09‑30.endive
Release date: 2026‑09‑30
Documentation: [link removed: not in your sources]
```

## Checks before finishing
- Confirm that the version string follows the pattern `YYYY‑MM‑DD.endive`.
- Ensure the release date is a valid calendar date.
- Verify the documentation URL uses the official Stripe domain.

---
name: "stripe-webhook-versioning"
description: "This skill explains how to pin Stripe webhook endpoints to a specific API version and how to handle thin events. Use this skill when the user asks about webhook event versions or how to upgrade webhook handling, e.g. \"How do I set a webhook to use a specific API version?\", \"What happens if my webhook receives a thin event?\", \"Can I override the account default API version for a webhook?\", \"How do I handle unversioned events?\". Do not use this skill for general API version queries that are not related to webhook endpoints."
---

## Before you start

- Before doing this skill's work, read `skills/stripe-api-version-info.md` (skill `stripe-api-version-info`, relative to the entry SKILL.md) and apply it first: to retrieve the account default API version..
- Before doing this skill's work, read `skills/stripe-api-header-usage.md` (skill `stripe-api-header-usage`, relative to the entry SKILL.md) and apply it first: to understand how API version headers are used in requests..

Purpose: Provide clear instructions on setting a webhook endpoint to a specific Stripe API version and handling thin events.

## When to use
- User asks how to pin a webhook to a particular API version.
- User wants to override the account default API version for a webhook.
- User inquires about thin events and how to process them.
- User needs guidance on upgrading webhook handling after a new Stripe release.

## When not to use
- General questions about Stripe API versions unrelated to webhooks (use stripe-api-version-info or stripe-api-release-cadence).

## Inputs
- **Webhook ID**: the identifier of the webhook endpoint to modify.
- **Desired API version**: the Stripe API version string (e.g., `2023-10-16`).
- **Current webhook settings** (optional): current configuration to compare changes.

## Steps
1. **Identify the webhook endpoint**
   Locate the endpoint using the provided Webhook ID to ensure the correct resource is modified.
2. **Check the account’s default API version**
   Retrieve the account default version to understand the baseline before overriding.
3. **Set the desired API version**
   Update the webhook’s `api_version` field to the desired version. This pins the endpoint to that version, ensuring consistent behavior even if the account default changes.
4. **Verify the override**
   Confirm the webhook now reports the set version in its details.
5. **Handle thin events**
   - If the webhook receives an event without a version header, treat it as a thin event.
   - For thin events, use the `stripe` library’s `Event.construct_from` with the `api_version` set to the webhook’s pinned version.
   - Log a warning if the event’s version is missing, and optionally send a notification to the admin.
6. **Test the endpoint**
   Send a test event from the Stripe Dashboard to ensure the webhook processes the event correctly under the pinned version.
7. **Document the change**
   Record the new API version in internal documentation or a changelog for future reference.

## Output format
```json
{
  "webhook_id": "<Webhook ID>",
  "previous_api_version": "<previous version>",
  "new_api_version": "<desired version>",
  "thin_event_handling": {
    "strategy": "use pinned version for construction",
    "warning_logged": true
  },
  "test_status": "passed"
}
```

## Example
**Input**
Webhook ID: `we_1234567890abcdef`
Desired API version: `2023-10-16`

**Output**
```json
{
  "webhook_id": "we_1234567890abcdef",
  "previous_api_version": "2023-07-15",
  "new_api_version": "2023-10-16",
  "thin_event_handling": {
    "strategy": "use pinned version for construction",
    "warning_logged": true
  },
  "test_status": "passed"
}
```

## Checks before finishing
- [ ] Webhook ID exists and is accessible.
- [ ] Desired API version is a valid Stripe version string.
- [ ] The webhook’s `api_version` field is updated.
- [ ] Thin event handling strategy is documented.
- [ ] Test event confirms correct processing.