Beyond basic skill file structure, there are advanced patterns that make skills dramatically more effective. This skill covers conditional instruction blocks, multi-mode skills that adapt to context, progressive disclosure patterns, skill chaining, self-validating instructions, and meta-skill patterns that generate other skills.

## Key Points

1. Install PostgreSQL:
2. Create the database:
- [ ] Node.js 20+ installed (verify: `node --version`)
- [ ] Git repository initialized (verify: `git status`)
- [ ] No existing CI configuration (verify: no `.github/workflows/`)
- [x] CI pipeline configured in `.github/workflows/ci.yml`
- [x] Tests running on push to main and pull requests
- [x] Build artifact uploaded on success
- [x] Status badge available at `[URL]`
1. Capture the error output
2. Check the [Troubleshooting Skill Name] skill
3. Verify your [technology] version matches the prerequisite

Advanced Skill Patterns

Purpose

Beyond basic skill file structure, there are advanced patterns that make skills dramatically more effective. This skill covers conditional instruction blocks, multi-mode skills that adapt to context, progressive disclosure patterns, skill chaining, self-validating instructions, and meta-skill patterns that generate other skills.

Pattern 1: Context-Adaptive Skills

Adapting to the User's Situation

A single skill file can serve different contexts by using clear conditional blocks:

Context-Adaptive Pattern:

## Implementation

### Determine Your Context

Before proceeding, identify your situation:

**Context A: New Project (no existing code)**
  → Follow Section "Starting Fresh" below

**Context B: Existing Project (adding this feature)**
  → Follow Section "Adding to Existing Project" below

**Context C: Migrating (replacing old approach)**
  → Follow Section "Migration Path" below

### Starting Fresh

[Complete setup from scratch, including project creation]

### Adding to Existing Project

[Assumes project exists, focuses on integration]
Prerequisites: Working [framework] project with [feature] configured

### Migration Path

[Assumes old approach exists, focuses on replacement]
Prerequisites: Current implementation using [old approach]

Benefits:
├── Single skill covers three common entry points
├── User self-selects the relevant section
├── Agent can determine context from project state
├── No need for three separate skills
└── Shared concepts only written once

Runtime Detection

For AI agents, provide detection criteria:

## Detect Your Context

Check these to determine which instructions to follow:

If `package.json` exists and contains "react":
  → This is an existing React project → Skip setup, go to Integration

If `package.json` does not exist:
  → New project → Go to Setup

If `package.json` contains "[old-library]":
  → Migration needed → Go to Migration

If `tsconfig.json` exists:
  → TypeScript project → Use TypeScript examples throughout

If no `tsconfig.json`:
  → JavaScript project → Use JavaScript examples throughout

This explicit detection logic helps AI agents make correct decisions
based on observable project state, not guessing.

Pattern 2: Progressive Disclosure

Layered Depth

Progressive Disclosure Pattern:
Start simple, reveal complexity only when needed.

## Quick Start (30 seconds)

