sinapse-ai 1.0.0

package/squad-claude/tasks/claude-code-project-setup.md

@@ -0,0 +1,97 @@
+---
+task: claude-code-project-setup
+responsavel: "@config-engineer"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Validar inputs"
+  - "[ ] Executar steps"
+  - "[ ] Verificar qualidade"
+  - "[ ] Gerar output"
+---
+
+# Claude Code Project Setup
+
+## Objective
+
+Create an optimal Claude Code project configuration from scratch, establishing the CLAUDE.md hierarchy, rules system, settings, hooks, and MCP integrations that maximize Claude Code's effectiveness for the specific project type and team workflow.
+
+## Pre-Conditions
+
+- Project repository exists (or will be created)
+- Project type identified (web app, API, library, monorepo, etc.)
+- Team size and workflow preferences documented
+- Technology stack defined
+- Development methodology chosen (agile, kanban, etc.)
+
+## Steps
+
+1. **Assess Project Requirements** — Analyze the project to determine Claude Code configuration needs: project type (affects rules and conventions), tech stack (affects code patterns and linting), team size (affects permission model), workflow (affects hooks and automation), and complexity (affects context engineering strategy).
+2. **Create CLAUDE.md Hierarchy** — Design the CLAUDE.md file structure: root CLAUDE.md with project-wide rules and conventions, directory-level CLAUDE.md files for component-specific instructions (e.g., src/api/CLAUDE.md for API conventions, src/ui/CLAUDE.md for frontend patterns). Keep root CLAUDE.md under 3000 tokens.
+3. **Configure .claude/settings.json** — Set up project settings: allowed and denied tool patterns, permission boundaries (which directories Claude can modify), MCP server configurations, and custom settings. Balance security with productivity.
+4. **Design Rules System** — Create .claude/rules/ files for contextual instructions: always-loaded rules for universal conventions, path-conditional rules for file-type-specific guidance. Use `paths:` frontmatter to control when each rule loads.
+5. **Set Up Hooks** — Configure automation hooks based on project needs: PreToolUse hooks for safety gates (block writes to protected files), PostToolUse hooks for automation (auto-format after file writes, auto-lint after code changes), and Notification hooks for team alerts.
+6. **Configure MCP Integrations** — Set up MCP servers relevant to the project: Supabase for database projects, Figma for design-heavy projects, GitHub for all projects, Notion for documented projects. Configure each with proper auth and permissions.
+7. **Create .env.example** — Document all environment variables the project uses with Claude Code: API keys for MCP servers, project-specific configuration, and debug flags. Include descriptions and example values (never real credentials).
+8. **Set Up Git Integration** — Configure git-related settings: commit message conventions, branch naming patterns, PR templates, and any git hooks that complement Claude Code hooks. Ensure .claude/ directory is properly gitignored or committed as appropriate.
+9. **Build Onboarding Document** — Create a quick-start guide for team members: how to install Claude Code, how to configure their environment, what the project's Claude Code setup does, and how to use the custom rules and hooks effectively.
+10. **Validate the Setup** — Test the complete configuration: create a new Claude Code session, verify CLAUDE.md loads correctly, trigger each hook, test MCP connections, verify rules load for the correct files, and check that permissions work as expected.
+11. **Create Maintenance Checklist** — Document ongoing maintenance tasks: when to update CLAUDE.md (after architectural changes), when to review rules (quarterly), when to audit hooks (after workflow changes), and when to update MCP configurations (after service changes).
+
+## Output
+
+```markdown
+# Claude Code Project Setup Report
+
+## Configuration Summary
+| Component | Status | Files |
+|-----------|--------|-------|
+| CLAUDE.md hierarchy | {configured} | {file list} |
+| Settings | {configured} | .claude/settings.json |
+| Rules | {count} rules | .claude/rules/*.md |
+| Hooks | {count} hooks | {hook locations} |
+| MCP servers | {count} servers | {server list} |
+
+## File Tree
+```
+.claude/
+├── settings.json
+├── rules/
+│   ├── {rule files}
+CLAUDE.md
+src/
+├── api/CLAUDE.md
+├── ui/CLAUDE.md
+```
+
+## Environment Variables
+| Variable | Purpose | Required |
+|----------|---------|----------|
+
+## Onboarding Steps
+1. {step}
+2. {step}
+
+## Maintenance Schedule
+| Task | Frequency | Trigger |
+|------|-----------|---------|
+```
+
+## Quality Criteria
+
+- Root CLAUDE.md must be under 3000 tokens and contain only project-wide essentials
+- All rules must have appropriate `paths:` frontmatter (no unnecessary always-load rules)
+- Settings must follow least-privilege principle (deny by default, allow explicitly)
+- Hooks must complete within performance budgets (PreToolUse < 500ms)
+- MCP servers must connect successfully in validation testing
+- Onboarding document must enable a new developer to set up in under 15 minutes

