From skills-alena
Use when a task could benefit from the skills library. Guides skill discovery, activation, composition, and effective application.
npx claudepluginhub radenadri/skills-alenaThis skill uses the workspace's default tool permissions.
Skills are not optional reading — they are mandatory workflows when their activation conditions are met.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Performs token-optimized structural code search using tree-sitter AST parsing to discover symbols, outline files, and unfold code without reading full files.
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.
IF A SKILL EXISTS FOR YOUR SITUATION, YOU MUST USE IT. NO EXCEPTIONS.
This is a meta-skill. It's always relevant. Check it before every task.
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
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?
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
| 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) |
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
Each skill's process is sequential and complete. Skipping steps means:
Using "the parts I like" from a skill is not using the skill. Follow it completely or not at all.
Iron laws exist because violations cause real damage. No rationalization justifies breaking them.
Skills are designed to work together. When multiple skills apply, use all of them in the appropriate order.
If you need to deviate from a skill (rare), document why and get approval.
Even if you've used a skill before, re-read the SKILL.md each time. Skills get updated and your memory is imperfect.
| 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 |
writing-skills for creating new skills