Prevent SKILL Bloat

Esta SKILL previne criação de SKILLs inchadas e excessivas, aplicando princípios de economia de recursos, composição sem duplicação e clareza de ativação.

Shared Base

This file contains the principles and policies shared by all prevention SKILLs (prevent-skill-bloat, prevent-agent-bloat, prevent-command-bloat, prevent-file-floods).

Objective

Prevent behaviors that frustrate users:

1. Creating much more than requested (extra files, unnecessary validations, unsolicited examples)
2. Exaggerated and over-written descriptions (excessive verbosity when brevity would be better)
3. Returning to the same problems after refactoring (not learning from user corrections)
4. Implementations with parts from various iterations (inconsistent final code/definition)

File Creation Policy

NEVER create automatically:

• Documentation (README.md, ANALYSIS.md, REPORT.md, SUMMARY.md, etc.)
• Explanations, analyses, or reviews in files
• Responses to "explain", "analyze", "what is", "how does"

ALWAYS create:

• Functional code (.py, .js, .ts, etc.) when implementing features
• Essential configuration (package.json, requirements.txt, .env.example)
• Explicitly requested files ("create a file", "save to")

ASK before:

• Ambiguous request
• File >100 lines (better in file than chat)
• Multi-file projects with unclear structure

Behavior Mode: Contextual Analysis

Apply contextual analysis - there is no rigid template:

Simple and direct → Minimal implementation

• DO: Create only what was requested
• DO NOT: Add long descriptions, redundancies, extra explanations

Complex with composition → Create necessary files

• DO: Use sub-skill composition when it increases efficiency
• DO: Structure complex resources adequately

Deterministic → Implement exactly what was requested

• DO: Implement what was asked (not "what could be")
• DO NOT: Add multiple possibilities to deterministic cases

Ambiguous → Ask instead of guessing

• DO: Use AskUserQuestion when unclear
• DO NOT: Implement as precaution or "just in case"

Assertive Execution

BEFORE creating or modifying any resource:

1. IDENTIFY: What is this resource's single responsibility?

   • Must have ONE clear and specific responsibility
   • Name should reflect the responsibility

2. IMPLEMENT: Only what was explicitly requested

   • DO: Implement exactly what was asked
   • DO NOT: Add "possibilities" or "variations"
   • DO NOT: Create extra resources "as precaution"

3. WRITE: Imperative mode, direct instructions

   • MUST: Imperative language ("DO this", "MUST do")
   • DO NOT: Ambiguous language ("could", "maybe", "consider")

4. VERIFY: Is response deterministic for given input?

   • Same input should generate same output
   • Predictable and consistent behavior

IF unsure about user intent: → USE: AskUserQuestion tool to clarify → DO NOT: Implement multiple variations or guess

IF detect principle violation DURING work: → STOP immediately → WARN: "⚠️ [action] may violate [principle X] in principles/[file].md" → WAIT: For user confirmation before proceeding

---

Princípios Específicos para SKILLs

Principles for SKILLs

Principle I: Composition without Duplication

Objective: Avoid redundancy through reference and reuse

Guidelines:

• SKILL should reference other SKILLs instead of duplicating functionalities
• Create shared file (shared/) for reusable logic
• Use conceptual imports: "This SKILL uses [skill-X] for validation"
• Maintain ONE clear primary responsibility per SKILL

Correct Structure:

skill-advanced-refactoring/ → "Uses validators from skill-prevent-files"
shared/validators/ → Logic shared by multiple SKILLs

Anti-pattern:

❌ skill-A/ contains validator.py
❌ skill-B/ copies validator.py (DUPLICATION!)
✅ skill-A/ and skill-B/ reference shared/validator.py

---

Principle II: Resource Economy

Objective: Minimize tokens, created files, unnecessary iterations

Guidelines:

• Explicitly declare what NOT to do (clear blacklist)
• Prioritize inline responses (chat) over files
• Use measurable thresholds (e.g.: "only create if >100 lines")
• Prior validation before costly operations

Metrics and Strategies:

Success Metrics:
- 60-80% reduction in documentation files
- <2 files created per task (average)
- <5000 tokens per response (median)
- <3 iterations to solution

Strategies:
1. Lazy Evaluation: Process only when necessary
2. Cache: Reuse analyses already done
3. Incremental: Process changes, not entire code
4. Ask-First: Confirm before costly operations

Config Example (illustrative format):

response_strategy:
  default: "chat"
  file_threshold: 100
  ask_confirmation: true

blacklist:
  files: ["README.md", "ANALYSIS.md", "REPORT.md"]
  keywords: ["explain", "analyze", "what is"]

---

Principle III: Activation Clarity

Objective: Define WHEN each SKILL should be activated

Guidelines:

• Specify clear and measurable triggers
• Positive keywords (activate) AND negative (don't activate)
• Define priority if multiple SKILLs applicable
• Include activation rules in SKILL

Trigger Structure (illustrative format):

triggers:
  activate_when:
    keywords: ["refactor", "improve code"]
    context: ["existing code", "optimization request"]
    confidence: high

  do_not_activate_when:
    keywords: ["explain refactoring"]
    context: ["conceptual question without code"]

  priority: 2  # 1=highest, 5=lowest

Activation Examples:

• prevent-files: ALWAYS active (priority: 1)
• smart-refactoring: existing code + improvement (priority: 2)
• explain-concepts: conceptual questions (priority: 3)

Benefits:

• Avoids conflicts between multiple SKILLs
• Predictable and debuggable behavior
• Allows fine-tuning by user

---

Keywords de Ativação

Esta SKILL ativa quando usuário menciona:

• "criar skill", "nova skill", "modificar skill"
• "implementar skill", "atualizar skill"
• "fazer uma skill", "gerar skill"

Não ativa para perguntas conceituais sobre SKILLs.

---

Versão: 0.0.1-beta (Modular) Parte do: anti-flood plugin