acp-loader

What this skill does

# Skill Activation Engine

(Plugin id `acp-loader` kept for install compatibility.)

The loader that ensures every skill gets activated. Without this, skills sit idle while Claude improvises solutions that already have purpose-built workflows.

<SUBAGENT-STOP>
If you were dispatched as a subagent to execute a specific task, skip this skill entirely.
</SUBAGENT-STOP>

<EXTREMELY-IMPORTANT>
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this.
</EXTREMELY-IMPORTANT>

## Instruction Priority

Marketplace skills override default system prompt behavior, but **user instructions always take precedence**:

1. **User's explicit instructions** (CLAUDE.md, direct requests) -- highest priority
2. **Marketplace skills** -- override default system behavior where they conflict
3. **Default system prompt** -- lowest priority

If CLAUDE.md says "don't use TDD" and a skill says "always use TDD," follow the user's instructions. The user is in control.

## How to Access Skills

Use the `Skill` tool. When you invoke a skill, its content is loaded and presented to you -- follow it directly. Never use the Read tool on skill files.

Skills are namespaced by plugin: `plugin-name:skill-name` (e.g., `ai-tooling:brainstorming`, `frontend:frontend-css`).

---

## The Rule

**Invoke relevant or requested skills BEFORE any response or action.** Even a 1% chance a skill might apply means you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to follow it.

## Decision Flow

Before responding to ANY user message, run this check:

```
1. Is the user about to BUILD something new?
   --> ai-tooling:brainstorming FIRST, then implementation skills

2. Is the user asking to FIX a bug?
   --> Investigate root cause before fixing (no blind patches)

3. Does a written plan or spec exist?
   --> ai-tooling:executing-plans to implement it

4. Is this a multi-step implementation task (3+ files)?
   --> ai-tooling:writing-plans to create a plan first

5. Is this frontend/UI work?
   --> Check: frontend:frontend-css, frontend:frontend-strategy,
       frontend:shadcn-ui, frontend:daisyui, frontend:radix-ui, agent-teams:team-design

6. Is this a code review request?
   --> Check: senior-review:code-review, senior-review:full-review

7. Is this Python work?
   --> Check: python-development skills (python-tdd, python-refactor, etc.)

8. Is this Tauri/Rust work?
   --> Check: tauri-development skills, agent-teams:team-spawn tauri

9. Is this about documentation?
   --> Check: codebase-mapper:docs-create

10. Is this about prompts or AI tooling?
    --> Check: ai-tooling:prompt-optimize

11. Could any other installed skill apply?
    --> Check the skill list in the system prompt
```

## Red Flags

These thoughts mean STOP -- you are rationalizing not using a skill:

| Thought | Reality |
|---------|---------|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "I can handle this without a skill" | If a skill exists for this, use it. |
| "This doesn't need a formal process" | Simple things become complex. Use the skill. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "The skill is overkill" | Overkill prevents underkill. Use it. |
| "I know what that means" | Knowing the concept != using the skill. Invoke it. |
| "Let me just write the code" | Did you brainstorm? Did you plan? Check first. |

## Skill Priority

When multiple skills could apply, use this order:

1. **Process skills first** (brainstorming, writing-plans) -- these determine HOW to approach the task
2. **Domain skills second** (frontend-design, frontend, python-tdd) -- these guide execution
3. **Review skills last** (code-review, full-review) -- these validate the result

Examples:
- "Build a new dashboard" --> brainstorming --> writing-plans --> frontend skills --> review
- "Fix this CSS bug" --> frontend skill directly
- "Review this code" --> code-review or full-review
- "Create a Python API" --> brainstorming --> python-tdd --> writing-plans --> executing-plans

## Workflow Awareness

These commands orchestrate multi-agent teams for complex tasks. Prefer them over invoking individual skills:

| Task | Command |
|------|---------|
| Build a new feature end-to-end | `/agent-teams:team-feature` or `/agent-teams:team-spawn fullstack` |
| Build a new UI from scratch | `/agent-teams:team-design` |
| Full codebase review (deep-dive + review) | `/senior-review:full-review` |
| Frontend redesign | `/agent-teams:team-design` |
| Mobile app from competitor analysis | `/agent-teams:team-spawn app-analysis` |
| Mobile app with Tauri build + review | `/agent-teams:team-spawn tauri` |
| Tauri desktop app review | `/agent-teams:team-spawn tauri` |
| Debug with competing hypotheses | `/agent-teams:team-debug` |
| Deep multi-source research | `/agent-teams:team-research` |
| Map an unfamiliar codebase | `/agent-teams:team-codebase-map` |

If the user's request matches a team scope, suggest the team command instead of invoking individual skills.

## Skill Types

**Rigid** (brainstorming, TDD): Follow exactly. Don't adapt away the discipline. The gates exist for a reason.

**Flexible** (frontend-design, frontend): Adapt principles to context. Use judgment.

The skill itself tells you which type it is.

## User Instructions

Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip the process. It means use the process to deliver what was asked.