Using Skills

Using Skills

Overview

Skills are not optional reading — they are mandatory workflows when their activation conditions are met.

Core principle: If a skill exists for your situation, you MUST use it. Not using it is a process violation.

The Iron Law

IF A SKILL EXISTS FOR YOUR SITUATION, YOU MUST USE IT. NO EXCEPTIONS.

When to Use

• Before starting any task (check if a skill applies)
• When composing multiple skills for complex work
• When unsure which skill applies

When NOT to Use

This is a meta-skill. It's always relevant. Check it before every task.

Anti-Shortcut Rules

YOU CANNOT:
- Skip checking for applicable skills — check before EVERY task
- Cherry-pick parts of a skill — follow it completely or not at all
- Say "I know the gist" and skip reading SKILL.md — read it fully every time
- Override Iron Laws with rationalizations — Iron Laws are absolute
- Skip a skill because "this task is simple" — simple tasks have applicable skills too
- Use a skill partially and claim you followed it — partial compliance ≠ compliance
- Deviate from a skill without documenting why and getting approval

How Skills Work

Automatic Activation

Skills activate when their description field matches the current situation:

# In each SKILL.md:
description: "Use when debugging any technical issue..."

Before every task, check: Does a skill exist for this?

Skill Composition

Skills compose naturally. A typical feature implementation activates:

brainstorming          → Understand requirements
    ↓
writing-plans          → Create implementation plan
    ↓
executing-plans        → Execute task by task
    ├── test-driven-development  → Per-task TDD cycle
    ├── verification-before-completion → After each task
    └── git-workflow             → Atomic commits
    ↓
code-review            → Review all changes
    ↓
verification-before-completion → Final verification

Common Compositions

| Scenario | Skill Chain | |----------|------------| | New feature | brainstorming → writing-plans → executing-plans | | Bug fix | systematic-debugging → test-driven-development → verification-before-completion | | Full audit | codebase-mapping → architecture-audit + security-audit + performance-audit + database-audit | | Refactoring | codebase-mapping → architecture-audit → refactoring-safely | | Production incident | incident-response → systematic-debugging → test-driven-development | | New API endpoint | brainstorming → api-design-audit → writing-plans → executing-plans | | Frontend feature | brainstorming → frontend-audit → writing-plans → executing-plans | | Deep quality check | product-completeness-audit → brutal-exhaustive-audit | | API integration | full-stack-api-integration → verification-before-completion | | Documentation | writing-documentation → code-review | | Multi-role task | agent-team-coordination → (skills per role) |

Skill Discovery

When starting a task:

1. READ the task description
2. IDENTIFY keywords that match skill descriptions
3. CHECK the entry point file activation table
4. IF match found → READ the SKILL.md before proceeding
5. IF multiple matches → compose them in logical order
6. IF no match → Proceed with general principles from core-principles.md

Rules for Skill Usage

Don't Skip Steps

Each skill's process is sequential and complete. Skipping steps means:

• You'll miss something
• You'll produce worse results
• You'll violate the iron law

Don't Cherry-Pick

Using "the parts I like" from a skill is not using the skill. Follow it completely or not at all.

Don't Override Iron Laws

Iron laws exist because violations cause real damage. No rationalization justifies breaking them.

Do Compose Skills

Skills are designed to work together. When multiple skills apply, use all of them in the appropriate order.

Do Report Deviations

If you need to deviate from a skill (rare), document why and get approval.

Do Re-Read Skills

Even if you've used a skill before, re-read the SKILL.md each time. Skills get updated and your memory is imperfect.

Quick Reference

| Need | Skill | |------|-------| | "I need to build something" | brainstorming → writing-plans → executing-plans | | "Something is broken" | systematic-debugging | | "Review this code" | code-review | | "Is this done?" | verification-before-completion | | "Audit the system" | codebase-mapping → [appropriate audit skills] | | "Improve existing code" | refactoring-safely | | "Production is down" | incident-response | | "Write tests" | test-driven-development | | "Document this" | writing-documentation | | "Check security" | security-audit | | "Why is it slow?" | performance-audit | | "Check the database" | database-audit | | "Check the frontend" | frontend-audit | | "Design an API" | api-design-audit | | "Check dependencies" | dependency-audit | | "Check logging/monitoring" | observability-audit | | "Check accessibility" | accessibility-audit | | "Check CI/CD" | ci-cd-audit | | "Git help" | git-workflow | | "Check completeness" | product-completeness-audit | | "Deep exhaustive audit" | brutal-exhaustive-audit | | "Integrate an API" | full-stack-api-integration | | "Multi-agent task" | agent-team-coordination | | "Cross-session context" | persistent-memory | | "Create a new skill" | writing-skills |

Integration

• This is a meta-skill: used to discover and apply other skills
• Pairs with writing-skills for creating new skills
• References all other skills in the library

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: boparaiamrit
• Source: boparaiamrit/skills-by-amrit
• License: MIT

Install and usage instructions live in the source repository linked above.