Eager vs Lazy Loading: Control When Your AI Skills Activate

Example: The Coding Standards Problem

You install a skill with your team's TypeScript conventions. The AI starts writing code. It uses any types because it doesn't know your standards forbid them. You catch it in code review. Three files later, same problem.

Why? The skill was available but not active. The AI didn't realize it needed to load your standards before generating code.

That's what eager loading fixes.

Eager Skills: Always Active

When you install a skill with --eager, it's loaded at the start of every session. The AI doesn't need to think "should I load this?"—it's already there.

# Install coding standards that must always apply
prpm install @myteam/typescript-standards --eager

# Install security rules that can't be forgotten
prpm install @myteam/api-security-rules --eager

These skills appear in a special priority="0" section in your manifest file:

<skills_system priority="0">
<usage>
MANDATORY: You MUST load and apply these skills at the START of every session.
Do not wait for relevance - these are always active.
</usage>

<eager_skills>
<skill activation="eager">
  <name>typescript-standards</name>
  <description>Team TypeScript coding conventions</description>
  <path>.openskills/typescript-standards/SKILL.md</path>
</skill>
</eager_skills>
</skills_system>

Lazy Skills: On-Demand Only

Most skills should be lazy. They're available when needed but don't clutter your context window until the AI determines they're relevant.

# Install a specialized skill for occasional use
prpm install @prpm/aws-cdk-expert

# Or explicitly mark as lazy (default behavior)
prpm install @prpm/debugging-helper --lazy

Lazy skills appear in a priority="1" section and are only loaded when the AI determines they match the current task:

<skills_system priority="1">
<usage>
When users ask you to perform tasks, check if any of the available skills
below can help complete the task more effectively.

How to use skills:
- Invoke: Bash("cat <path>")
- The skill content will load into your current context
</usage>

<available_skills>
<skill activation="lazy">
  <name>aws-cdk-expert</name>
  <description>AWS CDK infrastructure patterns and best practices</description>
  <path>.openskills/aws-cdk-expert/SKILL.md</path>
</skill>
</available_skills>
</skills_system>

File-Level Control in Collections

For multi-file packages, you can mark specific files as eager:

{
  "name": "@myteam/fullstack-standards",
  "version": "1.0.0",
  "description": "Team standards collection",
  "format": "claude",
  "subtype": "skill",
  "files": [
    {
      "path": ".claude/skills/typescript-conventions.md",
      "format": "claude",
      "subtype": "skill",
      "eager": true
    },
    {
      "path": ".claude/skills/react-best-practices.md",
      "format": "claude",
      "subtype": "skill",
      "eager": true
    },
    {
      "path": ".claude/skills/debugging-helpers.md",
      "format": "claude",
      "subtype": "skill"
    }
  ]
}

In this example, TypeScript conventions and React best practices load eagerly, while debugging helpers wait until needed.

Examples

# Package says "eager", but you want lazy
prpm install @myteam/standards --lazy

# Package says "lazy", but you need it always active
prpm install @vendor/helper --eager

# Trust the package author's judgment
prpm install @myteam/standards  # uses package default

Users always have final control, but package authors can express their intent about how their packages should be used.

Use Eager For:

• Coding standards - TypeScript conventions, naming patterns, file organization
• Security rules - Authentication patterns, input validation, secret handling
• Architectural patterns - API design, database schemas, service boundaries
• Testing requirements - Coverage minimums, test structure, mocking strategies
• Code review checklists - What every PR must include

These can't be forgotten. They apply to every file, every function, every session.

Use Lazy For:

• Framework expertise - Next.js patterns, React hooks, Vue composition API
• Domain knowledge - Payment processing, real-time messaging, ML pipelines
• Migration tools - Version upgrades, API changes, deprecation handling
• Debugging helpers - Performance profiling, error diagnosis, log analysis
• Specialized utilities - Data transformations, config generators, boilerplate creation

These are powerful when needed but would waste context window space if always loaded.

1. Always-On Standards Packages

Companies can now publish internal standards as eager packages. Install once, and every developer's AI assistant follows the same rules—no more "I forgot to check the style guide."

# Published by your platform team
@acme/typescript-standards (eager: true)
@acme/api-design-patterns (eager: true)
@acme/security-checklist (eager: true)

# Every new project
prpm install @acme/typescript-standards
prpm install @acme/api-design-patterns
prpm install @acme/security-checklist

# Now every AI session enforces your standards

2. Efficient Context Management

You can install dozens of specialized skills without bloating your context window. Only the mandatory ones load eagerly—the rest activate when relevant.

# 3 eager skills (always loaded)
@myteam/code-standards
@myteam/security-rules
@myteam/testing-requirements

# 15 lazy skills (on-demand)
@prpm/nextjs-expert
@prpm/react-performance
@prpm/postgres-migrations
@prpm/stripe-integration
# ... etc

# Total skills: 18
# Context usage at session start: 3 skills
# Context efficiency: 83% saved

3. Trust Package Authors

Package authors know whether their package should be eager or lazy. Framework maintainers can publish migration packages that are lazy by default. Security teams can publish audit checklists that must be eager.

Users get smart defaults and can override when needed.