Stitching Skills Together

Given skills A, B, C to stitch into a new skill:

YAML
# composed-skill-manifest.yaml (scratch work, not the deliverable)
name: routing-support-tickets
composes: [classifying-intent, enriching-customer-context, deciding-routing]
pipeline:
  - step: classifying-intent
    input: {subject: string, body: string}
    output: {intent: string, sentiment: string, priority: string}
  - step: enriching-customer-context
    input: {customer_id: string}
    output: {last_ticket: string, account_age: string}
  - step: deciding-routing
    input: "{merge(step1.output, step2.output)}"
    output: {assigned_agent: string, priority_badge: string}
feedback:
  capture: [resolution_time, customer_satisfaction_rating]
  updates: deciding-routing.weights

Then write the actual SKILL.md for routing-support-tickets documenting this pipeline in prose + examples, per standard skill format. The manifest is scratch work to clarify design — ship a readable skill, not a YAML pipeline.

Progress:

• Step 1: Inventory the skills to stitch — read each one's actual inputs/outputs
• Step 2: Define the composed skill's single overall purpose (not "does everything A, B, C do")
• Step 3: Map data flow — what output feeds what input, in what order
• Step 4: Identify format mismatches and write adapter logic
• Step 5: Decide sequencing — strict pipeline, conditional branching, or parallel-then-merge
• Step 6: Add a feedback/growth mechanism appropriate to the skill's nature
• Step 7: Write the composed skill as a normal SKILL.md (Quick Start, Workflow, Examples, Pitfalls)
• Step 8: Test end-to-end with one real example before calling it done

Step 1 — Inventory. For each component skill, extract: what it needs as input, what it produces as output, what it assumes about context. If a skill's input/output isn't explicit, infer it from its examples section.

Step 2 — Single purpose. A stitched skill is not "skill A + skill B bolted together" — it's a new capability that happens to use A and B internally. Name it for what it accomplishes end-to-end (routing-support-tickets, not classifying-then-enriching-then-deciding).

Step 3 — Data flow map. Draw it as a simple chain:

raw_input → [Skill A] → intermediate_1 → [Skill B] → intermediate_2 → [Skill C] → final_output

Note any fan-out (one output feeds multiple downstream skills) or fan-in (multiple outputs merge into one input).

Step 4 — Adapters. When Skill A outputs {text: "..."} and Skill B expects {content: "...", format: "plain"}, write the tiny transform explicitly in the composed skill's workflow section. Keep adapters inline and simple — one-line mappings, not new sub-skills.

Step 5 — Sequencing pattern. Pick one:

• Strict pipeline: each step depends on the prior step's output. Use when logic is inherently sequential.
• Conditional branch: output of step 1 determines which skill runs next. Use when skills are alternatives, not additions.
• Parallel + merge: independent skills run on the same input, outputs combined by a final rule. Use for ensemble-style decisions (e.g., recommendation scoring).

Step 6 — Growth mechanism. Not every stitched skill needs machine learning. Match the mechanism to the skill:

• Rule refinement: log failures/edge cases as plain notes in the skill file's Pitfalls section; periodically review and add new rules.
• Weighted decisions: track outcomes (success/failure, user rating) in a simple log; adjust a documented scoring rule based on aggregate results.
• Prompt/example growth: when the stitched skill underperforms, add the failing case as a new worked Example — this is the cheapest and most common growth loop for Claude-based skills.

Step 7 — Write the final skill. The output is a single SKILL.md following standard format (frontmatter, Quick Start, Workflow, Examples, Best Practices, Pitfalls) — the fact that it's composed of other skills is an implementation detail mentioned briefly, not the main content.

Step 8 — Test with a real example. Run one concrete input through the full chain mentally or literally. If any step's output doesn't match the next step's expected input, fix the adapter before shipping.

Example 1: Stitching three skills into a support router

Input: Skills classifying-intent, enriching-customer-context, deciding-routing need to become one skill that routes tickets.

Output:

Markdown
---
name: routing-support-tickets
description: Routes incoming support tickets to the right agent by classifying
  intent/sentiment, enriching with customer history, then applying routing
  rules that improve as resolution outcomes are logged. Use when a new
  support ticket needs to be assigned to an agent or queue.
---

1. Classify: extract intent, sentiment, priority from subject+body.
2. Enrich: look up customer_id for last_ticket and account_age.
3. Decide: if intent=Billing AND sentiment=Negative → Senior Billing Agent; else apply standard priority queue rules.
4. Log outcome (resolution_time, csat) to refine step 3's rules monthly.

[steps corresponding to the three stitched skills...]

Input: subject="Urgent: Payment failed", sentiment=Negative, intent=Billing Output: routed to Senior Billing Agent, priority=High