package/squad-claude/tasks/claude-md-engineer.md

@@ -0,0 +1,58 @@
+---
+task: claude-md-engineer
+responsavel: "@config-engineer"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Validar inputs"
+  - "[ ] Executar steps"
+  - "[ ] Verificar qualidade"
+  - "[ ] Gerar output"
+---
+
+# CLAUDE.md Engineer
+
+## Objective
+
+Design and write CLAUDE.md files that effectively shape Claude Code behavior for a project. Craft instructions with high information density, proper structure, and optimal token budget that make Claude Code a productive team member.
+
+## Inputs
+
+- Project description and goals
+- Technology stack and conventions
+- Team coding standards
+- Known pitfalls or anti-patterns to avoid
+- Existing CLAUDE.md (if updating)
+- Token budget target (small < 2K tokens, medium < 5K, large < 10K)
+
+## Steps
+
+1. **Audit Existing CLAUDE.md** — If updating, measure current token count, identify low-value sections, and flag contradictions with .claude/rules/.
+2. **Structure Sections** — Organize into high-value sections: Project Overview (brief), Tech Stack, Code Standards, File Structure, Common Commands, Testing, Known Issues. Omit anything better suited for rules/.
+3. **Write with Information Density** — Every sentence must earn its tokens. Use tables over paragraphs. Use bullet points over prose. Use code examples only when essential. Avoid restating what Claude Code already knows (e.g., don't explain how to use git).
+4. **Define Behavioral Constraints** — Explicitly state what Claude Code should NOT do (anti-patterns, forbidden approaches). These are high-value instructions.
+5. **Add Project-Specific Knowledge** — Include information Claude Code cannot infer: internal API conventions, non-obvious file relationships, deployment quirks, environment-specific gotchas.
+6. **Set Persona (Optional)** — If the project benefits from a specific interaction style, define it briefly at the top of CLAUDE.md.
+7. **Measure Token Budget** — Estimate token count of the final CLAUDE.md. Trim if over budget. Every section must justify its token cost.
+
+## Quality Gates
+
+- CLAUDE.md must be within token budget
+- No section should duplicate information available in .claude/rules/
+- Anti-patterns section must be present
+- File must be valid Markdown
+- Information density score >= 3/5 for every section
+
+## Output Format
+
+Complete CLAUDE.md file with section comments indicating token cost estimates.

package/squad-claude/tasks/configure-settings.md

@@ -0,0 +1,58 @@
+---
+task: configure-settings
+responsavel: "@config-engineer"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Validar inputs"
+  - "[ ] Executar steps"
+  - "[ ] Verificar qualidade"
+  - "[ ] Gerar output"
+---
+
+# Configure Settings
+
+## Objective
+
+Create or update the .claude/settings.json file for a project with properly configured permissions, MCP server entries, behavioral flags, and tool access controls tailored to the project's security and workflow requirements.
+
+## Inputs
+
+- Project technology stack
+- Security requirements (strict / standard / permissive)
+- Tools that should be auto-approved
+- Tools or commands that should be blocked
+- MCP servers to include
+- Team size (affects managed policy needs)
+
+## Steps
+
+1. **Assess Current Settings** — Read existing .claude/settings.json if present. Note current permissions, MCP configs, and any custom flags. If absent, start from blank template.
+2. **Design Permission Model** — Based on security requirements, define the three permission lists: allow (tools permitted with prompt), deny (tools blocked entirely), auto-approve (tools permitted without prompt).
+3. **Configure Tool Permissions** — Set permissions for core tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, WebSearch, MCP tools. Apply principle of least privilege.
+4. **Add MCP Server Entries** — For each required MCP server, add the configuration with correct transport type (stdio/sse), command, args, and environment variables.
+5. **Set Behavioral Flags** — Configure model preferences, context limits, and any project-specific behavioral overrides.
+6. **Validate Schema** — Ensure the settings.json conforms to Claude Code's expected schema. Check for typos, invalid keys, and conflicting permissions.
+7. **Create settings.local.json Template** — Generate a template for developer-specific overrides that should not be committed to version control.
+
+## Quality Gates
+
+- No tool appears in both allow and deny lists
+- All MCP server entries have valid transport configurations
+- Permission model matches stated security requirements
+- settings.json passes schema validation
+- Sensitive values (API keys, tokens) are in environment variables, not hardcoded
+
+## Output Format
+
+Complete .claude/settings.json file plus documentation of each configuration choice and a settings.local.json template.

package/squad-claude/tasks/content-curation-pipeline.md

@@ -0,0 +1,100 @@
+---
+task: content-curation-pipeline
+responsavel: "@project-integrator"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Validar inputs"
+  - "[ ] Executar steps"
+  - "[ ] Verificar qualidade"
+  - "[ ] Gerar output"
+---
+
+# Content Curation Pipeline
+
+## Objective
+
+Build a content curation pipeline that systematically discovers, evaluates, transforms, and organizes knowledge from various sources into the project's knowledge base. Create a repeatable process for turning raw information into high-quality, AI-optimized knowledge entries.
+
+## Pre-Conditions
+
+- Knowledge base architecture established (from knowledge-base-architecture task)
+- Content sources identified (documentation, APIs, research, team expertise)
+- Quality criteria for KB entries defined
+- Token efficiency targets established
+- Curation schedule and ownership determined
+
+## Steps
+
+1. **Define Source Inventory** — Catalog all potential content sources: official documentation (framework docs, API references), internal documentation (READMEs, wikis, ADRs), community knowledge (blog posts, Stack Overflow, GitHub issues), and team expertise (interviews, pair sessions, code reviews).
+2. **Create Discovery Process** — Design how new content is discovered: scheduled scans of documentation changes (version updates, new features), monitoring of team questions (repeated questions indicate KB gaps), tracking of error patterns (common mistakes need KB entries), and watching technology announcements.
+3. **Build Evaluation Rubric** — Create a rubric for evaluating candidate content: relevance (directly applicable to project?), accuracy (verified and current?), uniqueness (not already in KB?), stability (will this remain true for > 3 months?), and token value (information density high enough?). Score 1-5 on each dimension.
+4. **Design Transformation Pipeline** — Define how raw content becomes a KB entry: extract key information (remove fluff, examples, explanations of basics), restructure for AI consumption (tables, bullet points, code blocks), add project-specific context (how this applies to our codebase), and compress to target token count.
+5. **Implement Quality Review** — Create a review process for new KB entries: technical accuracy check (is the information correct?), format compliance check (follows template?), token efficiency check (within budget?), integration check (fits the taxonomy?), and uniqueness check (no duplication?).
+6. **Create Versioning Strategy** — Design how KB entries are versioned: semantic versioning for major rewrites vs. minor updates, changelog per entry, date stamping for freshness tracking, and deprecation marking for outdated entries that are pending removal.
+7. **Build Freshness Monitoring** — Implement staleness detection: track source update dates, flag entries when their source is updated, schedule periodic review cycles per content category, and auto-generate freshness reports with entries needing attention.
+8. **Design Deduplication Process** — Create a process for detecting and resolving duplicate content: scan for overlapping topics across KB files, merge related entries, maintain a single source of truth per topic, and create references instead of copies.
+9. **Implement Metrics Tracking** — Track curation pipeline health: entries added per month, entries updated per month, entries deprecated, average entry quality score, total token footprint trend, and gap analysis (topics without coverage).
+10. **Create Automation Hooks** — Set up automation where possible: PostToolUse hooks that detect when documentation files are updated and flag corresponding KB entries for review, scheduled reminders for periodic content reviews, and automated freshness reports.
+
+## Output
+
+```markdown
+# Content Curation Pipeline
+
+## Source Registry
+| Source | Type | Update Frequency | Priority |
+|--------|------|-----------------|----------|
+
+## Discovery Schedule
+| Activity | Frequency | Trigger | Owner |
+|----------|-----------|---------|-------|
+
+## Evaluation Rubric
+| Dimension | Weight | 1 (Poor) | 3 (Adequate) | 5 (Excellent) |
+|-----------|--------|----------|--------------|---------------|
+
+## Transformation Steps
+1. Extract → {method}
+2. Restructure → {format}
+3. Contextualize → {how}
+4. Compress → {target tokens}
+
+## Review Checklist
+- [ ] Technical accuracy verified
+- [ ] Format follows template
+- [ ] Token count within budget
+- [ ] Taxonomy placement correct
+- [ ] No duplicate content
+
+## Pipeline Metrics
+| Metric | Target | Measurement |
+|--------|--------|-------------|
+| Entries added/month | {target} | {how} |
+| Freshness (< 90 days) | > 80% | {how} |
+| Quality score average | > 4.0 | {how} |
+| Token efficiency | > 70% | {how} |
+
+## Automation
+| Hook/Script | Trigger | Action |
+|------------|---------|--------|
+```
+
+## Quality Criteria
+
+- Pipeline must process at least 5 content sources per evaluation cycle
+- Every entry must pass the evaluation rubric with a score of 3.5+ average
+- Transformation must reduce source content by at least 50% in token count
+- Deduplication must identify and resolve overlapping entries within 1 review cycle
+- Freshness monitoring must flag stale entries within 7 days of source update
+- Pipeline metrics must be tracked and reported monthly

package/squad-claude/tasks/context-rot-audit.md

@@ -0,0 +1,83 @@
+---
+task: context-rot-audit
+responsavel: "@skill-craftsman"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Validar inputs"
+  - "[ ] Executar steps"
+  - "[ ] Verificar qualidade"
+  - "[ ] Gerar output"
+---
+
+# Context Rot Audit
+
+## Objective
+
+Detect and catalog all instances of context rot in a Claude Code project's configuration files. Context rot is stale, redundant, contradictory, or bloated information that wastes context tokens and can mislead Claude Code.
+
+## Inputs
+
+- All CLAUDE.md files
+- All .claude/rules/ files
+- Knowledge base files
+- Current project state (actual files, commands, dependencies)
+- Git history of config files (to detect age of content)
+
+## Steps
+
+1. **Scan for Staleness** — Check every reference in config files against current project state: Do referenced files still exist? Are listed commands still valid? Are mentioned dependencies still installed? Are API endpoints still active?
+2. **Detect Redundancy** — Find duplicate information: same instruction in multiple files, overlapping rules with identical advice, knowledge base content repeated in CLAUDE.md.
+3. **Find Contradictions** — Identify conflicting instructions: one file says "use semicolons" while another says "no semicolons," rules that contradict CLAUDE.md directives, permission settings that conflict with stated policies.
+4. **Measure Bloat** — Identify sections that contain information Claude Code already knows: generic programming advice, well-known framework conventions, obvious coding standards. These waste tokens without adding value.
+5. **Check Path References** — Verify all file paths mentioned in `paths:` frontmatter, CLAUDE.md examples, and rules actually match existing project files.
+6. **Assess Decay Rate** — Using git history, determine how quickly config files become stale. Flag files not updated in > 30 days if the project is actively developed.
+7. **Generate Rot Report** — Catalog all findings by category (stale, redundant, contradictory, bloated) with specific locations and recommended fixes.
+
+## Quality Gates
+
+- Every file in the config surface must be scanned
+- Findings must include specific line references
+- Each finding must have a recommended action (remove, update, merge, or rewrite)
+- Contradiction findings must list both conflicting sources
+
+## Output Format
+
+```markdown
+# Context Rot Audit
+
+## Summary
+- Stale items: {count}
+- Redundant items: {count}
+- Contradictions: {count}
+- Bloat items: {count}
+- Total rot token estimate: {X} tokens ({Y}% of total context)
+
+## Findings
+
+### Stale
+| # | File | Line | Content | Recommended Action |
+|---|------|------|---------|-------------------|
+
+### Redundant
+| # | File A | File B | Duplicate Content | Action |
+|---|--------|--------|-------------------|--------|
+
+### Contradictory
+| # | File A (says) | File B (says) | Resolution |
+|---|---------------|---------------|------------|
+
+### Bloated
+| # | File | Section | Why It's Bloat | Token Cost |
+|---|------|---------|---------------|------------|
+```

package/squad-claude/tasks/context-window-audit.md

@@ -0,0 +1,95 @@
+---
+task: context-window-audit
+responsavel: "@skill-craftsman"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Validar inputs"
+  - "[ ] Executar steps"
+  - "[ ] Verificar qualidade"
+  - "[ ] Gerar output"
+---
+
+# Context Window Audit
+
+## Objective
+
+Perform a comprehensive audit of context window usage in a Claude Code project. Measure token consumption across all context sources, identify waste and inefficiency, and produce an optimization plan that maximizes useful information density within the available context budget.
+
+## Pre-Conditions
+
+- Project with CLAUDE.md, rules, knowledge bases, or agent definitions
+- Understanding of the project's primary workflows and use cases
+- Token estimation tools or methods available
+- Target context budget defined (or model's context limit known)
+- List of most frequent interaction patterns
+
+## Steps
+
+1. **Inventory All Context Sources** — Enumerate every file that contributes to the context window: root CLAUDE.md, directory-level CLAUDE.md files, .claude/rules/ files (always-loaded and path-conditional), knowledge base files, agent definitions, MCP tool descriptions, and system prompts.
+2. **Measure Token Footprint** — Estimate token count for each context source. Use character-to-token heuristics (1 token per ~4 characters for English) or tokenizer tools. Create a breakdown table sorted by token consumption (largest first).
+3. **Classify Information Type** — Tag each section of each file with its information type: behavioral rules (MUST/SHOULD), reference data (tables, schemas), examples (code samples, templates), metadata (version, dates), and filler (generic advice, obvious instructions).
+4. **Score Information Value** — Rate each section on a 1-5 value scale: 1=Claude already knows this (generic best practices), 2=nice to have but rarely referenced, 3=useful for specific tasks, 4=important for common workflows, 5=critical and unique (project-specific rules that prevent errors).
+5. **Calculate Efficiency Ratio** — For each file, compute: (tokens scored 4-5) / (total tokens) = efficiency ratio. Files below 40% efficiency are optimization candidates. Rank all files by efficiency ratio.
+6. **Identify Always-Loaded Waste** — Find content that is always loaded but only relevant to specific tasks. This is the highest-impact optimization: move task-specific content to path-conditional rules (using `paths:` frontmatter) so it only loads when relevant files are being edited.
+7. **Detect Redundancy** — Find duplicated information: same rules stated in CLAUDE.md and in rules files, examples repeated across knowledge bases, instructions that duplicate Claude's built-in behavior. Mark each redundancy with the recommended resolution (remove, merge, or reference).
+8. **Analyze MCP Tool Description Overhead** — Count tokens consumed by MCP tool descriptions that load into context. Identify tools that are rarely used but always present. Recommend tool description optimization or selective loading.
+9. **Produce Optimization Plan** — Create a prioritized action plan: each action has a description, affected file(s), estimated token savings, effort level (easy/medium/hard), and risk level (safe/moderate/risky). Sort by token savings descending.
+10. **Project Post-Optimization Footprint** — Calculate the expected context footprint after all optimizations are applied. Compare with current footprint. Estimate the percentage of context freed for actual conversation and tool results.
+
+## Output
+
+```markdown
+# Context Window Audit Report
+
+## Summary
+| Metric | Value |
+|--------|-------|
+| Total context sources | {count} |
+| Total token footprint | {tokens} |
+| Average efficiency ratio | {%} |
+| Estimated waste | {tokens} ({%}) |
+| Post-optimization estimate | {tokens} |
+
+## Token Breakdown (Top Sources)
+| Source | Tokens | Efficiency | Type |
+|--------|--------|-----------|------|
+| {file} | {tokens} | {%} | {always/conditional} |
+
+## Optimization Plan
+| # | Action | File(s) | Token Savings | Effort | Risk |
+|---|--------|---------|--------------|--------|------|
+| 1 | {action} | {file} | {tokens} | {effort} | {risk} |
+
+## Redundancy Map
+| Content | Found In | Resolution |
+|---------|----------|------------|
+
+## MCP Overhead
+| MCP Server | Tools | Description Tokens | Usage Frequency |
+|-----------|-------|-------------------|----------------|
+
+## Recommendations
+1. {highest impact recommendation}
+2. {second highest}
+3. {third highest}
+```
+
+## Quality Criteria
+
+- Every context source must be measured (zero sources skipped)
+- Token estimates must be within 20% of actual (validate with sample tokenization)
+- Optimization plan must target at least 20% token reduction
+- No optimization may remove content scored 5 (critical/unique)
+- Path-conditional migrations must include correct `paths:` frontmatter syntax
+- Report must be actionable without requiring additional analysis

package/squad-claude/tasks/create-agent-definition.md

@@ -0,0 +1,59 @@
+---
+task: create-agent-definition
+responsavel: "@skill-craftsman"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Validar inputs"
+  - "[ ] Executar steps"
+  - "[ ] Verificar qualidade"
+  - "[ ] Gerar output"
+---
+
+# Create Agent Definition
+
+## Objective
+
+Create a complete agent definition file following the squad agent format. Design the agent's identity, persona, competencies, frameworks, metrics, delegation matrix, and cross-squad handoffs for effective Claude Code operation.
+
+## Inputs
+
+- Agent purpose and domain
+- Required competencies
+- Tools the agent needs access to
+- Tasks the agent will execute
+- Related agents (for delegation matrix)
+- Squad membership
+
+## Steps
+
+1. **Define Identity** — Choose a meaningful name, icon, agent ID (lowercase-hyphenated), and squad assignment. The name should evoke the agent's domain.
+2. **Craft Persona** — Write a personality description that shapes how Claude Code behaves when this agent is active. Include thinking style, communication preferences, and decision-making approach.
+3. **List Core Competencies** — Define 5-8 specific competencies with descriptions. Each must be actionable and measurable, not vague (e.g., "React component testing with Jest and RTL" not "testing").
+4. **Design Frameworks** — Create 3-5 mental models or decision frameworks the agent uses. These shape how the agent approaches problems (e.g., "Security-First Checklist", "Performance Budget Model").
+5. **Set Key Metrics** — Define 4-6 measurable metrics with targets that indicate the agent is performing well.
+6. **Build Delegation Matrix** — Map incoming request types to actions: handle directly, collaborate with another agent, or delegate entirely. Be explicit about boundaries.
+7. **Define Cross-Squad Handoffs** — Specify inbound and outbound handoff triggers with other squads. Include the triggering condition for each handoff.
+8. **Validate Completeness** — Check all sections against the agent template. Ensure no section is missing or placeholder.
+
+## Quality Gates
+
+- Agent ID must be unique across all squads
+- Every competency must map to at least one task
+- Delegation matrix must cover all reasonable request types
+- Persona must be distinct from other agents in the same squad
+- Frameworks must be specific to the agent's domain (not generic)
+
+## Output Format
+
+Complete agent definition Markdown file following the standard structure: Identity table, Role, Personality, Core Competencies, Frameworks, Key Metrics, Delegation Matrix, Tasks, Cross-Squad Handoffs.

package/squad-claude/tasks/create-rules.md

@@ -0,0 +1,55 @@
+---
+task: create-rules
+responsavel: "@config-engineer"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Validar inputs"
+  - "[ ] Executar steps"
+  - "[ ] Verificar qualidade"
+  - "[ ] Gerar output"
+---
+
+# Create Rules
+
+## Objective
+
+Design and create .claude/rules/ files with proper frontmatter for conditional loading based on file paths, providing Claude Code with context-specific instructions that activate only when relevant files are being edited.
+
+## Inputs
+
+- Project structure and key directories
+- Rules needed (coding standards, framework-specific guidance, testing patterns, security policies)
+- File path patterns for conditional activation
+- Existing rules (to avoid conflicts)
+
+## Steps
+
+1. **Map Rules to Contexts** — Identify which instructions are needed for which file patterns. E.g., React component rules for `src/components/**/*.tsx`, API rules for `src/api/**/*.ts`.
+2. **Design Frontmatter** — Create proper YAML frontmatter with `paths:` field using glob patterns. Rules without `paths:` load globally (use sparingly).
+3. **Write Rule Content** — Write clear, actionable instructions. Use imperative mood. Be specific about what Claude Code should and should not do when editing matching files.
+4. **Check for Conflicts** — Verify new rules don't contradict existing rules or CLAUDE.md instructions. Check for overlapping path patterns that could cause confusion.
+5. **Organize File Names** — Use descriptive names: `react-components.md`, `api-routes.md`, `testing-standards.md`, `security-policies.md`. Prefix with domain.
+6. **Validate Loading** — Verify that rules would load correctly by checking path patterns against actual project file paths.
+7. **Document Rule Set** — Create an index of all rules with their activation patterns and purposes.
+
+## Quality Gates
+
+- Every rule with `paths:` frontmatter must match at least one existing file in the project
+- No two rules should give contradictory instructions for the same file pattern
+- Global rules (no `paths:`) must be genuinely universal
+- Rule content must be actionable (not just informational)
+
+## Output Format
+
+Individual .claude/rules/*.md files with frontmatter, plus an index document listing all rules and their activation patterns.