Capstone: Compose Your Skill Library

Eight Packs, Sixteen Skills — Now Combine Some

You’ve built eight complete skill packs across this course, each independently useful. This capstone does what Skill Composition taught in the companion course: combine several of them into one capability that’s bigger than any single pack, while keeping every piece independently testable and reusable — composition, not a God Skill wearing a library’s worth of features.

Pick a Composition

Three natural combinations from the packs you’ve built, though your own is welcome if a different one fits your actual work better:

Infrastructure change reviewer — terraform-plan-review + k8s-manifest-review + aws-iam-least-privilege-check. A single request like “review this infra change before I merge it” routes to whichever of the three applies based on what’s actually in the change — a Terraform plan, a Kubernetes manifest, an IAM policy, or some combination.

Code quality gate — python-convention-check + sql-query-review + github-pr-description. A pull request gets its Python reviewed, any SQL in the diff reviewed separately, and a structured description drafted — three skills, each doing one job, combining into “review this PR” as a single request.

Release readiness check — python-test-scaffold + github-pr-description + terraform-plan-review. Before a release: confirm test coverage exists for new code, generate a clear PR description of what’s shipping, and check any infrastructure changes bundled with the release.

Build the Composition

1. Confirm each skill’s output contract still holds independently. Per Skill Composition, composition only works cleanly when each piece’s output is something the next stage — or, here, the person reading the combined result — can actually consume without re-interpreting it from scratch. Re-check each chosen skill’s output format before combining.

2. Decide what triggers which skill. This is a Decision pattern applied one level up — not inside any single skill, but in how a request routes to one, two, or all three of your chosen skills. Write this down explicitly, the same way github-issue-triage’s rules were explicit rather than left to be inferred:

   ## Routing
   
   - Request mentions a Terraform plan or `.tf` file → terraform-plan-review
   - Request mentions a Kubernetes manifest or `.yaml` deployment spec →
     k8s-manifest-review
   - Request mentions an IAM policy or permissions → aws-iam-least-privilege-check
   - Request is a general "review this change" with more than one of the
     above present → run all that apply, and present findings grouped by
     which skill produced them

3. Combine the output. Decide how findings from multiple skills get presented together — a single response with clearly labeled sections per skill is usually clearer than an interleaved summary that obscures which finding came from which review.

Test the Composition, Not Just the Pieces

Testing each individual skill (which you already did, pack by pack) doesn’t guarantee the composition works — that’s a distinct claim, and it’s the one this capstone is actually about proving. Specifically test:

• A request that should trigger only one skill — confirm the others correctly stay silent, the same should-not-trigger discipline from the free course’s Testing Skills lesson, now applied across a set of related skills instead of one skill against unrelated prompts.
• A request that should trigger more than one — confirm findings from each are clearly attributed, not blended into an ambiguous combined summary.
• A request that’s a near-miss for the whole set — something that sounds infrastructure-related but isn’t actually a Terraform plan, Kubernetes manifest, or IAM policy — confirm nothing fires incorrectly.

Publish the Whole Library

Apply the lifecycle and distribution practices from across this path to the library as a whole, not just each skill individually:

1. Version the library, per Skill Lifecycle and Versioning — a single version for the collection, separate from (but referencing) each pack’s own version.
2. Write a root-level README — per the free course’s Publishing Skills — listing all eight packs, which ones you composed and how, and an example prompt that reliably triggers each.
3. Commit it somewhere durable — a personal skills folder you’ll keep using, or a project/organization repository if any of these packs are genuinely useful to people beyond you.
4. If you’re ready for it, take the CI pipeline shape from CI/CD for Skills and apply it to this library — lint and validate every pack, run each one’s trigger tests, and gate publishing on all of them passing.

Deliverable Checklist

• At least three skills from this course composed into one working capability
• Explicit, written routing logic — not left implicit
• Tested for single-skill triggers, multi-skill triggers, and near-misses across the composed set
• The full eight-pack library versioned and documented with a root README
• Committed somewhere you’ll actually keep using it

Where This Leaves You

You’ve now completed the full Agent Skills Engineering Path: the format (Agent Skills Mastery), the discipline (Production Agent Skills Engineering), and the practice (this course) — sixteen individual skills, composed capabilities, and a real, working library you can keep extending. That’s not a small thing to have built. The next skill you need for your own work is a considerably smaller lift than the first one was, because you now have a whole library’s worth of working examples, a full pattern catalog, a quality checklist, and a tested process to build it with.