```bash
npx create-my-app my-project
cd my-project
npm run dev

That's it. Your app is running at http://localhost:3000.

Basic Configuration (5 minutes)

The default configuration works for most cases. Customize these common options in config.ts:

export const config = {
  port: 3000,          // Change if port is in use
  database: 'sqlite',  // Change to 'postgres' for production
};

Full Configuration Reference (as needed)

For complete control, see all available options:

[Detailed table of every configuration option] [Only consult this when the basics aren't enough]

Advanced Customization (specialized needs)

For extending beyond built-in options:

[Plugin system, custom middleware, hooks] [Only relevant for 10% of users]

Benefits: ├── Most users get what they need in Quick Start ├── Some users go deeper into Basic Configuration ├── Few users need Full Reference ├── Almost nobody needs Advanced Customization ├── But those who do can find it └── No one is forced to read content they don't need

## Pattern 3: Self-Validating Instructions

### Built-In Verification

Self-Validating Pattern: After each instruction, include how to verify it worked.

Setup Database

1. Install PostgreSQL:

   brew install postgresql@16
   brew services start postgresql@16
   

   Verify:

   psql --version
   # Expected: psql (PostgreSQL) 16.x
   pg_isready
   # Expected: accepting connections
   

   If pg_isready returns "no response": The service didn't start. Run brew services restart postgresql@16 and check again.

2. Create the database:

   createdb myapp_development
   

   Verify:

   psql -d myapp_development -c "SELECT 1 AS connected;"
   # Expected:
   #  connected
   # -----------
   #          1
   # (1 row)
   

   If "database does not exist": The createdb command failed silently. Check PostgreSQL logs: cat /opt/homebrew/var/log/postgresql@16.log

Pattern Rules: ├── Every significant step has a Verify block ├── Verify uses a specific command with expected output ├── Include the failure case (what if verification fails?) ├── Agent can execute verification to confirm progress └── Prevents cascading errors (catch issues at each step)

## Pattern 4: Skill Chaining Protocol

### Explicit Handoff Between Skills

Skill Chaining Pattern: Define clear entry/exit points for multi-skill workflows.

Entry Point

This skill expects:

• Node.js 20+ installed (verify: node --version)
• Git repository initialized (verify: git status)
• No existing CI configuration (verify: no .github/workflows/)

If any checkbox fails, resolve before proceeding.

[Main content of the skill...]

Exit Point

After completing this skill, you have:

• CI pipeline configured in .github/workflows/ci.yml
• Tests running on push to main and pull requests
• Build artifact uploaded on success
• Status badge available at [URL]

Recommended Next Skills

Based on what you just set up:

If deploying to production: → Apply "Continuous Deployment Pipeline" skill Entry point: Has CI pipeline (which you now have)

If adding code quality checks: → Apply "Code Quality Automation" skill Entry point: Has CI pipeline (which you now have)

If adding security scanning: → Apply "Security Scanning in CI" skill Entry point: Has CI pipeline (which you now have)

Benefits: ├── Clear contract: what the skill needs, what it produces ├── Agent can verify entry conditions before starting ├── Agent knows what to do next (downstream skills) ├── Skills chain together without gaps or overlap └── Each skill is still independently valuable

## Pattern 5: Escape Hatches

### Handling the Unexpected

Escape Hatch Pattern: Provide guidance for when things go off the happy path.

Standard Approach

[Normal instructions for 80% of cases]

If You Hit [Specific Problem]

This sometimes happens when [circumstance]. Instead of the standard approach, use this alternative:

[Alternative approach that handles the edge case]

If Your Environment Differs

The instructions above assume [standard environment]. If your setup differs:

Your Situation	Adjustment
Using Windows instead of macOS/Linux	Replace brew with choco, paths use \
Using Docker instead of local install	Skip install, use docker compose up instead
Behind a corporate proxy	Set HTTP_PROXY env var first
Using a monorepo	Run commands from the package subdirectory

If Nothing Works

If you've followed the instructions and the result isn't what's expected:

1. Capture the error output
2. Check the [Troubleshooting Skill Name] skill
3. Verify your [technology] version matches the prerequisite
4. Check if [common environmental issue] applies

Benefits: ├── Acknowledges that real-world environments vary ├── Provides specific alternatives, not just "try something else" ├── Prevents users from getting stuck with no recourse └── Agent can select the appropriate escape hatch based on context

## Pattern 6: Parameterized Skills

### Skills That Accept Variables

Parameterized Pattern: Use placeholders that the user/agent fills in.

Configuration

Replace these placeholders with your values:

Placeholder	Your Value	Example
{PROJECT_NAME}	Your project name	my-web-app
{DATABASE_URL}	Your database connection	postgresql://user:pass@localhost/db
{DEPLOY_REGION}	Target deployment region	us-east-1
{DOMAIN_NAME}	Your domain	app.example.com

Setup

# Create project
mkdir {PROJECT_NAME}
cd {PROJECT_NAME}
npm init -y

# Configure environment
echo "DATABASE_URL={DATABASE_URL}" > .env
echo "REGION={DEPLOY_REGION}" >> .env

Deploy

# Deploy to {DEPLOY_REGION}
deploy --app {PROJECT_NAME} \
       --region {DEPLOY_REGION} \
       --domain {DOMAIN_NAME}

Benefits: ├── One skill covers many specific instances ├── Parameters are clearly identified (not buried in prose) ├── Agent can substitute values from project context ├── Reduces skill count (one parameterized > many specific) └── Table at top serves as a configuration checklist

## Pattern 7: Opinionated With Justification

Opinionated Pattern: Make a clear recommendation but explain why, so the reader can disagree with information.

Recommendation: Use [Option A]

We recommend Option A for most projects because:

1. [Concrete advantage with evidence]
2. [Concrete advantage with evidence]
3. [Concrete advantage with evidence]

When to Choose Option B Instead

Option B is better when:

• [Specific condition that favors B]
• [Specific condition that favors B]

When to Choose Option C Instead

Option C is better when:

• [Specific condition that favors C]

Why NOT Option D

We specifically recommend against D because:

• [Concrete problem with evidence]
• [Concrete problem with evidence]

Benefits: ├── Reader/agent gets a clear default ("just use A") ├── Reasons are provided (not arbitrary preference) ├── Alternatives are acknowledged (not dogmatic) ├── Conditions for exceptions are clear ├── Anti-recommendations prevent known bad choices └── Agent can follow the recommendation or select an alternative based on project-specific conditions

## Pattern 8: Meta-Skill (Skill Generator)

Meta-Skill Pattern: A skill that generates other skills.

Generate a [Domain] Skill

Follow these steps to create a new skill file for [domain]:

1. Identify the topic:

   • What specific task or concept does this skill cover?
   • Who is the audience?
   • What should they be able to do after reading?

2. Choose the archetype: [Reference to Skill File Templates skill]

3. Write the frontmatter:

   ---
   title: "[Technology]: [Specific Aspect]"
   category: "[domain-skills]"
   tags: ["[technology]", "[aspect]", "[use-case]"]
   version: "1.0.0"
   ---
   

4. Fill in each section:

   • Purpose: 2-4 sentences, task-oriented
   • Core content: 200-400 lines, actionable
   • Examples: At least 2 code examples
   • Pitfalls: At least 3 common mistakes
   • When to Apply: Specific scenarios

5. Validate against the Quality Checklist skill

6. Test with an AI agent (give only the skill, give a task)

This meta-skill is useful for: ├── Training new skill authors ├── Ensuring consistency across a team ├── Automating skill generation pipelines └── Quality-controlled skill production

## When to Apply This Skill

Use this skill when:
- Standard skill structure isn't sufficient for your use case
- Building skills that need to adapt to different contexts
- Creating multi-skill workflows that chain together
- Writing skills for diverse environments (Windows/Mac/Linux)
- Designing skill packs with consistent patterns
- Building tools or pipelines that generate skills