Scope Definition

Lesson 3 · Agentic Skills Best Practices · ~8 minutes

By the end of this lesson, you'll be able to apply the Single Responsibility Principle to skill files — drawing clear boundaries that prevent scope creep, reduce token usage, and make skills composable.

Win

After this lesson, you'll instinctively decompose a "do-everything" skill into focused, single-purpose skills that compose cleanly.

The Single Responsibility Principle for Skills

David Parnas wrote in 1972 that modules should be decomposed based on information hiding — each module encapsulates one design decision. The same principle applies to skills:

Each skill file addresses one domain or task family
Avoid mixing unrelated capabilities
Use composition over inheritance — multiple focused skills working together
Define explicit boundaries in the skill description

The Monolithic Skill Anti-Pattern

Consider a "business-operations" skill that handles invoices, sends emails, and manages inventory. This monolith causes four concrete problems:

Problem	Impact
Increased token usage	The full skill definition (all three domains) loads into context even when only invoicing is needed
Reduced reliability	An email-sending bug breaks invoice processing too
Difficult maintenance	Changes to inventory logic require re-testing email workflows
Poor reusability	Another team needs email-sending but gets forced to take the whole bundle

Decomposition Strategy

The fix is composition. Split along domain boundaries:

❌ business-operations-skill (monolith) ├── invoice processing ├── customer communication └── inventory management ✅ Three focused skills: ├── invoice-processing-skill ├── customer-communication-skill └── inventory-management-skill

Each skill now:

Has one clear trigger ("user asks about invoices")
Loads only its own context (fewer tokens)
Can be versioned and tested independently
Can be reused by other teams without baggage

The Governance Dimension

The AWS governance guide adds an enterprise reason for tight scope: access control. Each agent operates with a core identity that defines its scope of permissions. A monolithic skill requires broad permissions (read invoices AND send emails AND modify inventory). Focused skills enable least-privilege — the invoice skill only needs invoice-system access.

Enterprise Rule

Tool invocations must respect both the agent's capabilities and the user's access rights. Tightly scoped skills make permission boundaries enforceable. A monolithic skill with broad access becomes a privilege escalation vector.

Where to Draw the Line

Use these heuristics to decide if two capabilities belong in one skill or two:

Same data domain? — Invoice creation and invoice querying can share a skill. Invoice creation and email sending cannot.
Same failure mode? — If one capability can fail without affecting the other, they're separate skills.
Same rate of change? — If email templates change weekly but invoice logic is stable, separate them.
Same permission set? — Different access requirements = different skills.

Verify Your Understanding

A skill handles both "create Jira ticket" and "send Slack notification." Should these be one skill or two?

One skill — they're both communication actions for the same workflow
Two skills — different services, different permissions, different failure modes
One skill — splitting them would increase token usage from skill discovery
Two skills — but only because Jira uses REST and Slack uses WebSocket APIs

What is the primary security risk of a monolithic skill?

It uses more tokens, increasing cost and reducing response quality
It's harder to test, leading to undetected bugs in production systems
It requires broad permissions that violate least-privilege and enable escalation
It creates dependency conflicts between its internal unrelated components

Apply It

Look at your largest skill file. Ask yourself the four heuristic questions for each capability it contains. If any capability answers differently from the others, extract it into its own skill.

Primary Source

Read Parnas (1972), "On the Criteria to Be Used in Decomposing Systems into Modules" — the foundational paper on information hiding that underpins this entire approach.

🤖 Ask your teacher: Not sure whether to split a skill? Describe the capabilities and I'll walk through the heuristics with you.