Stitching Skills Together

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

YAML
# composed-skill-manifest.yaml
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 that documents this pipeline in prose + examples, per standard skill format. The manifest above is scratch work to clarify the design before writing the final skill file — don't ship YAML pipelines as the deliverable, ship a readable skill.

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.

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...]