Compare commits
113 Commits
v1.9.0
...
ecc-tools/
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
06c8402b19 | ||
|
|
e9264d84f5 | ||
|
|
9c74492f86 | ||
|
|
f38fff2155 | ||
|
|
080194436d | ||
|
|
6ef930ed3e | ||
|
|
a5e40ef0f7 | ||
|
|
cffe9cf953 | ||
|
|
09e85c4350 | ||
|
|
ae19bad71f | ||
|
|
9a24665935 | ||
|
|
c1327505ad | ||
|
|
1571d23a40 | ||
|
|
c8c6ebabb3 | ||
|
|
db4ffbc398 | ||
|
|
f2de3453a7 | ||
|
|
aa98844de4 | ||
|
|
bad5ebf7b0 | ||
|
|
62e4d16008 | ||
|
|
4a4c01b7ec | ||
|
|
e3d1500efb | ||
|
|
7eaae99cc7 | ||
|
|
b7012da28b | ||
|
|
4be983ac03 | ||
|
|
350c43e10a | ||
|
|
10177640ff | ||
|
|
72f8ec41f3 | ||
|
|
49788ec1f3 | ||
|
|
203ce6a7d8 | ||
|
|
280b7ef537 | ||
|
|
22bb2ff0e7 | ||
|
|
0f3c64d7f9 | ||
|
|
b5017c2a70 | ||
|
|
e416d9459f | ||
|
|
7e16420feb | ||
|
|
81ad3abb82 | ||
|
|
830e591fba | ||
|
|
8a76b4a93f | ||
|
|
bed40d72a9 | ||
|
|
c19d101e09 | ||
|
|
e006aacac8 | ||
|
|
d7802cfba1 | ||
|
|
60070e54fb | ||
|
|
3782530e32 | ||
|
|
23c3284848 | ||
|
|
72497ccae7 | ||
|
|
b032846806 | ||
|
|
6f13b057af | ||
|
|
0e733753e0 | ||
|
|
4f5665c7f0 | ||
|
|
83d3279fd8 | ||
|
|
0c7deb26a3 | ||
|
|
fdb10ba116 | ||
|
|
401dca07d0 | ||
|
|
4df960c9d5 | ||
|
|
09efd68228 | ||
|
|
4e6b5cc19f | ||
|
|
4f6f587700 | ||
|
|
fd2a8edb53 | ||
|
|
bb1efad7c7 | ||
|
|
57fa3b56c0 | ||
|
|
c3769b5c13 | ||
|
|
d54b57e77d | ||
|
|
82e842ad69 | ||
|
|
408a208086 | ||
|
|
bb1c625b30 | ||
|
|
900c9836fb | ||
|
|
6b2de1baff | ||
|
|
f55dc50435 | ||
|
|
dae25a15b3 | ||
|
|
4dafacaa8b | ||
|
|
9b24173867 | ||
|
|
91dcb31886 | ||
|
|
be6d7f314a | ||
|
|
1ef8bc1e72 | ||
|
|
5fb3bca5fd | ||
|
|
29c0434eb3 | ||
|
|
0195465234 | ||
|
|
0d2828cc00 | ||
|
|
c1847bec5d | ||
|
|
4b01c8eef5 | ||
|
|
e73c2ffa34 | ||
|
|
0af0fbf40b | ||
|
|
af30ae63c5 | ||
|
|
fc4e5d654b | ||
|
|
7ccfda9e25 | ||
|
|
2643e0c72f | ||
|
|
1975a576c5 | ||
|
|
f563fe2a3b | ||
|
|
e8495aa3fc | ||
|
|
35071150b7 | ||
|
|
40f18885b1 | ||
|
|
b77f49569b | ||
|
|
bea68549c5 | ||
|
|
b981c765ae | ||
|
|
b61f549444 | ||
|
|
162236f463 | ||
|
|
04ad4737de | ||
|
|
8ebb47bdd1 | ||
|
|
e70c43bcd4 | ||
|
|
cbccb7fdc0 | ||
|
|
a2df9397ff | ||
|
|
47f508ec21 | ||
|
|
ce828c1c3c | ||
|
|
c8f631b046 | ||
|
|
8511d84042 | ||
|
|
8a57894394 | ||
|
|
68484da2fc | ||
|
|
0b0b66c02f | ||
|
|
28de7cc420 | ||
|
|
9a478ad676 | ||
|
|
52e949a85b | ||
|
|
07f6156d8a |
373
.agents/skills/everything-claude-code/SKILL.md
Normal file
@@ -0,0 +1,373 @@
|
||||
---
|
||||
name: everything-claude-code-conventions
|
||||
description: Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.
|
||||
---
|
||||
|
||||
# Everything Claude Code Conventions
|
||||
|
||||
> Generated from [affaan-m/everything-claude-code](https://github.com/affaan-m/everything-claude-code) on 2026-03-24
|
||||
|
||||
## Overview
|
||||
|
||||
This skill teaches Claude the development patterns and conventions used in everything-claude-code.
|
||||
|
||||
## Tech Stack
|
||||
|
||||
- **Primary Language**: JavaScript
|
||||
- **Architecture**: hybrid module organization
|
||||
- **Test Location**: separate
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Activate this skill when:
|
||||
- Making changes to this repository
|
||||
- Adding new features following established patterns
|
||||
- Writing tests that match project conventions
|
||||
- Creating commits with proper message format
|
||||
|
||||
## Commit Conventions
|
||||
|
||||
Follow these commit message conventions based on 500 analyzed commits.
|
||||
|
||||
### Commit Style: Conventional Commits
|
||||
|
||||
### Prefixes Used
|
||||
|
||||
- `feat`
|
||||
- `fix`
|
||||
- `docs`
|
||||
- `test`
|
||||
|
||||
### Message Guidelines
|
||||
|
||||
- Average message length: ~62 characters
|
||||
- Keep first line concise and descriptive
|
||||
- Use imperative mood ("Add feature" not "Added feature")
|
||||
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
feat: add everything-claude-code ECC bundle (.claude/commands/add-or-update-skill.md)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
perf(hooks): move post-edit-format and post-edit-typecheck to strict-only (#757)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
fix: safe Codex config sync — merge AGENTS.md + add-only MCP servers (#723)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
docs(zh-CN): translate code block(plain text) (#753)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
security: remove supply chain risks, external promotions, and unauthorized credits
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
feat: add everything-claude-code ECC bundle (.claude/commands/feature-development.md)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
feat: add everything-claude-code ECC bundle (.claude/commands/database-migration.md)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
feat: add everything-claude-code ECC bundle (.claude/enterprise/controls.md)
|
||||
```
|
||||
|
||||
## Architecture
|
||||
|
||||
### Project Structure: Single Package
|
||||
|
||||
This project uses **hybrid** module organization.
|
||||
|
||||
### Configuration Files
|
||||
|
||||
- `.github/workflows/ci.yml`
|
||||
- `.github/workflows/maintenance.yml`
|
||||
- `.github/workflows/monthly-metrics.yml`
|
||||
- `.github/workflows/release.yml`
|
||||
- `.github/workflows/reusable-release.yml`
|
||||
- `.github/workflows/reusable-test.yml`
|
||||
- `.github/workflows/reusable-validate.yml`
|
||||
- `.opencode/package.json`
|
||||
- `.opencode/tsconfig.json`
|
||||
- `.prettierrc`
|
||||
- `eslint.config.js`
|
||||
- `package.json`
|
||||
|
||||
### Guidelines
|
||||
|
||||
- This project uses a hybrid organization
|
||||
- Follow existing patterns when adding new code
|
||||
|
||||
## Code Style
|
||||
|
||||
### Language: JavaScript
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
| Element | Convention |
|
||||
|---------|------------|
|
||||
| Files | camelCase |
|
||||
| Functions | camelCase |
|
||||
| Classes | PascalCase |
|
||||
| Constants | SCREAMING_SNAKE_CASE |
|
||||
|
||||
### Import Style: Relative Imports
|
||||
|
||||
### Export Style: Mixed Style
|
||||
|
||||
|
||||
*Preferred import style*
|
||||
|
||||
```typescript
|
||||
// Use relative imports
|
||||
import { Button } from '../components/Button'
|
||||
import { useAuth } from './hooks/useAuth'
|
||||
```
|
||||
|
||||
## Testing
|
||||
|
||||
### Test Framework
|
||||
|
||||
No specific test framework detected — use the repository's existing test patterns.
|
||||
|
||||
### File Pattern: `*.test.js`
|
||||
|
||||
### Test Types
|
||||
|
||||
- **Unit tests**: Test individual functions and components in isolation
|
||||
- **Integration tests**: Test interactions between multiple components/services
|
||||
|
||||
### Coverage
|
||||
|
||||
This project has coverage reporting configured. Aim for 80%+ coverage.
|
||||
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Error Handling Style: Try-Catch Blocks
|
||||
|
||||
|
||||
*Standard error handling pattern*
|
||||
|
||||
```typescript
|
||||
try {
|
||||
const result = await riskyOperation()
|
||||
return result
|
||||
} catch (error) {
|
||||
console.error('Operation failed:', error)
|
||||
throw new Error('User-friendly message')
|
||||
}
|
||||
```
|
||||
|
||||
## Common Workflows
|
||||
|
||||
These workflows were detected from analyzing commit patterns.
|
||||
|
||||
### Database Migration
|
||||
|
||||
Database schema changes with migration files
|
||||
|
||||
**Frequency**: ~2 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Create migration file
|
||||
2. Update schema definitions
|
||||
3. Generate/update types
|
||||
|
||||
**Files typically involved**:
|
||||
- `migrations/*`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Add Turkish (tr) docs and update README (#744)
|
||||
docs(zh-CN): translate code block(plain text) (#753)
|
||||
fix(install): add rust, cpp, csharp to legacy language alias map (#747)
|
||||
```
|
||||
|
||||
### Feature Development
|
||||
|
||||
Standard feature implementation workflow
|
||||
|
||||
**Frequency**: ~26 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Add feature implementation
|
||||
2. Add tests for feature
|
||||
3. Update documentation
|
||||
|
||||
**Files typically involved**:
|
||||
- `manifests/*`
|
||||
- `**/*.test.*`
|
||||
- `**/api/**`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Merge pull request #736 from pvgomes/docs/add-brazilian-portuguese-translation
|
||||
fix: bump plugin.json and marketplace.json to v1.9.0
|
||||
Add Turkish (tr) docs and update README (#744)
|
||||
```
|
||||
|
||||
### Add Or Update Skill
|
||||
|
||||
Adds or updates a skill in the ECC system, including documentation and provenance.
|
||||
|
||||
**Frequency**: ~3 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Create or update SKILL.md in the appropriate skills directory (e.g., skills/{skill-name}/SKILL.md or .claude/skills/{skill-name}/SKILL.md)
|
||||
2. Optionally add or update agent YAML files (e.g., .agents/skills/{skill-name}/agents/*.yaml)
|
||||
3. Optionally update provenance or placement policy files (e.g., schemas/provenance.schema.json, docs/SKILL-PLACEMENT-POLICY.md)
|
||||
|
||||
**Files typically involved**:
|
||||
- `skills/*/SKILL.md`
|
||||
- `.claude/skills/*/SKILL.md`
|
||||
- `.agents/skills/*/SKILL.md`
|
||||
- `.agents/skills/*/agents/*.yaml`
|
||||
- `schemas/provenance.schema.json`
|
||||
- `docs/SKILL-PLACEMENT-POLICY.md`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Create or update SKILL.md in the appropriate skills directory (e.g., skills/{skill-name}/SKILL.md or .claude/skills/{skill-name}/SKILL.md)
|
||||
Optionally add or update agent YAML files (e.g., .agents/skills/{skill-name}/agents/*.yaml)
|
||||
Optionally update provenance or placement policy files (e.g., schemas/provenance.schema.json, docs/SKILL-PLACEMENT-POLICY.md)
|
||||
```
|
||||
|
||||
### Add Or Update Command Documentation
|
||||
|
||||
Adds or updates documentation for a command, often as part of a new feature or workflow.
|
||||
|
||||
**Frequency**: ~4 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Create or update .claude/commands/{command-name}.md
|
||||
2. Optionally update localized docs (e.g., docs/zh-CN/commands/{command-name}.md, docs/tr/commands/{command-name}.md, docs/pt-BR/commands/{command-name}.md)
|
||||
|
||||
**Files typically involved**:
|
||||
- `.claude/commands/*.md`
|
||||
- `docs/zh-CN/commands/*.md`
|
||||
- `docs/tr/commands/*.md`
|
||||
- `docs/pt-BR/commands/*.md`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Create or update .claude/commands/{command-name}.md
|
||||
Optionally update localized docs (e.g., docs/zh-CN/commands/{command-name}.md, docs/tr/commands/{command-name}.md, docs/pt-BR/commands/{command-name}.md)
|
||||
```
|
||||
|
||||
### Add Or Update Localized Documentation
|
||||
|
||||
Adds or updates documentation in a new or existing language (localization).
|
||||
|
||||
**Frequency**: ~2 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Add or update files in docs/{locale}/ (where locale is zh-CN, tr, pt-BR, etc.)
|
||||
2. Update README.md to reflect new language support
|
||||
|
||||
**Files typically involved**:
|
||||
- `docs/zh-CN/**/*`
|
||||
- `docs/tr/**/*`
|
||||
- `docs/pt-BR/**/*`
|
||||
- `README.md`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Add or update files in docs/{locale}/ (where locale is zh-CN, tr, pt-BR, etc.)
|
||||
Update README.md to reflect new language support
|
||||
```
|
||||
|
||||
### Update Or Add Hooks
|
||||
|
||||
Adds or updates hooks for validation, config protection, or workflow automation.
|
||||
|
||||
**Frequency**: ~2 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Edit hooks/hooks.json to add or update hook definitions
|
||||
2. Create or update scripts/hooks/*.js or .ts for hook logic
|
||||
3. Optionally update plugin files (e.g., .opencode/plugins/ecc-hooks.ts)
|
||||
|
||||
**Files typically involved**:
|
||||
- `hooks/hooks.json`
|
||||
- `scripts/hooks/*.js`
|
||||
- `.opencode/plugins/*.ts`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Edit hooks/hooks.json to add or update hook definitions
|
||||
Create or update scripts/hooks/*.js or .ts for hook logic
|
||||
Optionally update plugin files (e.g., .opencode/plugins/ecc-hooks.ts)
|
||||
```
|
||||
|
||||
### Add Or Update Ecc Bundle
|
||||
|
||||
Adds or updates a set of ECC configuration, command, or skill files as a bundle.
|
||||
|
||||
**Frequency**: ~2 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Create or update files in .claude/ (commands, skills, rules, team, identity, etc.)
|
||||
2. Optionally update .codex/agents/*.toml and .agents/skills/*
|
||||
3. Repeat for each bundle component as needed
|
||||
|
||||
**Files typically involved**:
|
||||
- `.claude/commands/*.md`
|
||||
- `.claude/skills/*/SKILL.md`
|
||||
- `.claude/rules/*.md`
|
||||
- `.claude/team/*.json`
|
||||
- `.claude/identity.json`
|
||||
- `.claude/ecc-tools.json`
|
||||
- `.codex/agents/*.toml`
|
||||
- `.agents/skills/*/SKILL.md`
|
||||
- `.agents/skills/*/agents/*.yaml`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Create or update files in .claude/ (commands, skills, rules, team, identity, etc.)
|
||||
Optionally update .codex/agents/*.toml and .agents/skills/*
|
||||
Repeat for each bundle component as needed
|
||||
```
|
||||
|
||||
|
||||
## Best Practices
|
||||
|
||||
Based on analysis of the codebase, follow these practices:
|
||||
|
||||
### Do
|
||||
|
||||
- Use conventional commit format (feat:, fix:, etc.)
|
||||
- Follow *.test.js naming pattern
|
||||
- Use camelCase for file names
|
||||
- Prefer mixed exports
|
||||
|
||||
### Don't
|
||||
|
||||
- Don't write vague commit messages
|
||||
- Don't skip tests for new features
|
||||
- Don't deviate from established patterns without discussion
|
||||
|
||||
---
|
||||
|
||||
*This skill was auto-generated by [ECC Tools](https://ecc.tools). Review and customize as needed for your team.*
|
||||
6
.agents/skills/everything-claude-code/agents/openai.yaml
Normal file
@@ -0,0 +1,6 @@
|
||||
interface:
|
||||
display_name: "Everything Claude Code"
|
||||
short_description: "Repo-specific patterns and workflows for everything-claude-code"
|
||||
default_prompt: "Use the everything-claude-code repo skill to follow existing architecture, testing, and workflow conventions."
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
@@ -14,7 +14,7 @@
|
||||
"name": "everything-claude-code",
|
||||
"source": "./",
|
||||
"description": "The most comprehensive Claude Code plugin — 14+ agents, 56+ skills, 33+ commands, and production-ready hooks for TDD, security scanning, code review, and continuous learning",
|
||||
"version": "1.8.0",
|
||||
"version": "1.9.0",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
"email": "me@affaanmustafa.com"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "everything-claude-code",
|
||||
"version": "1.8.0",
|
||||
"version": "1.9.0",
|
||||
"description": "Complete collection of battle-tested Claude Code configs from an Anthropic hackathon winner - agents, skills, hooks, and rules evolved over 10+ months of intensive daily use",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
|
||||
39
.claude/commands/add-language-rules.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: add-language-rules
|
||||
description: Workflow command scaffold for add-language-rules in everything-claude-code.
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /add-language-rules
|
||||
|
||||
Use this workflow when working on **add-language-rules** in `everything-claude-code`.
|
||||
|
||||
## Goal
|
||||
|
||||
Adds a new programming language to the rules system, including coding style, hooks, patterns, security, and testing guidelines.
|
||||
|
||||
## Common Files
|
||||
|
||||
- `rules/*/coding-style.md`
|
||||
- `rules/*/hooks.md`
|
||||
- `rules/*/patterns.md`
|
||||
- `rules/*/security.md`
|
||||
- `rules/*/testing.md`
|
||||
|
||||
## Suggested Sequence
|
||||
|
||||
1. Understand the current state and failure mode before editing.
|
||||
2. Make the smallest coherent change that satisfies the workflow goal.
|
||||
3. Run the most relevant verification for touched files.
|
||||
4. Summarize what changed and what still needs review.
|
||||
|
||||
## Typical Commit Signals
|
||||
|
||||
- Create a new directory under rules/{language}/
|
||||
- Add coding-style.md, hooks.md, patterns.md, security.md, and testing.md files with language-specific content
|
||||
- Optionally reference or link to related skills
|
||||
|
||||
## Notes
|
||||
|
||||
- Treat this as a scaffold, not a hard-coded script.
|
||||
- Update the command if the workflow evolves materially.
|
||||
37
.claude/commands/add-or-update-skill-documentation.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: add-or-update-skill-documentation
|
||||
description: Workflow command scaffold for add-or-update-skill-documentation in everything-claude-code.
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /add-or-update-skill-documentation
|
||||
|
||||
Use this workflow when working on **add-or-update-skill-documentation** in `everything-claude-code`.
|
||||
|
||||
## Goal
|
||||
|
||||
Adds a new skill or updates documentation for an existing skill, typically in the form of a SKILL.md file under skills/ or skills/*/SKILL.md.
|
||||
|
||||
## Common Files
|
||||
|
||||
- `skills/*/SKILL.md`
|
||||
- `AGENTS.md`
|
||||
- `README.md`
|
||||
|
||||
## Suggested Sequence
|
||||
|
||||
1. Understand the current state and failure mode before editing.
|
||||
2. Make the smallest coherent change that satisfies the workflow goal.
|
||||
3. Run the most relevant verification for touched files.
|
||||
4. Summarize what changed and what still needs review.
|
||||
|
||||
## Typical Commit Signals
|
||||
|
||||
- Create or update skills/<skill-name>/SKILL.md
|
||||
- Optionally update AGENTS.md or README.md to reflect new skill
|
||||
- Optionally add architecture diagrams or implementation notes
|
||||
|
||||
## Notes
|
||||
|
||||
- Treat this as a scaffold, not a hard-coded script.
|
||||
- Update the command if the workflow evolves materially.
|
||||
40
.claude/commands/add-or-update-skill.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: add-or-update-skill
|
||||
description: Workflow command scaffold for add-or-update-skill in everything-claude-code.
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /add-or-update-skill
|
||||
|
||||
Use this workflow when working on **add-or-update-skill** in `everything-claude-code`.
|
||||
|
||||
## Goal
|
||||
|
||||
Adds or updates a skill in the ECC system, including documentation and provenance.
|
||||
|
||||
## Common Files
|
||||
|
||||
- `skills/*/SKILL.md`
|
||||
- `.claude/skills/*/SKILL.md`
|
||||
- `.agents/skills/*/SKILL.md`
|
||||
- `.agents/skills/*/agents/*.yaml`
|
||||
- `schemas/provenance.schema.json`
|
||||
- `docs/SKILL-PLACEMENT-POLICY.md`
|
||||
|
||||
## Suggested Sequence
|
||||
|
||||
1. Understand the current state and failure mode before editing.
|
||||
2. Make the smallest coherent change that satisfies the workflow goal.
|
||||
3. Run the most relevant verification for touched files.
|
||||
4. Summarize what changed and what still needs review.
|
||||
|
||||
## Typical Commit Signals
|
||||
|
||||
- Create or update SKILL.md in the appropriate skills directory (e.g., skills/{skill-name}/SKILL.md or .claude/skills/{skill-name}/SKILL.md)
|
||||
- Optionally add or update agent YAML files (e.g., .agents/skills/{skill-name}/agents/*.yaml)
|
||||
- Optionally update provenance or placement policy files (e.g., schemas/provenance.schema.json, docs/SKILL-PLACEMENT-POLICY.md)
|
||||
|
||||
## Notes
|
||||
|
||||
- Treat this as a scaffold, not a hard-coded script.
|
||||
- Update the command if the workflow evolves materially.
|
||||
35
.claude/commands/database-migration.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
name: database-migration
|
||||
description: Workflow command scaffold for database-migration in everything-claude-code.
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /database-migration
|
||||
|
||||
Use this workflow when working on **database-migration** in `everything-claude-code`.
|
||||
|
||||
## Goal
|
||||
|
||||
Database schema changes with migration files
|
||||
|
||||
## Common Files
|
||||
|
||||
- `migrations/*`
|
||||
|
||||
## Suggested Sequence
|
||||
|
||||
1. Understand the current state and failure mode before editing.
|
||||
2. Make the smallest coherent change that satisfies the workflow goal.
|
||||
3. Run the most relevant verification for touched files.
|
||||
4. Summarize what changed and what still needs review.
|
||||
|
||||
## Typical Commit Signals
|
||||
|
||||
- Create migration file
|
||||
- Update schema definitions
|
||||
- Generate/update types
|
||||
|
||||
## Notes
|
||||
|
||||
- Treat this as a scaffold, not a hard-coded script.
|
||||
- Update the command if the workflow evolves materially.
|
||||
37
.claude/commands/feature-development.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: feature-development
|
||||
description: Workflow command scaffold for feature-development in everything-claude-code.
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /feature-development
|
||||
|
||||
Use this workflow when working on **feature-development** in `everything-claude-code`.
|
||||
|
||||
## Goal
|
||||
|
||||
Standard feature implementation workflow
|
||||
|
||||
## Common Files
|
||||
|
||||
- `manifests/*`
|
||||
- `**/*.test.*`
|
||||
- `**/api/**`
|
||||
|
||||
## Suggested Sequence
|
||||
|
||||
1. Understand the current state and failure mode before editing.
|
||||
2. Make the smallest coherent change that satisfies the workflow goal.
|
||||
3. Run the most relevant verification for touched files.
|
||||
4. Summarize what changed and what still needs review.
|
||||
|
||||
## Typical Commit Signals
|
||||
|
||||
- Add feature implementation
|
||||
- Add tests for feature
|
||||
- Update documentation
|
||||
|
||||
## Notes
|
||||
|
||||
- Treat this as a scaffold, not a hard-coded script.
|
||||
- Update the command if the workflow evolves materially.
|
||||
334
.claude/ecc-tools.json
Normal file
@@ -0,0 +1,334 @@
|
||||
{
|
||||
"version": "1.3",
|
||||
"schemaVersion": "1.0",
|
||||
"generatedBy": "ecc-tools",
|
||||
"generatedAt": "2026-03-24T10:44:06.345Z",
|
||||
"repo": "https://github.com/affaan-m/everything-claude-code",
|
||||
"profiles": {
|
||||
"requested": "full",
|
||||
"recommended": "full",
|
||||
"effective": "full",
|
||||
"requestedAlias": "full",
|
||||
"recommendedAlias": "full",
|
||||
"effectiveAlias": "full"
|
||||
},
|
||||
"requestedProfile": "full",
|
||||
"profile": "full",
|
||||
"recommendedProfile": "full",
|
||||
"effectiveProfile": "full",
|
||||
"tier": "enterprise",
|
||||
"requestedComponents": [
|
||||
"repo-baseline",
|
||||
"workflow-automation",
|
||||
"security-audits",
|
||||
"research-tooling",
|
||||
"team-rollout",
|
||||
"governance-controls"
|
||||
],
|
||||
"selectedComponents": [
|
||||
"repo-baseline",
|
||||
"workflow-automation",
|
||||
"security-audits",
|
||||
"research-tooling",
|
||||
"team-rollout",
|
||||
"governance-controls"
|
||||
],
|
||||
"requestedAddComponents": [],
|
||||
"requestedRemoveComponents": [],
|
||||
"blockedRemovalComponents": [],
|
||||
"tierFilteredComponents": [],
|
||||
"requestedRootPackages": [
|
||||
"runtime-core",
|
||||
"workflow-pack",
|
||||
"agentshield-pack",
|
||||
"research-pack",
|
||||
"team-config-sync",
|
||||
"enterprise-controls"
|
||||
],
|
||||
"selectedRootPackages": [
|
||||
"runtime-core",
|
||||
"workflow-pack",
|
||||
"agentshield-pack",
|
||||
"research-pack",
|
||||
"team-config-sync",
|
||||
"enterprise-controls"
|
||||
],
|
||||
"requestedPackages": [
|
||||
"runtime-core",
|
||||
"workflow-pack",
|
||||
"agentshield-pack",
|
||||
"research-pack",
|
||||
"team-config-sync",
|
||||
"enterprise-controls"
|
||||
],
|
||||
"requestedAddPackages": [],
|
||||
"requestedRemovePackages": [],
|
||||
"selectedPackages": [
|
||||
"runtime-core",
|
||||
"workflow-pack",
|
||||
"agentshield-pack",
|
||||
"research-pack",
|
||||
"team-config-sync",
|
||||
"enterprise-controls"
|
||||
],
|
||||
"packages": [
|
||||
"runtime-core",
|
||||
"workflow-pack",
|
||||
"agentshield-pack",
|
||||
"research-pack",
|
||||
"team-config-sync",
|
||||
"enterprise-controls"
|
||||
],
|
||||
"blockedRemovalPackages": [],
|
||||
"tierFilteredRootPackages": [],
|
||||
"tierFilteredPackages": [],
|
||||
"conflictingPackages": [],
|
||||
"dependencyGraph": {
|
||||
"runtime-core": [],
|
||||
"workflow-pack": [
|
||||
"runtime-core"
|
||||
],
|
||||
"agentshield-pack": [
|
||||
"workflow-pack"
|
||||
],
|
||||
"research-pack": [
|
||||
"workflow-pack"
|
||||
],
|
||||
"team-config-sync": [
|
||||
"runtime-core"
|
||||
],
|
||||
"enterprise-controls": [
|
||||
"team-config-sync"
|
||||
]
|
||||
},
|
||||
"resolutionOrder": [
|
||||
"runtime-core",
|
||||
"workflow-pack",
|
||||
"agentshield-pack",
|
||||
"research-pack",
|
||||
"team-config-sync",
|
||||
"enterprise-controls"
|
||||
],
|
||||
"requestedModules": [
|
||||
"runtime-core",
|
||||
"workflow-pack",
|
||||
"agentshield-pack",
|
||||
"research-pack",
|
||||
"team-config-sync",
|
||||
"enterprise-controls"
|
||||
],
|
||||
"selectedModules": [
|
||||
"runtime-core",
|
||||
"workflow-pack",
|
||||
"agentshield-pack",
|
||||
"research-pack",
|
||||
"team-config-sync",
|
||||
"enterprise-controls"
|
||||
],
|
||||
"modules": [
|
||||
"runtime-core",
|
||||
"workflow-pack",
|
||||
"agentshield-pack",
|
||||
"research-pack",
|
||||
"team-config-sync",
|
||||
"enterprise-controls"
|
||||
],
|
||||
"managedFiles": [
|
||||
".claude/skills/everything-claude-code/SKILL.md",
|
||||
".agents/skills/everything-claude-code/SKILL.md",
|
||||
".agents/skills/everything-claude-code/agents/openai.yaml",
|
||||
".claude/identity.json",
|
||||
".codex/config.toml",
|
||||
".codex/AGENTS.md",
|
||||
".codex/agents/explorer.toml",
|
||||
".codex/agents/reviewer.toml",
|
||||
".codex/agents/docs-researcher.toml",
|
||||
".claude/homunculus/instincts/inherited/everything-claude-code-instincts.yaml",
|
||||
".claude/rules/everything-claude-code-guardrails.md",
|
||||
".claude/research/everything-claude-code-research-playbook.md",
|
||||
".claude/team/everything-claude-code-team-config.json",
|
||||
".claude/enterprise/controls.md",
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
],
|
||||
"packageFiles": {
|
||||
"runtime-core": [
|
||||
".claude/skills/everything-claude-code/SKILL.md",
|
||||
".agents/skills/everything-claude-code/SKILL.md",
|
||||
".agents/skills/everything-claude-code/agents/openai.yaml",
|
||||
".claude/identity.json",
|
||||
".codex/config.toml",
|
||||
".codex/AGENTS.md",
|
||||
".codex/agents/explorer.toml",
|
||||
".codex/agents/reviewer.toml",
|
||||
".codex/agents/docs-researcher.toml",
|
||||
".claude/homunculus/instincts/inherited/everything-claude-code-instincts.yaml"
|
||||
],
|
||||
"agentshield-pack": [
|
||||
".claude/rules/everything-claude-code-guardrails.md"
|
||||
],
|
||||
"research-pack": [
|
||||
".claude/research/everything-claude-code-research-playbook.md"
|
||||
],
|
||||
"team-config-sync": [
|
||||
".claude/team/everything-claude-code-team-config.json"
|
||||
],
|
||||
"enterprise-controls": [
|
||||
".claude/enterprise/controls.md"
|
||||
],
|
||||
"workflow-pack": [
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
]
|
||||
},
|
||||
"moduleFiles": {
|
||||
"runtime-core": [
|
||||
".claude/skills/everything-claude-code/SKILL.md",
|
||||
".agents/skills/everything-claude-code/SKILL.md",
|
||||
".agents/skills/everything-claude-code/agents/openai.yaml",
|
||||
".claude/identity.json",
|
||||
".codex/config.toml",
|
||||
".codex/AGENTS.md",
|
||||
".codex/agents/explorer.toml",
|
||||
".codex/agents/reviewer.toml",
|
||||
".codex/agents/docs-researcher.toml",
|
||||
".claude/homunculus/instincts/inherited/everything-claude-code-instincts.yaml"
|
||||
],
|
||||
"agentshield-pack": [
|
||||
".claude/rules/everything-claude-code-guardrails.md"
|
||||
],
|
||||
"research-pack": [
|
||||
".claude/research/everything-claude-code-research-playbook.md"
|
||||
],
|
||||
"team-config-sync": [
|
||||
".claude/team/everything-claude-code-team-config.json"
|
||||
],
|
||||
"enterprise-controls": [
|
||||
".claude/enterprise/controls.md"
|
||||
],
|
||||
"workflow-pack": [
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
]
|
||||
},
|
||||
"files": [
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".claude/skills/everything-claude-code/SKILL.md",
|
||||
"description": "Repository-specific Claude Code skill generated from git history."
|
||||
},
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".agents/skills/everything-claude-code/SKILL.md",
|
||||
"description": "Codex-facing copy of the generated repository skill."
|
||||
},
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".agents/skills/everything-claude-code/agents/openai.yaml",
|
||||
"description": "Codex skill metadata so the repo skill appears cleanly in the skill interface."
|
||||
},
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".claude/identity.json",
|
||||
"description": "Suggested identity.json baseline derived from repository conventions."
|
||||
},
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".codex/config.toml",
|
||||
"description": "Repo-local Codex MCP and multi-agent baseline aligned with ECC defaults."
|
||||
},
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".codex/AGENTS.md",
|
||||
"description": "Codex usage guide that points at the generated repo skill and workflow bundle."
|
||||
},
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".codex/agents/explorer.toml",
|
||||
"description": "Read-only explorer role config for Codex multi-agent work."
|
||||
},
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".codex/agents/reviewer.toml",
|
||||
"description": "Read-only reviewer role config focused on correctness and security."
|
||||
},
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".codex/agents/docs-researcher.toml",
|
||||
"description": "Read-only docs researcher role config for API verification."
|
||||
},
|
||||
{
|
||||
"moduleId": "runtime-core",
|
||||
"path": ".claude/homunculus/instincts/inherited/everything-claude-code-instincts.yaml",
|
||||
"description": "Continuous-learning instincts derived from repository patterns."
|
||||
},
|
||||
{
|
||||
"moduleId": "agentshield-pack",
|
||||
"path": ".claude/rules/everything-claude-code-guardrails.md",
|
||||
"description": "Repository guardrails distilled from analysis for security and workflow review."
|
||||
},
|
||||
{
|
||||
"moduleId": "research-pack",
|
||||
"path": ".claude/research/everything-claude-code-research-playbook.md",
|
||||
"description": "Research workflow playbook for source attribution and long-context tasks."
|
||||
},
|
||||
{
|
||||
"moduleId": "team-config-sync",
|
||||
"path": ".claude/team/everything-claude-code-team-config.json",
|
||||
"description": "Team config scaffold that points collaborators at the shared ECC bundle."
|
||||
},
|
||||
{
|
||||
"moduleId": "enterprise-controls",
|
||||
"path": ".claude/enterprise/controls.md",
|
||||
"description": "Enterprise governance scaffold for approvals, audit posture, and escalation."
|
||||
},
|
||||
{
|
||||
"moduleId": "workflow-pack",
|
||||
"path": ".claude/commands/database-migration.md",
|
||||
"description": "Workflow command scaffold for database-migration."
|
||||
},
|
||||
{
|
||||
"moduleId": "workflow-pack",
|
||||
"path": ".claude/commands/feature-development.md",
|
||||
"description": "Workflow command scaffold for feature-development."
|
||||
},
|
||||
{
|
||||
"moduleId": "workflow-pack",
|
||||
"path": ".claude/commands/add-or-update-skill.md",
|
||||
"description": "Workflow command scaffold for add-or-update-skill."
|
||||
}
|
||||
],
|
||||
"workflows": [
|
||||
{
|
||||
"command": "database-migration",
|
||||
"path": ".claude/commands/database-migration.md"
|
||||
},
|
||||
{
|
||||
"command": "feature-development",
|
||||
"path": ".claude/commands/feature-development.md"
|
||||
},
|
||||
{
|
||||
"command": "add-or-update-skill",
|
||||
"path": ".claude/commands/add-or-update-skill.md"
|
||||
}
|
||||
],
|
||||
"adapters": {
|
||||
"claudeCode": {
|
||||
"skillPath": ".claude/skills/everything-claude-code/SKILL.md",
|
||||
"identityPath": ".claude/identity.json",
|
||||
"commandPaths": [
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
]
|
||||
},
|
||||
"codex": {
|
||||
"configPath": ".codex/config.toml",
|
||||
"agentsGuidePath": ".codex/AGENTS.md",
|
||||
"skillPath": ".agents/skills/everything-claude-code/SKILL.md"
|
||||
}
|
||||
}
|
||||
}
|
||||
15
.claude/enterprise/controls.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Enterprise Controls
|
||||
|
||||
This is a starter governance file for enterprise ECC deployments.
|
||||
|
||||
## Baseline
|
||||
|
||||
- Repository: https://github.com/affaan-m/everything-claude-code
|
||||
- Recommended profile: full
|
||||
- Keep install manifests, audit allowlists, and Codex baselines under review.
|
||||
|
||||
## Approval Expectations
|
||||
|
||||
- Security-sensitive workflow changes require explicit reviewer acknowledgement.
|
||||
- Audit suppressions must include a reason and the narrowest viable matcher.
|
||||
- Generated skills should be reviewed before broad rollout to teams.
|
||||
14
.claude/identity.json
Normal file
@@ -0,0 +1,14 @@
|
||||
{
|
||||
"version": "2.0",
|
||||
"technicalLevel": "technical",
|
||||
"preferredStyle": {
|
||||
"verbosity": "minimal",
|
||||
"codeComments": true,
|
||||
"explanations": true
|
||||
},
|
||||
"domains": [
|
||||
"javascript"
|
||||
],
|
||||
"suggestedBy": "ecc-tools-repo-analysis",
|
||||
"createdAt": "2026-03-24T10:44:20.963Z"
|
||||
}
|
||||
21
.claude/research/everything-claude-code-research-playbook.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# Everything Claude Code Research Playbook
|
||||
|
||||
Use this when the task is documentation-heavy, source-sensitive, or requires broad repository context.
|
||||
|
||||
## Defaults
|
||||
|
||||
- Prefer primary documentation and direct source links.
|
||||
- Include concrete dates when facts may change over time.
|
||||
- Keep a short evidence trail for each recommendation or conclusion.
|
||||
|
||||
## Suggested Flow
|
||||
|
||||
1. Inspect local code and docs first.
|
||||
2. Browse only for unstable or external facts.
|
||||
3. Summarize findings with file paths, commands, or links.
|
||||
|
||||
## Repo Signals
|
||||
|
||||
- Primary language: JavaScript
|
||||
- Framework: Not detected
|
||||
- Workflows detected: 7
|
||||
34
.claude/rules/everything-claude-code-guardrails.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Everything Claude Code Guardrails
|
||||
|
||||
Generated by ECC Tools from repository history. Review before treating it as a hard policy file.
|
||||
|
||||
## Commit Workflow
|
||||
|
||||
- Prefer `conventional` commit messaging with prefixes such as feat, fix, docs, test.
|
||||
- Keep new changes aligned with the existing pull-request and review flow already present in the repo.
|
||||
|
||||
## Architecture
|
||||
|
||||
- Preserve the current `hybrid` module organization.
|
||||
- Respect the current test layout: `separate`.
|
||||
|
||||
## Code Style
|
||||
|
||||
- Use `camelCase` file naming.
|
||||
- Prefer `relative` imports and `mixed` exports.
|
||||
|
||||
## ECC Defaults
|
||||
|
||||
- Current recommended install profile: `full`.
|
||||
- Validate risky config changes in PRs and keep the install manifest in source control.
|
||||
|
||||
## Detected Workflows
|
||||
|
||||
- database-migration: Database schema changes with migration files
|
||||
- feature-development: Standard feature implementation workflow
|
||||
- add-or-update-skill: Adds or updates a skill in the ECC system, including documentation and provenance.
|
||||
|
||||
## Review Reminder
|
||||
|
||||
- Regenerate this bundle when repository conventions materially change.
|
||||
- Keep suppressions narrow and auditable.
|
||||
@@ -1,97 +1,373 @@
|
||||
# Everything Claude Code
|
||||
---
|
||||
name: everything-claude-code-conventions
|
||||
description: Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.
|
||||
---
|
||||
|
||||
Use this skill when working inside the `everything-claude-code` repository and you need repo-specific guidance instead of generic coding advice.
|
||||
# Everything Claude Code Conventions
|
||||
|
||||
Optional companion instincts live at `.claude/homunculus/instincts/inherited/everything-claude-code-instincts.yaml` for teams using `continuous-learning-v2`.
|
||||
> Generated from [affaan-m/everything-claude-code](https://github.com/affaan-m/everything-claude-code) on 2026-03-24
|
||||
|
||||
## When to Use
|
||||
## Overview
|
||||
|
||||
Activate this skill when the task touches one or more of these areas:
|
||||
- cross-platform parity across Claude Code, Cursor, Codex, and OpenCode
|
||||
- hook scripts, hook docs, or hook tests
|
||||
- skills, commands, agents, or rules that must stay synchronized across surfaces
|
||||
- release work such as version bumps, changelog updates, or plugin metadata updates
|
||||
- continuous-learning or instinct workflows inside this repository
|
||||
This skill teaches Claude the development patterns and conventions used in everything-claude-code.
|
||||
|
||||
## How It Works
|
||||
## Tech Stack
|
||||
|
||||
### 1. Follow the repo's development contract
|
||||
- **Primary Language**: JavaScript
|
||||
- **Architecture**: hybrid module organization
|
||||
- **Test Location**: separate
|
||||
|
||||
- Use conventional commits such as `feat:`, `fix:`, `docs:`, `test:`, `chore:`.
|
||||
- Keep commit subjects concise and close to the repo norm of about 70 characters.
|
||||
- Prefer camelCase for JavaScript and TypeScript module filenames.
|
||||
- Use kebab-case for skill directories and command filenames.
|
||||
- Keep test files on the existing `*.test.js` pattern.
|
||||
## When to Use This Skill
|
||||
|
||||
### 2. Treat the root repo as the source of truth
|
||||
Activate this skill when:
|
||||
- Making changes to this repository
|
||||
- Adding new features following established patterns
|
||||
- Writing tests that match project conventions
|
||||
- Creating commits with proper message format
|
||||
|
||||
Start from the root implementation, then mirror changes where they are intentionally shipped.
|
||||
## Commit Conventions
|
||||
|
||||
Typical mirror targets:
|
||||
- `.cursor/`
|
||||
- `.codex/`
|
||||
- `.opencode/`
|
||||
- `.agents/`
|
||||
Follow these commit message conventions based on 500 analyzed commits.
|
||||
|
||||
Do not assume every `.claude/` artifact needs a cross-platform copy. Only mirror files that are part of the shipped multi-platform surface.
|
||||
### Commit Style: Conventional Commits
|
||||
|
||||
### 3. Update hooks with tests and docs together
|
||||
### Prefixes Used
|
||||
|
||||
When changing hook behavior:
|
||||
1. update `hooks/hooks.json` or the relevant script in `scripts/hooks/`
|
||||
2. update matching tests in `tests/hooks/` or `tests/integration/`
|
||||
3. update `hooks/README.md` if behavior or configuration changed
|
||||
4. verify parity for `.cursor/hooks/` and `.opencode/plugins/` when applicable
|
||||
- `feat`
|
||||
- `fix`
|
||||
- `docs`
|
||||
- `test`
|
||||
|
||||
### 4. Keep release metadata in sync
|
||||
### Message Guidelines
|
||||
|
||||
When preparing a release, verify the same version is reflected anywhere it is surfaced:
|
||||
- `package.json`
|
||||
- `.claude-plugin/plugin.json`
|
||||
- `.claude-plugin/marketplace.json`
|
||||
- Average message length: ~62 characters
|
||||
- Keep first line concise and descriptive
|
||||
- Use imperative mood ("Add feature" not "Added feature")
|
||||
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
feat: add everything-claude-code ECC bundle (.claude/commands/add-or-update-skill.md)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
perf(hooks): move post-edit-format and post-edit-typecheck to strict-only (#757)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
fix: safe Codex config sync — merge AGENTS.md + add-only MCP servers (#723)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
docs(zh-CN): translate code block(plain text) (#753)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
security: remove supply chain risks, external promotions, and unauthorized credits
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
feat: add everything-claude-code ECC bundle (.claude/commands/feature-development.md)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
feat: add everything-claude-code ECC bundle (.claude/commands/database-migration.md)
|
||||
```
|
||||
|
||||
*Commit message example*
|
||||
|
||||
```text
|
||||
feat: add everything-claude-code ECC bundle (.claude/enterprise/controls.md)
|
||||
```
|
||||
|
||||
## Architecture
|
||||
|
||||
### Project Structure: Single Package
|
||||
|
||||
This project uses **hybrid** module organization.
|
||||
|
||||
### Configuration Files
|
||||
|
||||
- `.github/workflows/ci.yml`
|
||||
- `.github/workflows/maintenance.yml`
|
||||
- `.github/workflows/monthly-metrics.yml`
|
||||
- `.github/workflows/release.yml`
|
||||
- `.github/workflows/reusable-release.yml`
|
||||
- `.github/workflows/reusable-test.yml`
|
||||
- `.github/workflows/reusable-validate.yml`
|
||||
- `.opencode/package.json`
|
||||
- release notes or changelog entries when the release process expects them
|
||||
- `.opencode/tsconfig.json`
|
||||
- `.prettierrc`
|
||||
- `eslint.config.js`
|
||||
- `package.json`
|
||||
|
||||
### 5. Be explicit about continuous-learning changes
|
||||
### Guidelines
|
||||
|
||||
If the task touches `skills/continuous-learning-v2/` or imported instincts:
|
||||
- prefer accurate, low-noise instincts over auto-generated bulk output
|
||||
- keep instinct files importable by `instinct-cli.py`
|
||||
- remove duplicated or contradictory instincts instead of layering more guidance on top
|
||||
- This project uses a hybrid organization
|
||||
- Follow existing patterns when adding new code
|
||||
|
||||
## Examples
|
||||
## Code Style
|
||||
|
||||
### Naming examples
|
||||
### Language: JavaScript
|
||||
|
||||
```text
|
||||
skills/continuous-learning-v2/SKILL.md
|
||||
commands/update-docs.md
|
||||
scripts/hooks/session-start.js
|
||||
tests/hooks/hooks.test.js
|
||||
### Naming Conventions
|
||||
|
||||
| Element | Convention |
|
||||
|---------|------------|
|
||||
| Files | camelCase |
|
||||
| Functions | camelCase |
|
||||
| Classes | PascalCase |
|
||||
| Constants | SCREAMING_SNAKE_CASE |
|
||||
|
||||
### Import Style: Relative Imports
|
||||
|
||||
### Export Style: Mixed Style
|
||||
|
||||
|
||||
*Preferred import style*
|
||||
|
||||
```typescript
|
||||
// Use relative imports
|
||||
import { Button } from '../components/Button'
|
||||
import { useAuth } from './hooks/useAuth'
|
||||
```
|
||||
|
||||
### Commit examples
|
||||
## Testing
|
||||
|
||||
```text
|
||||
fix: harden session summary extraction on Stop hook
|
||||
docs: align Codex config examples with current schema
|
||||
test: cover Windows formatter fallback behavior
|
||||
### Test Framework
|
||||
|
||||
No specific test framework detected — use the repository's existing test patterns.
|
||||
|
||||
### File Pattern: `*.test.js`
|
||||
|
||||
### Test Types
|
||||
|
||||
- **Unit tests**: Test individual functions and components in isolation
|
||||
- **Integration tests**: Test interactions between multiple components/services
|
||||
|
||||
### Coverage
|
||||
|
||||
This project has coverage reporting configured. Aim for 80%+ coverage.
|
||||
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Error Handling Style: Try-Catch Blocks
|
||||
|
||||
|
||||
*Standard error handling pattern*
|
||||
|
||||
```typescript
|
||||
try {
|
||||
const result = await riskyOperation()
|
||||
return result
|
||||
} catch (error) {
|
||||
console.error('Operation failed:', error)
|
||||
throw new Error('User-friendly message')
|
||||
}
|
||||
```
|
||||
|
||||
### Skill update checklist
|
||||
## Common Workflows
|
||||
|
||||
```text
|
||||
1. Update the root skill or command.
|
||||
2. Mirror it only where that surface is shipped.
|
||||
3. Run targeted tests first, then the broader suite if behavior changed.
|
||||
4. Review docs and release notes for user-visible changes.
|
||||
These workflows were detected from analyzing commit patterns.
|
||||
|
||||
### Database Migration
|
||||
|
||||
Database schema changes with migration files
|
||||
|
||||
**Frequency**: ~2 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Create migration file
|
||||
2. Update schema definitions
|
||||
3. Generate/update types
|
||||
|
||||
**Files typically involved**:
|
||||
- `migrations/*`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Add Turkish (tr) docs and update README (#744)
|
||||
docs(zh-CN): translate code block(plain text) (#753)
|
||||
fix(install): add rust, cpp, csharp to legacy language alias map (#747)
|
||||
```
|
||||
|
||||
### Release checklist
|
||||
### Feature Development
|
||||
|
||||
```text
|
||||
1. Bump package and plugin versions.
|
||||
2. Run npm test.
|
||||
3. Verify platform-specific manifests.
|
||||
4. Publish the release notes with a human-readable summary.
|
||||
Standard feature implementation workflow
|
||||
|
||||
**Frequency**: ~26 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Add feature implementation
|
||||
2. Add tests for feature
|
||||
3. Update documentation
|
||||
|
||||
**Files typically involved**:
|
||||
- `manifests/*`
|
||||
- `**/*.test.*`
|
||||
- `**/api/**`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Merge pull request #736 from pvgomes/docs/add-brazilian-portuguese-translation
|
||||
fix: bump plugin.json and marketplace.json to v1.9.0
|
||||
Add Turkish (tr) docs and update README (#744)
|
||||
```
|
||||
|
||||
### Add Or Update Skill
|
||||
|
||||
Adds or updates a skill in the ECC system, including documentation and provenance.
|
||||
|
||||
**Frequency**: ~3 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Create or update SKILL.md in the appropriate skills directory (e.g., skills/{skill-name}/SKILL.md or .claude/skills/{skill-name}/SKILL.md)
|
||||
2. Optionally add or update agent YAML files (e.g., .agents/skills/{skill-name}/agents/*.yaml)
|
||||
3. Optionally update provenance or placement policy files (e.g., schemas/provenance.schema.json, docs/SKILL-PLACEMENT-POLICY.md)
|
||||
|
||||
**Files typically involved**:
|
||||
- `skills/*/SKILL.md`
|
||||
- `.claude/skills/*/SKILL.md`
|
||||
- `.agents/skills/*/SKILL.md`
|
||||
- `.agents/skills/*/agents/*.yaml`
|
||||
- `schemas/provenance.schema.json`
|
||||
- `docs/SKILL-PLACEMENT-POLICY.md`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Create or update SKILL.md in the appropriate skills directory (e.g., skills/{skill-name}/SKILL.md or .claude/skills/{skill-name}/SKILL.md)
|
||||
Optionally add or update agent YAML files (e.g., .agents/skills/{skill-name}/agents/*.yaml)
|
||||
Optionally update provenance or placement policy files (e.g., schemas/provenance.schema.json, docs/SKILL-PLACEMENT-POLICY.md)
|
||||
```
|
||||
|
||||
### Add Or Update Command Documentation
|
||||
|
||||
Adds or updates documentation for a command, often as part of a new feature or workflow.
|
||||
|
||||
**Frequency**: ~4 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Create or update .claude/commands/{command-name}.md
|
||||
2. Optionally update localized docs (e.g., docs/zh-CN/commands/{command-name}.md, docs/tr/commands/{command-name}.md, docs/pt-BR/commands/{command-name}.md)
|
||||
|
||||
**Files typically involved**:
|
||||
- `.claude/commands/*.md`
|
||||
- `docs/zh-CN/commands/*.md`
|
||||
- `docs/tr/commands/*.md`
|
||||
- `docs/pt-BR/commands/*.md`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Create or update .claude/commands/{command-name}.md
|
||||
Optionally update localized docs (e.g., docs/zh-CN/commands/{command-name}.md, docs/tr/commands/{command-name}.md, docs/pt-BR/commands/{command-name}.md)
|
||||
```
|
||||
|
||||
### Add Or Update Localized Documentation
|
||||
|
||||
Adds or updates documentation in a new or existing language (localization).
|
||||
|
||||
**Frequency**: ~2 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Add or update files in docs/{locale}/ (where locale is zh-CN, tr, pt-BR, etc.)
|
||||
2. Update README.md to reflect new language support
|
||||
|
||||
**Files typically involved**:
|
||||
- `docs/zh-CN/**/*`
|
||||
- `docs/tr/**/*`
|
||||
- `docs/pt-BR/**/*`
|
||||
- `README.md`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Add or update files in docs/{locale}/ (where locale is zh-CN, tr, pt-BR, etc.)
|
||||
Update README.md to reflect new language support
|
||||
```
|
||||
|
||||
### Update Or Add Hooks
|
||||
|
||||
Adds or updates hooks for validation, config protection, or workflow automation.
|
||||
|
||||
**Frequency**: ~2 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Edit hooks/hooks.json to add or update hook definitions
|
||||
2. Create or update scripts/hooks/*.js or .ts for hook logic
|
||||
3. Optionally update plugin files (e.g., .opencode/plugins/ecc-hooks.ts)
|
||||
|
||||
**Files typically involved**:
|
||||
- `hooks/hooks.json`
|
||||
- `scripts/hooks/*.js`
|
||||
- `.opencode/plugins/*.ts`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Edit hooks/hooks.json to add or update hook definitions
|
||||
Create or update scripts/hooks/*.js or .ts for hook logic
|
||||
Optionally update plugin files (e.g., .opencode/plugins/ecc-hooks.ts)
|
||||
```
|
||||
|
||||
### Add Or Update Ecc Bundle
|
||||
|
||||
Adds or updates a set of ECC configuration, command, or skill files as a bundle.
|
||||
|
||||
**Frequency**: ~2 times per month
|
||||
|
||||
**Steps**:
|
||||
1. Create or update files in .claude/ (commands, skills, rules, team, identity, etc.)
|
||||
2. Optionally update .codex/agents/*.toml and .agents/skills/*
|
||||
3. Repeat for each bundle component as needed
|
||||
|
||||
**Files typically involved**:
|
||||
- `.claude/commands/*.md`
|
||||
- `.claude/skills/*/SKILL.md`
|
||||
- `.claude/rules/*.md`
|
||||
- `.claude/team/*.json`
|
||||
- `.claude/identity.json`
|
||||
- `.claude/ecc-tools.json`
|
||||
- `.codex/agents/*.toml`
|
||||
- `.agents/skills/*/SKILL.md`
|
||||
- `.agents/skills/*/agents/*.yaml`
|
||||
|
||||
**Example commit sequence**:
|
||||
```
|
||||
Create or update files in .claude/ (commands, skills, rules, team, identity, etc.)
|
||||
Optionally update .codex/agents/*.toml and .agents/skills/*
|
||||
Repeat for each bundle component as needed
|
||||
```
|
||||
|
||||
|
||||
## Best Practices
|
||||
|
||||
Based on analysis of the codebase, follow these practices:
|
||||
|
||||
### Do
|
||||
|
||||
- Use conventional commit format (feat:, fix:, etc.)
|
||||
- Follow *.test.js naming pattern
|
||||
- Use camelCase for file names
|
||||
- Prefer mixed exports
|
||||
|
||||
### Don't
|
||||
|
||||
- Don't write vague commit messages
|
||||
- Don't skip tests for new features
|
||||
- Don't deviate from established patterns without discussion
|
||||
|
||||
---
|
||||
|
||||
*This skill was auto-generated by [ECC Tools](https://ecc.tools). Review and customize as needed for your team.*
|
||||
|
||||
15
.claude/team/everything-claude-code-team-config.json
Normal file
@@ -0,0 +1,15 @@
|
||||
{
|
||||
"version": "1.0",
|
||||
"generatedBy": "ecc-tools",
|
||||
"profile": "full",
|
||||
"sharedSkills": [
|
||||
".claude/skills/everything-claude-code/SKILL.md",
|
||||
".agents/skills/everything-claude-code/SKILL.md"
|
||||
],
|
||||
"commandFiles": [
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
],
|
||||
"updatedAt": "2026-03-24T10:44:06.345Z"
|
||||
}
|
||||
@@ -46,6 +46,17 @@ Available skills:
|
||||
|
||||
Treat the project-local `.codex/config.toml` as the default Codex baseline for ECC. The current ECC baseline enables GitHub, Context7, Exa, Memory, Playwright, and Sequential Thinking; add heavier extras in `~/.codex/config.toml` only when a task actually needs them.
|
||||
|
||||
### Automatic config.toml merging
|
||||
|
||||
The sync script (`scripts/sync-ecc-to-codex.sh`) uses a Node-based TOML parser to safely merge ECC MCP servers into `~/.codex/config.toml`:
|
||||
|
||||
- **Add-only by default** — missing ECC servers are appended; existing servers are never modified or removed.
|
||||
- **7 managed servers** — Supabase, Playwright, Context7, Exa, GitHub, Memory, Sequential Thinking.
|
||||
- **Package-manager aware** — uses the project's configured package manager (npm/pnpm/yarn/bun) instead of hardcoding `pnpm`.
|
||||
- **Drift warnings** — if an existing server's config differs from the ECC recommendation, the script logs a warning.
|
||||
- **`--update-mcp`** — explicitly replaces all ECC-managed servers with the latest recommended config (safely removes subtables like `[mcp_servers.supabase.env]`).
|
||||
- **User config is always preserved** — custom servers, args, env vars, and credentials outside ECC-managed sections are never touched.
|
||||
|
||||
## Multi-Agent Support
|
||||
|
||||
Codex now supports multi-agent workflows behind the experimental `features.multi_agent` flag.
|
||||
|
||||
@@ -6,4 +6,4 @@ developer_instructions = """
|
||||
Verify APIs, framework behavior, and release-note claims against primary documentation before changes land.
|
||||
Cite the exact docs or file paths that support each claim.
|
||||
Do not invent undocumented behavior.
|
||||
"""
|
||||
"""
|
||||
@@ -6,4 +6,4 @@ developer_instructions = """
|
||||
Stay in exploration mode.
|
||||
Trace the real execution path, cite files and symbols, and avoid proposing fixes unless the parent agent asks for them.
|
||||
Prefer targeted search and file reads over broad scans.
|
||||
"""
|
||||
"""
|
||||
@@ -6,4 +6,4 @@ developer_instructions = """
|
||||
Review like an owner.
|
||||
Prioritize correctness, security, behavioral regressions, and missing tests.
|
||||
Lead with concrete findings and avoid style-only feedback unless it hides a real bug.
|
||||
"""
|
||||
"""
|
||||
@@ -15,6 +15,11 @@
|
||||
}
|
||||
],
|
||||
"beforeShellExecution": [
|
||||
{
|
||||
"command": "npx block-no-verify@1.1.2",
|
||||
"event": "beforeShellExecution",
|
||||
"description": "Block git hook-bypass flag to protect pre-commit, commit-msg, and pre-push hooks from being skipped"
|
||||
},
|
||||
{
|
||||
"command": "node .cursor/hooks/before-shell-execution.js",
|
||||
"event": "beforeShellExecution",
|
||||
|
||||
4
.gitignore
vendored
@@ -83,7 +83,11 @@ temp/
|
||||
*.bak
|
||||
*.backup
|
||||
|
||||
# Rust build artifacts
|
||||
ecc2/target/
|
||||
|
||||
# Bootstrap pipeline outputs
|
||||
# Generated lock files in tool subdirectories
|
||||
.opencode/package-lock.json
|
||||
.opencode/node_modules/
|
||||
assets/images/security/badrudi-exploit.mp4
|
||||
|
||||
@@ -77,7 +77,7 @@ export const ECCHooksPlugin = async ({
|
||||
editedFiles.add(event.path)
|
||||
|
||||
// Auto-format JS/TS files
|
||||
if (hookEnabled("post:edit:format", ["standard", "strict"]) && event.path.match(/\.(ts|tsx|js|jsx)$/)) {
|
||||
if (hookEnabled("post:edit:format", ["strict"]) && event.path.match(/\.(ts|tsx|js|jsx)$/)) {
|
||||
try {
|
||||
await $`prettier --write ${event.path} 2>/dev/null`
|
||||
log("info", `[ECC] Formatted: ${event.path}`)
|
||||
@@ -116,7 +116,7 @@ export const ECCHooksPlugin = async ({
|
||||
) => {
|
||||
// Check if a TypeScript file was edited
|
||||
if (
|
||||
hookEnabled("post:edit:typecheck", ["standard", "strict"]) &&
|
||||
hookEnabled("post:edit:typecheck", ["strict"]) &&
|
||||
input.tool === "edit" &&
|
||||
input.args?.filePath?.match(/\.tsx?$/)
|
||||
) {
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — Agent Instructions
|
||||
|
||||
This is a **production-ready AI coding plugin** providing 27 specialized agents, 109 skills, 57 commands, and automated hook workflows for software development.
|
||||
This is a **production-ready AI coding plugin** providing 28 specialized agents, 116 skills, 60 commands, and automated hook workflows for software development.
|
||||
|
||||
**Version:** 1.9.0
|
||||
|
||||
@@ -141,9 +141,9 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
agents/ — 27 specialized subagents
|
||||
skills/ — 109 workflow skills and domain knowledge
|
||||
commands/ — 57 slash commands
|
||||
agents/ — 28 specialized subagents
|
||||
skills/ — 115 workflow skills and domain knowledge
|
||||
commands/ — 60 slash commands
|
||||
hooks/ — Trigger-based automations
|
||||
rules/ — Always-follow guidelines (common + per-language)
|
||||
scripts/ — Cross-platform Node.js utilities
|
||||
|
||||
@@ -47,6 +47,7 @@ The project is organized into several core components:
|
||||
- Cross-platform: Windows, macOS, Linux support via Node.js scripts
|
||||
- Agent format: Markdown with YAML frontmatter (name, description, tools, model)
|
||||
- Skill format: Markdown with clear sections for when to use, how it works, examples
|
||||
- Skill placement: Curated in skills/; generated/imported under ~/.claude/skills/. See docs/SKILL-PLACEMENT-POLICY.md
|
||||
- Hook format: JSON with matcher conditions and command/notification hooks
|
||||
|
||||
## Contributing
|
||||
|
||||
69
README.md
@@ -1,4 +1,6 @@
|
||||
**Language:** English | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md)
|
||||
**Language:** English | [Português (Brasil)](docs/pt-BR/README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md)
|
||||
[Türkçe](docs/tr/README.md)
|
||||
|
||||
|
||||
# Everything Claude Code
|
||||
|
||||
@@ -17,15 +19,16 @@
|
||||

|
||||

|
||||
|
||||
> **50K+ stars** | **6K+ forks** | **30 contributors** | **5 languages supported** | **Anthropic Hackathon Winner**
|
||||
> **50K+ stars** | **6K+ forks** | **30 contributors** | **7 languages supported** | **Anthropic Hackathon Winner**
|
||||
|
||||
---
|
||||
|
||||
<div align="center">
|
||||
|
||||
**🌐 Language / 语言 / 語言**
|
||||
**🌐 Language / 语言 / 語言 / Dil**
|
||||
|
||||
[**English**](README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md)
|
||||
[**English**](README.md) | [Português (Brasil)](docs/pt-BR/README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md)
|
||||
| [Türkçe](docs/tr/README.md)
|
||||
|
||||
</div>
|
||||
|
||||
@@ -45,20 +48,26 @@ This repo is the raw code only. The guides explain everything.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td width="50%">
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2012378465664745795">
|
||||
<img src="https://github.com/user-attachments/assets/1a471488-59cc-425b-8345-5245c7efbcef" alt="The Shorthand Guide to Everything Claude Code" />
|
||||
<img src="./assets/images/guides/shorthand-guide.png" alt="The Shorthand Guide to Everything Claude Code" />
|
||||
</a>
|
||||
</td>
|
||||
<td width="50%">
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2014040193557471352">
|
||||
<img src="https://github.com/user-attachments/assets/c9ca43bc-b149-427f-b551-af6840c368f0" alt="The Longform Guide to Everything Claude Code" />
|
||||
<img src="./assets/images/guides/longform-guide.png" alt="The Longform Guide to Everything Claude Code" />
|
||||
</a>
|
||||
</td>
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2033263813387223421">
|
||||
<img src="./assets/images/security/security-guide-header.png" alt="The Shorthand Guide to Everything Agentic Security" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="center"><b>Shorthand Guide</b><br/>Setup, foundations, philosophy. <b>Read this first.</b></td>
|
||||
<td align="center"><b>Longform Guide</b><br/>Token optimization, memory persistence, evals, parallelization.</td>
|
||||
<td align="center"><b>Security Guide</b><br/>Attack vectors, sandboxing, sanitization, CVEs, AgentShield.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@@ -84,7 +93,7 @@ This repo is the raw code only. The guides explain everything.
|
||||
- **Orchestration overhaul** — Harness audit scoring made deterministic, orchestration status and launcher compatibility hardened, observer loop prevention with 5-layer guard.
|
||||
- **Observer reliability** — Memory explosion fix with throttling and tail sampling, sandbox access fix, lazy-start logic, and re-entrancy guard.
|
||||
- **12 language ecosystems** — New rules for Java, PHP, Perl, Kotlin/Android/KMP, C++, and Rust join existing TypeScript, Python, Go, and common rules.
|
||||
- **Community contributions** — Korean and Chinese translations, InsAIts security hook, biome hook optimization, VideoDB skills, Evos operational skills, PowerShell installer, Antigravity IDE support.
|
||||
- **Community contributions** — Korean and Chinese translations, security hook, biome hook optimization, video processing skills, operational skills, PowerShell installer, Antigravity IDE support.
|
||||
- **CI hardening** — 19 test failure fixes, catalog count enforcement, install manifest validation, and full test suite green.
|
||||
|
||||
### v1.8.0 — Harness Performance System (Mar 2026)
|
||||
@@ -116,7 +125,7 @@ This repo is the raw code only. The guides explain everything.
|
||||
|
||||
### v1.4.1 — Bug Fix (Feb 2026)
|
||||
|
||||
- **Fixed instinct import content loss** — `parse_instinct_file()` was silently dropping all content after frontmatter (Action, Evidence, Examples sections) during `/instinct-import`. Fixed by community contributor @ericcai0814 ([#148](https://github.com/affaan-m/everything-claude-code/issues/148), [#161](https://github.com/affaan-m/everything-claude-code/pull/161))
|
||||
- **Fixed instinct import content loss** — `parse_instinct_file()` was silently dropping all content after frontmatter (Action, Evidence, Examples sections) during `/instinct-import`. ([#148](https://github.com/affaan-m/everything-claude-code/issues/148), [#161](https://github.com/affaan-m/everything-claude-code/pull/161))
|
||||
|
||||
### v1.4.0 — Multi-Language Rules, Installation Wizard & PM2 (Feb 2026)
|
||||
|
||||
@@ -203,7 +212,7 @@ For manual install instructions see the README in the `rules/` folder.
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
✨ **That's it!** You now have access to 27 agents, 109 skills, and 57 commands.
|
||||
✨ **That's it!** You now have access to 28 agents, 116 skills, and 60 commands.
|
||||
|
||||
---
|
||||
|
||||
@@ -264,7 +273,7 @@ everything-claude-code/
|
||||
| |-- plugin.json # Plugin metadata and component paths
|
||||
| |-- marketplace.json # Marketplace catalog for /plugin marketplace add
|
||||
|
|
||||
|-- agents/ # 27 specialized subagents for delegation
|
||||
|-- agents/ # 28 specialized subagents for delegation
|
||||
| |-- planner.md # Feature implementation planning
|
||||
| |-- architect.md # System design decisions
|
||||
| |-- tdd-guide.md # Test-driven development
|
||||
@@ -379,6 +388,7 @@ everything-claude-code/
|
||||
| |-- instinct-import.md # /instinct-import - Import instincts (NEW)
|
||||
| |-- instinct-export.md # /instinct-export - Export instincts (NEW)
|
||||
| |-- evolve.md # /evolve - Cluster instincts into skills
|
||||
| |-- prune.md # /prune - Delete expired pending instincts (NEW)
|
||||
| |-- pm2.md # /pm2 - PM2 service lifecycle management (NEW)
|
||||
| |-- multi-plan.md # /multi-plan - Multi-agent task decomposition (NEW)
|
||||
| |-- multi-execute.md # /multi-execute - Orchestrated multi-agent workflows (NEW)
|
||||
@@ -520,10 +530,6 @@ Use `/security-scan` in Claude Code to run it, or add to CI with the [GitHub Act
|
||||
|
||||
[GitHub](https://github.com/affaan-m/agentshield) | [npm](https://www.npmjs.com/package/ecc-agentshield)
|
||||
|
||||
### 🔬 Plankton — Write-Time Code Quality Enforcement
|
||||
|
||||
Plankton (credit: @alxfazio) is a recommended companion for write-time code quality enforcement. It runs formatters and 20+ linters on every file edit via PostToolUse hooks, then spawns Claude subprocesses (routed to Haiku/Sonnet/Opus by violation complexity) to fix issues the main agent missed. Three-phase architecture: auto-format silently (40-50% of issues), collect remaining violations as structured JSON, delegate fixes to a subprocess. Includes config protection hooks that prevent agents from modifying linter configs to pass instead of fixing code. Supports Python, TypeScript, Shell, YAML, JSON, TOML, Markdown, and Dockerfile. Use alongside AgentShield for security + quality coverage. See `skills/plankton-code-quality/` for full integration guide.
|
||||
|
||||
### 🧠 Continuous Learning v2
|
||||
|
||||
The instinct-based learning system automatically learns your patterns:
|
||||
@@ -981,10 +987,18 @@ ECC provides **first-class Codex support** for both the macOS app and CLI, with
|
||||
# Run Codex CLI in the repo — AGENTS.md and .codex/ are auto-detected
|
||||
codex
|
||||
|
||||
# Optional: copy the global-safe defaults to your home directory
|
||||
# Automatic setup: sync ECC assets (AGENTS.md, skills, MCP servers) into ~/.codex
|
||||
npm install && bash scripts/sync-ecc-to-codex.sh
|
||||
# or: pnpm install && bash scripts/sync-ecc-to-codex.sh
|
||||
# or: yarn install && bash scripts/sync-ecc-to-codex.sh
|
||||
# or: bun install && bash scripts/sync-ecc-to-codex.sh
|
||||
|
||||
# Or manually: copy the reference config to your home directory
|
||||
cp .codex/config.toml ~/.codex/config.toml
|
||||
```
|
||||
|
||||
The sync script safely merges ECC MCP servers into your existing `~/.codex/config.toml` using an **add-only** strategy — it never removes or modifies your existing servers. Run with `--dry-run` to preview changes, or `--update-mcp` to force-refresh ECC servers to the latest recommended config.
|
||||
|
||||
Codex macOS app:
|
||||
- Open this repository as your workspace.
|
||||
- The root `AGENTS.md` is auto-detected.
|
||||
@@ -999,7 +1013,7 @@ Codex macOS app:
|
||||
| Config | 1 | `.codex/config.toml` — top-level approvals/sandbox/web_search, MCP servers, notifications, profiles |
|
||||
| AGENTS.md | 2 | Root (universal) + `.codex/AGENTS.md` (Codex-specific supplement) |
|
||||
| Skills | 16 | `.agents/skills/` — SKILL.md + agents/openai.yaml per skill |
|
||||
| MCP Servers | 4 | GitHub, Context7, Memory, Sequential Thinking (command-based) |
|
||||
| MCP Servers | 6 | Supabase, Playwright, Context7, GitHub, Memory, Sequential Thinking (auto-merged via add-only sync) |
|
||||
| Profiles | 2 | `strict` (read-only sandbox) and `yolo` (full auto-approve) |
|
||||
| Agent Roles | 3 | `.codex/agents/` — explorer, reviewer, docs-researcher |
|
||||
|
||||
@@ -1069,9 +1083,9 @@ The configuration is automatically detected from `.opencode/opencode.json`.
|
||||
|
||||
| Feature | Claude Code | OpenCode | Status |
|
||||
|---------|-------------|----------|--------|
|
||||
| Agents | ✅ 27 agents | ✅ 12 agents | **Claude Code leads** |
|
||||
| Commands | ✅ 57 commands | ✅ 31 commands | **Claude Code leads** |
|
||||
| Skills | ✅ 109 skills | ✅ 37 skills | **Claude Code leads** |
|
||||
| Agents | ✅ 28 agents | ✅ 12 agents | **Claude Code leads** |
|
||||
| Commands | ✅ 60 commands | ✅ 31 commands | **Claude Code leads** |
|
||||
| Skills | ✅ 116 skills | ✅ 37 skills | **Claude Code leads** |
|
||||
| Hooks | ✅ 8 event types | ✅ 11 events | **OpenCode has more!** |
|
||||
| Rules | ✅ 29 rules | ✅ 13 instructions | **Claude Code leads** |
|
||||
| MCP Servers | ✅ 14 servers | ✅ Full | **Full parity** |
|
||||
@@ -1127,6 +1141,7 @@ OpenCode's plugin system is MORE sophisticated than Claude Code with 20+ event t
|
||||
| `/evolve` | Cluster instincts into skills |
|
||||
| `/promote` | Promote project instincts to global scope |
|
||||
| `/projects` | List known projects and instinct stats |
|
||||
| `/prune` | Delete expired pending instincts (30d TTL) |
|
||||
| `/learn-eval` | Extract and evaluate patterns before saving |
|
||||
| `/setup-pm` | Configure package manager |
|
||||
| `/harness-audit` | Audit harness reliability, eval readiness, and risk posture |
|
||||
@@ -1184,7 +1199,7 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
|
||||
| **Hook Scripts** | 20+ scripts | 16 scripts (DRY adapter) | N/A | Plugin hooks |
|
||||
| **Rules** | 34 (common + lang) | 34 (YAML frontmatter) | Instruction-based | 13 instructions |
|
||||
| **Custom Tools** | Via hooks | Via hooks | N/A | 6 native tools |
|
||||
| **MCP Servers** | 14 | Shared (mcp.json) | 4 (command-based) | Full |
|
||||
| **MCP Servers** | 14 | Shared (mcp.json) | 7 (auto-merged via TOML parser) | Full |
|
||||
| **Config Format** | settings.json | hooks.json + rules/ | config.toml | opencode.json |
|
||||
| **Context File** | CLAUDE.md + AGENTS.md | AGENTS.md | AGENTS.md | AGENTS.md |
|
||||
| **Secret Detection** | Hook-based | beforeSubmitPrompt hook | Sandbox-based | Hook-based |
|
||||
@@ -1201,15 +1216,10 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
|
||||
|
||||
## 📖 Background
|
||||
|
||||
I've been using Claude Code since the experimental rollout. Won the Anthropic x Forum Ventures hackathon in Sep 2025 building [zenith.chat](https://zenith.chat) with [@DRodriguezFX](https://x.com/DRodriguezFX) - entirely using Claude Code.
|
||||
I've been using Claude Code since the experimental rollout. Won the Anthropic x Forum Ventures hackathon in Sep 2025 with [@DRodriguezFX](https://x.com/DRodriguezFX) — built [zenith.chat](https://zenith.chat) entirely using Claude Code.
|
||||
|
||||
These configs are battle-tested across multiple production applications.
|
||||
|
||||
## Inspiration Credits
|
||||
|
||||
- inspired by [zarazhangrui](https://github.com/zarazhangrui)
|
||||
- homunculus-inspired by [humanplane](https://github.com/humanplane)
|
||||
|
||||
---
|
||||
|
||||
## Token Optimization
|
||||
@@ -1328,9 +1338,8 @@ This project is free and open source. Sponsors help keep it maintained and growi
|
||||
|
||||
- **Shorthand Guide (Start Here):** [The Shorthand Guide to Everything Claude Code](https://x.com/affaanmustafa/status/2012378465664745795)
|
||||
- **Longform Guide (Advanced):** [The Longform Guide to Everything Claude Code](https://x.com/affaanmustafa/status/2014040193557471352)
|
||||
- **Security Guide:** [Security Guide](./the-security-guide.md) | [Thread](https://x.com/affaanmustafa/status/2033263813387223421)
|
||||
- **Follow:** [@affaanmustafa](https://x.com/affaanmustafa)
|
||||
- **zenith.chat:** [zenith.chat](https://zenith.chat)
|
||||
- **Skills Directory:** awesome-agent-skills (community-maintained directory of agent skills)
|
||||
|
||||
---
|
||||
|
||||
|
||||
53
SECURITY.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# Security Policy
|
||||
|
||||
## Supported Versions
|
||||
|
||||
| Version | Supported |
|
||||
| ------- | ------------------ |
|
||||
| 1.9.x | :white_check_mark: |
|
||||
| 1.8.x | :white_check_mark: |
|
||||
| < 1.8 | :x: |
|
||||
|
||||
## Reporting a Vulnerability
|
||||
|
||||
If you discover a security vulnerability in ECC, please report it responsibly.
|
||||
|
||||
**Do not open a public GitHub issue for security vulnerabilities.**
|
||||
|
||||
Instead, email **security@ecc.tools** with:
|
||||
|
||||
- A description of the vulnerability
|
||||
- Steps to reproduce
|
||||
- The affected version(s)
|
||||
- Any potential impact assessment
|
||||
|
||||
You can expect:
|
||||
|
||||
- **Acknowledgment** within 48 hours
|
||||
- **Status update** within 7 days
|
||||
- **Fix or mitigation** within 30 days for critical issues
|
||||
|
||||
If the vulnerability is accepted, we will:
|
||||
|
||||
- Credit you in the release notes (unless you prefer anonymity)
|
||||
- Fix the issue in a timely manner
|
||||
- Coordinate disclosure timing with you
|
||||
|
||||
If the vulnerability is declined, we will explain why and provide guidance on whether it should be reported elsewhere.
|
||||
|
||||
## Scope
|
||||
|
||||
This policy covers:
|
||||
|
||||
- The ECC plugin and all scripts in this repository
|
||||
- Hook scripts that execute on your machine
|
||||
- Install/uninstall/repair lifecycle scripts
|
||||
- MCP configurations shipped with ECC
|
||||
- The AgentShield security scanner ([github.com/affaan-m/agentshield](https://github.com/affaan-m/agentshield))
|
||||
|
||||
## Security Resources
|
||||
|
||||
- **AgentShield**: Scan your agent config for vulnerabilities — `npx ecc-agentshield scan`
|
||||
- **Security Guide**: [The Shorthand Guide to Everything Agentic Security](./the-security-guide.md)
|
||||
- **OWASP MCP Top 10**: [owasp.org/www-project-mcp-top-10](https://owasp.org/www-project-mcp-top-10/)
|
||||
- **OWASP Agentic Applications Top 10**: [genai.owasp.org](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)
|
||||
243
agents/flutter-reviewer.md
Normal file
@@ -0,0 +1,243 @@
|
||||
---
|
||||
name: flutter-reviewer
|
||||
description: Flutter and Dart code reviewer. Reviews Flutter code for widget best practices, state management patterns, Dart idioms, performance pitfalls, accessibility, and clean architecture violations. Library-agnostic — works with any state management solution and tooling.
|
||||
tools: ["Read", "Grep", "Glob", "Bash"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
You are a senior Flutter and Dart code reviewer ensuring idiomatic, performant, and maintainable code.
|
||||
|
||||
## Your Role
|
||||
|
||||
- Review Flutter/Dart code for idiomatic patterns and framework best practices
|
||||
- Detect state management anti-patterns and widget rebuild issues regardless of which solution is used
|
||||
- Enforce the project's chosen architecture boundaries
|
||||
- Identify performance, accessibility, and security issues
|
||||
- You DO NOT refactor or rewrite code — you report findings only
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Gather Context
|
||||
|
||||
Run `git diff --staged` and `git diff` to see changes. If no diff, check `git log --oneline -5`. Identify changed Dart files.
|
||||
|
||||
### Step 2: Understand Project Structure
|
||||
|
||||
Check for:
|
||||
- `pubspec.yaml` — dependencies and project type
|
||||
- `analysis_options.yaml` — lint rules
|
||||
- `CLAUDE.md` — project-specific conventions
|
||||
- Whether this is a monorepo (melos) or single-package project
|
||||
- **Identify the state management approach** (BLoC, Riverpod, Provider, GetX, MobX, Signals, or built-in). Adapt review to the chosen solution's conventions.
|
||||
- **Identify the routing and DI approach** to avoid flagging idiomatic usage as violations
|
||||
|
||||
### Step 2b: Security Review
|
||||
|
||||
Check before continuing — if any CRITICAL security issue is found, stop and hand off to `security-reviewer`:
|
||||
- Hardcoded API keys, tokens, or secrets in Dart source
|
||||
- Sensitive data in plaintext storage instead of platform-secure storage
|
||||
- Missing input validation on user input and deep link URLs
|
||||
- Cleartext HTTP traffic; sensitive data logged via `print()`/`debugPrint()`
|
||||
- Exported Android components and iOS URL schemes without proper guards
|
||||
|
||||
### Step 3: Read and Review
|
||||
|
||||
Read changed files fully. Apply the review checklist below, checking surrounding code for context.
|
||||
|
||||
### Step 4: Report Findings
|
||||
|
||||
Use the output format below. Only report issues with >80% confidence.
|
||||
|
||||
**Noise control:**
|
||||
- Consolidate similar issues (e.g. "5 widgets missing `const` constructors" not 5 separate findings)
|
||||
- Skip stylistic preferences unless they violate project conventions or cause functional issues
|
||||
- Only flag unchanged code for CRITICAL security issues
|
||||
- Prioritize bugs, security, data loss, and correctness over style
|
||||
|
||||
## Review Checklist
|
||||
|
||||
### Architecture (CRITICAL)
|
||||
|
||||
Adapt to the project's chosen architecture (Clean Architecture, MVVM, feature-first, etc.):
|
||||
|
||||
- **Business logic in widgets** — Complex logic belongs in a state management component, not in `build()` or callbacks
|
||||
- **Data models leaking across layers** — If the project separates DTOs and domain entities, they must be mapped at boundaries; if models are shared, review for consistency
|
||||
- **Cross-layer imports** — Imports must respect the project's layer boundaries; inner layers must not depend on outer layers
|
||||
- **Framework leaking into pure-Dart layers** — If the project has a domain/model layer intended to be framework-free, it must not import Flutter or platform code
|
||||
- **Circular dependencies** — Package A depends on B and B depends on A
|
||||
- **Private `src/` imports across packages** — Importing `package:other/src/internal.dart` breaks Dart package encapsulation
|
||||
- **Direct instantiation in business logic** — State managers should receive dependencies via injection, not construct them internally
|
||||
- **Missing abstractions at layer boundaries** — Concrete classes imported across layers instead of depending on interfaces
|
||||
|
||||
### State Management (CRITICAL)
|
||||
|
||||
**Universal (all solutions):**
|
||||
- **Boolean flag soup** — `isLoading`/`isError`/`hasData` as separate fields allows impossible states; use sealed types, union variants, or the solution's built-in async state type
|
||||
- **Non-exhaustive state handling** — All state variants must be handled exhaustively; unhandled variants silently break
|
||||
- **Single responsibility violated** — Avoid "god" managers handling unrelated concerns
|
||||
- **Direct API/DB calls from widgets** — Data access should go through a service/repository layer
|
||||
- **Subscribing in `build()`** — Never call `.listen()` inside build methods; use declarative builders
|
||||
- **Stream/subscription leaks** — All manual subscriptions must be cancelled in `dispose()`/`close()`
|
||||
- **Missing error/loading states** — Every async operation must model loading, success, and error distinctly
|
||||
|
||||
**Immutable-state solutions (BLoC, Riverpod, Redux):**
|
||||
- **Mutable state** — State must be immutable; create new instances via `copyWith`, never mutate in-place
|
||||
- **Missing value equality** — State classes must implement `==`/`hashCode` so the framework detects changes
|
||||
|
||||
**Reactive-mutation solutions (MobX, GetX, Signals):**
|
||||
- **Mutations outside reactivity API** — State must only change through `@action`, `.value`, `.obs`, etc.; direct mutation bypasses tracking
|
||||
- **Missing computed state** — Derivable values should use the solution's computed mechanism, not be stored redundantly
|
||||
|
||||
**Cross-component dependencies:**
|
||||
- In **Riverpod**, `ref.watch` between providers is expected — flag only circular or tangled chains
|
||||
- In **BLoC**, blocs should not directly depend on other blocs — prefer shared repositories
|
||||
- In other solutions, follow documented conventions for inter-component communication
|
||||
|
||||
### Widget Composition (HIGH)
|
||||
|
||||
- **Oversized `build()`** — Exceeding ~80 lines; extract subtrees to separate widget classes
|
||||
- **`_build*()` helper methods** — Private methods returning widgets prevent framework optimizations; extract to classes
|
||||
- **Missing `const` constructors** — Widgets with all-final fields must declare `const` to prevent unnecessary rebuilds
|
||||
- **Object allocation in parameters** — Inline `TextStyle(...)` without `const` causes rebuilds
|
||||
- **`StatefulWidget` overuse** — Prefer `StatelessWidget` when no mutable local state is needed
|
||||
- **Missing `key` in list items** — `ListView.builder` items without stable `ValueKey` cause state bugs
|
||||
- **Hardcoded colors/text styles** — Use `Theme.of(context).colorScheme`/`textTheme`; hardcoded styles break dark mode
|
||||
- **Hardcoded spacing** — Prefer design tokens or named constants over magic numbers
|
||||
|
||||
### Performance (HIGH)
|
||||
|
||||
- **Unnecessary rebuilds** — State consumers wrapping too much tree; scope narrow and use selectors
|
||||
- **Expensive work in `build()`** — Sorting, filtering, regex, or I/O in build; compute in the state layer
|
||||
- **`MediaQuery.of(context)` overuse** — Use specific accessors (`MediaQuery.sizeOf(context)`)
|
||||
- **Concrete list constructors for large data** — Use `ListView.builder`/`GridView.builder` for lazy construction
|
||||
- **Missing image optimization** — No caching, no `cacheWidth`/`cacheHeight`, full-res thumbnails
|
||||
- **`Opacity` in animations** — Use `AnimatedOpacity` or `FadeTransition`
|
||||
- **Missing `const` propagation** — `const` widgets stop rebuild propagation; use wherever possible
|
||||
- **`IntrinsicHeight`/`IntrinsicWidth` overuse** — Cause extra layout passes; avoid in scrollable lists
|
||||
- **`RepaintBoundary` missing** — Complex independently-repainting subtrees should be wrapped
|
||||
|
||||
### Dart Idioms (MEDIUM)
|
||||
|
||||
- **Missing type annotations / implicit `dynamic`** — Enable `strict-casts`, `strict-inference`, `strict-raw-types` to catch these
|
||||
- **`!` bang overuse** — Prefer `?.`, `??`, `case var v?`, or `requireNotNull`
|
||||
- **Broad exception catching** — `catch (e)` without `on` clause; specify exception types
|
||||
- **Catching `Error` subtypes** — `Error` indicates bugs, not recoverable conditions
|
||||
- **`var` where `final` works** — Prefer `final` for locals, `const` for compile-time constants
|
||||
- **Relative imports** — Use `package:` imports for consistency
|
||||
- **Missing Dart 3 patterns** — Prefer switch expressions and `if-case` over verbose `is` checks
|
||||
- **`print()` in production** — Use `dart:developer` `log()` or the project's logging package
|
||||
- **`late` overuse** — Prefer nullable types or constructor initialization
|
||||
- **Ignoring `Future` return values** — Use `await` or mark with `unawaited()`
|
||||
- **Unused `async`** — Functions marked `async` that never `await` add unnecessary overhead
|
||||
- **Mutable collections exposed** — Public APIs should return unmodifiable views
|
||||
- **String concatenation in loops** — Use `StringBuffer` for iterative building
|
||||
- **Mutable fields in `const` classes** — Fields in `const` constructor classes must be final
|
||||
|
||||
### Resource Lifecycle (HIGH)
|
||||
|
||||
- **Missing `dispose()`** — Every resource from `initState()` (controllers, subscriptions, timers) must be disposed
|
||||
- **`BuildContext` used after `await`** — Check `context.mounted` (Flutter 3.7+) before navigation/dialogs after async gaps
|
||||
- **`setState` after `dispose`** — Async callbacks must check `mounted` before calling `setState`
|
||||
- **`BuildContext` stored in long-lived objects** — Never store context in singletons or static fields
|
||||
- **Unclosed `StreamController`** / **`Timer` not cancelled** — Must be cleaned up in `dispose()`
|
||||
- **Duplicated lifecycle logic** — Identical init/dispose blocks should be extracted to reusable patterns
|
||||
|
||||
### Error Handling (HIGH)
|
||||
|
||||
- **Missing global error capture** — Both `FlutterError.onError` and `PlatformDispatcher.instance.onError` must be set
|
||||
- **No error reporting service** — Crashlytics/Sentry or equivalent should be integrated with non-fatal reporting
|
||||
- **Missing state management error observer** — Wire errors to reporting (BlocObserver, ProviderObserver, etc.)
|
||||
- **Red screen in production** — `ErrorWidget.builder` not customized for release mode
|
||||
- **Raw exceptions reaching UI** — Map to user-friendly, localized messages before presentation layer
|
||||
|
||||
### Testing (HIGH)
|
||||
|
||||
- **Missing unit tests** — State manager changes must have corresponding tests
|
||||
- **Missing widget tests** — New/changed widgets should have widget tests
|
||||
- **Missing golden tests** — Design-critical components should have pixel-perfect regression tests
|
||||
- **Untested state transitions** — All paths (loading→success, loading→error, retry, empty) must be tested
|
||||
- **Test isolation violated** — External dependencies must be mocked; no shared mutable state between tests
|
||||
- **Flaky async tests** — Use `pumpAndSettle` or explicit `pump(Duration)`, not timing assumptions
|
||||
|
||||
### Accessibility (MEDIUM)
|
||||
|
||||
- **Missing semantic labels** — Images without `semanticLabel`, icons without `tooltip`
|
||||
- **Small tap targets** — Interactive elements below 48x48 pixels
|
||||
- **Color-only indicators** — Color alone conveying meaning without icon/text alternative
|
||||
- **Missing `ExcludeSemantics`/`MergeSemantics`** — Decorative elements and related widget groups need proper semantics
|
||||
- **Text scaling ignored** — Hardcoded sizes that don't respect system accessibility settings
|
||||
|
||||
### Platform, Responsive & Navigation (MEDIUM)
|
||||
|
||||
- **Missing `SafeArea`** — Content obscured by notches/status bars
|
||||
- **Broken back navigation** — Android back button or iOS swipe-to-go-back not working as expected
|
||||
- **Missing platform permissions** — Required permissions not declared in `AndroidManifest.xml` or `Info.plist`
|
||||
- **No responsive layout** — Fixed layouts that break on tablets/desktops/landscape
|
||||
- **Text overflow** — Unbounded text without `Flexible`/`Expanded`/`FittedBox`
|
||||
- **Mixed navigation patterns** — `Navigator.push` mixed with declarative router; pick one
|
||||
- **Hardcoded route paths** — Use constants, enums, or generated routes
|
||||
- **Missing deep link validation** — URLs not sanitized before navigation
|
||||
- **Missing auth guards** — Protected routes accessible without redirect
|
||||
|
||||
### Internationalization (MEDIUM)
|
||||
|
||||
- **Hardcoded user-facing strings** — All visible text must use a localization system
|
||||
- **String concatenation for localized text** — Use parameterized messages
|
||||
- **Locale-unaware formatting** — Dates, numbers, currencies must use locale-aware formatters
|
||||
|
||||
### Dependencies & Build (LOW)
|
||||
|
||||
- **No strict static analysis** — Project should have strict `analysis_options.yaml`
|
||||
- **Stale/unused dependencies** — Run `flutter pub outdated`; remove unused packages
|
||||
- **Dependency overrides in production** — Only with comment linking to tracking issue
|
||||
- **Unjustified lint suppressions** — `// ignore:` without explanatory comment
|
||||
- **Hardcoded path deps in monorepo** — Use workspace resolution, not `path: ../../`
|
||||
|
||||
### Security (CRITICAL)
|
||||
|
||||
- **Hardcoded secrets** — API keys, tokens, or credentials in Dart source
|
||||
- **Insecure storage** — Sensitive data in plaintext instead of Keychain/EncryptedSharedPreferences
|
||||
- **Cleartext traffic** — HTTP without HTTPS; missing network security config
|
||||
- **Sensitive logging** — Tokens, PII, or credentials in `print()`/`debugPrint()`
|
||||
- **Missing input validation** — User input passed to APIs/navigation without sanitization
|
||||
- **Unsafe deep links** — Handlers that act without validation
|
||||
|
||||
If any CRITICAL security issue is present, stop and escalate to `security-reviewer`.
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
[CRITICAL] Domain layer imports Flutter framework
|
||||
File: packages/domain/lib/src/usecases/user_usecase.dart:3
|
||||
Issue: `import 'package:flutter/material.dart'` — domain must be pure Dart.
|
||||
Fix: Move widget-dependent logic to presentation layer.
|
||||
|
||||
[HIGH] State consumer wraps entire screen
|
||||
File: lib/features/cart/presentation/cart_page.dart:42
|
||||
Issue: Consumer rebuilds entire page on every state change.
|
||||
Fix: Narrow scope to the subtree that depends on changed state, or use a selector.
|
||||
```
|
||||
|
||||
## Summary Format
|
||||
|
||||
End every review with:
|
||||
|
||||
```
|
||||
## Review Summary
|
||||
|
||||
| Severity | Count | Status |
|
||||
|----------|-------|--------|
|
||||
| CRITICAL | 0 | pass |
|
||||
| HIGH | 1 | block |
|
||||
| MEDIUM | 2 | info |
|
||||
| LOW | 0 | note |
|
||||
|
||||
Verdict: BLOCK — HIGH issues must be fixed before merge.
|
||||
```
|
||||
|
||||
## Approval Criteria
|
||||
|
||||
- **Approve**: No CRITICAL or HIGH issues
|
||||
- **Block**: Any CRITICAL or HIGH issues — must fix before merge
|
||||
|
||||
Refer to the `flutter-dart-code-review` skill for the comprehensive review checklist.
|
||||
BIN
assets/images/guides/longform-guide.png
Normal file
|
After Width: | Height: | Size: 676 KiB |
BIN
assets/images/guides/shorthand-guide.png
Normal file
|
After Width: | Height: | Size: 514 KiB |
BIN
assets/images/security/attack-chain.png
Normal file
|
After Width: | Height: | Size: 950 KiB |
BIN
assets/images/security/attack-vectors.png
Normal file
|
After Width: | Height: | Size: 950 KiB |
BIN
assets/images/security/ghostyy-overflow.jpeg
Normal file
|
After Width: | Height: | Size: 338 KiB |
BIN
assets/images/security/observability.png
Normal file
|
After Width: | Height: | Size: 1.3 MiB |
BIN
assets/images/security/sandboxing-brain.png
Normal file
|
After Width: | Height: | Size: 82 KiB |
BIN
assets/images/security/sandboxing-comparison.png
Normal file
|
After Width: | Height: | Size: 1.0 MiB |
BIN
assets/images/security/sandboxing.png
Normal file
|
After Width: | Height: | Size: 1.0 MiB |
BIN
assets/images/security/sanitization-utility.png
Normal file
|
After Width: | Height: | Size: 389 KiB |
BIN
assets/images/security/sanitization.png
Normal file
|
After Width: | Height: | Size: 1.0 MiB |
BIN
assets/images/security/security-guide-header.png
Normal file
|
After Width: | Height: | Size: 657 KiB |
31
commands/prune.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: prune
|
||||
description: Delete pending instincts older than 30 days that were never promoted
|
||||
command: true
|
||||
---
|
||||
|
||||
# Prune Pending Instincts
|
||||
|
||||
Remove expired pending instincts that were auto-generated but never reviewed or promoted.
|
||||
|
||||
## Implementation
|
||||
|
||||
Run the instinct CLI using the plugin root path:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" prune
|
||||
```
|
||||
|
||||
Or if `CLAUDE_PLUGIN_ROOT` is not set (manual installation):
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py prune
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/prune # Delete instincts older than 30 days
|
||||
/prune --max-age 60 # Custom age threshold (days)
|
||||
/prune --dry-run # Preview without deleting
|
||||
```
|
||||
11
commands/rules-distill.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
description: "Scan skills to extract cross-cutting principles and distill them into rules"
|
||||
---
|
||||
|
||||
# /rules-distill — Distill Principles from Skills into Rules
|
||||
|
||||
Scan installed skills, extract cross-cutting principles, and distill them into rules.
|
||||
|
||||
## Process
|
||||
|
||||
Follow the full workflow defined in the `rules-distill` skill.
|
||||
@@ -29,8 +29,8 @@ Use `/sessions info` when you need operator-surface context for a swarm: branch,
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-manager');
|
||||
const aa = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-aliases');
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
const path = require('path');
|
||||
|
||||
const result = sm.getAllSessions({ limit: 20 });
|
||||
@@ -70,8 +70,8 @@ Load and display a session's content (by ID or alias).
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-manager');
|
||||
const aa = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-aliases');
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
const id = process.argv[1];
|
||||
|
||||
// First try to resolve as alias
|
||||
@@ -143,8 +143,8 @@ Create a memorable alias for a session.
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-manager');
|
||||
const aa = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-aliases');
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const sessionId = process.argv[1];
|
||||
const aliasName = process.argv[2];
|
||||
@@ -183,7 +183,7 @@ Delete an existing alias.
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const aa = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-aliases');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const aliasName = process.argv[1];
|
||||
if (!aliasName) {
|
||||
@@ -212,8 +212,8 @@ Show detailed information about a session.
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-manager');
|
||||
const aa = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-aliases');
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const id = process.argv[1];
|
||||
const resolved = aa.resolveAlias(id);
|
||||
@@ -262,7 +262,7 @@ Show all session aliases.
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const aa = require((process.env.CLAUDE_PLUGIN_ROOT||require('path').join(require('os').homedir(),'.claude'))+'/scripts/lib/session-aliases');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const aliases = aa.listAliases();
|
||||
console.log('Session Aliases (' + aliases.length + '):');
|
||||
|
||||
@@ -13,19 +13,22 @@ Shows a comprehensive health dashboard for all skills in the portfolio with succ
|
||||
Run the skill health CLI in dashboard mode:
|
||||
|
||||
```bash
|
||||
node "${CLAUDE_PLUGIN_ROOT}/scripts/skills-health.js" --dashboard
|
||||
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
|
||||
node "$ECC_ROOT/scripts/skills-health.js" --dashboard
|
||||
```
|
||||
|
||||
For a specific panel only:
|
||||
|
||||
```bash
|
||||
node "${CLAUDE_PLUGIN_ROOT}/scripts/skills-health.js" --dashboard --panel failures
|
||||
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
|
||||
node "$ECC_ROOT/scripts/skills-health.js" --dashboard --panel failures
|
||||
```
|
||||
|
||||
For machine-readable output:
|
||||
|
||||
```bash
|
||||
node "${CLAUDE_PLUGIN_ROOT}/scripts/skills-health.js" --dashboard --json
|
||||
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
|
||||
node "$ECC_ROOT/scripts/skills-health.js" --dashboard --json
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
@@ -42,6 +42,7 @@ Every adapter MUST return a JSON-serializable object with this top-level shape:
|
||||
"id": "seed-check",
|
||||
"label": "seed-check",
|
||||
"state": "running",
|
||||
"health": "healthy",
|
||||
"branch": "feature/seed-check",
|
||||
"worktree": "/tmp/worktree",
|
||||
"runtime": {
|
||||
@@ -71,6 +72,9 @@ Every adapter MUST return a JSON-serializable object with this top-level shape:
|
||||
"workerCount": 1,
|
||||
"states": {
|
||||
"running": 1
|
||||
},
|
||||
"healths": {
|
||||
"healthy": 1
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -110,7 +114,8 @@ Every adapter MUST return a JSON-serializable object with this top-level shape:
|
||||
| --- | --- | --- |
|
||||
| `id` | string | Stable worker identifier in adapter scope |
|
||||
| `label` | string | Operator-facing label |
|
||||
| `state` | string | Canonical worker state |
|
||||
| `state` | string | Canonical worker state (lifecycle) |
|
||||
| `health` | string | Canonical worker health (operational condition) |
|
||||
| `runtime` | object | Execution/runtime metadata |
|
||||
| `intent` | object | Why this worker/session exists |
|
||||
| `outputs` | object | Structured outcomes and checks |
|
||||
@@ -145,6 +150,7 @@ Every adapter MUST return a JSON-serializable object with this top-level shape:
|
||||
| --- | --- | --- |
|
||||
| `workerCount` | integer | MUST equal `workers.length` |
|
||||
| `states` | object | Count map derived from `workers[].state` |
|
||||
| `healths` | object | Count map derived from `workers[].health` |
|
||||
|
||||
## Optional Fields
|
||||
|
||||
@@ -189,6 +195,7 @@ degrade gracefully.
|
||||
- adding new optional nested fields
|
||||
- adding new adapter ids
|
||||
- adding new state string values
|
||||
- adding new health string values
|
||||
- adding new artifact keys inside `workers[].artifacts`
|
||||
|
||||
### Requires a new schema version
|
||||
@@ -214,6 +221,7 @@ Every ECC session adapter MUST:
|
||||
documented nested objects.
|
||||
5. Ensure `aggregates.workerCount === workers.length`.
|
||||
6. Ensure `aggregates.states` matches the emitted worker states.
|
||||
7. Ensure `aggregates.healths` matches the emitted worker health values.
|
||||
7. Produce plain JSON-serializable values only.
|
||||
8. Validate the canonical shape before persistence or downstream use.
|
||||
9. Persist the normalized canonical snapshot through the session recording shim.
|
||||
|
||||
104
docs/SKILL-PLACEMENT-POLICY.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# Skill Placement and Provenance Policy
|
||||
|
||||
This document defines where generated, imported, and curated skills belong, how they are identified, and what gets shipped.
|
||||
|
||||
## Skill Types and Placement
|
||||
|
||||
| Type | Root Path | Shipped | Provenance |
|
||||
|------|-----------|---------|------------|
|
||||
| Curated | `skills/` (repo) | Yes | Not required |
|
||||
| Learned | `~/.claude/skills/learned/` | No | Required |
|
||||
| Imported | `~/.claude/skills/imported/` | No | Required |
|
||||
| Evolved | `~/.claude/homunculus/evolved/skills/` (global) or `projects/<hash>/evolved/skills/` (per-project) | No | Inherits from instinct source |
|
||||
|
||||
Curated skills live in the repo under `skills/`. Install manifests reference only curated paths. Generated and imported skills live under the user home directory and are never shipped.
|
||||
|
||||
## Curated Skills
|
||||
|
||||
Location: `skills/<skill-name>/` with `SKILL.md` at root.
|
||||
|
||||
- Included in `manifests/install-modules.json` paths.
|
||||
- Validated by `scripts/ci/validate-skills.js`.
|
||||
- No provenance file. Use `origin` in SKILL.md frontmatter (ECC, community) for attribution.
|
||||
|
||||
## Learned Skills
|
||||
|
||||
Location: `~/.claude/skills/learned/<skill-name>/`.
|
||||
|
||||
Created by continuous-learning (evaluate-session hook, /learn command). Default path is configurable via `skills/continuous-learning/config.json` → `learned_skills_path`.
|
||||
|
||||
- Not in repo. Not shipped.
|
||||
- Must have `.provenance.json` sibling to `SKILL.md`.
|
||||
- Loaded at runtime when directory exists.
|
||||
|
||||
## Imported Skills
|
||||
|
||||
Location: `~/.claude/skills/imported/<skill-name>/`.
|
||||
|
||||
User-installed skills from external sources (URL, file copy, etc.). No automated importer exists yet; placement is by convention.
|
||||
|
||||
- Not in repo. Not shipped.
|
||||
- Must have `.provenance.json` sibling to `SKILL.md`.
|
||||
|
||||
## Evolved Skills (Continuous Learning v2)
|
||||
|
||||
Location: `~/.claude/homunculus/evolved/skills/` (global) or `~/.claude/homunculus/projects/<hash>/evolved/skills/` (per-project).
|
||||
|
||||
Generated by instinct-cli evolve from clustered instincts. Separate system from learned/imported.
|
||||
|
||||
- Not in repo. Not shipped.
|
||||
- Provenance inherited from source instincts; no separate `.provenance.json` required.
|
||||
|
||||
## Provenance Metadata
|
||||
|
||||
Required for learned and imported skills. File: `.provenance.json` in the skill directory.
|
||||
|
||||
Required fields:
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| source | string | Origin (URL, path, or identifier) |
|
||||
| created_at | string | ISO 8601 timestamp |
|
||||
| confidence | number | 0–1 |
|
||||
| author | string | Who or what produced the skill |
|
||||
|
||||
Schema: `schemas/provenance.schema.json`. Validation: `scripts/lib/skill-evolution/provenance.js` → `validateProvenance`.
|
||||
|
||||
## Validator Behavior
|
||||
|
||||
### validate-skills.js
|
||||
|
||||
Scope: Curated skills only (`skills/` in repo).
|
||||
|
||||
- If `skills/` does not exist: exit 0 (nothing to validate).
|
||||
- For each subdirectory: must contain `SKILL.md`, non-empty.
|
||||
- Does not touch learned/imported/evolved roots.
|
||||
|
||||
### validate-install-manifests.js
|
||||
|
||||
Scope: Curated paths only. All `paths` in modules must exist in the repo.
|
||||
|
||||
- Generated/imported roots are out of scope. No manifest references them.
|
||||
- Missing path → error. No optional-path handling.
|
||||
|
||||
### Scripts That Use Generated Roots
|
||||
|
||||
`scripts/skills-health.js`, `scripts/lib/skill-evolution/health.js`, session hooks: they probe `~/.claude/skills/learned` and `~/.claude/skills/imported`. Missing directories are treated as empty; no errors.
|
||||
|
||||
## Publishable vs Local-Only
|
||||
|
||||
| Publishable | Local-Only |
|
||||
|-------------|------------|
|
||||
| `skills/*` (curated) | `~/.claude/skills/learned/*` |
|
||||
| | `~/.claude/skills/imported/*` |
|
||||
| | `~/.claude/homunculus/**/evolved/**` |
|
||||
|
||||
Only curated skills appear in install manifests and get copied during install.
|
||||
|
||||
## Implementation Roadmap
|
||||
|
||||
1. Policy document and provenance schema (this change).
|
||||
2. Add provenance validation to learned-skill write paths (evaluate-session, /learn output) so new learned skills always get `.provenance.json`.
|
||||
3. Update instinct-cli evolve to write optional provenance when generating evolved skills.
|
||||
4. Add `scripts/validate-provenance.js` to CI for any repo paths that must not contain learned/imported content (if needed).
|
||||
5. Document learned/imported roots in CONTRIBUTING.md or user docs so contributors know not to commit them.
|
||||
426
docs/pt-BR/CONTRIBUTING.md
Normal file
@@ -0,0 +1,426 @@
|
||||
# Contribuindo para o Everything Claude Code
|
||||
|
||||
Obrigado por querer contribuir! Este repositório é um recurso comunitário para usuários do Claude Code.
|
||||
|
||||
## Índice
|
||||
|
||||
- [O Que Estamos Buscando](#o-que-estamos-buscando)
|
||||
- [Início Rápido](#início-rápido)
|
||||
- [Contribuindo com Skills](#contribuindo-com-skills)
|
||||
- [Contribuindo com Agentes](#contribuindo-com-agentes)
|
||||
- [Contribuindo com Hooks](#contribuindo-com-hooks)
|
||||
- [Contribuindo com Comandos](#contribuindo-com-comandos)
|
||||
- [MCP e Documentação (ex: Context7)](#mcp-e-documentação-ex-context7)
|
||||
- [Multiplataforma e Traduções](#multiplataforma-e-traduções)
|
||||
- [Processo de Pull Request](#processo-de-pull-request)
|
||||
|
||||
---
|
||||
|
||||
## O Que Estamos Buscando
|
||||
|
||||
### Agentes
|
||||
Novos agentes que lidam bem com tarefas específicas:
|
||||
- Revisores específicos de linguagem (Python, Go, Rust)
|
||||
- Especialistas em frameworks (Django, Rails, Laravel, Spring)
|
||||
- Especialistas em DevOps (Kubernetes, Terraform, CI/CD)
|
||||
- Especialistas de domínio (pipelines de ML, engenharia de dados, mobile)
|
||||
|
||||
### Skills
|
||||
Definições de fluxo de trabalho e conhecimento de domínio:
|
||||
- Melhores práticas de linguagem
|
||||
- Padrões de frameworks
|
||||
- Estratégias de testes
|
||||
- Guias de arquitetura
|
||||
|
||||
### Hooks
|
||||
Automações úteis:
|
||||
- Hooks de lint/formatação
|
||||
- Verificações de segurança
|
||||
- Hooks de validação
|
||||
- Hooks de notificação
|
||||
|
||||
### Comandos
|
||||
Comandos slash que invocam fluxos de trabalho úteis:
|
||||
- Comandos de implantação
|
||||
- Comandos de teste
|
||||
- Comandos de geração de código
|
||||
|
||||
---
|
||||
|
||||
## Início Rápido
|
||||
|
||||
```bash
|
||||
# 1. Fork e clone
|
||||
gh repo fork affaan-m/everything-claude-code --clone
|
||||
cd everything-claude-code
|
||||
|
||||
# 2. Criar uma branch
|
||||
git checkout -b feat/minha-contribuicao
|
||||
|
||||
# 3. Adicionar sua contribuição (veja as seções abaixo)
|
||||
|
||||
# 4. Testar localmente
|
||||
cp -r skills/minha-skill ~/.claude/skills/ # para skills
|
||||
# Em seguida teste com o Claude Code
|
||||
|
||||
# 5. Enviar PR
|
||||
git add . && git commit -m "feat: adicionar minha-skill" && git push -u origin feat/minha-contribuicao
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Contribuindo com Skills
|
||||
|
||||
Skills são módulos de conhecimento que o Claude Code carrega baseado no contexto.
|
||||
|
||||
### Estrutura de Diretório
|
||||
|
||||
```
|
||||
skills/
|
||||
└── nome-da-sua-skill/
|
||||
└── SKILL.md
|
||||
```
|
||||
|
||||
### Template SKILL.md
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: nome-da-sua-skill
|
||||
description: Breve descrição mostrada na lista de skills
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Título da Sua Skill
|
||||
|
||||
Breve visão geral do que esta skill cobre.
|
||||
|
||||
## Conceitos Principais
|
||||
|
||||
Explique padrões e diretrizes chave.
|
||||
|
||||
## Exemplos de Código
|
||||
|
||||
\`\`\`typescript
|
||||
// Inclua exemplos práticos e testados
|
||||
function exemplo() {
|
||||
// Código bem comentado
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
## Melhores Práticas
|
||||
|
||||
- Diretrizes acionáveis
|
||||
- O que fazer e o que não fazer
|
||||
- Armadilhas comuns a evitar
|
||||
|
||||
## Quando Usar
|
||||
|
||||
Descreva cenários onde esta skill se aplica.
|
||||
```
|
||||
|
||||
### Checklist de Skill
|
||||
|
||||
- [ ] Focada em um domínio/tecnologia
|
||||
- [ ] Inclui exemplos práticos de código
|
||||
- [ ] Abaixo de 500 linhas
|
||||
- [ ] Usa cabeçalhos de seção claros
|
||||
- [ ] Testada com o Claude Code
|
||||
|
||||
### Exemplos de Skills
|
||||
|
||||
| Skill | Propósito |
|
||||
|-------|-----------|
|
||||
| `coding-standards/` | Padrões TypeScript/JavaScript |
|
||||
| `frontend-patterns/` | Melhores práticas React e Next.js |
|
||||
| `backend-patterns/` | Padrões de API e banco de dados |
|
||||
| `security-review/` | Checklist de segurança |
|
||||
|
||||
---
|
||||
|
||||
## Contribuindo com Agentes
|
||||
|
||||
Agentes são assistentes especializados invocados via a ferramenta Task.
|
||||
|
||||
### Localização do Arquivo
|
||||
|
||||
```
|
||||
agents/nome-do-seu-agente.md
|
||||
```
|
||||
|
||||
### Template de Agente
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: nome-do-seu-agente
|
||||
description: O que este agente faz e quando o Claude deve invocá-lo. Seja específico!
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
Você é um especialista em [função].
|
||||
|
||||
## Seu Papel
|
||||
|
||||
- Responsabilidade principal
|
||||
- Responsabilidade secundária
|
||||
- O que você NÃO faz (limites)
|
||||
|
||||
## Fluxo de Trabalho
|
||||
|
||||
### Passo 1: Entender
|
||||
Como você aborda a tarefa.
|
||||
|
||||
### Passo 2: Executar
|
||||
Como você realiza o trabalho.
|
||||
|
||||
### Passo 3: Verificar
|
||||
Como você valida os resultados.
|
||||
|
||||
## Formato de Saída
|
||||
|
||||
O que você retorna ao usuário.
|
||||
|
||||
## Exemplos
|
||||
|
||||
### Exemplo: [Cenário]
|
||||
Entrada: [o que o usuário fornece]
|
||||
Ação: [o que você faz]
|
||||
Saída: [o que você retorna]
|
||||
```
|
||||
|
||||
### Campos do Agente
|
||||
|
||||
| Campo | Descrição | Opções |
|
||||
|-------|-----------|--------|
|
||||
| `name` | Minúsculas, com hifens | `code-reviewer` |
|
||||
| `description` | Usado para decidir quando invocar | Seja específico! |
|
||||
| `tools` | Apenas o que é necessário | `Read, Write, Edit, Bash, Grep, Glob, WebFetch, Task` |
|
||||
| `model` | Nível de complexidade | `haiku` (simples), `sonnet` (codificação), `opus` (complexo) |
|
||||
|
||||
### Agentes de Exemplo
|
||||
|
||||
| Agente | Propósito |
|
||||
|--------|-----------|
|
||||
| `tdd-guide.md` | Desenvolvimento orientado a testes |
|
||||
| `code-reviewer.md` | Revisão de código |
|
||||
| `security-reviewer.md` | Varredura de segurança |
|
||||
| `build-error-resolver.md` | Correção de erros de build |
|
||||
|
||||
---
|
||||
|
||||
## Contribuindo com Hooks
|
||||
|
||||
Hooks são comportamentos automáticos disparados por eventos do Claude Code.
|
||||
|
||||
### Localização do Arquivo
|
||||
|
||||
```
|
||||
hooks/hooks.json
|
||||
```
|
||||
|
||||
### Tipos de Hooks
|
||||
|
||||
| Tipo | Gatilho | Caso de Uso |
|
||||
|------|---------|-------------|
|
||||
| `PreToolUse` | Antes da execução da ferramenta | Validar, avisar, bloquear |
|
||||
| `PostToolUse` | Após a execução da ferramenta | Formatar, verificar, notificar |
|
||||
| `SessionStart` | Sessão começa | Carregar contexto |
|
||||
| `Stop` | Sessão termina | Limpeza, auditoria |
|
||||
|
||||
### Formato de Hook
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"PreToolUse": [
|
||||
{
|
||||
"matcher": "tool == \"Bash\" && tool_input.command matches \"rm -rf /\"",
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "echo '[Hook] BLOQUEADO: Comando perigoso' && exit 1"
|
||||
}
|
||||
],
|
||||
"description": "Bloquear comandos rm perigosos"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Sintaxe de Matcher
|
||||
|
||||
```javascript
|
||||
// Corresponder ferramentas específicas
|
||||
tool == "Bash"
|
||||
tool == "Edit"
|
||||
tool == "Write"
|
||||
|
||||
// Corresponder padrões de entrada
|
||||
tool_input.command matches "npm install"
|
||||
tool_input.file_path matches "\\.tsx?$"
|
||||
|
||||
// Combinar condições
|
||||
tool == "Bash" && tool_input.command matches "git push"
|
||||
```
|
||||
|
||||
### Checklist de Hook
|
||||
|
||||
- [ ] O matcher é específico (não excessivamente abrangente)
|
||||
- [ ] Inclui mensagens de erro/informação claras
|
||||
- [ ] Usa códigos de saída corretos (`exit 1` bloqueia, `exit 0` permite)
|
||||
- [ ] Testado exaustivamente
|
||||
- [ ] Tem descrição
|
||||
|
||||
---
|
||||
|
||||
## Contribuindo com Comandos
|
||||
|
||||
Comandos são ações invocadas pelo usuário com `/nome-do-comando`.
|
||||
|
||||
### Localização do Arquivo
|
||||
|
||||
```
|
||||
commands/seu-comando.md
|
||||
```
|
||||
|
||||
### Template de Comando
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: Breve descrição mostrada em /help
|
||||
---
|
||||
|
||||
# Nome do Comando
|
||||
|
||||
## Propósito
|
||||
|
||||
O que este comando faz.
|
||||
|
||||
## Uso
|
||||
|
||||
\`\`\`
|
||||
/seu-comando [args]
|
||||
\`\`\`
|
||||
|
||||
## Fluxo de Trabalho
|
||||
|
||||
1. Primeiro passo
|
||||
2. Segundo passo
|
||||
3. Passo final
|
||||
|
||||
## Saída
|
||||
|
||||
O que o usuário recebe.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## MCP e Documentação (ex: Context7)
|
||||
|
||||
Skills e agentes podem usar ferramentas **MCP (Model Context Protocol)** para obter dados atualizados em vez de depender apenas de dados de treinamento. Isso é especialmente útil para documentação.
|
||||
|
||||
- **Context7** é um servidor MCP que expõe `resolve-library-id` e `query-docs`. Use quando o usuário perguntar sobre bibliotecas, frameworks ou APIs para que as respostas reflitam a documentação atual.
|
||||
- Ao contribuir com **skills** que dependem de docs em tempo real, descreva como usar as ferramentas MCP relevantes.
|
||||
- Ao contribuir com **agentes** que respondem perguntas sobre docs/API, inclua os nomes das ferramentas MCP do Context7 nas ferramentas do agente.
|
||||
|
||||
---
|
||||
|
||||
## Multiplataforma e Traduções
|
||||
|
||||
### Subconjuntos de Skills (Codex e Cursor)
|
||||
|
||||
O ECC vem com subconjuntos de skills para outros harnesses:
|
||||
|
||||
- **Codex:** `.agents/skills/` — skills listadas em `agents/openai.yaml` são carregadas pelo Codex.
|
||||
- **Cursor:** `.cursor/skills/` — um subconjunto de skills é incluído para Cursor.
|
||||
|
||||
Ao **adicionar uma nova skill** que deve estar disponível no Codex ou Cursor:
|
||||
|
||||
1. Adicione a skill em `skills/nome-da-sua-skill/` como de costume.
|
||||
2. Se deve estar disponível no **Codex**, adicione-a em `.agents/skills/` e garanta que seja referenciada em `agents/openai.yaml` se necessário.
|
||||
3. Se deve estar disponível no **Cursor**, adicione-a em `.cursor/skills/`.
|
||||
|
||||
### Traduções
|
||||
|
||||
Traduções ficam em `docs/` (ex: `docs/zh-CN`, `docs/zh-TW`, `docs/ja-JP`, `docs/ko-KR`, `docs/pt-BR`). Se você alterar agentes, comandos ou skills que são traduzidos, considere atualizar os arquivos de tradução correspondentes ou abrir uma issue.
|
||||
|
||||
---
|
||||
|
||||
## Processo de Pull Request
|
||||
|
||||
### 1. Formato do Título do PR
|
||||
|
||||
```
|
||||
feat(skills): adicionar skill rust-patterns
|
||||
feat(agents): adicionar agente api-designer
|
||||
feat(hooks): adicionar hook auto-format
|
||||
fix(skills): atualizar padrões React
|
||||
docs: melhorar guia de contribuição
|
||||
docs(pt-BR): adicionar tradução para português brasileiro
|
||||
```
|
||||
|
||||
### 2. Descrição do PR
|
||||
|
||||
```markdown
|
||||
## Resumo
|
||||
O que você está adicionando e por quê.
|
||||
|
||||
## Tipo
|
||||
- [ ] Skill
|
||||
- [ ] Agente
|
||||
- [ ] Hook
|
||||
- [ ] Comando
|
||||
- [ ] Docs / Tradução
|
||||
|
||||
## Testes
|
||||
Como você testou isso.
|
||||
|
||||
## Checklist
|
||||
- [ ] Segue as diretrizes de formato
|
||||
- [ ] Testado com o Claude Code
|
||||
- [ ] Sem informações sensíveis (chaves de API, caminhos)
|
||||
- [ ] Descrições claras
|
||||
```
|
||||
|
||||
### 3. Processo de Revisão
|
||||
|
||||
1. Mantenedores revisam em até 48 horas
|
||||
2. Abordar o feedback se solicitado
|
||||
3. Uma vez aprovado, mesclado na main
|
||||
|
||||
---
|
||||
|
||||
## Diretrizes
|
||||
|
||||
### Faça
|
||||
- Mantenha as contribuições focadas e modulares
|
||||
- Inclua descrições claras
|
||||
- Teste antes de enviar
|
||||
- Siga os padrões existentes
|
||||
- Documente dependências
|
||||
|
||||
### Não Faça
|
||||
- Incluir dados sensíveis (chaves de API, tokens, caminhos)
|
||||
- Adicionar configurações excessivamente complexas ou de nicho
|
||||
- Enviar contribuições não testadas
|
||||
- Criar duplicatas de funcionalidade existente
|
||||
|
||||
---
|
||||
|
||||
## Nomenclatura de Arquivos
|
||||
|
||||
- Use minúsculas com hifens: `python-reviewer.md`
|
||||
- Seja descritivo: `tdd-workflow.md` não `workflow.md`
|
||||
- Combine nome com nome do arquivo
|
||||
|
||||
---
|
||||
|
||||
## Dúvidas?
|
||||
|
||||
- **Issues:** [github.com/affaan-m/everything-claude-code/issues](https://github.com/affaan-m/everything-claude-code/issues)
|
||||
- **X/Twitter:** [@affaanmustafa](https://x.com/affaanmustafa)
|
||||
|
||||
---
|
||||
|
||||
Obrigado por contribuir! Vamos construir um ótimo recurso juntos.
|
||||
509
docs/pt-BR/README.md
Normal file
@@ -0,0 +1,509 @@
|
||||
**Idioma:** [English](../../README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](../ja-JP/README.md) | [한국어](../ko-KR/README.md) | Português (BR)
|
||||
|
||||
# Everything Claude Code
|
||||
|
||||
[](https://github.com/affaan-m/everything-claude-code/stargazers)
|
||||
[](https://github.com/affaan-m/everything-claude-code/network/members)
|
||||
[](https://github.com/affaan-m/everything-claude-code/graphs/contributors)
|
||||
[](https://www.npmjs.com/package/ecc-universal)
|
||||
[](https://www.npmjs.com/package/ecc-agentshield)
|
||||
[](https://github.com/marketplace/ecc-tools)
|
||||
[](../../LICENSE)
|
||||

|
||||

|
||||

|
||||

|
||||

|
||||

|
||||
|
||||
> **50K+ estrelas** | **6K+ forks** | **30 contribuidores** | **6 idiomas suportados** | **Vencedor do Hackathon Anthropic**
|
||||
|
||||
---
|
||||
|
||||
<div align="center">
|
||||
|
||||
**🌐 Idioma / Language / 语言**
|
||||
|
||||
[**English**](../../README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](../ja-JP/README.md) | [한국어](../ko-KR/README.md) | [Português (BR)](README.md)
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
**O sistema de otimização de desempenho para harnesses de agentes de IA. De um vencedor do hackathon da Anthropic.**
|
||||
|
||||
Não são apenas configurações. Um sistema completo: skills, instincts, otimização de memória, aprendizado contínuo, varredura de segurança e desenvolvimento com pesquisa em primeiro lugar. Agentes, hooks, comandos, regras e configurações MCP prontos para produção, desenvolvidos ao longo de 10+ meses de uso intensivo diário construindo produtos reais.
|
||||
|
||||
Funciona com **Claude Code**, **Codex**, **Cowork** e outros harnesses de agentes de IA.
|
||||
|
||||
---
|
||||
|
||||
## Os Guias
|
||||
|
||||
Este repositório contém apenas o código. Os guias explicam tudo.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2012378465664745795">
|
||||
<img src="../../assets/images/guides/shorthand-guide.png" alt="The Shorthand Guide to Everything Claude Code" />
|
||||
</a>
|
||||
</td>
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2014040193557471352">
|
||||
<img src="../../assets/images/guides/longform-guide.png" alt="The Longform Guide to Everything Claude Code" />
|
||||
</a>
|
||||
</td>
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2033263813387223421">
|
||||
<img src="../../assets/images/security/security-guide-header.png" alt="The Shorthand Guide to Everything Agentic Security" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="center"><b>Guia Resumido</b><br/>Configuração, fundamentos, filosofia. <b>Leia este primeiro.</b></td>
|
||||
<td align="center"><b>Guia Completo</b><br/>Otimização de tokens, persistência de memória, evals, paralelização.</td>
|
||||
<td align="center"><b>Guia de Segurança</b><br/>Vetores de ataque, sandboxing, sanitização, CVEs, AgentShield.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
| Tópico | O Que Você Aprenderá |
|
||||
|--------|----------------------|
|
||||
| Otimização de Tokens | Seleção de modelo, redução de prompt de sistema, processos em segundo plano |
|
||||
| Persistência de Memória | Hooks que salvam/carregam contexto entre sessões automaticamente |
|
||||
| Aprendizado Contínuo | Extração automática de padrões das sessões em skills reutilizáveis |
|
||||
| Loops de Verificação | Checkpoint vs evals contínuos, tipos de avaliador, métricas pass@k |
|
||||
| Paralelização | Git worktrees, método cascade, quando escalar instâncias |
|
||||
| Orquestração de Subagentes | O problema de contexto, padrão de recuperação iterativa |
|
||||
|
||||
---
|
||||
|
||||
## O Que Há de Novo
|
||||
|
||||
### v1.9.0 — Instalação Seletiva e Expansão de Idiomas (Mar 2026)
|
||||
|
||||
- **Arquitetura de instalação seletiva** — Pipeline de instalação baseado em manifesto com `install-plan.js` e `install-apply.js` para instalação de componentes direcionada. O state store rastreia o que está instalado e habilita atualizações incrementais.
|
||||
- **6 novos agentes** — `typescript-reviewer`, `pytorch-build-resolver`, `java-build-resolver`, `java-reviewer`, `kotlin-reviewer`, `kotlin-build-resolver` expandem a cobertura para 10 linguagens.
|
||||
- **Novas skills** — `pytorch-patterns` para fluxos de deep learning, `documentation-lookup` para pesquisa de referências de API, `bun-runtime` e `nextjs-turbopack` para toolchains JS modernas, além de 8 skills de domínio operacional e `mcp-server-patterns`.
|
||||
- **Infraestrutura de sessão e estado** — State store SQLite com CLI de consulta, adaptadores de sessão para gravação estruturada, fundação de evolução de skills para skills auto-aprimoráveis.
|
||||
- **Revisão de orquestração** — Pontuação de auditoria de harness tornado determinístico, status de orquestração e compatibilidade de launcher reforçados, prevenção de loop de observer com guarda de 5 camadas.
|
||||
- **Confiabilidade do observer** — Correção de explosão de memória com throttling e tail sampling, correção de acesso sandbox, lógica de início preguiçoso e guarda de reentrância.
|
||||
- **12 ecossistemas de linguagem** — Novas regras para Java, PHP, Perl, Kotlin/Android/KMP, C++ e Rust se juntam ao TypeScript, Python, Go e regras comuns existentes.
|
||||
- **Contribuições da comunidade** — Traduções para coreano e chinês, hook de segurança InsAIts, otimização de hook biome, skills VideoDB, skills operacionais Evos, instalador PowerShell, suporte ao IDE Antigravity.
|
||||
- **CI reforçado** — 19 correções de falhas de teste, aplicação de contagem de catálogo, validação de manifesto de instalação e suíte de testes completa no verde.
|
||||
|
||||
### v1.8.0 — Sistema de Desempenho de Harness (Mar 2026)
|
||||
|
||||
- **Lançamento focado em harness** — O ECC agora é explicitamente enquadrado como um sistema de desempenho de harness de agentes, não apenas um pacote de configurações.
|
||||
- **Revisão de confiabilidade de hooks** — Fallback de raiz SessionStart, resumos de sessão na fase Stop e hooks baseados em scripts substituindo frágeis one-liners inline.
|
||||
- **Controles de runtime de hooks** — `ECC_HOOK_PROFILE=minimal|standard|strict` e `ECC_DISABLED_HOOKS=...` para controle em tempo de execução sem editar arquivos de hook.
|
||||
- **Novos comandos de harness** — `/harness-audit`, `/loop-start`, `/loop-status`, `/quality-gate`, `/model-route`.
|
||||
- **NanoClaw v2** — roteamento de modelo, carregamento a quente de skill, ramificação/busca/exportação/compactação/métricas de sessão.
|
||||
- **Paridade entre harnesses** — comportamento unificado em Claude Code, Cursor, OpenCode e Codex app/CLI.
|
||||
- **997 testes internos passando** — suíte completa no verde após refatoração de hook/runtime e atualizações de compatibilidade.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Início Rápido
|
||||
|
||||
Comece em menos de 2 minutos:
|
||||
|
||||
### Passo 1: Instalar o Plugin
|
||||
|
||||
```bash
|
||||
# Adicionar marketplace
|
||||
/plugin marketplace add affaan-m/everything-claude-code
|
||||
|
||||
# Instalar plugin
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
### Passo 2: Instalar as Regras (Obrigatório)
|
||||
|
||||
> ⚠️ **Importante:** Plugins do Claude Code não podem distribuir `rules` automaticamente. Instale-as manualmente:
|
||||
|
||||
```bash
|
||||
# Clone o repositório primeiro
|
||||
git clone https://github.com/affaan-m/everything-claude-code.git
|
||||
cd everything-claude-code
|
||||
|
||||
# Instalar dependências (escolha seu gerenciador de pacotes)
|
||||
npm install # ou: pnpm install | yarn install | bun install
|
||||
|
||||
# macOS/Linux
|
||||
./install.sh typescript # ou python ou golang ou swift ou php
|
||||
# ./install.sh typescript python golang swift php
|
||||
# ./install.sh --target cursor typescript
|
||||
# ./install.sh --target antigravity typescript
|
||||
```
|
||||
|
||||
```powershell
|
||||
# Windows PowerShell
|
||||
.\install.ps1 typescript # ou python ou golang ou swift ou php
|
||||
# .\install.ps1 typescript python golang swift php
|
||||
# .\install.ps1 --target cursor typescript
|
||||
# .\install.ps1 --target antigravity typescript
|
||||
|
||||
# O ponto de entrada de compatibilidade npm também funciona multiplataforma
|
||||
npx ecc-install typescript
|
||||
```
|
||||
|
||||
### Passo 3: Começar a Usar
|
||||
|
||||
```bash
|
||||
# Experimente um comando (a instalação do plugin usa forma com namespace)
|
||||
/everything-claude-code:plan "Adicionar autenticação de usuário"
|
||||
|
||||
# Instalação manual (Opção 2) usa a forma mais curta:
|
||||
# /plan "Adicionar autenticação de usuário"
|
||||
|
||||
# Verificar comandos disponíveis
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
✨ **Pronto!** Você agora tem acesso a 28 agentes, 116 skills e 59 comandos.
|
||||
|
||||
---
|
||||
|
||||
## 🌐 Suporte Multiplataforma
|
||||
|
||||
Este plugin agora suporta totalmente **Windows, macOS e Linux**, com integração estreita em principais IDEs (Cursor, OpenCode, Antigravity) e harnesses CLI. Todos os hooks e scripts foram reescritos em Node.js para máxima compatibilidade.
|
||||
|
||||
### Detecção de Gerenciador de Pacotes
|
||||
|
||||
O plugin detecta automaticamente seu gerenciador de pacotes preferido (npm, pnpm, yarn ou bun) com a seguinte prioridade:
|
||||
|
||||
1. **Variável de ambiente**: `CLAUDE_PACKAGE_MANAGER`
|
||||
2. **Config do projeto**: `.claude/package-manager.json`
|
||||
3. **package.json**: campo `packageManager`
|
||||
4. **Arquivo de lock**: Detecção por package-lock.json, yarn.lock, pnpm-lock.yaml ou bun.lockb
|
||||
5. **Config global**: `~/.claude/package-manager.json`
|
||||
6. **Fallback**: Primeiro gerenciador disponível (pnpm > bun > yarn > npm)
|
||||
|
||||
Para definir seu gerenciador de pacotes preferido:
|
||||
|
||||
```bash
|
||||
# Via variável de ambiente
|
||||
export CLAUDE_PACKAGE_MANAGER=pnpm
|
||||
|
||||
# Via config global
|
||||
node scripts/setup-package-manager.js --global pnpm
|
||||
|
||||
# Via config do projeto
|
||||
node scripts/setup-package-manager.js --project bun
|
||||
|
||||
# Detectar configuração atual
|
||||
node scripts/setup-package-manager.js --detect
|
||||
```
|
||||
|
||||
Ou use o comando `/setup-pm` no Claude Code.
|
||||
|
||||
### Controles de Runtime de Hooks
|
||||
|
||||
Use flags de runtime para ajustar rigor ou desabilitar hooks específicos temporariamente:
|
||||
|
||||
```bash
|
||||
# Perfil de rigor de hooks (padrão: standard)
|
||||
export ECC_HOOK_PROFILE=standard
|
||||
|
||||
# IDs de hooks separados por vírgula para desabilitar
|
||||
export ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📦 O Que Está Incluído
|
||||
|
||||
```
|
||||
everything-claude-code/
|
||||
|-- agents/ # 28 subagentes especializados para delegação
|
||||
|-- skills/ # Definições de fluxo de trabalho e conhecimento de domínio
|
||||
|-- commands/ # Comandos slash para execução rápida
|
||||
|-- rules/ # Diretrizes sempre seguidas (copiar para ~/.claude/rules/)
|
||||
|-- hooks/ # Automações baseadas em gatilhos
|
||||
|-- scripts/ # Scripts Node.js multiplataforma
|
||||
|-- tests/ # Suíte de testes
|
||||
|-- contexts/ # Contextos de injeção de prompt de sistema
|
||||
|-- examples/ # Configurações e sessões de exemplo
|
||||
|-- mcp-configs/ # Configurações de servidor MCP
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Ferramentas do Ecossistema
|
||||
|
||||
### Criador de Skills
|
||||
|
||||
Dois modos de gerar skills do Claude Code a partir do seu repositório:
|
||||
|
||||
#### Opção A: Análise Local (Integrada)
|
||||
|
||||
Use o comando `/skill-create` para análise local sem serviços externos:
|
||||
|
||||
```bash
|
||||
/skill-create # Analisar repositório atual
|
||||
/skill-create --instincts # Também gerar instincts para continuous-learning
|
||||
```
|
||||
|
||||
#### Opção B: GitHub App (Avançado)
|
||||
|
||||
Para recursos avançados (10k+ commits, PRs automáticos, compartilhamento em equipe):
|
||||
|
||||
[Instalar GitHub App](https://github.com/apps/skill-creator) | [ecc.tools](https://ecc.tools)
|
||||
|
||||
### AgentShield — Auditor de Segurança
|
||||
|
||||
> Construído no Claude Code Hackathon (Cerebral Valley x Anthropic, Fev 2026). 1282 testes, 98% de cobertura, 102 regras de análise estática.
|
||||
|
||||
```bash
|
||||
# Verificação rápida (sem instalação necessária)
|
||||
npx ecc-agentshield scan
|
||||
|
||||
# Corrigir automaticamente problemas seguros
|
||||
npx ecc-agentshield scan --fix
|
||||
|
||||
# Análise profunda com três agentes Opus 4.6
|
||||
npx ecc-agentshield scan --opus --stream
|
||||
|
||||
# Gerar configuração segura do zero
|
||||
npx ecc-agentshield init
|
||||
```
|
||||
|
||||
### 🧠 Aprendizado Contínuo v2
|
||||
|
||||
O sistema de aprendizado baseado em instincts aprende automaticamente seus padrões:
|
||||
|
||||
```bash
|
||||
/instinct-status # Mostrar instincts aprendidos com confiança
|
||||
/instinct-import <file> # Importar instincts de outros
|
||||
/instinct-export # Exportar seus instincts para compartilhar
|
||||
/evolve # Agrupar instincts relacionados em skills
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📋 Requisitos
|
||||
|
||||
### Versão do Claude Code CLI
|
||||
|
||||
**Versão mínima: v2.1.0 ou posterior**
|
||||
|
||||
Verifique sua versão:
|
||||
```bash
|
||||
claude --version
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📥 Instalação
|
||||
|
||||
### Opção 1: Instalar como Plugin (Recomendado)
|
||||
|
||||
```bash
|
||||
# Adicionar este repositório como marketplace
|
||||
/plugin marketplace add affaan-m/everything-claude-code
|
||||
|
||||
# Instalar o plugin
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
Ou adicione diretamente ao seu `~/.claude/settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"extraKnownMarketplaces": {
|
||||
"everything-claude-code": {
|
||||
"source": {
|
||||
"source": "github",
|
||||
"repo": "affaan-m/everything-claude-code"
|
||||
}
|
||||
}
|
||||
},
|
||||
"enabledPlugins": {
|
||||
"everything-claude-code@everything-claude-code": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> **Nota:** O sistema de plugins do Claude Code não suporta distribuição de `rules` via plugins. Você precisa instalar as regras manualmente:
|
||||
>
|
||||
> ```bash
|
||||
> # Clone o repositório primeiro
|
||||
> git clone https://github.com/affaan-m/everything-claude-code.git
|
||||
>
|
||||
> # Opção A: Regras no nível do usuário (aplica a todos os projetos)
|
||||
> mkdir -p ~/.claude/rules
|
||||
> cp -r everything-claude-code/rules/common/* ~/.claude/rules/
|
||||
> cp -r everything-claude-code/rules/typescript/* ~/.claude/rules/ # escolha sua stack
|
||||
>
|
||||
> # Opção B: Regras no nível do projeto (aplica apenas ao projeto atual)
|
||||
> mkdir -p .claude/rules
|
||||
> cp -r everything-claude-code/rules/common/* .claude/rules/
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
### 🔧 Opção 2: Instalação Manual
|
||||
|
||||
```bash
|
||||
# Clonar o repositório
|
||||
git clone https://github.com/affaan-m/everything-claude-code.git
|
||||
|
||||
# Copiar agentes para sua config Claude
|
||||
cp everything-claude-code/agents/*.md ~/.claude/agents/
|
||||
|
||||
# Copiar regras (comuns + específicas da linguagem)
|
||||
cp -r everything-claude-code/rules/common/* ~/.claude/rules/
|
||||
cp -r everything-claude-code/rules/typescript/* ~/.claude/rules/
|
||||
|
||||
# Copiar comandos
|
||||
cp everything-claude-code/commands/*.md ~/.claude/commands/
|
||||
|
||||
# Copiar skills (core vs nicho)
|
||||
cp -r everything-claude-code/.agents/skills/* ~/.claude/skills/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Conceitos-Chave
|
||||
|
||||
### Agentes
|
||||
|
||||
Subagentes lidam com tarefas delegadas com escopo limitado.
|
||||
|
||||
### Skills
|
||||
|
||||
Skills são definições de fluxo de trabalho invocadas por comandos ou agentes.
|
||||
|
||||
### Hooks
|
||||
|
||||
Hooks disparam em eventos de ferramenta. Exemplo — avisar sobre console.log:
|
||||
|
||||
```json
|
||||
{
|
||||
"matcher": "tool == \"Edit\" && tool_input.file_path matches \"\\\\.(ts|tsx|js|jsx)$\"",
|
||||
"hooks": [{
|
||||
"type": "command",
|
||||
"command": "#!/bin/bash\ngrep -n 'console\\.log' \"$file_path\" && echo '[Hook] Remova o console.log' >&2"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
### Regras
|
||||
|
||||
Regras são diretrizes sempre seguidas, organizadas em `common/` (agnóstico à linguagem) + diretórios específicos por linguagem.
|
||||
|
||||
---
|
||||
|
||||
## 🗺️ Qual Agente Devo Usar?
|
||||
|
||||
| Quero... | Use este comando | Agente usado |
|
||||
|----------|-----------------|--------------|
|
||||
| Planejar um novo recurso | `/everything-claude-code:plan "Adicionar auth"` | planner |
|
||||
| Projetar arquitetura de sistema | `/everything-claude-code:plan` + agente architect | architect |
|
||||
| Escrever código com testes primeiro | `/tdd` | tdd-guide |
|
||||
| Revisar código que acabei de escrever | `/code-review` | code-reviewer |
|
||||
| Corrigir build com falha | `/build-fix` | build-error-resolver |
|
||||
| Executar testes end-to-end | `/e2e` | e2e-runner |
|
||||
| Encontrar vulnerabilidades de segurança | `/security-scan` | security-reviewer |
|
||||
| Remover código morto | `/refactor-clean` | refactor-cleaner |
|
||||
| Atualizar documentação | `/update-docs` | doc-updater |
|
||||
| Revisar código Go | `/go-review` | go-reviewer |
|
||||
| Revisar código Python | `/python-review` | python-reviewer |
|
||||
|
||||
### Fluxos de Trabalho Comuns
|
||||
|
||||
**Começando um novo recurso:**
|
||||
```
|
||||
/everything-claude-code:plan "Adicionar autenticação de usuário com OAuth"
|
||||
→ planner cria blueprint de implementação
|
||||
/tdd → tdd-guide aplica escrita de testes primeiro
|
||||
/code-review → code-reviewer verifica seu trabalho
|
||||
```
|
||||
|
||||
**Corrigindo um bug:**
|
||||
```
|
||||
/tdd → tdd-guide: escrever teste falhando que reproduz o bug
|
||||
→ implementar a correção, verificar se o teste passa
|
||||
/code-review → code-reviewer: detectar regressões
|
||||
```
|
||||
|
||||
**Preparando para produção:**
|
||||
```
|
||||
/security-scan → security-reviewer: auditoria OWASP Top 10
|
||||
/e2e → e2e-runner: testes de fluxo crítico do usuário
|
||||
/test-coverage → verificar cobertura 80%+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ❓ FAQ
|
||||
|
||||
<details>
|
||||
<summary><b>Como verificar quais agentes/comandos estão instalados?</b></summary>
|
||||
|
||||
```bash
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Meus hooks não estão funcionando / Vejo erros "Duplicate hooks file"</b></summary>
|
||||
|
||||
Este é o problema mais comum. **NÃO adicione um campo `"hooks"` ao `.claude-plugin/plugin.json`.** O Claude Code v2.1+ carrega automaticamente `hooks/hooks.json` de plugins instalados. Declarar explicitamente causa erros de detecção de duplicatas.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Posso usar o ECC com Cursor / OpenCode / Codex / Antigravity?</b></summary>
|
||||
|
||||
Sim. O ECC é multiplataforma:
|
||||
- **Cursor**: Configs pré-traduzidas em `.cursor/`
|
||||
- **OpenCode**: Suporte completo a plugins em `.opencode/`
|
||||
- **Codex**: Suporte de primeira classe para app macOS e CLI
|
||||
- **Antigravity**: Configuração integrada em `.agent/`
|
||||
- **Claude Code**: Nativo — este é o alvo principal
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Como contribuir com uma nova skill ou agente?</b></summary>
|
||||
|
||||
Veja [CONTRIBUTING.md](CONTRIBUTING.md). Em resumo:
|
||||
1. Faça um fork do repositório
|
||||
2. Crie sua skill em `skills/seu-nome-de-skill/SKILL.md` (com frontmatter YAML)
|
||||
3. Ou crie um agente em `agents/seu-agente.md`
|
||||
4. Envie um PR com uma descrição clara do que faz e quando usar
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Executando Testes
|
||||
|
||||
```bash
|
||||
# Executar todos os testes
|
||||
node tests/run-all.js
|
||||
|
||||
# Executar arquivos de teste individuais
|
||||
node tests/lib/utils.test.js
|
||||
node tests/lib/package-manager.test.js
|
||||
node tests/hooks/hooks.test.js
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🤝 Contribuindo
|
||||
|
||||
**Contribuições são bem-vindas e incentivadas.**
|
||||
|
||||
Este repositório é um recurso para a comunidade. Se você tem:
|
||||
- Agentes ou skills úteis
|
||||
- Hooks inteligentes
|
||||
- Melhores configurações MCP
|
||||
- Regras aprimoradas
|
||||
|
||||
Por favor contribua! Veja [CONTRIBUTING.md](CONTRIBUTING.md) para diretrizes.
|
||||
|
||||
---
|
||||
|
||||
## 📄 Licença
|
||||
|
||||
MIT — consulte o [arquivo LICENSE](../../LICENSE) para detalhes.
|
||||
102
docs/pt-BR/TERMINOLOGY.md
Normal file
@@ -0,0 +1,102 @@
|
||||
# Glossário de Terminologia (TERMINOLOGY)
|
||||
|
||||
Este documento registra a correspondência de termos utilizados nas traduções para português brasileiro (pt-BR), garantindo consistência.
|
||||
|
||||
## Status
|
||||
|
||||
- **Confirmado**: Tradução confirmada
|
||||
- **Pendente**: Aguardando revisão
|
||||
|
||||
---
|
||||
|
||||
## Tabela de Termos
|
||||
|
||||
| English | pt-BR | Status | Observações |
|
||||
|---------|-------|--------|-------------|
|
||||
| Agent | Agent | Confirmado | Manter em inglês |
|
||||
| Hook | Hook | Confirmado | Manter em inglês |
|
||||
| Plugin | Plugin | Confirmado | Manter em inglês |
|
||||
| Token | Token | Confirmado | Manter em inglês |
|
||||
| Skill | Skill | Confirmado | Manter em inglês |
|
||||
| Command | Comando | Confirmado | |
|
||||
| Rule | Regra | Confirmado | |
|
||||
| TDD (Test-Driven Development) | TDD (Desenvolvimento Orientado a Testes) | Confirmado | Expandir na primeira ocorrência |
|
||||
| E2E (End-to-End) | E2E (ponta a ponta) | Confirmado | Expandir na primeira ocorrência |
|
||||
| API | API | Confirmado | Manter em inglês |
|
||||
| CLI | CLI | Confirmado | Manter em inglês |
|
||||
| IDE | IDE | Confirmado | Manter em inglês |
|
||||
| MCP (Model Context Protocol) | MCP | Confirmado | Manter em inglês |
|
||||
| Workflow | Fluxo de trabalho | Confirmado | |
|
||||
| Codebase | Base de código | Confirmado | |
|
||||
| Coverage | Cobertura | Confirmado | |
|
||||
| Build | Build | Confirmado | Manter em inglês |
|
||||
| Debug | Debug / Depuração | Confirmado | |
|
||||
| Deploy | Implantação | Confirmado | |
|
||||
| Commit | Commit | Confirmado | Manter em inglês |
|
||||
| PR (Pull Request) | PR | Confirmado | Manter em inglês |
|
||||
| Branch | Branch | Confirmado | Manter em inglês |
|
||||
| Merge | Merge | Confirmado | Manter em inglês |
|
||||
| Repository | Repositório | Confirmado | |
|
||||
| Fork | Fork | Confirmado | Manter em inglês |
|
||||
| Supabase | Supabase | Confirmado | Nome de produto |
|
||||
| Redis | Redis | Confirmado | Nome de produto |
|
||||
| Playwright | Playwright | Confirmado | Nome de produto |
|
||||
| TypeScript | TypeScript | Confirmado | Nome de linguagem |
|
||||
| JavaScript | JavaScript | Confirmado | Nome de linguagem |
|
||||
| Go/Golang | Go | Confirmado | Nome de linguagem |
|
||||
| React | React | Confirmado | Nome de framework |
|
||||
| Next.js | Next.js | Confirmado | Nome de framework |
|
||||
| PostgreSQL | PostgreSQL | Confirmado | Nome de produto |
|
||||
| RLS (Row Level Security) | RLS (Segurança em Nível de Linha) | Confirmado | Expandir na primeira ocorrência |
|
||||
| OWASP | OWASP | Confirmado | Manter em inglês |
|
||||
| XSS | XSS | Confirmado | Manter em inglês |
|
||||
| SQL Injection | Injeção SQL | Confirmado | |
|
||||
| CSRF | CSRF | Confirmado | Manter em inglês |
|
||||
| Refactor | Refatoração | Confirmado | |
|
||||
| Dead Code | Código morto | Confirmado | |
|
||||
| Lint/Linter | Lint | Confirmado | Manter em inglês |
|
||||
| Code Review | Revisão de código | Confirmado | |
|
||||
| Security Review | Revisão de segurança | Confirmado | |
|
||||
| Best Practices | Melhores práticas | Confirmado | |
|
||||
| Edge Case | Caso extremo | Confirmado | |
|
||||
| Happy Path | Caminho feliz | Confirmado | |
|
||||
| Fallback | Fallback | Confirmado | Manter em inglês |
|
||||
| Cache | Cache | Confirmado | Manter em inglês |
|
||||
| Queue | Fila | Confirmado | |
|
||||
| Pagination | Paginação | Confirmado | |
|
||||
| Cursor | Cursor | Confirmado | |
|
||||
| Index | Índice | Confirmado | |
|
||||
| Schema | Schema | Confirmado | Manter em inglês |
|
||||
| Migration | Migração | Confirmado | |
|
||||
| Transaction | Transação | Confirmado | |
|
||||
| Concurrency | Concorrência | Confirmado | |
|
||||
| Goroutine | Goroutine | Confirmado | Termo Go |
|
||||
| Channel | Channel | Confirmado | No contexto Go |
|
||||
| Mutex | Mutex | Confirmado | Manter em inglês |
|
||||
| Interface | Interface | Confirmado | |
|
||||
| Struct | Struct | Confirmado | Termo Go |
|
||||
| Mock | Mock | Confirmado | Termo de teste |
|
||||
| Stub | Stub | Confirmado | Termo de teste |
|
||||
| Fixture | Fixture | Confirmado | Termo de teste |
|
||||
| Assertion | Asserção | Confirmado | |
|
||||
| Snapshot | Snapshot | Confirmado | Manter em inglês |
|
||||
| Trace | Trace | Confirmado | Manter em inglês |
|
||||
| Artifact | Artefato | Confirmado | |
|
||||
| CI/CD | CI/CD | Confirmado | Manter em inglês |
|
||||
| Pipeline | Pipeline | Confirmado | Manter em inglês |
|
||||
| Harness | Harness | Confirmado | Manter em inglês (contexto específico) |
|
||||
| Instinct | Instinct | Confirmado | Manter em inglês (contexto ECC) |
|
||||
|
||||
---
|
||||
|
||||
## Princípios de Tradução
|
||||
|
||||
1. **Nomes de produto**: Manter em inglês (Supabase, Redis, Playwright)
|
||||
2. **Linguagens de programação**: Manter em inglês (TypeScript, Go, JavaScript)
|
||||
3. **Nomes de frameworks**: Manter em inglês (React, Next.js, Vue)
|
||||
4. **Siglas técnicas**: Manter em inglês (API, CLI, IDE, MCP, TDD, E2E)
|
||||
5. **Termos Git**: Manter em inglês na maioria (commit, PR, fork)
|
||||
6. **Conteúdo de código**: Não traduzir (nomes de variáveis, funções mantidos no original; comentários explicativos traduzidos)
|
||||
7. **Primeira aparição**: Siglas devem ser expandidas na primeira ocorrência
|
||||
|
||||
---
|
||||
80
docs/pt-BR/agents/architect.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
name: architect
|
||||
description: Especialista em arquitetura de software para design de sistemas, escalabilidade e tomada de decisões técnicas. Use PROATIVAMENTE ao planejar novas funcionalidades, refatorar sistemas grandes ou tomar decisões arquiteturais.
|
||||
tools: ["Read", "Grep", "Glob"]
|
||||
model: opus
|
||||
---
|
||||
|
||||
Você é um arquiteto de software sênior especializado em design de sistemas escaláveis e manuteníveis.
|
||||
|
||||
## Seu Papel
|
||||
|
||||
- Projetar arquitetura de sistemas para novas funcionalidades
|
||||
- Avaliar trade-offs técnicos
|
||||
- Recomendar padrões e boas práticas
|
||||
- Identificar gargalos de escalabilidade
|
||||
- Planejar para crescimento futuro
|
||||
- Garantir consistência em toda a base de código
|
||||
|
||||
## Processo de Revisão Arquitetural
|
||||
|
||||
### 1. Análise do Estado Atual
|
||||
- Revisar a arquitetura existente
|
||||
- Identificar padrões e convenções
|
||||
- Documentar dívida técnica
|
||||
- Avaliar limitações de escalabilidade
|
||||
|
||||
### 2. Levantamento de Requisitos
|
||||
- Requisitos funcionais
|
||||
- Requisitos não-funcionais (performance, segurança, escalabilidade)
|
||||
- Pontos de integração
|
||||
- Requisitos de fluxo de dados
|
||||
|
||||
### 3. Proposta de Design
|
||||
- Diagrama de arquitetura de alto nível
|
||||
- Responsabilidades dos componentes
|
||||
- Modelos de dados
|
||||
- Contratos de API
|
||||
- Padrões de integração
|
||||
|
||||
### 4. Análise de Trade-offs
|
||||
Para cada decisão de design, documente:
|
||||
- **Prós**: Benefícios e vantagens
|
||||
- **Contras**: Desvantagens e limitações
|
||||
- **Alternativas**: Outras opções consideradas
|
||||
- **Decisão**: Escolha final e justificativa
|
||||
|
||||
## Princípios Arquiteturais
|
||||
|
||||
### 1. Modularidade & Separação de Responsabilidades
|
||||
- Princípio da Responsabilidade Única
|
||||
- Alta coesão, baixo acoplamento
|
||||
- Interfaces claras entre componentes
|
||||
- Implantação independente
|
||||
|
||||
### 2. Escalabilidade
|
||||
- Capacidade de escalonamento horizontal
|
||||
- Design stateless quando possível
|
||||
- Consultas de banco de dados eficientes
|
||||
- Estratégias de cache
|
||||
- Considerações de balanceamento de carga
|
||||
|
||||
### 3. Manutenibilidade
|
||||
- Organização clara do código
|
||||
- Padrões consistentes
|
||||
- Documentação abrangente
|
||||
- Fácil de testar
|
||||
- Simples de entender
|
||||
|
||||
### 4. Segurança
|
||||
- Defesa em profundidade
|
||||
- Princípio do menor privilégio
|
||||
- Validação de entrada nas fronteiras
|
||||
- Seguro por padrão
|
||||
- Trilha de auditoria
|
||||
|
||||
### 5. Performance
|
||||
- Algoritmos eficientes
|
||||
- Mínimo de requisições de rede
|
||||
- Consultas de banco de dados otimizadas
|
||||
- Cache apropriado
|
||||
80
docs/pt-BR/agents/build-error-resolver.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
name: build-error-resolver
|
||||
description: Especialista em resolução de erros de build e TypeScript. Use PROATIVAMENTE quando o build falhar ou ocorrerem erros de tipo. Corrige erros de build/tipo apenas com diffs mínimos, sem edições arquiteturais. Foca em deixar o build verde rapidamente.
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# Resolvedor de Erros de Build
|
||||
|
||||
Você é um especialista em resolução de erros de build. Sua missão é fazer os builds passarem com o mínimo de alterações — sem refatorações, sem mudanças de arquitetura, sem melhorias.
|
||||
|
||||
## Responsabilidades Principais
|
||||
|
||||
1. **Resolução de Erros TypeScript** — Corrigir erros de tipo, problemas de inferência, restrições de generics
|
||||
2. **Correção de Erros de Build** — Resolver falhas de compilação, resolução de módulos
|
||||
3. **Problemas de Dependência** — Corrigir erros de importação, pacotes ausentes, conflitos de versão
|
||||
4. **Erros de Configuração** — Resolver problemas de tsconfig, webpack, Next.js config
|
||||
5. **Diffs Mínimos** — Fazer as menores alterações possíveis para corrigir erros
|
||||
6. **Sem Mudanças Arquiteturais** — Apenas corrigir erros, não redesenhar
|
||||
|
||||
## Comandos de Diagnóstico
|
||||
|
||||
```bash
|
||||
npx tsc --noEmit --pretty
|
||||
npx tsc --noEmit --pretty --incremental false # Mostrar todos os erros
|
||||
npm run build
|
||||
npx eslint . --ext .ts,.tsx,.js,.jsx
|
||||
```
|
||||
|
||||
## Fluxo de Trabalho
|
||||
|
||||
### 1. Coletar Todos os Erros
|
||||
- Executar `npx tsc --noEmit --pretty` para obter todos os erros de tipo
|
||||
- Categorizar: inferência de tipo, tipos ausentes, importações, configuração, dependências
|
||||
- Priorizar: bloqueadores de build primeiro, depois erros de tipo, depois avisos
|
||||
|
||||
### 2. Estratégia de Correção (MUDANÇAS MÍNIMAS)
|
||||
Para cada erro:
|
||||
1. Ler a mensagem de erro cuidadosamente — entender esperado vs real
|
||||
2. Encontrar a correção mínima (anotação de tipo, verificação de null, correção de importação)
|
||||
3. Verificar que a correção não quebra outro código — reexecutar tsc
|
||||
4. Iterar até o build passar
|
||||
|
||||
### 3. Correções Comuns
|
||||
|
||||
| Erro | Correção |
|
||||
|------|----------|
|
||||
| `implicitly has 'any' type` | Adicionar anotação de tipo |
|
||||
| `Object is possibly 'undefined'` | Encadeamento opcional `?.` ou verificação de null |
|
||||
| `Property does not exist` | Adicionar à interface ou usar `?` opcional |
|
||||
| `Cannot find module` | Verificar paths no tsconfig, instalar pacote, ou corrigir path de importação |
|
||||
| `Type 'X' not assignable to 'Y'` | Converter/parsear tipo ou corrigir o tipo |
|
||||
| `Generic constraint` | Adicionar `extends { ... }` |
|
||||
| `Hook called conditionally` | Mover hooks para o nível superior |
|
||||
| `'await' outside async` | Adicionar palavra-chave `async` |
|
||||
|
||||
## O QUE FAZER e NÃO FAZER
|
||||
|
||||
**FAZER:**
|
||||
- Adicionar anotações de tipo quando ausentes
|
||||
- Adicionar verificações de null quando necessário
|
||||
- Corrigir importações/exportações
|
||||
- Adicionar dependências ausentes
|
||||
- Atualizar definições de tipo
|
||||
- Corrigir arquivos de configuração
|
||||
|
||||
**NÃO FAZER:**
|
||||
- Refatorar código não relacionado
|
||||
- Mudar arquitetura
|
||||
- Renomear variáveis (a menos que cause erro)
|
||||
- Adicionar novas funcionalidades
|
||||
- Mudar fluxo lógico (a menos que corrija erro)
|
||||
- Otimizar performance ou estilo
|
||||
|
||||
## Níveis de Prioridade
|
||||
|
||||
| Nível | Sintomas | Ação |
|
||||
|-------|----------|------|
|
||||
| CRÍTICO | Build completamente quebrado, sem servidor de dev | Corrigir imediatamente |
|
||||
| ALTO | Arquivo único falhando, erros de tipo em código novo | Corrigir em breve |
|
||||
86
docs/pt-BR/agents/code-reviewer.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
name: code-reviewer
|
||||
description: Especialista em revisão de código. Revisa código proativamente em busca de qualidade, segurança e manutenibilidade. Use imediatamente após escrever ou modificar código. DEVE SER USADO para todas as alterações de código.
|
||||
tools: ["Read", "Grep", "Glob", "Bash"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
Você é um revisor de código sênior garantindo altos padrões de qualidade e segurança.
|
||||
|
||||
## Processo de Revisão
|
||||
|
||||
Quando invocado:
|
||||
|
||||
1. **Coletar contexto** — Execute `git diff --staged` e `git diff` para ver todas as alterações. Se não houver diff, verificar commits recentes com `git log --oneline -5`.
|
||||
2. **Entender o escopo** — Identificar quais arquivos mudaram, a qual funcionalidade/correção se relacionam e como se conectam.
|
||||
3. **Ler o código ao redor** — Não revisar alterações isoladamente. Ler o arquivo completo e entender importações, dependências e call sites.
|
||||
4. **Aplicar checklist de revisão** — Trabalhar por cada categoria abaixo, de CRÍTICO a BAIXO.
|
||||
5. **Reportar descobertas** — Usar o formato de saída abaixo. Reportar apenas problemas com mais de 80% de confiança de que são reais.
|
||||
|
||||
## Filtragem Baseada em Confiança
|
||||
|
||||
**IMPORTANTE**: Não inundar a revisão com ruído. Aplicar estes filtros:
|
||||
|
||||
- **Reportar** se tiver >80% de confiança de que é um problema real
|
||||
- **Ignorar** preferências de estilo a menos que violem convenções do projeto
|
||||
- **Ignorar** problemas em código não alterado a menos que sejam problemas CRÍTICOS de segurança
|
||||
- **Consolidar** problemas similares (ex: "5 funções sem tratamento de erros" não 5 entradas separadas)
|
||||
- **Priorizar** problemas que possam causar bugs, vulnerabilidades de segurança ou perda de dados
|
||||
|
||||
## Checklist de Revisão
|
||||
|
||||
### Segurança (CRÍTICO)
|
||||
|
||||
Estes DEVEM ser sinalizados — podem causar danos reais:
|
||||
|
||||
- **Credenciais hardcoded** — API keys, senhas, tokens, connection strings no código-fonte
|
||||
- **SQL injection** — Concatenação de strings em consultas em vez de queries parametrizadas
|
||||
- **Vulnerabilidades XSS** — Input de usuário não escapado renderizado em HTML/JSX
|
||||
- **Path traversal** — Caminhos de arquivo controlados pelo usuário sem sanitização
|
||||
- **Vulnerabilidades CSRF** — Endpoints que alteram estado sem proteção CSRF
|
||||
- **Bypasses de autenticação** — Verificações de auth ausentes em rotas protegidas
|
||||
- **Dependências inseguras** — Pacotes com vulnerabilidades conhecidas
|
||||
- **Segredos expostos em logs** — Logging de dados sensíveis (tokens, senhas, PII)
|
||||
|
||||
```typescript
|
||||
// RUIM: SQL injection via concatenação de strings
|
||||
const query = `SELECT * FROM users WHERE id = ${userId}`;
|
||||
|
||||
// BOM: Query parametrizada
|
||||
const query = `SELECT * FROM users WHERE id = $1`;
|
||||
const result = await db.query(query, [userId]);
|
||||
```
|
||||
|
||||
```typescript
|
||||
// RUIM: Renderizar HTML bruto do usuário sem sanitização
|
||||
// Sempre sanitize conteúdo do usuário com DOMPurify.sanitize() ou equivalente
|
||||
|
||||
// BOM: Usar text content ou sanitizar
|
||||
<div>{userComment}</div>
|
||||
```
|
||||
|
||||
### Qualidade de Código (ALTO)
|
||||
|
||||
- **Funções grandes** (>50 linhas) — Dividir em funções menores e focadas
|
||||
- **Arquivos grandes** (>800 linhas) — Extrair módulos por responsabilidade
|
||||
- **Aninhamento profundo** (>4 níveis) — Usar retornos antecipados, extrair helpers
|
||||
- **Tratamento de erros ausente** — Rejeições de promise não tratadas, blocos catch vazios
|
||||
- **Padrões de mutação** — Preferir operações imutáveis (spread, map, filter)
|
||||
- **Declarações console.log** — Remover logging de debug antes do merge
|
||||
- **Testes ausentes** — Novos caminhos de código sem cobertura de testes
|
||||
- **Código morto** — Código comentado, importações não usadas, branches inacessíveis
|
||||
|
||||
### Confiabilidade (MÉDIO)
|
||||
|
||||
- Condições de corrida
|
||||
- Casos de borda não tratados (null, undefined, array vazio)
|
||||
- Lógica de retry ausente para operações externas
|
||||
- Ausência de timeouts em chamadas de API
|
||||
- Limites de taxa não aplicados
|
||||
|
||||
### Qualidade Geral (BAIXO)
|
||||
|
||||
- Nomes de variáveis pouco claros
|
||||
- Lógica complexa sem comentários explicativos
|
||||
- Código duplicado que poderia ser extraído
|
||||
- Imports não utilizados
|
||||
91
docs/pt-BR/agents/database-reviewer.md
Normal file
@@ -0,0 +1,91 @@
|
||||
---
|
||||
name: database-reviewer
|
||||
description: Especialista em banco de dados PostgreSQL para otimização de queries, design de schema, segurança e performance. Use PROATIVAMENTE ao escrever SQL, criar migrações, projetar schemas ou solucionar problemas de performance. Incorpora boas práticas do Supabase.
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# Revisor de Banco de Dados
|
||||
|
||||
Você é um especialista em PostgreSQL focado em otimização de queries, design de schema, segurança e performance. Sua missão é garantir que o código de banco de dados siga boas práticas, previna problemas de performance e mantenha integridade dos dados. Incorpora padrões das boas práticas postgres do Supabase (crédito: equipe Supabase).
|
||||
|
||||
## Responsabilidades Principais
|
||||
|
||||
1. **Performance de Queries** — Otimizar queries, adicionar índices adequados, prevenir table scans
|
||||
2. **Design de Schema** — Projetar schemas eficientes com tipos de dados e restrições adequados
|
||||
3. **Segurança & RLS** — Implementar Row Level Security, acesso com menor privilégio
|
||||
4. **Gerenciamento de Conexões** — Configurar pooling, timeouts, limites
|
||||
5. **Concorrência** — Prevenir deadlocks, otimizar estratégias de locking
|
||||
6. **Monitoramento** — Configurar análise de queries e rastreamento de performance
|
||||
|
||||
## Comandos de Diagnóstico
|
||||
|
||||
```bash
|
||||
psql $DATABASE_URL
|
||||
psql -c "SELECT query, mean_exec_time, calls FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;"
|
||||
psql -c "SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) FROM pg_stat_user_tables ORDER BY pg_total_relation_size(relid) DESC;"
|
||||
psql -c "SELECT indexrelname, idx_scan, idx_tup_read FROM pg_stat_user_indexes ORDER BY idx_scan DESC;"
|
||||
```
|
||||
|
||||
## Fluxo de Revisão
|
||||
|
||||
### 1. Performance de Queries (CRÍTICO)
|
||||
- Colunas de WHERE/JOIN estão indexadas?
|
||||
- Executar `EXPLAIN ANALYZE` em queries complexas — verificar Seq Scans em tabelas grandes
|
||||
- Observar padrões N+1
|
||||
- Verificar ordem das colunas em índices compostos (igualdade primeiro, depois range)
|
||||
|
||||
### 2. Design de Schema (ALTO)
|
||||
- Usar tipos adequados: `bigint` para IDs, `text` para strings, `timestamptz` para timestamps, `numeric` para dinheiro, `boolean` para flags
|
||||
- Definir restrições: PK, FK com `ON DELETE`, `NOT NULL`, `CHECK`
|
||||
- Usar identificadores `lowercase_snake_case` (sem mixed-case com aspas)
|
||||
|
||||
### 3. Segurança (CRÍTICO)
|
||||
- RLS habilitado em tabelas multi-tenant com padrão `(SELECT auth.uid())`
|
||||
- Colunas de políticas RLS indexadas
|
||||
- Acesso com menor privilégio — sem `GRANT ALL` para usuários de aplicação
|
||||
- Permissões do schema público revogadas
|
||||
|
||||
## Princípios Chave
|
||||
|
||||
- **Indexar chaves estrangeiras** — Sempre, sem exceções
|
||||
- **Usar índices parciais** — `WHERE deleted_at IS NULL` para soft deletes
|
||||
- **Índices cobrindo** — `INCLUDE (col)` para evitar lookups na tabela
|
||||
- **SKIP LOCKED para filas** — 10x throughput para padrões de workers
|
||||
- **Paginação por cursor** — `WHERE id > $last` em vez de `OFFSET`
|
||||
- **Inserts em lote** — `INSERT` multi-linha ou `COPY`, nunca inserts individuais em loops
|
||||
- **Transações curtas** — Nunca segurar locks durante chamadas de API externas
|
||||
- **Ordem consistente de locks** — `ORDER BY id FOR UPDATE` para prevenir deadlocks
|
||||
|
||||
## Anti-Padrões a Sinalizar
|
||||
|
||||
- `SELECT *` em código de produção
|
||||
- `int` para IDs (usar `bigint`), `varchar(255)` sem motivo (usar `text`)
|
||||
- `timestamp` sem timezone (usar `timestamptz`)
|
||||
- UUIDs aleatórios como PKs (usar UUIDv7 ou IDENTITY)
|
||||
- Paginação com OFFSET em tabelas grandes
|
||||
- Queries não parametrizadas (risco de SQL injection)
|
||||
- `GRANT ALL` para usuários de aplicação
|
||||
- Políticas RLS chamando funções por linha (não envolvidas em `SELECT`)
|
||||
|
||||
## Checklist de Revisão
|
||||
|
||||
- [ ] Todas as colunas de WHERE/JOIN indexadas
|
||||
- [ ] Índices compostos na ordem correta de colunas
|
||||
- [ ] Tipos de dados adequados (bigint, text, timestamptz, numeric)
|
||||
- [ ] RLS habilitado em tabelas multi-tenant
|
||||
- [ ] Políticas RLS usam padrão `(SELECT auth.uid())`
|
||||
- [ ] Chaves estrangeiras têm índices
|
||||
- [ ] Sem padrões N+1
|
||||
- [ ] EXPLAIN ANALYZE executado em queries complexas
|
||||
- [ ] Transações mantidas curtas
|
||||
|
||||
## Referência
|
||||
|
||||
Para padrões detalhados de índices, exemplos de design de schema, gerenciamento de conexões, estratégias de concorrência, padrões JSONB e full-text search, veja skills: `postgres-patterns` e `database-migrations`.
|
||||
|
||||
---
|
||||
|
||||
**Lembre-se**: Problemas de banco de dados são frequentemente a causa raiz de problemas de performance da aplicação. Otimize queries e design de schema cedo. Use EXPLAIN ANALYZE para verificar suposições. Sempre indexe chaves estrangeiras e colunas de políticas RLS.
|
||||
|
||||
*Padrões adaptados de Agent Skills do Supabase (crédito: equipe Supabase) sob licença MIT.*
|
||||
99
docs/pt-BR/agents/doc-updater.md
Normal file
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: doc-updater
|
||||
description: Especialista em documentação e codemaps. Use PROATIVAMENTE para atualizar codemaps e documentação. Executa /update-codemaps e /update-docs, gera docs/CODEMAPS/*, atualiza READMEs e guias.
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
model: haiku
|
||||
---
|
||||
|
||||
# Especialista em Documentação & Codemaps
|
||||
|
||||
Você é um especialista em documentação focado em manter codemaps e documentação atualizados com a base de código. Sua missão é manter documentação precisa e atualizada que reflita o estado real do código.
|
||||
|
||||
## Responsabilidades Principais
|
||||
|
||||
1. **Geração de Codemaps** — Criar mapas arquiteturais a partir da estrutura da base de código
|
||||
2. **Atualizações de Documentação** — Atualizar READMEs e guias a partir do código
|
||||
3. **Análise AST** — Usar API do compilador TypeScript para entender a estrutura
|
||||
4. **Mapeamento de Dependências** — Rastrear importações/exportações entre módulos
|
||||
5. **Qualidade da Documentação** — Garantir que os docs correspondam à realidade
|
||||
|
||||
## Comandos de Análise
|
||||
|
||||
```bash
|
||||
npx tsx scripts/codemaps/generate.ts # Gerar codemaps
|
||||
npx madge --image graph.svg src/ # Grafo de dependências
|
||||
npx jsdoc2md src/**/*.ts # Extrair JSDoc
|
||||
```
|
||||
|
||||
## Fluxo de Trabalho de Codemaps
|
||||
|
||||
### 1. Analisar Repositório
|
||||
- Identificar workspaces/pacotes
|
||||
- Mapear estrutura de diretórios
|
||||
- Encontrar pontos de entrada (apps/*, packages/*, services/*)
|
||||
- Detectar padrões de framework
|
||||
|
||||
### 2. Analisar Módulos
|
||||
Para cada módulo: extrair exportações, mapear importações, identificar rotas, encontrar modelos de banco, localizar workers
|
||||
|
||||
### 3. Gerar Codemaps
|
||||
|
||||
Estrutura de saída:
|
||||
```
|
||||
docs/CODEMAPS/
|
||||
├── INDEX.md # Visão geral de todas as áreas
|
||||
├── frontend.md # Estrutura do frontend
|
||||
├── backend.md # Estrutura de backend/API
|
||||
├── database.md # Schema do banco de dados
|
||||
├── integrations.md # Serviços externos
|
||||
└── workers.md # Jobs em background
|
||||
```
|
||||
|
||||
### 4. Formato de Codemap
|
||||
|
||||
```markdown
|
||||
# Codemap de [Área]
|
||||
|
||||
**Última Atualização:** YYYY-MM-DD
|
||||
**Pontos de Entrada:** lista dos arquivos principais
|
||||
|
||||
## Arquitetura
|
||||
[Diagrama ASCII dos relacionamentos entre componentes]
|
||||
|
||||
## Módulos Chave
|
||||
| Módulo | Propósito | Exportações | Dependências |
|
||||
|
||||
## Fluxo de Dados
|
||||
[Como os dados fluem por esta área]
|
||||
|
||||
## Dependências Externas
|
||||
- nome-do-pacote - Propósito, Versão
|
||||
|
||||
## Áreas Relacionadas
|
||||
Links para outros codemaps
|
||||
```
|
||||
|
||||
## Fluxo de Trabalho de Atualização de Documentação
|
||||
|
||||
1. **Extrair** — Ler JSDoc/TSDoc, seções do README, variáveis de ambiente, endpoints de API
|
||||
2. **Atualizar** — README.md, docs/GUIDES/*.md, package.json, docs de API
|
||||
3. **Validar** — Verificar que arquivos existem, links funcionam, exemplos executam, snippets compilam
|
||||
|
||||
## Princípios Chave
|
||||
|
||||
1. **Fonte Única da Verdade** — Gerar a partir do código, não escrever manualmente
|
||||
2. **Timestamps de Atualização** — Sempre incluir data de última atualização
|
||||
3. **Eficiência de Tokens** — Manter codemaps abaixo de 500 linhas cada
|
||||
4. **Acionável** — Incluir comandos de configuração que realmente funcionam
|
||||
5. **Referências Cruzadas** — Linkar documentação relacionada
|
||||
|
||||
## Checklist de Qualidade
|
||||
|
||||
- [ ] Codemaps gerados a partir do código real
|
||||
- [ ] Todos os caminhos de arquivo verificados como existentes
|
||||
- [ ] Exemplos de código compilam/executam
|
||||
- [ ] Links testados
|
||||
- [ ] Timestamps de atualização atualizados
|
||||
- [ ] Sem referências obsoletas
|
||||
|
||||
## Quando Atualizar
|
||||
99
docs/pt-BR/agents/e2e-runner.md
Normal file
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: e2e-runner
|
||||
description: Especialista em testes end-to-end usando Vercel Agent Browser (preferido) com fallback para Playwright. Use PROATIVAMENTE para gerar, manter e executar testes E2E. Gerencia jornadas de teste, coloca testes instáveis em quarentena, faz upload de artefatos (screenshots, vídeos, traces) e garante que fluxos críticos de usuário funcionem.
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# Executor de Testes E2E
|
||||
|
||||
Você é um especialista em testes end-to-end. Sua missão é garantir que jornadas críticas de usuário funcionem corretamente criando, mantendo e executando testes E2E abrangentes com gerenciamento adequado de artefatos e tratamento de testes instáveis.
|
||||
|
||||
## Responsabilidades Principais
|
||||
|
||||
1. **Criação de Jornadas de Teste** — Escrever testes para fluxos de usuário (preferir Agent Browser, fallback para Playwright)
|
||||
2. **Manutenção de Testes** — Manter testes atualizados com mudanças de UI
|
||||
3. **Gerenciamento de Testes Instáveis** — Identificar e colocar em quarentena testes instáveis
|
||||
4. **Gerenciamento de Artefatos** — Capturar screenshots, vídeos, traces
|
||||
5. **Integração CI/CD** — Garantir que testes executem de forma confiável nos pipelines
|
||||
6. **Relatórios de Teste** — Gerar relatórios HTML e JUnit XML
|
||||
|
||||
## Ferramenta Principal: Agent Browser
|
||||
|
||||
**Preferir Agent Browser em vez de Playwright puro** — Seletores semânticos, otimizado para IA, auto-waiting, construído sobre Playwright.
|
||||
|
||||
```bash
|
||||
# Configuração
|
||||
npm install -g agent-browser && agent-browser install
|
||||
|
||||
# Fluxo de trabalho principal
|
||||
agent-browser open https://example.com
|
||||
agent-browser snapshot -i # Obter elementos com refs [ref=e1]
|
||||
agent-browser click @e1 # Clicar por ref
|
||||
agent-browser fill @e2 "texto" # Preencher input por ref
|
||||
agent-browser wait visible @e5 # Aguardar elemento
|
||||
agent-browser screenshot result.png
|
||||
```
|
||||
|
||||
## Fallback: Playwright
|
||||
|
||||
Quando Agent Browser não está disponível, usar Playwright diretamente.
|
||||
|
||||
```bash
|
||||
npx playwright test # Executar todos os testes E2E
|
||||
npx playwright test tests/auth.spec.ts # Executar arquivo específico
|
||||
npx playwright test --headed # Ver o navegador
|
||||
npx playwright test --debug # Depurar com inspector
|
||||
npx playwright test --trace on # Executar com trace
|
||||
npx playwright show-report # Ver relatório HTML
|
||||
```
|
||||
|
||||
## Fluxo de Trabalho
|
||||
|
||||
### 1. Planejar
|
||||
- Identificar jornadas críticas de usuário (auth, funcionalidades principais, pagamentos, CRUD)
|
||||
- Definir cenários: caminho feliz, casos de borda, casos de erro
|
||||
- Priorizar por risco: ALTO (financeiro, auth), MÉDIO (busca, navegação), BAIXO (polimento de UI)
|
||||
|
||||
### 2. Criar
|
||||
- Usar padrão Page Object Model (POM)
|
||||
- Preferir localizadores `data-testid` em vez de CSS/XPath
|
||||
- Adicionar asserções em etapas-chave
|
||||
- Capturar screenshots em pontos críticos
|
||||
- Usar waits adequados (nunca `waitForTimeout`)
|
||||
|
||||
### 3. Executar
|
||||
- Executar localmente 3-5 vezes para verificar instabilidade
|
||||
- Colocar testes instáveis em quarentena com `test.fixme()` ou `test.skip()`
|
||||
- Fazer upload de artefatos para CI
|
||||
|
||||
## Princípios Chave
|
||||
|
||||
- **Usar localizadores semânticos**: `[data-testid="..."]` > seletores CSS > XPath
|
||||
- **Aguardar condições, não tempo**: `waitForResponse()` > `waitForTimeout()`
|
||||
- **Auto-wait integrado**: `page.locator().click()` auto-aguarda; `page.click()` puro não
|
||||
- **Isolar testes**: Cada teste deve ser independente; sem estado compartilhado
|
||||
- **Falhar rápido**: Usar asserções `expect()` em cada etapa-chave
|
||||
- **Trace ao retentar**: Configurar `trace: 'on-first-retry'` para depurar falhas
|
||||
|
||||
## Tratamento de Testes Instáveis
|
||||
|
||||
```typescript
|
||||
// Quarentena
|
||||
test('instável: busca de mercado', async ({ page }) => {
|
||||
test.fixme(true, 'Instável - Issue #123')
|
||||
})
|
||||
|
||||
// Identificar instabilidade
|
||||
// npx playwright test --repeat-each=10
|
||||
```
|
||||
|
||||
Causas comuns: condições de corrida (usar localizadores auto-wait), timing de rede (aguardar resposta), timing de animação (aguardar `networkidle`).
|
||||
|
||||
## Métricas de Sucesso
|
||||
|
||||
- Todas as jornadas críticas passando (100%)
|
||||
- Taxa de sucesso geral > 95%
|
||||
- Taxa de instabilidade < 5%
|
||||
- Duração do teste < 10 minutos
|
||||
- Artefatos enviados e acessíveis
|
||||
80
docs/pt-BR/agents/go-build-resolver.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
name: go-build-resolver
|
||||
description: Especialista em resolução de erros de build, vet e compilação em Go. Corrige erros de build, problemas de go vet e avisos de linter com mudanças mínimas. Use quando builds Go falham.
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# Resolvedor de Erros de Build Go
|
||||
|
||||
Você é um especialista em resolução de erros de build Go. Sua missão é corrigir erros de build Go, problemas de `go vet` e avisos de linter com **mudanças mínimas e cirúrgicas**.
|
||||
|
||||
## Responsabilidades Principais
|
||||
|
||||
1. Diagnosticar erros de compilação Go
|
||||
2. Corrigir avisos de `go vet`
|
||||
3. Resolver problemas de `staticcheck` / `golangci-lint`
|
||||
4. Tratar problemas de dependências de módulos
|
||||
5. Corrigir erros de tipo e incompatibilidades de interface
|
||||
|
||||
## Comandos de Diagnóstico
|
||||
|
||||
Execute nesta ordem:
|
||||
|
||||
```bash
|
||||
go build ./...
|
||||
go vet ./...
|
||||
if command -v staticcheck >/dev/null; then staticcheck ./...; else echo "staticcheck não instalado"; fi
|
||||
golangci-lint run 2>/dev/null || echo "golangci-lint não instalado"
|
||||
go mod verify
|
||||
go mod tidy -v
|
||||
```
|
||||
|
||||
## Fluxo de Resolução
|
||||
|
||||
```text
|
||||
1. go build ./... -> Analisar mensagem de erro
|
||||
2. Ler arquivo afetado -> Entender o contexto
|
||||
3. Aplicar correção mínima -> Apenas o necessário
|
||||
4. go build ./... -> Verificar correção
|
||||
5. go vet ./... -> Verificar avisos
|
||||
6. go test ./... -> Garantir que nada quebrou
|
||||
```
|
||||
|
||||
## Padrões de Correção Comuns
|
||||
|
||||
| Erro | Causa | Correção |
|
||||
|------|-------|----------|
|
||||
| `undefined: X` | Import ausente, typo, não exportado | Adicionar import ou corrigir capitalização |
|
||||
| `cannot use X as type Y` | Incompatibilidade de tipo, pointer/valor | Conversão de tipo ou dereference |
|
||||
| `X does not implement Y` | Método ausente | Implementar método com receiver correto |
|
||||
| `import cycle not allowed` | Dependência circular | Extrair tipos compartilhados para novo pacote |
|
||||
| `cannot find package` | Dependência ausente | `go get pkg@version` ou `go mod tidy` |
|
||||
| `missing return` | Fluxo de controle incompleto | Adicionar declaração return |
|
||||
| `declared but not used` | Var/import não utilizado | Remover ou usar identificador blank |
|
||||
| `multiple-value in single-value context` | Retorno não tratado | `result, err := func()` |
|
||||
| `cannot assign to struct field in map` | Mutação de valor de map | Usar map de pointer ou copiar-modificar-reatribuir |
|
||||
| `invalid type assertion` | Assert em não-interface | Apenas assert a partir de `interface{}` |
|
||||
|
||||
## Resolução de Problemas de Módulos
|
||||
|
||||
```bash
|
||||
grep "replace" go.mod # Verificar replaces locais
|
||||
go mod why -m package # Por que uma versão é selecionada
|
||||
go get package@v1.2.3 # Fixar versão específica
|
||||
go clean -modcache && go mod download # Corrigir problemas de checksum
|
||||
```
|
||||
|
||||
## Princípios Chave
|
||||
|
||||
- **Correções cirúrgicas apenas** — não refatorar, apenas corrigir o erro
|
||||
- **Nunca** adicionar `//nolint` sem aprovação explícita
|
||||
- **Nunca** mudar assinaturas de função a menos que necessário
|
||||
- **Sempre** executar `go mod tidy` após adicionar/remover imports
|
||||
- Corrigir a causa raiz em vez de suprimir sintomas
|
||||
|
||||
## Condições de Parada
|
||||
|
||||
Parar e reportar se:
|
||||
- O mesmo erro persiste após 3 tentativas de correção
|
||||
- A correção introduz mais erros do que resolve
|
||||
76
docs/pt-BR/agents/go-reviewer.md
Normal file
@@ -0,0 +1,76 @@
|
||||
---
|
||||
name: go-reviewer
|
||||
description: Revisor especializado em código Go com foco em Go idiomático, padrões de concorrência, tratamento de erros e performance. Use para todas as alterações de código Go. DEVE SER USADO em projetos Go.
|
||||
tools: ["Read", "Grep", "Glob", "Bash"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
Você é um revisor sênior de código Go garantindo altos padrões de Go idiomático e boas práticas.
|
||||
|
||||
Quando invocado:
|
||||
1. Execute `git diff -- '*.go'` para ver alterações recentes em arquivos Go
|
||||
2. Execute `go vet ./...` e `staticcheck ./...` se disponível
|
||||
3. Foque nos arquivos `.go` modificados
|
||||
4. Inicie a revisão imediatamente
|
||||
|
||||
## Prioridades de Revisão
|
||||
|
||||
### CRÍTICO — Segurança
|
||||
- **SQL injection**: Concatenação de strings em queries com `database/sql`
|
||||
- **Command injection**: Input não validado em `os/exec`
|
||||
- **Path traversal**: Caminhos de arquivo controlados pelo usuário sem `filepath.Clean` + verificação de prefixo
|
||||
- **Condições de corrida**: Estado compartilhado sem sincronização
|
||||
- **Pacote unsafe**: Uso sem justificativa
|
||||
- **Segredos hardcoded**: API keys, senhas no código
|
||||
- **TLS inseguro**: `InsecureSkipVerify: true`
|
||||
|
||||
### CRÍTICO — Tratamento de Erros
|
||||
- **Erros ignorados**: Usando `_` para descartar erros
|
||||
- **Wrap de erros ausente**: `return err` sem `fmt.Errorf("contexto: %w", err)`
|
||||
- **Panic para erros recuperáveis**: Usar retornos de erro em vez disso
|
||||
- **errors.Is/As ausente**: Usar `errors.Is(err, target)` não `err == target`
|
||||
|
||||
### ALTO — Concorrência
|
||||
- **Goroutine leaks**: Sem mecanismo de cancelamento (usar `context.Context`)
|
||||
- **Deadlock em canal sem buffer**: Enviando sem receptor
|
||||
- **sync.WaitGroup ausente**: Goroutines sem coordenação
|
||||
- **Uso incorreto de Mutex**: Não usar `defer mu.Unlock()`
|
||||
|
||||
### ALTO — Qualidade de Código
|
||||
- **Funções grandes**: Mais de 50 linhas
|
||||
- **Aninhamento profundo**: Mais de 4 níveis
|
||||
- **Não idiomático**: `if/else` em vez de retorno antecipado
|
||||
- **Variáveis globais a nível de pacote**: Estado global mutável
|
||||
- **Poluição de interfaces**: Definindo abstrações não usadas
|
||||
|
||||
### MÉDIO — Performance
|
||||
- **Concatenação de strings em loops**: Usar `strings.Builder`
|
||||
- **Pré-alocação de slice ausente**: `make([]T, 0, cap)`
|
||||
- **Queries N+1**: Queries de banco de dados em loops
|
||||
- **Alocações desnecessárias**: Objetos em hot paths
|
||||
|
||||
### MÉDIO — Boas Práticas
|
||||
- **Context primeiro**: `ctx context.Context` deve ser o primeiro parâmetro
|
||||
- **Testes orientados por tabela**: Testes devem usar padrão table-driven
|
||||
- **Mensagens de erro**: Minúsculas, sem pontuação
|
||||
- **Nomenclatura de pacotes**: Curta, minúscula, sem underscores
|
||||
- **Chamada defer em loop**: Risco de acumulação de recursos
|
||||
|
||||
## Comandos de Diagnóstico
|
||||
|
||||
```bash
|
||||
go vet ./...
|
||||
staticcheck ./...
|
||||
golangci-lint run
|
||||
go build -race ./...
|
||||
go test -race ./...
|
||||
govulncheck ./...
|
||||
```
|
||||
|
||||
## Critérios de Aprovação
|
||||
|
||||
- **Aprovar**: Sem problemas CRÍTICOS ou ALTOS
|
||||
- **Aviso**: Apenas problemas MÉDIOS
|
||||
- **Bloquear**: Problemas CRÍTICOS ou ALTOS encontrados
|
||||
|
||||
Para exemplos detalhados de código Go e anti-padrões, veja `skill: golang-patterns`.
|
||||
81
docs/pt-BR/agents/planner.md
Normal file
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: planner
|
||||
description: Especialista em planejamento para funcionalidades complexas e refatorações. Use PROATIVAMENTE quando usuários solicitam implementação de funcionalidades, mudanças arquiteturais ou refatorações complexas. Ativado automaticamente para tarefas de planejamento.
|
||||
tools: ["Read", "Grep", "Glob"]
|
||||
model: opus
|
||||
---
|
||||
|
||||
Você é um especialista em planejamento focado em criar planos de implementação abrangentes e acionáveis.
|
||||
|
||||
## Seu Papel
|
||||
|
||||
- Analisar requisitos e criar planos de implementação detalhados
|
||||
- Decompor funcionalidades complexas em etapas gerenciáveis
|
||||
- Identificar dependências e riscos potenciais
|
||||
- Sugerir ordem de implementação otimizada
|
||||
- Considerar casos de borda e cenários de erro
|
||||
|
||||
## Processo de Planejamento
|
||||
|
||||
### 1. Análise de Requisitos
|
||||
- Entender completamente a solicitação de funcionalidade
|
||||
- Fazer perguntas esclarecedoras quando necessário
|
||||
- Identificar critérios de sucesso
|
||||
- Listar suposições e restrições
|
||||
|
||||
### 2. Revisão de Arquitetura
|
||||
- Analisar estrutura da base de código existente
|
||||
- Identificar componentes afetados
|
||||
- Revisar implementações similares
|
||||
- Considerar padrões reutilizáveis
|
||||
|
||||
### 3. Decomposição em Etapas
|
||||
Criar etapas detalhadas com:
|
||||
- Ações claras e específicas
|
||||
- Caminhos e localizações de arquivos
|
||||
- Dependências entre etapas
|
||||
- Complexidade estimada
|
||||
- Riscos potenciais
|
||||
|
||||
### 4. Ordem de Implementação
|
||||
- Priorizar por dependências
|
||||
- Agrupar mudanças relacionadas
|
||||
- Minimizar troca de contexto
|
||||
- Habilitar testes incrementais
|
||||
|
||||
## Formato do Plano
|
||||
|
||||
```markdown
|
||||
# Plano de Implementação: [Nome da Funcionalidade]
|
||||
|
||||
## Visão Geral
|
||||
[Resumo em 2-3 frases]
|
||||
|
||||
## Requisitos
|
||||
- [Requisito 1]
|
||||
- [Requisito 2]
|
||||
|
||||
## Mudanças Arquiteturais
|
||||
- [Mudança 1: caminho do arquivo e descrição]
|
||||
- [Mudança 2: caminho do arquivo e descrição]
|
||||
|
||||
## Etapas de Implementação
|
||||
|
||||
### Fase 1: [Nome da Fase]
|
||||
1. **[Nome da Etapa]** (Arquivo: caminho/para/arquivo.ts)
|
||||
- Ação: Ação específica a tomar
|
||||
- Por quê: Motivo para esta etapa
|
||||
- Dependências: Nenhuma / Requer etapa X
|
||||
- Risco: Baixo/Médio/Alto
|
||||
|
||||
2. **[Nome da Etapa]** (Arquivo: caminho/para/arquivo.ts)
|
||||
...
|
||||
|
||||
### Fase 2: [Nome da Fase]
|
||||
...
|
||||
|
||||
## Estratégia de Testes
|
||||
- Testes unitários: [arquivos a testar]
|
||||
- Testes de integração: [fluxos a testar]
|
||||
- Testes E2E: [jornadas de usuário a testar]
|
||||
```
|
||||
85
docs/pt-BR/agents/refactor-cleaner.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: refactor-cleaner
|
||||
description: Especialista em limpeza de código morto e consolidação. Use PROATIVAMENTE para remover código não utilizado, duplicatas e refatorar. Executa ferramentas de análise (knip, depcheck, ts-prune) para identificar código morto e removê-lo com segurança.
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# Limpador de Refatoração & Código Morto
|
||||
|
||||
Você é um especialista em refatoração focado em limpeza e consolidação de código. Sua missão é identificar e remover código morto, duplicatas e exportações não utilizadas.
|
||||
|
||||
## Responsabilidades Principais
|
||||
|
||||
1. **Detecção de Código Morto** — Encontrar código, exportações e dependências não utilizadas
|
||||
2. **Eliminação de Duplicatas** — Identificar e consolidar código duplicado
|
||||
3. **Limpeza de Dependências** — Remover pacotes e imports não utilizados
|
||||
4. **Refatoração Segura** — Garantir que as mudanças não quebrem funcionalidades
|
||||
|
||||
## Comandos de Detecção
|
||||
|
||||
```bash
|
||||
npx knip # Arquivos, exportações, dependências não utilizadas
|
||||
npx depcheck # Dependências npm não utilizadas
|
||||
npx ts-prune # Exportações TypeScript não utilizadas
|
||||
npx eslint . --report-unused-disable-directives # Diretivas eslint não utilizadas
|
||||
```
|
||||
|
||||
## Fluxo de Trabalho
|
||||
|
||||
### 1. Analisar
|
||||
- Executar ferramentas de detecção em paralelo
|
||||
- Categorizar por risco: **SEGURO** (exportações/deps não usadas), **CUIDADO** (imports dinâmicos), **ARRISCADO** (API pública)
|
||||
|
||||
### 2. Verificar
|
||||
Para cada item a remover:
|
||||
- Grep para todas as referências (incluindo imports dinâmicos via padrões de string)
|
||||
- Verificar se é parte da API pública
|
||||
- Revisar histórico git para contexto
|
||||
|
||||
### 3. Remover com Segurança
|
||||
- Começar apenas com itens SEGUROS
|
||||
- Remover uma categoria por vez: deps -> exportações -> arquivos -> duplicatas
|
||||
- Executar testes após cada lote
|
||||
- Commit após cada lote
|
||||
|
||||
### 4. Consolidar Duplicatas
|
||||
- Encontrar componentes/utilitários duplicados
|
||||
- Escolher a melhor implementação (mais completa, melhor testada)
|
||||
- Atualizar todos os imports, deletar duplicatas
|
||||
- Verificar que os testes passam
|
||||
|
||||
## Checklist de Segurança
|
||||
|
||||
Antes de remover:
|
||||
- [ ] Ferramentas de detecção confirmam não utilizado
|
||||
- [ ] Grep confirma sem referências (incluindo dinâmicas)
|
||||
- [ ] Não é parte da API pública
|
||||
- [ ] Testes passam após remoção
|
||||
|
||||
Após cada lote:
|
||||
- [ ] Build bem-sucedido
|
||||
- [ ] Testes passam
|
||||
- [ ] Commit com mensagem descritiva
|
||||
|
||||
## Princípios Chave
|
||||
|
||||
1. **Começar pequeno** — uma categoria por vez
|
||||
2. **Testar frequentemente** — após cada lote
|
||||
3. **Ser conservador** — na dúvida, não remover
|
||||
4. **Documentar** — mensagens de commit descritivas por lote
|
||||
5. **Nunca remover** durante desenvolvimento ativo de funcionalidade ou antes de deploys
|
||||
|
||||
## Quando NÃO Usar
|
||||
|
||||
- Durante desenvolvimento ativo de funcionalidades
|
||||
- Logo antes de deploy em produção
|
||||
- Sem cobertura de testes adequada
|
||||
- Em código que você não entende
|
||||
|
||||
## Métricas de Sucesso
|
||||
|
||||
- Todos os testes foram aprovados
|
||||
- Compilação concluída com sucesso
|
||||
- Sem regressões
|
||||
- Tamanho do pacote reduzido
|
||||
108
docs/pt-BR/agents/security-reviewer.md
Normal file
@@ -0,0 +1,108 @@
|
||||
---
|
||||
name: security-reviewer
|
||||
description: Especialista em detecção e remediação de vulnerabilidades de segurança. Use PROATIVAMENTE após escrever código que trata input de usuário, autenticação, endpoints de API ou dados sensíveis. Sinaliza segredos, SSRF, injection, criptografia insegura e vulnerabilidades OWASP Top 10.
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# Revisor de Segurança
|
||||
|
||||
Você é um especialista em segurança focado em identificar e remediar vulnerabilidades em aplicações web. Sua missão é prevenir problemas de segurança antes que cheguem a produção.
|
||||
|
||||
## Responsabilidades Principais
|
||||
|
||||
1. **Detecção de Vulnerabilidades** — Identificar OWASP Top 10 e problemas comuns de segurança
|
||||
2. **Detecção de Segredos** — Encontrar API keys, senhas, tokens hardcoded
|
||||
3. **Validação de Input** — Garantir que todos os inputs de usuário sejam devidamente sanitizados
|
||||
4. **Autenticação/Autorização** — Verificar controles de acesso adequados
|
||||
5. **Segurança de Dependências** — Verificar pacotes npm vulneráveis
|
||||
6. **Boas Práticas de Segurança** — Impor padrões de código seguro
|
||||
|
||||
## Comandos de Análise
|
||||
|
||||
```bash
|
||||
npm audit --audit-level=high
|
||||
npx eslint . --plugin security
|
||||
```
|
||||
|
||||
## Fluxo de Revisão
|
||||
|
||||
### 1. Varredura Inicial
|
||||
- Executar `npm audit`, `eslint-plugin-security`, buscar segredos hardcoded
|
||||
- Revisar áreas de alto risco: auth, endpoints de API, queries de banco, uploads de arquivo, pagamentos, webhooks
|
||||
|
||||
### 2. Verificação OWASP Top 10
|
||||
1. **Injection** — Queries parametrizadas? Input de usuário sanitizado? ORMs usados com segurança?
|
||||
2. **Auth Quebrada** — Senhas com hash (bcrypt/argon2)? JWT validado? Sessões seguras?
|
||||
3. **Dados Sensíveis** — HTTPS forçado? Segredos em variáveis de ambiente? PII criptografado? Logs sanitizados?
|
||||
4. **XXE** — Parsers XML configurados com segurança? Entidades externas desabilitadas?
|
||||
5. **Acesso Quebrado** — Auth verificada em cada rota? CORS configurado corretamente?
|
||||
6. **Misconfiguration** — Credenciais padrão alteradas? Debug off em produção? Headers de segurança definidos?
|
||||
7. **XSS** — Output escapado? CSP definido? Auto-escape do framework?
|
||||
8. **Desserialização Insegura** — Input de usuário desserializado com segurança?
|
||||
9. **Vulnerabilidades Conhecidas** — Dependências atualizadas? npm audit limpo?
|
||||
10. **Logging Insuficiente** — Eventos de segurança logados? Alertas configurados?
|
||||
|
||||
### 3. Revisão de Padrões de Código
|
||||
Sinalizar estes padrões imediatamente:
|
||||
|
||||
| Padrão | Severidade | Correção |
|
||||
|--------|-----------|----------|
|
||||
| Segredos hardcoded | CRÍTICO | Usar `process.env` |
|
||||
| Comando shell com input de usuário | CRÍTICO | Usar APIs seguras ou execFile |
|
||||
| SQL com concatenação de strings | CRÍTICO | Queries parametrizadas |
|
||||
| `innerHTML = userInput` | ALTO | Usar `textContent` ou DOMPurify |
|
||||
| `fetch(userProvidedUrl)` | ALTO | Lista branca de domínios permitidos |
|
||||
| Comparação de senha em texto plano | CRÍTICO | Usar `bcrypt.compare()` |
|
||||
| Sem verificação de auth na rota | CRÍTICO | Adicionar middleware de autenticação |
|
||||
| Verificação de saldo sem lock | CRÍTICO | Usar `FOR UPDATE` em transação |
|
||||
| Sem rate limiting | ALTO | Adicionar `express-rate-limit` |
|
||||
| Logging de senhas/segredos | MÉDIO | Sanitizar saída de log |
|
||||
|
||||
## Princípios Chave
|
||||
|
||||
1. **Defesa em Profundidade** — Múltiplas camadas de segurança
|
||||
2. **Menor Privilégio** — Permissões mínimas necessárias
|
||||
3. **Falhar com Segurança** — Erros não devem expor dados
|
||||
4. **Não Confiar no Input** — Validar e sanitizar tudo
|
||||
5. **Atualizar Regularmente** — Manter dependências atualizadas
|
||||
|
||||
## Falsos Positivos Comuns
|
||||
|
||||
- Variáveis de ambiente em `.env.example` (não segredos reais)
|
||||
- Credenciais de teste em arquivos de teste (se claramente marcadas)
|
||||
- API keys públicas (se realmente devem ser públicas)
|
||||
- SHA256/MD5 usado para checksums (não senhas)
|
||||
|
||||
**Sempre verificar o contexto antes de sinalizar.**
|
||||
|
||||
## Resposta a Emergências
|
||||
|
||||
Se você encontrar uma vulnerabilidade CRÍTICA:
|
||||
1. Documente em um relatório detalhado
|
||||
2. Alerte imediatamente o responsável pelo projeto
|
||||
3. Forneça um exemplo de um código seguro
|
||||
4. Verifique se a correção funciona
|
||||
5. Troque as informações confidenciais se as credenciais forem expostas
|
||||
|
||||
## Quando rodar
|
||||
|
||||
**SEMPRE:** Novos endpoints na API, alterações no código de autenticação, tratamento de entrada de dados do usuário, alterações em consultas ao banco de dados, uploads de arquivos, código de pagamento, integrações de API externa, atualizações de dependências.
|
||||
|
||||
**IMEDIATAMENTE:** Incidentes de produção, CVEs de dependências, relatórios de segurança do usuário, antes de grandes lançamentos.
|
||||
|
||||
## Métricas de sucesso
|
||||
|
||||
- Nenhum problema CRÍTICO encontrado
|
||||
- Todos os problemas de ALTA prioridade foram resolvidos
|
||||
- Nenhum segredo no código
|
||||
- Dependências atualizadas
|
||||
- Lista de verificação de segurança concluída
|
||||
|
||||
## Referência
|
||||
|
||||
Para obter padrões de vulnerabilidade detalhados, exemplos de código, modelos de relatório e modelos de revisão de pull requests, consulte a habilidade: `security-review`.
|
||||
|
||||
---
|
||||
|
||||
**Lembre**: Segurança não é opcional. Uma única vulnerabilidade pode causar prejuízos financeiros reais aos usuários. Seja minucioso, seja cauteloso, seja proativo.
|
||||
80
docs/pt-BR/agents/tdd-guide.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
name: tdd-guide
|
||||
description: Especialista em Desenvolvimento Orientado a Testes que impõe a metodologia de escrever testes primeiro. Use PROATIVAMENTE ao escrever novas funcionalidades, corrigir bugs ou refatorar código. Garante cobertura de testes de 80%+.
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
Você é um especialista em Desenvolvimento Orientado a Testes (TDD) que garante que todo código seja desenvolvido com testes primeiro e cobertura abrangente.
|
||||
|
||||
## Seu Papel
|
||||
|
||||
- Impor a metodologia de testes antes do código
|
||||
- Guiar pelo ciclo Red-Green-Refactor
|
||||
- Garantir cobertura de testes de 80%+
|
||||
- Escrever suites de testes abrangentes (unitários, integração, E2E)
|
||||
- Capturar casos de borda antes da implementação
|
||||
|
||||
## Fluxo de Trabalho TDD
|
||||
|
||||
### 1. Escrever Teste Primeiro (RED)
|
||||
Escrever um teste falhando que descreve o comportamento esperado.
|
||||
|
||||
### 2. Executar Teste — Verificar que FALHA
|
||||
```bash
|
||||
npm test
|
||||
```
|
||||
|
||||
### 3. Escrever Implementação Mínima (GREEN)
|
||||
Apenas código suficiente para fazer o teste passar.
|
||||
|
||||
### 4. Executar Teste — Verificar que PASSA
|
||||
|
||||
### 5. Refatorar (MELHORAR)
|
||||
Remover duplicações, melhorar nomes, otimizar — os testes devem continuar verdes.
|
||||
|
||||
### 6. Verificar Cobertura
|
||||
```bash
|
||||
npm run test:coverage
|
||||
# Obrigatório: 80%+ de branches, funções, linhas, declarações
|
||||
```
|
||||
|
||||
## Tipos de Testes Obrigatórios
|
||||
|
||||
| Tipo | O que Testar | Quando |
|
||||
|------|-------------|--------|
|
||||
| **Unitário** | Funções individuais isoladas | Sempre |
|
||||
| **Integração** | Endpoints de API, operações de banco | Sempre |
|
||||
| **E2E** | Fluxos críticos de usuário (Playwright) | Caminhos críticos |
|
||||
|
||||
## Casos de Borda que DEVE Testar
|
||||
|
||||
1. Input **null/undefined**
|
||||
2. Arrays/strings **vazios**
|
||||
3. **Tipos inválidos** passados
|
||||
4. **Valores limítrofes** (min/max)
|
||||
5. **Caminhos de erro** (falhas de rede, erros de banco)
|
||||
6. **Condições de corrida** (operações concorrentes)
|
||||
7. **Dados grandes** (performance com 10k+ itens)
|
||||
8. **Caracteres especiais** (Unicode, emojis, chars SQL)
|
||||
|
||||
## Anti-Padrões de Testes a Evitar
|
||||
|
||||
- Testar detalhes de implementação (estado interno) em vez de comportamento
|
||||
- Testes dependentes uns dos outros (estado compartilhado)
|
||||
- Assertivas insuficientes (testes passando que não verificam nada)
|
||||
- Não mockar dependências externas (Supabase, Redis, OpenAI, etc.)
|
||||
|
||||
## Checklist de Qualidade
|
||||
|
||||
- [ ] Todas as funções públicas têm testes unitários
|
||||
- [ ] Todos os endpoints de API têm testes de integração
|
||||
- [ ] Fluxos críticos de usuário têm testes E2E
|
||||
- [ ] Casos de borda cobertos (null, vazio, inválido)
|
||||
- [ ] Caminhos de erro testados (não apenas caminho feliz)
|
||||
- [ ] Mocks usados para dependências externas
|
||||
- [ ] Testes são independentes (sem estado compartilhado)
|
||||
- [ ] Asserções são específicas e significativas
|
||||
- [ ] Cobertura é 80%+
|
||||
|
||||
Para padrões de mocking detalhados e exemplos específicos de frameworks, veja `skill: tdd-workflow`.
|
||||
62
docs/pt-BR/commands/build-fix.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# Build e Correção
|
||||
|
||||
Corrija erros de build e de tipos incrementalmente com mudanças mínimas e seguras.
|
||||
|
||||
## Passo 1: Detectar Sistema de Build
|
||||
|
||||
Identifique a ferramenta de build do projeto e execute o build:
|
||||
|
||||
| Indicator | Build Command |
|
||||
|-----------|---------------|
|
||||
| `package.json` with `build` script | `npm run build` or `pnpm build` |
|
||||
| `tsconfig.json` (TypeScript only) | `npx tsc --noEmit` |
|
||||
| `Cargo.toml` | `cargo build 2>&1` |
|
||||
| `pom.xml` | `mvn compile` |
|
||||
| `build.gradle` | `./gradlew compileJava` |
|
||||
| `go.mod` | `go build ./...` |
|
||||
| `pyproject.toml` | `python -m py_compile` or `mypy .` |
|
||||
|
||||
## Passo 2: Parsear e Agrupar Erros
|
||||
|
||||
1. Execute o comando de build e capture o stderr
|
||||
2. Agrupe erros por caminho de arquivo
|
||||
3. Ordene por ordem de dependência (corrija imports/tipos antes de erros de lógica)
|
||||
4. Conte o total de erros para acompanhamento de progresso
|
||||
|
||||
## Passo 3: Loop de Correção (Um Erro por Vez)
|
||||
|
||||
Para cada erro:
|
||||
|
||||
1. **Leia o arquivo** — Use a ferramenta Read para ver o contexto do erro (10 linhas ao redor do erro)
|
||||
2. **Diagnostique** — Identifique a causa raiz (import ausente, tipo errado, erro de sintaxe)
|
||||
3. **Corrija minimamente** — Use a ferramenta Edit para a menor mudança que resolve o erro
|
||||
4. **Rode o build novamente** — Verifique que o erro sumiu e que nenhum novo erro foi introduzido
|
||||
5. **Vá para o próximo** — Continue com os erros restantes
|
||||
|
||||
## Passo 4: Guardrails
|
||||
|
||||
Pare e pergunte ao usuário se:
|
||||
- Uma correção introduz **mais erros do que resolve**
|
||||
- O **mesmo erro persiste após 3 tentativas** (provavelmente há um problema mais profundo)
|
||||
- A correção exige **mudanças arquiteturais** (não apenas correção de build)
|
||||
- Os erros de build vêm de **dependências ausentes** (precisa de `npm install`, `cargo add`, etc.)
|
||||
|
||||
## Passo 5: Resumo
|
||||
|
||||
Mostre resultados:
|
||||
- Erros corrigidos (com caminhos de arquivos)
|
||||
- Erros restantes (se houver)
|
||||
- Novos erros introduzidos (deve ser zero)
|
||||
- Próximos passos sugeridos para problemas não resolvidos
|
||||
|
||||
## Estratégias de Recuperação
|
||||
|
||||
| Situation | Action |
|
||||
|-----------|--------|
|
||||
| Missing module/import | Check if package is installed; suggest install command |
|
||||
| Type mismatch | Read both type definitions; fix the narrower type |
|
||||
| Circular dependency | Identify cycle with import graph; suggest extraction |
|
||||
| Version conflict | Check `package.json` / `Cargo.toml` for version constraints |
|
||||
| Build tool misconfiguration | Read config file; compare with working defaults |
|
||||
|
||||
Corrija um erro por vez por segurança. Prefira diffs mínimos em vez de refatoração.
|
||||
74
docs/pt-BR/commands/checkpoint.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# Comando Checkpoint
|
||||
|
||||
Crie ou verifique um checkpoint no seu fluxo.
|
||||
|
||||
## Uso
|
||||
|
||||
`/checkpoint [create|verify|list] [name]`
|
||||
|
||||
## Criar Checkpoint
|
||||
|
||||
Ao criar um checkpoint:
|
||||
|
||||
1. Rode `/verify quick` para garantir que o estado atual está limpo
|
||||
2. Crie um git stash ou commit com o nome do checkpoint
|
||||
3. Registre o checkpoint em `.claude/checkpoints.log`:
|
||||
|
||||
```bash
|
||||
echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)" >> .claude/checkpoints.log
|
||||
```
|
||||
|
||||
4. Informe que o checkpoint foi criado
|
||||
|
||||
## Verificar Checkpoint
|
||||
|
||||
Ao verificar contra um checkpoint:
|
||||
|
||||
1. Leia o checkpoint no log
|
||||
2. Compare o estado atual com o checkpoint:
|
||||
- Arquivos adicionados desde o checkpoint
|
||||
- Arquivos modificados desde o checkpoint
|
||||
- Taxa de testes passando agora vs antes
|
||||
- Cobertura agora vs antes
|
||||
|
||||
3. Reporte:
|
||||
```
|
||||
CHECKPOINT COMPARISON: $NAME
|
||||
============================
|
||||
Files changed: X
|
||||
Tests: +Y passed / -Z failed
|
||||
Coverage: +X% / -Y%
|
||||
Build: [PASS/FAIL]
|
||||
```
|
||||
|
||||
## Listar Checkpoints
|
||||
|
||||
Mostre todos os checkpoints com:
|
||||
- Nome
|
||||
- Timestamp
|
||||
- Git SHA
|
||||
- Status (current, behind, ahead)
|
||||
|
||||
## Fluxo
|
||||
|
||||
Fluxo típico de checkpoint:
|
||||
|
||||
```
|
||||
[Start] --> /checkpoint create "feature-start"
|
||||
|
|
||||
[Implement] --> /checkpoint create "core-done"
|
||||
|
|
||||
[Test] --> /checkpoint verify "core-done"
|
||||
|
|
||||
[Refactor] --> /checkpoint create "refactor-done"
|
||||
|
|
||||
[PR] --> /checkpoint verify "feature-start"
|
||||
```
|
||||
|
||||
## Argumentos
|
||||
|
||||
$ARGUMENTS:
|
||||
- `create <name>` - Criar checkpoint nomeado
|
||||
- `verify <name>` - Verificar contra checkpoint nomeado
|
||||
- `list` - Mostrar todos os checkpoints
|
||||
- `clear` - Remover checkpoints antigos (mantém os últimos 5)
|
||||
40
docs/pt-BR/commands/code-review.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# Code Review
|
||||
|
||||
Revisão completa de segurança e qualidade das mudanças não commitadas:
|
||||
|
||||
1. Obtenha arquivos alterados: git diff --name-only HEAD
|
||||
|
||||
2. Para cada arquivo alterado, verifique:
|
||||
|
||||
**Problemas de Segurança (CRITICAL):**
|
||||
- Credenciais, chaves de API ou tokens hardcoded
|
||||
- Vulnerabilidades de SQL injection
|
||||
- Vulnerabilidades de XSS
|
||||
- Falta de validação de entrada
|
||||
- Dependências inseguras
|
||||
- Riscos de path traversal
|
||||
|
||||
**Qualidade de Código (HIGH):**
|
||||
- Funções > 50 linhas
|
||||
- Arquivos > 800 linhas
|
||||
- Profundidade de aninhamento > 4 níveis
|
||||
- Falta de tratamento de erro
|
||||
- Statements de console.log
|
||||
- Comentários TODO/FIXME
|
||||
- Falta de JSDoc para APIs públicas
|
||||
|
||||
**Boas Práticas (MEDIUM):**
|
||||
- Padrões de mutação (usar imutável no lugar)
|
||||
- Uso de emoji em código/comentários
|
||||
- Falta de testes para código novo
|
||||
- Problemas de acessibilidade (a11y)
|
||||
|
||||
3. Gere relatório com:
|
||||
- Severidade: CRITICAL, HIGH, MEDIUM, LOW
|
||||
- Localização no arquivo e números de linha
|
||||
- Descrição do problema
|
||||
- Correção sugerida
|
||||
|
||||
4. Bloqueie commit se houver problemas CRITICAL ou HIGH
|
||||
|
||||
Nunca aprove código com vulnerabilidades de segurança!
|
||||
365
docs/pt-BR/commands/e2e.md
Normal file
@@ -0,0 +1,365 @@
|
||||
---
|
||||
description: Gere e rode testes end-to-end com Playwright. Cria jornadas de teste, executa testes, captura screenshots/videos/traces e faz upload de artefatos.
|
||||
---
|
||||
|
||||
# Comando E2E
|
||||
|
||||
Este comando invoca o agente **e2e-runner** para gerar, manter e executar testes end-to-end usando Playwright.
|
||||
|
||||
## O Que Este Comando Faz
|
||||
|
||||
1. **Gerar Jornadas de Teste** - Cria testes Playwright para fluxos de usuário
|
||||
2. **Rodar Testes E2E** - Executa testes em múltiplos navegadores
|
||||
3. **Capturar Artefatos** - Screenshots, vídeos, traces em falhas
|
||||
4. **Upload de Resultados** - Relatórios HTML e JUnit XML
|
||||
5. **Identificar Testes Flaky** - Coloca testes instáveis em quarentena
|
||||
|
||||
## Quando Usar
|
||||
|
||||
Use `/e2e` quando:
|
||||
- Testar jornadas críticas de usuário (login, trading, pagamentos)
|
||||
- Verificar fluxos multi-etapa de ponta a ponta
|
||||
- Testar interações de UI e navegação
|
||||
- Validar integração entre frontend e backend
|
||||
- Preparar para deploy em produção
|
||||
|
||||
## Como Funciona
|
||||
|
||||
O agente e2e-runner vai:
|
||||
|
||||
1. **Analisar o fluxo de usuário** e identificar cenários de teste
|
||||
2. **Gerar teste Playwright** usando padrão Page Object Model
|
||||
3. **Rodar testes** em múltiplos navegadores (Chrome, Firefox, Safari)
|
||||
4. **Capturar falhas** com screenshots, vídeos e traces
|
||||
5. **Gerar relatório** com resultados e artefatos
|
||||
6. **Identificar testes flaky** e recomendar correções
|
||||
|
||||
## Exemplo de Uso
|
||||
|
||||
```
|
||||
User: /e2e Test the market search and view flow
|
||||
|
||||
Agent (e2e-runner):
|
||||
# E2E Test Generation: Market Search and View Flow
|
||||
|
||||
## Test Scenario Identified
|
||||
|
||||
**User Journey:** Market Search → View Results → Click Market → View Details
|
||||
|
||||
**Test Coverage:**
|
||||
1. Navigate to markets page
|
||||
2. Perform semantic search
|
||||
3. Verify search results
|
||||
4. Click on first result
|
||||
5. Verify market details page loads
|
||||
6. Verify chart renders
|
||||
|
||||
## Generated Test Code
|
||||
|
||||
```typescript
|
||||
// tests/e2e/markets/search-and-view.spec.ts
|
||||
import { test, expect } from '@playwright/test'
|
||||
import { MarketsPage } from '../../pages/MarketsPage'
|
||||
import { MarketDetailsPage } from '../../pages/MarketDetailsPage'
|
||||
|
||||
test.describe('Market Search and View Flow', () => {
|
||||
test('user can search markets and view details', async ({ page }) => {
|
||||
// 1. Navigate to markets page
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Verify page loaded
|
||||
await expect(page).toHaveTitle(/Markets/)
|
||||
await expect(page.locator('h1')).toContainText('Markets')
|
||||
|
||||
// 2. Perform semantic search
|
||||
await marketsPage.searchMarkets('election')
|
||||
|
||||
// Wait for API response
|
||||
await page.waitForResponse(resp =>
|
||||
resp.url().includes('/api/markets/search') && resp.status() === 200
|
||||
)
|
||||
|
||||
// 3. Verify search results
|
||||
const marketCards = marketsPage.marketCards
|
||||
await expect(marketCards.first()).toBeVisible()
|
||||
const resultCount = await marketCards.count()
|
||||
expect(resultCount).toBeGreaterThan(0)
|
||||
|
||||
// Take screenshot of search results
|
||||
await page.screenshot({ path: 'artifacts/search-results.png' })
|
||||
|
||||
// 4. Click on first result
|
||||
const firstMarketTitle = await marketCards.first().textContent()
|
||||
await marketCards.first().click()
|
||||
|
||||
// 5. Verify market details page loads
|
||||
await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/)
|
||||
|
||||
const detailsPage = new MarketDetailsPage(page)
|
||||
await expect(detailsPage.marketName).toBeVisible()
|
||||
await expect(detailsPage.marketDescription).toBeVisible()
|
||||
|
||||
// 6. Verify chart renders
|
||||
await expect(detailsPage.priceChart).toBeVisible()
|
||||
|
||||
// Verify market name matches
|
||||
const detailsTitle = await detailsPage.marketName.textContent()
|
||||
expect(detailsTitle?.toLowerCase()).toContain(
|
||||
firstMarketTitle?.toLowerCase().substring(0, 20) || ''
|
||||
)
|
||||
|
||||
// Take screenshot of market details
|
||||
await page.screenshot({ path: 'artifacts/market-details.png' })
|
||||
})
|
||||
|
||||
test('search with no results shows empty state', async ({ page }) => {
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Search for non-existent market
|
||||
await marketsPage.searchMarkets('xyznonexistentmarket123456')
|
||||
|
||||
// Verify empty state
|
||||
await expect(page.locator('[data-testid="no-results"]')).toBeVisible()
|
||||
await expect(page.locator('[data-testid="no-results"]')).toContainText(
|
||||
/no.*results|no.*markets/i
|
||||
)
|
||||
|
||||
const marketCount = await marketsPage.marketCards.count()
|
||||
expect(marketCount).toBe(0)
|
||||
})
|
||||
|
||||
test('can clear search and see all markets again', async ({ page }) => {
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Initial market count
|
||||
const initialCount = await marketsPage.marketCards.count()
|
||||
|
||||
// Perform search
|
||||
await marketsPage.searchMarkets('trump')
|
||||
await page.waitForLoadState('networkidle')
|
||||
|
||||
// Verify filtered results
|
||||
const filteredCount = await marketsPage.marketCards.count()
|
||||
expect(filteredCount).toBeLessThan(initialCount)
|
||||
|
||||
// Clear search
|
||||
await marketsPage.searchInput.clear()
|
||||
await page.waitForLoadState('networkidle')
|
||||
|
||||
// Verify all markets shown again
|
||||
const finalCount = await marketsPage.marketCards.count()
|
||||
expect(finalCount).toBe(initialCount)
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Rodando os Testes
|
||||
|
||||
```bash
|
||||
# Run the generated test
|
||||
npx playwright test tests/e2e/markets/search-and-view.spec.ts
|
||||
|
||||
Running 3 tests using 3 workers
|
||||
|
||||
✓ [chromium] › search-and-view.spec.ts:5:3 › user can search markets and view details (4.2s)
|
||||
✓ [chromium] › search-and-view.spec.ts:52:3 › search with no results shows empty state (1.8s)
|
||||
✓ [chromium] › search-and-view.spec.ts:67:3 › can clear search and see all markets again (2.9s)
|
||||
|
||||
3 passed (9.1s)
|
||||
|
||||
Artifacts generated:
|
||||
- artifacts/search-results.png
|
||||
- artifacts/market-details.png
|
||||
- playwright-report/index.html
|
||||
```
|
||||
|
||||
## Relatório de Teste
|
||||
|
||||
```
|
||||
╔══════════════════════════════════════════════════════════════╗
|
||||
║ E2E Test Results ║
|
||||
╠══════════════════════════════════════════════════════════════╣
|
||||
║ Status: ✅ ALL TESTS PASSED ║
|
||||
║ Total: 3 tests ║
|
||||
║ Passed: 3 (100%) ║
|
||||
║ Failed: 0 ║
|
||||
║ Flaky: 0 ║
|
||||
║ Duration: 9.1s ║
|
||||
╚══════════════════════════════════════════════════════════════╝
|
||||
|
||||
Artifacts:
|
||||
📸 Screenshots: 2 files
|
||||
📹 Videos: 0 files (only on failure)
|
||||
🔍 Traces: 0 files (only on failure)
|
||||
📊 HTML Report: playwright-report/index.html
|
||||
|
||||
View report: npx playwright show-report
|
||||
```
|
||||
|
||||
✅ E2E test suite ready for CI/CD integration!
|
||||
```
|
||||
|
||||
## Artefatos de Teste
|
||||
|
||||
Quando os testes rodam, os seguintes artefatos são capturados:
|
||||
|
||||
**Em Todos os Testes:**
|
||||
- Relatório HTML com timeline e resultados
|
||||
- JUnit XML para integração com CI
|
||||
|
||||
**Somente em Falha:**
|
||||
- Screenshot do estado de falha
|
||||
- Gravação em vídeo do teste
|
||||
- Arquivo de trace para debug (replay passo a passo)
|
||||
- Logs de rede
|
||||
- Logs de console
|
||||
|
||||
## Visualizando Artefatos
|
||||
|
||||
```bash
|
||||
# View HTML report in browser
|
||||
npx playwright show-report
|
||||
|
||||
# View specific trace file
|
||||
npx playwright show-trace artifacts/trace-abc123.zip
|
||||
|
||||
# Screenshots are saved in artifacts/ directory
|
||||
open artifacts/search-results.png
|
||||
```
|
||||
|
||||
## Detecção de Teste Flaky
|
||||
|
||||
Se um teste falhar de forma intermitente:
|
||||
|
||||
```
|
||||
⚠️ FLAKY TEST DETECTED: tests/e2e/markets/trade.spec.ts
|
||||
|
||||
Test passed 7/10 runs (70% pass rate)
|
||||
|
||||
Common failure:
|
||||
"Timeout waiting for element '[data-testid="confirm-btn"]'"
|
||||
|
||||
Recommended fixes:
|
||||
1. Add explicit wait: await page.waitForSelector('[data-testid="confirm-btn"]')
|
||||
2. Increase timeout: { timeout: 10000 }
|
||||
3. Check for race conditions in component
|
||||
4. Verify element is not hidden by animation
|
||||
|
||||
Quarantine recommendation: Mark as test.fixme() until fixed
|
||||
```
|
||||
|
||||
## Configuração de Navegador
|
||||
|
||||
Os testes rodam em múltiplos navegadores por padrão:
|
||||
- ✅ Chromium (Desktop Chrome)
|
||||
- ✅ Firefox (Desktop)
|
||||
- ✅ WebKit (Desktop Safari)
|
||||
- ✅ Mobile Chrome (optional)
|
||||
|
||||
Configure em `playwright.config.ts` para ajustar navegadores.
|
||||
|
||||
## Integração CI/CD
|
||||
|
||||
Adicione ao seu pipeline de CI:
|
||||
|
||||
```yaml
|
||||
# .github/workflows/e2e.yml
|
||||
- name: Install Playwright
|
||||
run: npx playwright install --with-deps
|
||||
|
||||
- name: Run E2E tests
|
||||
run: npx playwright test
|
||||
|
||||
- name: Upload artifacts
|
||||
if: always()
|
||||
uses: actions/upload-artifact@v3
|
||||
with:
|
||||
name: playwright-report
|
||||
path: playwright-report/
|
||||
```
|
||||
|
||||
## Fluxos Críticos Específicos do PMX
|
||||
|
||||
Para PMX, priorize estes testes E2E:
|
||||
|
||||
**🔴 CRITICAL (Must Always Pass):**
|
||||
1. User can connect wallet
|
||||
2. User can browse markets
|
||||
3. User can search markets (semantic search)
|
||||
4. User can view market details
|
||||
5. User can place trade (with test funds)
|
||||
6. Market resolves correctly
|
||||
7. User can withdraw funds
|
||||
|
||||
**🟡 IMPORTANT:**
|
||||
1. Market creation flow
|
||||
2. User profile updates
|
||||
3. Real-time price updates
|
||||
4. Chart rendering
|
||||
5. Filter and sort markets
|
||||
6. Mobile responsive layout
|
||||
|
||||
## Boas Práticas
|
||||
|
||||
**DO:**
|
||||
- ✅ Use Page Object Model para manutenção
|
||||
- ✅ Use atributos data-testid para seletores
|
||||
- ✅ Aguarde respostas de API, não timeouts arbitrários
|
||||
- ✅ Teste jornadas críticas de usuário end-to-end
|
||||
- ✅ Rode testes antes de mergear em main
|
||||
- ✅ Revise artefatos quando testes falharem
|
||||
|
||||
**DON'T:**
|
||||
- ❌ Use seletores frágeis (classes CSS podem mudar)
|
||||
- ❌ Teste detalhes de implementação
|
||||
- ❌ Rode testes contra produção
|
||||
- ❌ Ignore testes flaky
|
||||
- ❌ Pule revisão de artefatos em falhas
|
||||
- ❌ Teste todo edge case com E2E (use testes unitários)
|
||||
|
||||
## Notas Importantes
|
||||
|
||||
**CRITICAL para PMX:**
|
||||
- Testes E2E envolvendo dinheiro real DEVEM rodar apenas em testnet/staging
|
||||
- Nunca rode testes de trading em produção
|
||||
- Defina `test.skip(process.env.NODE_ENV === 'production')` para testes financeiros
|
||||
- Use carteiras de teste com fundos de teste pequenos apenas
|
||||
|
||||
## Integração com Outros Comandos
|
||||
|
||||
- Use `/plan` para identificar jornadas críticas a testar
|
||||
- Use `/tdd` para testes unitários (mais rápidos e granulares)
|
||||
- Use `/e2e` para integração e jornadas de usuário
|
||||
- Use `/code-review` para verificar qualidade dos testes
|
||||
|
||||
## Agentes Relacionados
|
||||
|
||||
Este comando invoca o agente `e2e-runner` fornecido pelo ECC.
|
||||
|
||||
Para instalações manuais, o arquivo fonte fica em:
|
||||
`agents/e2e-runner.md`
|
||||
|
||||
## Comandos Rápidos
|
||||
|
||||
```bash
|
||||
# Run all E2E tests
|
||||
npx playwright test
|
||||
|
||||
# Run specific test file
|
||||
npx playwright test tests/e2e/markets/search.spec.ts
|
||||
|
||||
# Run in headed mode (see browser)
|
||||
npx playwright test --headed
|
||||
|
||||
# Debug test
|
||||
npx playwright test --debug
|
||||
|
||||
# Generate test code
|
||||
npx playwright codegen http://localhost:3000
|
||||
|
||||
# View report
|
||||
npx playwright show-report
|
||||
```
|
||||
119
docs/pt-BR/commands/eval.md
Normal file
@@ -0,0 +1,119 @@
|
||||
# Comando Eval
|
||||
|
||||
Gerencie o fluxo de desenvolvimento orientado por evals.
|
||||
|
||||
## Uso
|
||||
|
||||
`/eval [define|check|report|list] [feature-name]`
|
||||
|
||||
## Definir Evals
|
||||
|
||||
`/eval define feature-name`
|
||||
|
||||
Crie uma nova definição de eval:
|
||||
|
||||
1. Crie `.claude/evals/feature-name.md` com o template:
|
||||
|
||||
```markdown
|
||||
## EVAL: feature-name
|
||||
Created: $(date)
|
||||
|
||||
### Evals de Capacidade
|
||||
- [ ] [Descrição da capacidade 1]
|
||||
- [ ] [Descrição da capacidade 2]
|
||||
|
||||
### Evals de Regressão
|
||||
- [ ] [Comportamento existente 1 ainda funciona]
|
||||
- [ ] [Comportamento existente 2 ainda funciona]
|
||||
|
||||
### Critérios de Sucesso
|
||||
- pass@3 > 90% para evals de capacidade
|
||||
- pass^3 = 100% para evals de regressão
|
||||
|
||||
2. Peça ao usuário para preencher os critérios específicos
|
||||
|
||||
## Verificar Evals
|
||||
|
||||
`/eval check feature-name`
|
||||
|
||||
Rode evals para uma feature:
|
||||
|
||||
1. Leia a definição de eval em `.claude/evals/feature-name.md`
|
||||
2. Para cada eval de capability:
|
||||
- Tente verificar o critério
|
||||
- Registre PASS/FAIL
|
||||
- Salve tentativa em `.claude/evals/feature-name.log`
|
||||
3. Para cada eval de regressão:
|
||||
- Rode os testes relevantes
|
||||
- Compare com baseline
|
||||
- Registre PASS/FAIL
|
||||
4. Reporte status atual:
|
||||
|
||||
```
|
||||
EVAL CHECK: feature-name
|
||||
========================
|
||||
Capability: X/Y passing
|
||||
Regression: X/Y passing
|
||||
Status: IN PROGRESS / READY
|
||||
```
|
||||
|
||||
## Relatório de Evals
|
||||
|
||||
`/eval report feature-name`
|
||||
|
||||
Gere relatório completo de eval:
|
||||
|
||||
```
|
||||
EVAL REPORT: feature-name
|
||||
=========================
|
||||
Generated: $(date)
|
||||
|
||||
CAPABILITY EVALS
|
||||
----------------
|
||||
[eval-1]: PASS (pass@1)
|
||||
[eval-2]: PASS (pass@2) - required retry
|
||||
[eval-3]: FAIL - see notes
|
||||
|
||||
REGRESSION EVALS
|
||||
----------------
|
||||
[test-1]: PASS
|
||||
[test-2]: PASS
|
||||
[test-3]: PASS
|
||||
|
||||
METRICS
|
||||
-------
|
||||
Capability pass@1: 67%
|
||||
Capability pass@3: 100%
|
||||
Regression pass^3: 100%
|
||||
|
||||
NOTES
|
||||
-----
|
||||
[Any issues, edge cases, or observations]
|
||||
|
||||
RECOMMENDATION
|
||||
--------------
|
||||
[SHIP / NEEDS WORK / BLOCKED]
|
||||
```
|
||||
|
||||
## Listar Evals
|
||||
|
||||
`/eval list`
|
||||
|
||||
Mostre todas as definições de eval:
|
||||
|
||||
```
|
||||
EVAL DEFINITIONS
|
||||
================
|
||||
feature-auth [3/5 passing] IN PROGRESS
|
||||
feature-search [5/5 passing] READY
|
||||
feature-export [0/4 passing] NOT STARTED
|
||||
```
|
||||
|
||||
## Argumentos
|
||||
|
||||
$ARGUMENTS:
|
||||
- `define <name>` - Criar nova definição de eval
|
||||
- `check <name>` - Rodar e verificar evals
|
||||
- `report <name>` - Gerar relatório completo
|
||||
- `list` - Mostrar todos os evals
|
||||
- `clean` - Remover logs antigos de eval (mantém as últimas 10 execuções)
|
||||
183
docs/pt-BR/commands/go-build.md
Normal file
@@ -0,0 +1,183 @@
|
||||
---
|
||||
description: Corrija erros de build em Go, avisos de go vet e problemas de lint incrementalmente. Invoca o agente go-build-resolver para correções mínimas e cirúrgicas.
|
||||
---
|
||||
|
||||
# Build e Correção Go
|
||||
|
||||
Este comando invoca o agente **go-build-resolver** para corrigir erros de build Go incrementalmente com mudanças mínimas.
|
||||
|
||||
## O Que Este Comando Faz
|
||||
|
||||
1. **Rodar Diagnósticos**: Executa `go build`, `go vet`, `staticcheck`
|
||||
2. **Parsear Erros**: Agrupa por arquivo e ordena por severidade
|
||||
3. **Corrigir Incrementalmente**: Um erro por vez
|
||||
4. **Verificar Cada Correção**: Roda build de novo após cada mudança
|
||||
5. **Reportar Resumo**: Mostra o que foi corrigido e o que resta
|
||||
|
||||
## Quando Usar
|
||||
|
||||
Use `/go-build` quando:
|
||||
- `go build ./...` falhar com erros
|
||||
- `go vet ./...` reportar problemas
|
||||
- `golangci-lint run` mostrar avisos
|
||||
- Dependências do módulo estiverem quebradas
|
||||
- Após puxar mudanças que quebraram o build
|
||||
|
||||
## Comandos de Diagnóstico Executados
|
||||
|
||||
```bash
|
||||
# Primary build check
|
||||
go build ./...
|
||||
|
||||
# Static analysis
|
||||
go vet ./...
|
||||
|
||||
# Extended linting (if available)
|
||||
staticcheck ./...
|
||||
golangci-lint run
|
||||
|
||||
# Module issues
|
||||
go mod verify
|
||||
go mod tidy -v
|
||||
```
|
||||
|
||||
## Exemplo de Sessão
|
||||
|
||||
```text
|
||||
User: /go-build
|
||||
|
||||
Agent:
|
||||
# Go Build Resolution
|
||||
|
||||
## Initial Diagnostics
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
internal/service/user.go:25:15: undefined: UserRepository
|
||||
internal/handler/api.go:42:9: cannot use x (type string) as type int
|
||||
internal/handler/api.go:58:2: missing return at end of function
|
||||
```
|
||||
|
||||
Errors found: 3
|
||||
|
||||
## Fix 1: Undefined Identifier
|
||||
|
||||
File: internal/service/user.go:25
|
||||
Error: undefined: UserRepository
|
||||
Cause: Missing import
|
||||
|
||||
```go
|
||||
// Added import
|
||||
import "project/internal/repository"
|
||||
|
||||
// Changed
|
||||
var repo UserRepository
|
||||
// To
|
||||
var repo repository.UserRepository
|
||||
```
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
# 2 errors remaining
|
||||
```
|
||||
|
||||
## Fix 2: Type Mismatch
|
||||
|
||||
File: internal/handler/api.go:42
|
||||
Error: cannot use x (type string) as type int
|
||||
|
||||
```go
|
||||
// Changed
|
||||
count := params.Get("count")
|
||||
// To
|
||||
countStr := params.Get("count")
|
||||
count, _ := strconv.Atoi(countStr)
|
||||
```
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
# 1 error remaining
|
||||
```
|
||||
|
||||
## Fix 3: Missing Return
|
||||
|
||||
File: internal/handler/api.go:58
|
||||
Error: missing return at end of function
|
||||
|
||||
```go
|
||||
func GetUser(id string) (*User, error) {
|
||||
if id == "" {
|
||||
return nil, ErrInvalidID
|
||||
}
|
||||
user := findUser(id)
|
||||
// Added missing return
|
||||
return user, nil
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
# Build successful!
|
||||
```
|
||||
|
||||
## Final Verification
|
||||
|
||||
```bash
|
||||
$ go vet ./...
|
||||
# No issues
|
||||
|
||||
$ go test ./...
|
||||
ok project/internal/service 0.015s
|
||||
ok project/internal/handler 0.023s
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
||||
| Metric | Count |
|
||||
|--------|-------|
|
||||
| Build errors fixed | 3 |
|
||||
| Vet warnings fixed | 0 |
|
||||
| Files modified | 2 |
|
||||
| Remaining issues | 0 |
|
||||
|
||||
Build Status: ✅ SUCCESS
|
||||
```
|
||||
|
||||
## Erros Comuns Corrigidos
|
||||
|
||||
| Error | Typical Fix |
|
||||
|-------|-------------|
|
||||
| `undefined: X` | Add import or fix typo |
|
||||
| `cannot use X as Y` | Type conversion or fix assignment |
|
||||
| `missing return` | Add return statement |
|
||||
| `X does not implement Y` | Add missing method |
|
||||
| `import cycle` | Restructure packages |
|
||||
| `declared but not used` | Remove or use variable |
|
||||
| `cannot find package` | `go get` or `go mod tidy` |
|
||||
|
||||
## Estratégia de Correção
|
||||
|
||||
1. **Erros de build primeiro** - O código precisa compilar
|
||||
2. **Avisos do vet depois** - Corrigir construções suspeitas
|
||||
3. **Avisos de lint por último** - Estilo e boas práticas
|
||||
4. **Uma correção por vez** - Verificar cada mudança
|
||||
5. **Mudanças mínimas** - Não refatorar, apenas corrigir
|
||||
|
||||
## Condições de Parada
|
||||
|
||||
O agente vai parar e reportar se:
|
||||
- O mesmo erro persistir após 3 tentativas
|
||||
- A correção introduzir mais erros
|
||||
- Exigir mudanças arquiteturais
|
||||
- Faltarem dependências externas
|
||||
|
||||
## Comandos Relacionados
|
||||
|
||||
- `/go-test` - Rode testes após o build passar
|
||||
- `/go-review` - Revise qualidade do código
|
||||
- `/verify` - Loop completo de verificação
|
||||
|
||||
## Relacionado
|
||||
|
||||
- Agent: `agents/go-build-resolver.md`
|
||||
- Skill: `skills/golang-patterns/`
|
||||
147
docs/pt-BR/commands/go-review.md
Normal file
@@ -0,0 +1,147 @@
|
||||
---
|
||||
description: Revisão completa de código Go para padrões idiomáticos, segurança de concorrência, tratamento de erro e segurança. Invoca o agente go-reviewer.
|
||||
---
|
||||
|
||||
# Code Review Go
|
||||
|
||||
Este comando invoca o agente **go-reviewer** para revisão abrangente e específica de Go.
|
||||
|
||||
## O Que Este Comando Faz
|
||||
|
||||
1. **Identificar Mudanças Go**: Encontra arquivos `.go` modificados via `git diff`
|
||||
2. **Rodar Análise Estática**: Executa `go vet`, `staticcheck` e `golangci-lint`
|
||||
3. **Varredura de Segurança**: Verifica SQL injection, command injection e race conditions
|
||||
4. **Revisão de Concorrência**: Analisa segurança de goroutines, uso de channels e padrões com mutex
|
||||
5. **Checagem de Go Idiomático**: Verifica se o código segue convenções e boas práticas de Go
|
||||
6. **Gerar Relatório**: Categoriza problemas por severidade
|
||||
|
||||
## Quando Usar
|
||||
|
||||
Use `/go-review` quando:
|
||||
- Após escrever ou modificar código Go
|
||||
- Antes de commitar mudanças Go
|
||||
- Ao revisar pull requests com código Go
|
||||
- Ao entrar em um novo codebase Go
|
||||
- Ao aprender padrões idiomáticos Go
|
||||
|
||||
## Categorias de Revisão
|
||||
|
||||
### CRITICAL (Obrigatório Corrigir)
|
||||
- Vulnerabilidades de SQL/Command injection
|
||||
- Race conditions sem sincronização
|
||||
- Vazamento de goroutine
|
||||
- Credenciais hardcoded
|
||||
- Uso inseguro de ponteiros
|
||||
- Erros ignorados em caminhos críticos
|
||||
|
||||
### HIGH (Deve Corrigir)
|
||||
- Falta de wrapping de erro com contexto
|
||||
- Panic em vez de retorno de erro
|
||||
- Context não propagado
|
||||
- Canais não bufferizados causando deadlock
|
||||
- Erros de interface não satisfeita
|
||||
- Falta de proteção com mutex
|
||||
|
||||
### MEDIUM (Considere)
|
||||
- Padrões não idiomáticos
|
||||
- Falta de comentários godoc em exports
|
||||
- Concatenação de string ineficiente
|
||||
- Slice sem pré-alocação
|
||||
- Table-driven tests não usados
|
||||
|
||||
## Checagens Automáticas Executadas
|
||||
|
||||
```bash
|
||||
# Static analysis
|
||||
go vet ./...
|
||||
|
||||
# Advanced checks (if installed)
|
||||
staticcheck ./...
|
||||
golangci-lint run
|
||||
|
||||
# Race detection
|
||||
go build -race ./...
|
||||
|
||||
# Security vulnerabilities
|
||||
govulncheck ./...
|
||||
```
|
||||
|
||||
## Exemplo de Uso
|
||||
|
||||
```text
|
||||
User: /go-review
|
||||
|
||||
Agent:
|
||||
# Go Code Review Report
|
||||
|
||||
## Files Reviewed
|
||||
- internal/handler/user.go (modified)
|
||||
- internal/service/auth.go (modified)
|
||||
|
||||
## Static Analysis Results
|
||||
✓ go vet: No issues
|
||||
✓ staticcheck: No issues
|
||||
|
||||
## Issues Found
|
||||
|
||||
[CRITICAL] Race Condition
|
||||
File: internal/service/auth.go:45
|
||||
Issue: Shared map accessed without synchronization
|
||||
```go
|
||||
var cache = map[string]*Session{} // Concurrent access!
|
||||
|
||||
func GetSession(id string) *Session {
|
||||
return cache[id] // Race condition
|
||||
}
|
||||
```
|
||||
Fix: Use sync.RWMutex or sync.Map
|
||||
```go
|
||||
var (
|
||||
cache = map[string]*Session{}
|
||||
cacheMu sync.RWMutex
|
||||
)
|
||||
|
||||
func GetSession(id string) *Session {
|
||||
cacheMu.RLock()
|
||||
defer cacheMu.RUnlock()
|
||||
return cache[id]
|
||||
}
|
||||
```
|
||||
|
||||
[HIGH] Missing Error Context
|
||||
File: internal/handler/user.go:28
|
||||
Issue: Error returned without context
|
||||
```go
|
||||
return err // No context
|
||||
```
|
||||
Fix: Wrap with context
|
||||
```go
|
||||
return fmt.Errorf("get user %s: %w", userID, err)
|
||||
```
|
||||
|
||||
## Summary
|
||||
- CRITICAL: 1
|
||||
- HIGH: 1
|
||||
- MEDIUM: 0
|
||||
|
||||
Recommendation: ❌ Block merge until CRITICAL issue is fixed
|
||||
```
|
||||
|
||||
## Critérios de Aprovação
|
||||
|
||||
| Status | Condição |
|
||||
|--------|----------|
|
||||
| ✅ Aprovado | Sem problemas CRÍTICO ou ALTO |
|
||||
| ⚠️ Aviso | Apenas problemas MÉDIOS (merge com cautela) |
|
||||
| ❌ Bloqueado | Problemas CRÍTICO ou ALTO encontrados |
|
||||
## Integração com Outros Comandos
|
||||
|
||||
- Use `/go-test` primeiro para garantir que os testes passam
|
||||
- Use `/go-build` se houver erros de build
|
||||
- Use `/go-review` antes de commitar
|
||||
- Use `/code-review` para preocupações não específicas de Go
|
||||
|
||||
## Relacionado
|
||||
|
||||
- Agent: `agents/go-reviewer.md`
|
||||
- Skills: `skills/golang-patterns/`, `skills/golang-testing/`
|
||||
268
docs/pt-BR/commands/go-test.md
Normal file
@@ -0,0 +1,268 @@
|
||||
---
|
||||
description: Impõe fluxo de TDD para Go. Escreva table-driven tests primeiro e depois implemente. Verifique cobertura de 80%+ com go test -cover.
|
||||
---
|
||||
|
||||
# Comando TDD Go
|
||||
|
||||
Este comando impõe a metodologia de desenvolvimento orientado a testes para código Go usando padrões idiomáticos de teste em Go.
|
||||
|
||||
## O Que Este Comando Faz
|
||||
|
||||
1. **Definir Tipos/Interfaces**: Estrutura assinaturas de função primeiro
|
||||
2. **Escrever Table-Driven Tests**: Criar casos de teste abrangentes (RED)
|
||||
3. **Rodar Testes**: Verificar que os testes falham pelo motivo certo
|
||||
4. **Implementar Código**: Escrever código mínimo para passar (GREEN)
|
||||
5. **Refatorar**: Melhorar mantendo testes verdes
|
||||
6. **Checar Cobertura**: Garantir 80%+ de cobertura
|
||||
|
||||
## Quando Usar
|
||||
|
||||
Use `/go-test` quando:
|
||||
- Implementar novas funções Go
|
||||
- Adicionar cobertura de testes a código existente
|
||||
- Corrigir bugs (escreva primeiro o teste que falha)
|
||||
- Construir lógica de negócio crítica
|
||||
- Aprender fluxo TDD em Go
|
||||
|
||||
## Ciclo TDD
|
||||
|
||||
```
|
||||
RED → Write failing table-driven test
|
||||
GREEN → Implement minimal code to pass
|
||||
REFACTOR → Improve code, tests stay green
|
||||
REPEAT → Next test case
|
||||
```
|
||||
|
||||
## Exemplo de Sessão
|
||||
|
||||
````
|
||||
User: /go-test I need a function to validate email addresses
|
||||
|
||||
Agent:
|
||||
# TDD Session: Email Validator
|
||||
|
||||
## Step 1: Define Interface
|
||||
|
||||
```go
|
||||
// validator/email.go
|
||||
package validator
|
||||
|
||||
// ValidateEmail checks if the given string is a valid email address.
|
||||
// Returns nil if valid, error describing the issue otherwise.
|
||||
func ValidateEmail(email string) error {
|
||||
panic("not implemented")
|
||||
}
|
||||
```
|
||||
|
||||
## Step 2: Write Table-Driven Tests (RED)
|
||||
|
||||
```go
|
||||
// validator/email_test.go
|
||||
package validator
|
||||
|
||||
import (
|
||||
"testing"
|
||||
)
|
||||
|
||||
func TestValidateEmail(t *testing.T) {
|
||||
tests := []struct {
|
||||
name string
|
||||
email string
|
||||
wantErr bool
|
||||
}{
|
||||
// Valid emails
|
||||
{"simple email", "user@example.com", false},
|
||||
{"with subdomain", "user@mail.example.com", false},
|
||||
{"with plus", "user+tag@example.com", false},
|
||||
{"with dots", "first.last@example.com", false},
|
||||
|
||||
// Invalid emails
|
||||
{"empty string", "", true},
|
||||
{"no at sign", "userexample.com", true},
|
||||
{"no domain", "user@", true},
|
||||
{"no local part", "@example.com", true},
|
||||
{"double at", "user@@example.com", true},
|
||||
{"spaces", "user @example.com", true},
|
||||
{"no tld", "user@example", true},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
err := ValidateEmail(tt.email)
|
||||
if tt.wantErr && err == nil {
|
||||
t.Errorf("ValidateEmail(%q) = nil; want error", tt.email)
|
||||
}
|
||||
if !tt.wantErr && err != nil {
|
||||
t.Errorf("ValidateEmail(%q) = %v; want nil", tt.email, err)
|
||||
}
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Step 3: Run Tests - Verify FAIL
|
||||
|
||||
```bash
|
||||
$ go test ./validator/...
|
||||
|
||||
--- FAIL: TestValidateEmail (0.00s)
|
||||
--- FAIL: TestValidateEmail/simple_email (0.00s)
|
||||
panic: not implemented
|
||||
|
||||
FAIL
|
||||
```
|
||||
|
||||
✓ Tests fail as expected (panic).
|
||||
|
||||
## Step 4: Implement Minimal Code (GREEN)
|
||||
|
||||
```go
|
||||
// validator/email.go
|
||||
package validator
|
||||
|
||||
import (
|
||||
"errors"
|
||||
"regexp"
|
||||
)
|
||||
|
||||
var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
|
||||
|
||||
var (
|
||||
ErrEmailEmpty = errors.New("email cannot be empty")
|
||||
ErrEmailInvalid = errors.New("email format is invalid")
|
||||
)
|
||||
|
||||
func ValidateEmail(email string) error {
|
||||
if email == "" {
|
||||
return ErrEmailEmpty
|
||||
}
|
||||
if !emailRegex.MatchString(email) {
|
||||
return ErrEmailInvalid
|
||||
}
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
## Step 5: Run Tests - Verify PASS
|
||||
|
||||
```bash
|
||||
$ go test ./validator/...
|
||||
|
||||
PASS
|
||||
ok project/validator 0.003s
|
||||
```
|
||||
|
||||
✓ All tests passing!
|
||||
|
||||
## Step 6: Check Coverage
|
||||
|
||||
```bash
|
||||
$ go test -cover ./validator/...
|
||||
|
||||
PASS
|
||||
coverage: 100.0% of statements
|
||||
ok project/validator 0.003s
|
||||
```
|
||||
|
||||
✓ Coverage: 100%
|
||||
|
||||
## TDD Complete!
|
||||
````
|
||||
|
||||
## Padrões de Teste
|
||||
|
||||
### Table-Driven Tests
|
||||
```go
|
||||
tests := []struct {
|
||||
name string
|
||||
input InputType
|
||||
want OutputType
|
||||
wantErr bool
|
||||
}{
|
||||
{"case 1", input1, want1, false},
|
||||
{"case 2", input2, want2, true},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
got, err := Function(tt.input)
|
||||
// assertions
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### Testes Paralelos
|
||||
```go
|
||||
for _, tt := range tests {
|
||||
tt := tt // Capture
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
t.Parallel()
|
||||
// test body
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### Helpers de Teste
|
||||
```go
|
||||
func setupTestDB(t *testing.T) *sql.DB {
|
||||
t.Helper()
|
||||
db := createDB()
|
||||
t.Cleanup(func() { db.Close() })
|
||||
return db
|
||||
}
|
||||
```
|
||||
|
||||
## Comandos de Cobertura
|
||||
|
||||
```bash
|
||||
# Basic coverage
|
||||
go test -cover ./...
|
||||
|
||||
# Coverage profile
|
||||
go test -coverprofile=coverage.out ./...
|
||||
|
||||
# View in browser
|
||||
go tool cover -html=coverage.out
|
||||
|
||||
# Coverage by function
|
||||
go tool cover -func=coverage.out
|
||||
|
||||
# With race detection
|
||||
go test -race -cover ./...
|
||||
```
|
||||
|
||||
## Metas de Cobertura
|
||||
|
||||
| Code Type | Target |
|
||||
|-----------|--------|
|
||||
| Critical business logic | 100% |
|
||||
| Public APIs | 90%+ |
|
||||
| General code | 80%+ |
|
||||
| Generated code | Exclude |
|
||||
|
||||
## Boas Práticas de TDD
|
||||
|
||||
**DO:**
|
||||
- Escreva teste PRIMEIRO, antes de qualquer implementação
|
||||
- Rode testes após cada mudança
|
||||
- Use table-driven tests para cobertura abrangente
|
||||
- Teste comportamento, não detalhes de implementação
|
||||
- Inclua casos de borda (empty, nil, max values)
|
||||
|
||||
**DON'T:**
|
||||
- Escrever implementação antes dos testes
|
||||
- Pular a fase RED
|
||||
- Testar funções privadas diretamente
|
||||
- Usar `time.Sleep` em testes
|
||||
- Ignorar testes flaky
|
||||
|
||||
## Comandos Relacionados
|
||||
|
||||
- `/go-build` - Corrigir erros de build
|
||||
- `/go-review` - Revisar código após implementação
|
||||
- `/verify` - Rodar loop completo de verificação
|
||||
|
||||
## Relacionado
|
||||
|
||||
- Skill: `skills/golang-testing/`
|
||||
- Skill: `skills/tdd-workflow/`
|
||||
70
docs/pt-BR/commands/learn.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# /learn - Extrair Padrões Reutilizáveis
|
||||
|
||||
Analise a sessão atual e extraia padrões que valem ser salvos como skills.
|
||||
|
||||
## Trigger
|
||||
|
||||
Rode `/learn` em qualquer ponto da sessão quando você tiver resolvido um problema não trivial.
|
||||
|
||||
## O Que Extrair
|
||||
|
||||
Procure por:
|
||||
|
||||
1. **Padrões de Resolução de Erro**
|
||||
- Qual erro ocorreu?
|
||||
- Qual foi a causa raiz?
|
||||
- O que corrigiu?
|
||||
- Isso é reutilizável para erros semelhantes?
|
||||
|
||||
2. **Técnicas de Debug**
|
||||
- Passos de debug não óbvios
|
||||
- Combinações de ferramentas que funcionaram
|
||||
- Padrões de diagnóstico
|
||||
|
||||
3. **Workarounds**
|
||||
- Quirks de bibliotecas
|
||||
- Limitações de API
|
||||
- Correções específicas de versão
|
||||
|
||||
4. **Padrões Específicos do Projeto**
|
||||
- Convenções de codebase descobertas
|
||||
- Decisões de arquitetura tomadas
|
||||
- Padrões de integração
|
||||
|
||||
## Formato de Saída
|
||||
|
||||
Crie um arquivo de skill em `~/.claude/skills/learned/[pattern-name].md`:
|
||||
|
||||
```markdown
|
||||
# [Descriptive Pattern Name]
|
||||
|
||||
**Extracted:** [Date]
|
||||
**Context:** [Brief description of when this applies]
|
||||
|
||||
## Problem
|
||||
[What problem this solves - be specific]
|
||||
|
||||
## Solution
|
||||
[The pattern/technique/workaround]
|
||||
|
||||
## Example
|
||||
[Code example if applicable]
|
||||
|
||||
## When to Use
|
||||
[Trigger conditions - what should activate this skill]
|
||||
```
|
||||
|
||||
## Processo
|
||||
|
||||
1. Revise a sessão para identificar padrões extraíveis
|
||||
2. Identifique o insight mais valioso/reutilizável
|
||||
3. Esboce o arquivo de skill
|
||||
4. Peça confirmação do usuário antes de salvar
|
||||
5. Salve em `~/.claude/skills/learned/`
|
||||
|
||||
## Notas
|
||||
|
||||
- Não extraia correções triviais (typos, erros simples de sintaxe)
|
||||
- Não extraia problemas de uso único (indisponibilidade específica de API etc.)
|
||||
- Foque em padrões que vão economizar tempo em sessões futuras
|
||||
- Mantenha skills focadas - um padrão por skill
|
||||
230
docs/pt-BR/commands/orchestrate.md
Normal file
@@ -0,0 +1,230 @@
|
||||
---
|
||||
description: Orientação de orquestração sequencial e tmux/worktree para fluxos multiagente.
|
||||
---
|
||||
|
||||
# Comando Orchestrate
|
||||
|
||||
Fluxo sequencial de agentes para tarefas complexas.
|
||||
|
||||
## Uso
|
||||
|
||||
`/orchestrate [workflow-type] [task-description]`
|
||||
|
||||
## Tipos de Workflow
|
||||
|
||||
### feature
|
||||
Workflow completo de implementação de feature:
|
||||
```
|
||||
planner -> tdd-guide -> code-reviewer -> security-reviewer
|
||||
```
|
||||
|
||||
### bugfix
|
||||
Workflow de investigação e correção de bug:
|
||||
```
|
||||
planner -> tdd-guide -> code-reviewer
|
||||
```
|
||||
|
||||
### refactor
|
||||
Workflow de refatoração segura:
|
||||
```
|
||||
architect -> code-reviewer -> tdd-guide
|
||||
```
|
||||
|
||||
### security
|
||||
Revisão focada em segurança:
|
||||
```
|
||||
security-reviewer -> code-reviewer -> architect
|
||||
```
|
||||
|
||||
## Padrão de Execução
|
||||
|
||||
Para cada agente no workflow:
|
||||
|
||||
1. **Invoque o agente** com contexto do agente anterior
|
||||
2. **Colete saída** como documento estruturado de handoff
|
||||
3. **Passe para o próximo agente** na cadeia
|
||||
4. **Agregue resultados** em um relatório final
|
||||
|
||||
## Formato do Documento de Handoff
|
||||
|
||||
Entre agentes, crie um documento de handoff:
|
||||
|
||||
```markdown
|
||||
## HANDOFF: [previous-agent] -> [next-agent]
|
||||
|
||||
### Context
|
||||
[Summary of what was done]
|
||||
|
||||
### Findings
|
||||
[Key discoveries or decisions]
|
||||
|
||||
### Files Modified
|
||||
[List of files touched]
|
||||
|
||||
### Open Questions
|
||||
[Unresolved items for next agent]
|
||||
|
||||
### Recommendations
|
||||
[Suggested next steps]
|
||||
```
|
||||
|
||||
## Exemplo: Workflow de Feature
|
||||
|
||||
```
|
||||
/orchestrate feature "Add user authentication"
|
||||
```
|
||||
|
||||
Executa:
|
||||
|
||||
1. **Planner Agent**
|
||||
- Analisa requisitos
|
||||
- Cria plano de implementação
|
||||
- Identifica dependências
|
||||
- Saída: `HANDOFF: planner -> tdd-guide`
|
||||
|
||||
2. **TDD Guide Agent**
|
||||
- Lê handoff do planner
|
||||
- Escreve testes primeiro
|
||||
- Implementa para passar testes
|
||||
- Saída: `HANDOFF: tdd-guide -> code-reviewer`
|
||||
|
||||
3. **Code Reviewer Agent**
|
||||
- Revisa implementação
|
||||
- Verifica problemas
|
||||
- Sugere melhorias
|
||||
- Saída: `HANDOFF: code-reviewer -> security-reviewer`
|
||||
|
||||
4. **Security Reviewer Agent**
|
||||
- Auditoria de segurança
|
||||
- Verificação de vulnerabilidades
|
||||
- Aprovação final
|
||||
- Saída: Relatório Final
|
||||
|
||||
## Formato do Relatório Final
|
||||
|
||||
```
|
||||
ORCHESTRATION REPORT
|
||||
====================
|
||||
Workflow: feature
|
||||
Task: Add user authentication
|
||||
Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer
|
||||
|
||||
SUMMARY
|
||||
-------
|
||||
[One paragraph summary]
|
||||
|
||||
AGENT OUTPUTS
|
||||
-------------
|
||||
Planner: [summary]
|
||||
TDD Guide: [summary]
|
||||
Code Reviewer: [summary]
|
||||
Security Reviewer: [summary]
|
||||
|
||||
FILES CHANGED
|
||||
-------------
|
||||
[List all files modified]
|
||||
|
||||
TEST RESULTS
|
||||
------------
|
||||
[Test pass/fail summary]
|
||||
|
||||
SECURITY STATUS
|
||||
---------------
|
||||
[Security findings]
|
||||
|
||||
RECOMMENDATION
|
||||
--------------
|
||||
[SHIP / NEEDS WORK / BLOCKED]
|
||||
```
|
||||
|
||||
## Execução Paralela
|
||||
|
||||
Para verificações independentes, rode agentes em paralelo:
|
||||
|
||||
```markdown
|
||||
### Fase Paralela
|
||||
Executar simultaneamente:
|
||||
- code-reviewer (qualidade)
|
||||
- security-reviewer (segurança)
|
||||
- architect (design)
|
||||
|
||||
### Mesclar Resultados
|
||||
Combinar saídas em um único relatório
|
||||
|
||||
Para workers externos em tmux panes com git worktrees separados, use `node scripts/orchestrate-worktrees.js plan.json --execute`. O padrão embutido de orquestração permanece no processo atual; o helper é para sessões longas ou cross-harness.
|
||||
|
||||
Quando os workers precisarem enxergar arquivos locais sujos ou não rastreados do checkout principal, adicione `seedPaths` ao arquivo de plano. O ECC faz overlay apenas desses caminhos selecionados em cada worktree do worker após `git worktree add`, mantendo o branch isolado e ainda expondo scripts, planos ou docs em andamento.
|
||||
|
||||
```json
|
||||
{
|
||||
"sessionName": "workflow-e2e",
|
||||
"seedPaths": [
|
||||
"scripts/orchestrate-worktrees.js",
|
||||
"scripts/lib/tmux-worktree-orchestrator.js",
|
||||
".claude/plan/workflow-e2e-test.json"
|
||||
],
|
||||
"workers": [
|
||||
{ "name": "docs", "task": "Update orchestration docs." }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Para exportar um snapshot do control plane para uma sessão tmux/worktree ao vivo, rode:
|
||||
|
||||
```bash
|
||||
node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json
|
||||
```
|
||||
|
||||
O snapshot inclui atividade da sessão, metadados de pane do tmux, estado dos workers, objetivos, overlays semeados e resumos recentes de handoff em formato JSON.
|
||||
|
||||
## Handoff de Command Center do Operador
|
||||
|
||||
Quando o workflow atravessar múltiplas sessões, worktrees ou panes tmux, acrescente um bloco de control plane ao handoff final:
|
||||
|
||||
```markdown
|
||||
CONTROL PLANE
|
||||
-------------
|
||||
Sessions:
|
||||
- active session ID or alias
|
||||
- branch + worktree path for each active worker
|
||||
- tmux pane or detached session name when applicable
|
||||
|
||||
Diffs:
|
||||
- git status summary
|
||||
- git diff --stat for touched files
|
||||
- merge/conflict risk notes
|
||||
|
||||
Approvals:
|
||||
- pending user approvals
|
||||
- blocked steps awaiting confirmation
|
||||
|
||||
Telemetry:
|
||||
- last activity timestamp or idle signal
|
||||
- estimated token or cost drift
|
||||
- policy events raised by hooks or reviewers
|
||||
```
|
||||
|
||||
Isso mantém planner, implementador, revisor e loop workers legíveis pela superfície de operação.
|
||||
|
||||
## Argumentos
|
||||
|
||||
$ARGUMENTS:
|
||||
- `feature <description>` - Workflow completo de feature
|
||||
- `bugfix <description>` - Workflow de correção de bug
|
||||
- `refactor <description>` - Workflow de refatoração
|
||||
- `security <description>` - Workflow de revisão de segurança
|
||||
- `custom <agents> <description>` - Sequência customizada de agentes
|
||||
|
||||
## Exemplo de Workflow Customizado
|
||||
|
||||
```
|
||||
/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer"
|
||||
```
|
||||
|
||||
## Dicas
|
||||
|
||||
1. **Comece com planner** para features complexas
|
||||
2. **Sempre inclua code-reviewer** antes do merge
|
||||
3. **Use security-reviewer** para auth/pagamento/PII
|
||||
4. **Mantenha handoffs concisos** - foque no que o próximo agente precisa
|
||||
5. **Rode verificação** entre agentes quando necessário
|
||||
113
docs/pt-BR/commands/plan.md
Normal file
@@ -0,0 +1,113 @@
|
||||
---
|
||||
description: Reafirme requisitos, avalie riscos e crie plano de implementação passo a passo. ESPERE confirmação do usuário ANTES de tocar em qualquer código.
|
||||
---
|
||||
|
||||
# Comando Plan
|
||||
|
||||
Este comando invoca o agente **planner** para criar um plano abrangente de implementação antes de escrever qualquer código.
|
||||
|
||||
## O Que Este Comando Faz
|
||||
|
||||
1. **Reafirmar Requisitos** - Esclarecer o que precisa ser construído
|
||||
2. **Identificar Riscos** - Levantar problemas e bloqueios potenciais
|
||||
3. **Criar Plano em Etapas** - Quebrar implementação em fases
|
||||
4. **Aguardar Confirmação** - DEVE receber aprovação do usuário antes de prosseguir
|
||||
|
||||
## Quando Usar
|
||||
|
||||
Use `/plan` quando:
|
||||
- Estiver iniciando uma nova feature
|
||||
- For fazer mudanças arquiteturais significativas
|
||||
- Estiver trabalhando em refatoração complexa
|
||||
- Múltiplos arquivos/componentes serão afetados
|
||||
- Requisitos estiverem pouco claros ou ambíguos
|
||||
|
||||
## Como Funciona
|
||||
|
||||
O agente planner vai:
|
||||
|
||||
1. **Analisar o pedido** e reafirmar os requisitos de forma clara
|
||||
2. **Quebrar em fases** com etapas específicas e acionáveis
|
||||
3. **Identificar dependências** entre componentes
|
||||
4. **Avaliar riscos** e possíveis bloqueios
|
||||
5. **Estimar complexidade** (High/Medium/Low)
|
||||
6. **Apresentar o plano** e AGUARDAR sua confirmação explícita
|
||||
|
||||
## Exemplo de Uso
|
||||
|
||||
```
|
||||
User: /plan I need to add real-time notifications when markets resolve
|
||||
|
||||
Agent (planner):
|
||||
# Implementation Plan: Real-Time Market Resolution Notifications
|
||||
|
||||
## Requirements Restatement
|
||||
- Send notifications to users when markets they're watching resolve
|
||||
- Support multiple notification channels (in-app, email, webhook)
|
||||
- Ensure notifications are delivered reliably
|
||||
- Include market outcome and user's position result
|
||||
|
||||
## Implementation Phases
|
||||
|
||||
### Phase 1: Database Schema
|
||||
- Add notifications table with columns: id, user_id, market_id, type, status, created_at
|
||||
- Add user_notification_preferences table for channel preferences
|
||||
- Create indexes on user_id and market_id for performance
|
||||
|
||||
### Phase 2: Notification Service
|
||||
- Create notification service in lib/notifications.ts
|
||||
- Implement notification queue using BullMQ/Redis
|
||||
- Add retry logic for failed deliveries
|
||||
- Create notification templates
|
||||
|
||||
### Phase 3: Integration Points
|
||||
- Hook into market resolution logic (when status changes to "resolved")
|
||||
- Query all users with positions in market
|
||||
- Enqueue notifications for each user
|
||||
|
||||
### Phase 4: Frontend Components
|
||||
- Create NotificationBell component in header
|
||||
- Add NotificationList modal
|
||||
- Implement real-time updates via Supabase subscriptions
|
||||
- Add notification preferences page
|
||||
|
||||
## Dependencies
|
||||
- Redis (for queue)
|
||||
- Email service (SendGrid/Resend)
|
||||
- Supabase real-time subscriptions
|
||||
|
||||
## Risks
|
||||
- HIGH: Email deliverability (SPF/DKIM required)
|
||||
- MEDIUM: Performance with 1000+ users per market
|
||||
- MEDIUM: Notification spam if markets resolve frequently
|
||||
- LOW: Real-time subscription overhead
|
||||
|
||||
## Estimated Complexity: MEDIUM
|
||||
- Backend: 4-6 hours
|
||||
- Frontend: 3-4 hours
|
||||
- Testing: 2-3 hours
|
||||
- Total: 9-13 hours
|
||||
|
||||
**WAITING FOR CONFIRMATION**: Proceed with this plan? (yes/no/modify)
|
||||
```
|
||||
|
||||
## Notas Importantes
|
||||
|
||||
**CRITICAL**: O agente planner **NÃO** vai escrever código até você confirmar explicitamente o plano com "yes", "proceed" ou resposta afirmativa similar.
|
||||
|
||||
Se quiser mudanças, responda com:
|
||||
- "modificar: [suas alterações]"
|
||||
- "abordagem diferente: [alternativa]"
|
||||
- "pular fase 2 e fazer fase 3 primeiro"
|
||||
|
||||
Após planejar:
|
||||
- Use `/tdd` para implementar com test-driven development
|
||||
- Use `/build-fix` se ocorrerem erros de build
|
||||
- Use `/code-review` para revisar a implementação concluída
|
||||
|
||||
## Agentes Relacionados
|
||||
|
||||
Este comando invoca o agente `planner` fornecido pelo ECC.
|
||||
|
||||
Para instalações manuais, o arquivo fonte fica em:
|
||||
`agents/planner.md`
|
||||
80
docs/pt-BR/commands/refactor-clean.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# Refactor Clean
|
||||
|
||||
Identifique e remova código morto com segurança, com verificação de testes em cada passo.
|
||||
|
||||
## Passo 1: Detectar Código Morto
|
||||
|
||||
Rode ferramentas de análise com base no tipo do projeto:
|
||||
|
||||
| Tool | What It Finds | Command |
|
||||
|------|--------------|---------|
|
||||
| knip | Unused exports, files, dependencies | `npx knip` |
|
||||
| depcheck | Unused npm dependencies | `npx depcheck` |
|
||||
| ts-prune | Unused TypeScript exports | `npx ts-prune` |
|
||||
| vulture | Unused Python code | `vulture src/` |
|
||||
| deadcode | Unused Go code | `deadcode ./...` |
|
||||
| cargo-udeps | Unused Rust dependencies | `cargo +nightly udeps` |
|
||||
|
||||
Se nenhuma ferramenta estiver disponível, use Grep para encontrar exports com zero imports:
|
||||
```
|
||||
# Find exports, then check if they're imported anywhere
|
||||
```
|
||||
|
||||
## Passo 2: Categorizar Achados
|
||||
|
||||
Classifique os achados em níveis de segurança:
|
||||
|
||||
| Tier | Examples | Action |
|
||||
|------|----------|--------|
|
||||
| **SAFE** | Unused utilities, test helpers, internal functions | Delete with confidence |
|
||||
| **CAUTION** | Components, API routes, middleware | Verify no dynamic imports or external consumers |
|
||||
| **DANGER** | Config files, entry points, type definitions | Investigate before touching |
|
||||
|
||||
## Passo 3: Loop de Remoção Segura
|
||||
|
||||
Para cada item SAFE:
|
||||
|
||||
1. **Rode a suíte completa de testes** — Estabeleça baseline (tudo verde)
|
||||
2. **Delete o código morto** — Use a ferramenta Edit para remoção cirúrgica
|
||||
3. **Rode a suíte de testes novamente** — Verifique se nada quebrou
|
||||
4. **Se testes falharem** — Reverta imediatamente com `git checkout -- <file>` e pule este item
|
||||
5. **Se testes passarem** — Vá para o próximo item
|
||||
|
||||
## Passo 4: Tratar Itens CAUTION
|
||||
|
||||
Antes de deletar itens CAUTION:
|
||||
- Procure imports dinâmicos: `import()`, `require()`, `__import__`
|
||||
- Procure referências em string: nomes de rota, nomes de componente em configs
|
||||
- Verifique se é exportado por API pública de pacote
|
||||
- Verifique ausência de consumidores externos (dependents, se publicado)
|
||||
|
||||
## Passo 5: Consolidar Duplicatas
|
||||
|
||||
Depois de remover código morto, procure:
|
||||
- Funções quase duplicadas (>80% similares) — mesclar em uma
|
||||
- Definições de tipo redundantes — consolidar
|
||||
- Funções wrapper sem valor — inline
|
||||
- Re-exports sem propósito — remover indireção
|
||||
|
||||
## Passo 6: Resumo
|
||||
|
||||
Reporte resultados:
|
||||
|
||||
```
|
||||
Dead Code Cleanup
|
||||
──────────────────────────────
|
||||
Deleted: 12 unused functions
|
||||
3 unused files
|
||||
5 unused dependencies
|
||||
Skipped: 2 items (tests failed)
|
||||
Saved: ~450 lines removed
|
||||
──────────────────────────────
|
||||
All tests passing ✅
|
||||
```
|
||||
|
||||
## Regras
|
||||
|
||||
- **Nunca delete sem rodar testes antes**
|
||||
- **Uma remoção por vez** — Mudanças atômicas facilitam rollback
|
||||
- **Se houver dúvida, pule** — Melhor manter código morto do que quebrar produção
|
||||
- **Não refatore durante limpeza** — Separe responsabilidades (limpar primeiro, refatorar depois)
|
||||
80
docs/pt-BR/commands/setup-pm.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
description: Configure seu package manager preferido (npm/pnpm/yarn/bun)
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# Configuração de Package Manager
|
||||
|
||||
Configure seu package manager preferido para este projeto ou globalmente.
|
||||
|
||||
## Uso
|
||||
|
||||
```bash
|
||||
# Detect current package manager
|
||||
node scripts/setup-package-manager.js --detect
|
||||
|
||||
# Set global preference
|
||||
node scripts/setup-package-manager.js --global pnpm
|
||||
|
||||
# Set project preference
|
||||
node scripts/setup-package-manager.js --project bun
|
||||
|
||||
# List available package managers
|
||||
node scripts/setup-package-manager.js --list
|
||||
```
|
||||
|
||||
## Prioridade de Detecção
|
||||
|
||||
Ao determinar qual package manager usar, esta ordem é verificada:
|
||||
|
||||
1. **Environment variable**: `CLAUDE_PACKAGE_MANAGER`
|
||||
2. **Project config**: `.claude/package-manager.json`
|
||||
3. **package.json**: `packageManager` field
|
||||
4. **Lock file**: Presence of package-lock.json, yarn.lock, pnpm-lock.yaml, or bun.lockb
|
||||
5. **Global config**: `~/.claude/package-manager.json`
|
||||
6. **Fallback**: First available package manager (pnpm > bun > yarn > npm)
|
||||
|
||||
## Arquivos de Configuração
|
||||
|
||||
### Configuração Global
|
||||
```json
|
||||
// ~/.claude/package-manager.json
|
||||
{
|
||||
"packageManager": "pnpm"
|
||||
}
|
||||
```
|
||||
|
||||
### Configuração do Projeto
|
||||
```json
|
||||
// .claude/package-manager.json
|
||||
{
|
||||
"packageManager": "bun"
|
||||
}
|
||||
```
|
||||
|
||||
### package.json
|
||||
```json
|
||||
{
|
||||
"packageManager": "pnpm@8.6.0"
|
||||
}
|
||||
```
|
||||
|
||||
## Variável de Ambiente
|
||||
|
||||
Defina `CLAUDE_PACKAGE_MANAGER` para sobrescrever todos os outros métodos de detecção:
|
||||
|
||||
```bash
|
||||
# Windows (PowerShell)
|
||||
$env:CLAUDE_PACKAGE_MANAGER = "pnpm"
|
||||
|
||||
# macOS/Linux
|
||||
export CLAUDE_PACKAGE_MANAGER=pnpm
|
||||
```
|
||||
|
||||
## Rodar a Detecção
|
||||
|
||||
Para ver os resultados atuais da detecção de package manager, rode:
|
||||
|
||||
```bash
|
||||
node scripts/setup-package-manager.js --detect
|
||||
```
|
||||
328
docs/pt-BR/commands/tdd.md
Normal file
@@ -0,0 +1,328 @@
|
||||
---
|
||||
description: Impõe fluxo de desenvolvimento orientado a testes. Estruture interfaces, gere testes PRIMEIRO e depois implemente código mínimo para passar. Garanta cobertura de 80%+.
|
||||
---
|
||||
|
||||
# Comando TDD
|
||||
|
||||
Este comando invoca o agente **tdd-guide** para impor a metodologia de desenvolvimento orientado a testes.
|
||||
|
||||
## O Que Este Comando Faz
|
||||
|
||||
1. **Estruturar Interfaces** - Definir tipos/interfaces primeiro
|
||||
2. **Gerar Testes Primeiro** - Escrever testes que falham (RED)
|
||||
3. **Implementar Código Mínimo** - Escrever apenas o suficiente para passar (GREEN)
|
||||
4. **Refatorar** - Melhorar o código mantendo testes verdes (REFACTOR)
|
||||
5. **Verificar Cobertura** - Garantir cobertura de testes de 80%+
|
||||
|
||||
## Quando Usar
|
||||
|
||||
Use `/tdd` quando:
|
||||
- Implementar novas features
|
||||
- Adicionar novas funções/componentes
|
||||
- Corrigir bugs (escrever primeiro teste que reproduz o bug)
|
||||
- Refatorar código existente
|
||||
- Construir lógica de negócio crítica
|
||||
|
||||
## Como Funciona
|
||||
|
||||
O agente tdd-guide vai:
|
||||
|
||||
1. **Definir interfaces** para entradas/saídas
|
||||
2. **Escrever testes que vão FALHAR** (porque o código ainda não existe)
|
||||
3. **Rodar testes** e verificar que falham pelo motivo correto
|
||||
4. **Escrever implementação mínima** para fazer testes passarem
|
||||
5. **Rodar testes** e verificar que passam
|
||||
6. **Refatorar** código mantendo testes verdes
|
||||
7. **Checar cobertura** e adicionar mais testes se estiver abaixo de 80%
|
||||
|
||||
## Ciclo TDD
|
||||
|
||||
```
|
||||
RED → GREEN → REFACTOR → REPEAT
|
||||
|
||||
RED: Write a failing test
|
||||
GREEN: Write minimal code to pass
|
||||
REFACTOR: Improve code, keep tests passing
|
||||
REPEAT: Next feature/scenario
|
||||
```
|
||||
|
||||
## Exemplo de Uso
|
||||
|
||||
```
|
||||
Usuário: /tdd Preciso de uma função para calcular a pontuação de liquidez do mercado
|
||||
|
||||
Agent (tdd-guide):
|
||||
# Sessão TDD: Calculadora de Pontuação de Liquidez de Mercado
|
||||
|
||||
## Etapa 1: Definir Interface (SCAFFOLD)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts
|
||||
export interface MarketData {
|
||||
totalVolume: number
|
||||
bidAskSpread: number
|
||||
activeTraders: number
|
||||
lastTradeTime: Date
|
||||
}
|
||||
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
// TODO: Implementation
|
||||
throw new Error('Not implemented')
|
||||
}
|
||||
```
|
||||
|
||||
## Etapa 2: Escreva o teste com falha (VERMELHO)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.test.ts
|
||||
import { calculateLiquidityScore } from './liquidity'
|
||||
|
||||
describe('calculateLiquidityScore', () => {
|
||||
it('should return high score for liquid market', () => {
|
||||
const market = {
|
||||
totalVolume: 100000,
|
||||
bidAskSpread: 0.01,
|
||||
activeTraders: 500,
|
||||
lastTradeTime: new Date()
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBeGreaterThan(80)
|
||||
expect(score).toBeLessThanOrEqual(100)
|
||||
})
|
||||
|
||||
it('should return low score for illiquid market', () => {
|
||||
const market = {
|
||||
totalVolume: 100,
|
||||
bidAskSpread: 0.5,
|
||||
activeTraders: 2,
|
||||
lastTradeTime: new Date(Date.now() - 86400000) // 1 day ago
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBeLessThan(30)
|
||||
expect(score).toBeGreaterThanOrEqual(0)
|
||||
})
|
||||
|
||||
it('should handle edge case: zero volume', () => {
|
||||
const market = {
|
||||
totalVolume: 0,
|
||||
bidAskSpread: 0,
|
||||
activeTraders: 0,
|
||||
lastTradeTime: new Date()
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBe(0)
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Etapa 3: Executar testes - Verificar FALHA
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
FAIL lib/liquidity.test.ts
|
||||
✕ should return high score for liquid market (2 ms)
|
||||
Error: Not implemented
|
||||
|
||||
1 test failed, 0 passed
|
||||
```
|
||||
|
||||
✅ Os testes falharam conforme o esperado. Pronto para implementação.
|
||||
|
||||
## Etapa 4: Implementar o código mínimo (VERDE)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
// Handle zero volume edge case
|
||||
if (market.totalVolume === 0) {
|
||||
return 0
|
||||
}
|
||||
|
||||
// Calculate component scores (0-100 scale)
|
||||
const volumeScore = Math.min(market.totalVolume / 1000, 100)
|
||||
const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0)
|
||||
const traderScore = Math.min(market.activeTraders / 10, 100)
|
||||
|
||||
// Recent activity bonus
|
||||
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
|
||||
const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0)
|
||||
|
||||
// Weighted average
|
||||
const score = (
|
||||
volumeScore * 0.4 +
|
||||
spreadScore * 0.3 +
|
||||
traderScore * 0.2 +
|
||||
recencyScore * 0.1
|
||||
)
|
||||
|
||||
return Math.min(Math.max(score, 0), 100) // Clamp to 0-100
|
||||
}
|
||||
```
|
||||
|
||||
## Etapa 5: Executar testes - Verificar se foi aprovado
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
PASS lib/liquidity.test.ts
|
||||
✓ should return high score for liquid market (3 ms)
|
||||
✓ should return low score for illiquid market (2 ms)
|
||||
✓ should handle edge case: zero volume (1 ms)
|
||||
|
||||
3 tests passed
|
||||
```
|
||||
|
||||
✅ Todos os testes passando
|
||||
|
||||
## Etapa 6: Refatorar (MELHORAR)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts - Refatorado com constantes e melhor legibilidade.
|
||||
const WEIGHTS = {
|
||||
VOLUME: 0.4,
|
||||
SPREAD: 0.3,
|
||||
TRADERS: 0.2,
|
||||
RECENCY: 0.1,
|
||||
} as const
|
||||
|
||||
const SCALE_FACTORS = {
|
||||
VOLUME: 1000,
|
||||
SPREAD: 1000,
|
||||
TRADERS: 10,
|
||||
RECENCY_PENALTY: 10,
|
||||
} as const
|
||||
|
||||
function clamp(value: number, min: number, max: number): number {
|
||||
return Math.min(Math.max(value, min), max)
|
||||
}
|
||||
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
if (market.totalVolume === 0) return 0
|
||||
|
||||
const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100)
|
||||
const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100)
|
||||
const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100)
|
||||
|
||||
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
|
||||
const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100)
|
||||
|
||||
const weightedScore =
|
||||
volumeScore * WEIGHTS.VOLUME +
|
||||
spreadScore * WEIGHTS.SPREAD +
|
||||
traderScore * WEIGHTS.TRADERS +
|
||||
recencyScore * WEIGHTS.RECENCY
|
||||
|
||||
return clamp(weightedScore, 0, 100)
|
||||
}
|
||||
```
|
||||
|
||||
## Etapa 7: Verificar se os testes ainda são aprovados
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
PASS lib/liquidity.test.ts
|
||||
✓ should return high score for liquid market (3 ms)
|
||||
✓ should return low score for illiquid market (2 ms)
|
||||
✓ should handle edge case: zero volume (1 ms)
|
||||
|
||||
3 tests passed
|
||||
```
|
||||
|
||||
✅ Refatoração concluída, testes ainda passando!
|
||||
|
||||
## Etapa 8: Verificar a cobertura
|
||||
|
||||
```bash
|
||||
npm test -- --coverage lib/liquidity.test.ts
|
||||
|
||||
File | % Stmts | % Branch | % Funcs | % Lines
|
||||
---------------|---------|----------|---------|--------
|
||||
liquidity.ts | 100 | 100 | 100 | 100
|
||||
|
||||
Coverage: 100% ✅ (Target: 80%)
|
||||
```
|
||||
|
||||
✅ TDD sessão completa!
|
||||
```
|
||||
|
||||
## Boas Práticas de TDD
|
||||
|
||||
**Fazer:**
|
||||
- ✅ Escreva o teste PRIMEIRO, antes da implementação
|
||||
- ✅ Rode testes e confirme que FALHAM antes de implementar
|
||||
- ✅ Escreva código mínimo para fazer passar
|
||||
- ✅ Refatore só depois que os testes estiverem verdes
|
||||
- ✅ Adicione casos de borda e cenários de erro
|
||||
- ✅ Mire 80%+ de cobertura (100% para código crítico)
|
||||
|
||||
**Não fazer:**
|
||||
- ❌ Escrever implementação antes de testes
|
||||
- ❌ Pular execução de testes após cada mudança
|
||||
- ❌ Escrever código demais de uma vez
|
||||
- ❌ Ignorar testes falhando
|
||||
- ❌ Testar detalhes de implementação (teste comportamento)
|
||||
- ❌ Fazer mock de tudo (prefira testes de integração)
|
||||
|
||||
## Tipos de Teste a Incluir
|
||||
|
||||
**Testes Unitários** (nível de função):
|
||||
- Cenários happy path
|
||||
- Casos de borda (vazio, null, valores máximos)
|
||||
- Condições de erro
|
||||
- Valores de fronteira
|
||||
|
||||
**Testes de Integração** (nível de componente):
|
||||
- Endpoints de API
|
||||
- Operações de banco de dados
|
||||
- Chamadas a serviços externos
|
||||
- Componentes React com hooks
|
||||
|
||||
**Testes E2E** (use comando `/e2e`):
|
||||
- Fluxos críticos de usuário
|
||||
- Processos multi-etapa
|
||||
- Integração full stack
|
||||
|
||||
## Requisitos de Cobertura
|
||||
|
||||
- **Mínimo de 80%** para todo o código
|
||||
- **100% obrigatório** para:
|
||||
- Cálculos financeiros
|
||||
- Lógica de autenticação
|
||||
- Código crítico de segurança
|
||||
- Lógica de negócio central
|
||||
|
||||
## Notas Importantes
|
||||
|
||||
**MANDATÓRIO**: Os testes devem ser escritos ANTES da implementação. O ciclo TDD é:
|
||||
|
||||
1. **RED** - Escrever teste que falha
|
||||
2. **GREEN** - Implementar para passar
|
||||
3. **REFACTOR** - Melhorar código
|
||||
|
||||
Nunca pule a fase RED. Nunca escreva código antes dos testes.
|
||||
|
||||
## Integração com Outros Comandos
|
||||
|
||||
- Use `/plan` primeiro para entender o que construir
|
||||
- Use `/tdd` para implementar com testes
|
||||
- Use `/build-fix` se ocorrerem erros de build
|
||||
- Use `/code-review` para revisar implementação
|
||||
- Use `/test-coverage` para verificar cobertura
|
||||
|
||||
## Agentes Relacionados
|
||||
|
||||
Este comando invoca o agente `tdd-guide` fornecido pelo ECC.
|
||||
|
||||
A skill relacionada `tdd-workflow` também é distribuída com o ECC.
|
||||
|
||||
Para instalações manuais, os arquivos fonte ficam em:
|
||||
- `agents/tdd-guide.md`
|
||||
- `skills/tdd-workflow/SKILL.md`
|
||||
69
docs/pt-BR/commands/test-coverage.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# Cobertura de Testes
|
||||
|
||||
Analise cobertura de testes, identifique lacunas e gere testes faltantes para alcançar cobertura de 80%+.
|
||||
|
||||
## Passo 1: Detectar Framework de Teste
|
||||
|
||||
| Indicator | Coverage Command |
|
||||
|-----------|-----------------|
|
||||
| `jest.config.*` or `package.json` jest | `npx jest --coverage --coverageReporters=json-summary` |
|
||||
| `vitest.config.*` | `npx vitest run --coverage` |
|
||||
| `pytest.ini` / `pyproject.toml` pytest | `pytest --cov=src --cov-report=json` |
|
||||
| `Cargo.toml` | `cargo llvm-cov --json` |
|
||||
| `pom.xml` with JaCoCo | `mvn test jacoco:report` |
|
||||
| `go.mod` | `go test -coverprofile=coverage.out ./...` |
|
||||
|
||||
## Passo 2: Analisar Relatório de Cobertura
|
||||
|
||||
1. Rode o comando de cobertura
|
||||
2. Parseie a saída (resumo em JSON ou saída de terminal)
|
||||
3. Liste arquivos **abaixo de 80% de cobertura**, ordenados do pior para o melhor
|
||||
4. Para cada arquivo abaixo da meta, identifique:
|
||||
- Funções ou métodos sem teste
|
||||
- Cobertura de branch faltante (if/else, switch, caminhos de erro)
|
||||
- Código morto que infla o denominador
|
||||
|
||||
## Passo 3: Gerar Testes Faltantes
|
||||
|
||||
Para cada arquivo abaixo da meta, gere testes seguindo esta prioridade:
|
||||
|
||||
1. **Happy path** — Funcionalidade principal com entradas válidas
|
||||
2. **Tratamento de erro** — Entradas inválidas, dados ausentes, falhas de rede
|
||||
3. **Casos de borda** — Arrays vazios, null/undefined, valores de fronteira (0, -1, MAX_INT)
|
||||
4. **Cobertura de branch** — Cada if/else, caso de switch, ternário
|
||||
|
||||
### Regras para Geração de Testes
|
||||
|
||||
- Coloque testes adjacentes ao código-fonte: `foo.ts` → `foo.test.ts` (ou convenção do projeto)
|
||||
- Use padrões de teste existentes do projeto (estilo de import, biblioteca de asserção, abordagem de mocking)
|
||||
- Faça mock de dependências externas (banco, APIs, sistema de arquivos)
|
||||
- Cada teste deve ser independente — sem estado mutável compartilhado entre testes
|
||||
- Nomeie testes de forma descritiva: `test_create_user_with_duplicate_email_returns_409`
|
||||
|
||||
## Passo 4: Verificar
|
||||
|
||||
1. Rode a suíte completa de testes — todos os testes devem passar
|
||||
2. Rode cobertura novamente — confirme a melhoria
|
||||
3. Se ainda estiver abaixo de 80%, repita o Passo 3 para as lacunas restantes
|
||||
|
||||
## Passo 5: Reportar
|
||||
|
||||
Mostre comparação antes/depois:
|
||||
|
||||
```
|
||||
Coverage Report
|
||||
──────────────────────────────
|
||||
File Before After
|
||||
src/services/auth.ts 45% 88%
|
||||
src/utils/validation.ts 32% 82%
|
||||
──────────────────────────────
|
||||
Overall: 67% 84% ✅
|
||||
```
|
||||
|
||||
## Áreas de Foco
|
||||
|
||||
- Funções com branching complexo (alta complexidade ciclomática)
|
||||
- Error handlers e blocos catch
|
||||
- Funções utilitárias usadas em todo o codebase
|
||||
- Handlers de endpoint de API (fluxo request → response)
|
||||
- Casos de borda: null, undefined, string vazia, array vazio, zero, números negativos
|
||||
72
docs/pt-BR/commands/update-codemaps.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# Atualizar Codemaps
|
||||
|
||||
Analise a estrutura do codebase e gere documentação arquitetural enxuta em tokens.
|
||||
|
||||
## Passo 1: Escanear Estrutura do Projeto
|
||||
|
||||
1. Identifique o tipo de projeto (monorepo, app única, library, microservice)
|
||||
2. Encontre todos os diretórios de código-fonte (src/, lib/, app/, packages/)
|
||||
3. Mapeie entry points (main.ts, index.ts, app.py, main.go, etc.)
|
||||
|
||||
## Passo 2: Gerar Codemaps
|
||||
|
||||
Crie ou atualize codemaps em `docs/CODEMAPS/` (ou `.reports/codemaps/`):
|
||||
|
||||
| File | Contents |
|
||||
|------|----------|
|
||||
| `architecture.md` | High-level system diagram, service boundaries, data flow |
|
||||
| `backend.md` | API routes, middleware chain, service → repository mapping |
|
||||
| `frontend.md` | Page tree, component hierarchy, state management flow |
|
||||
| `data.md` | Database tables, relationships, migration history |
|
||||
| `dependencies.md` | External services, third-party integrations, shared libraries |
|
||||
|
||||
### Formato de Codemap
|
||||
|
||||
Cada codemap deve ser enxuto em tokens — otimizado para consumo de contexto por IA:
|
||||
|
||||
```markdown
|
||||
# Backend Architecture
|
||||
|
||||
## Routes
|
||||
POST /api/users → UserController.create → UserService.create → UserRepo.insert
|
||||
GET /api/users/:id → UserController.get → UserService.findById → UserRepo.findById
|
||||
|
||||
## Key Files
|
||||
src/services/user.ts (business logic, 120 lines)
|
||||
src/repos/user.ts (database access, 80 lines)
|
||||
|
||||
## Dependencies
|
||||
- PostgreSQL (primary data store)
|
||||
- Redis (session cache, rate limiting)
|
||||
- Stripe (payment processing)
|
||||
```
|
||||
|
||||
## Passo 3: Detecção de Diff
|
||||
|
||||
1. Se codemaps anteriores existirem, calcule a porcentagem de diff
|
||||
2. Se mudanças > 30%, mostre o diff e solicite aprovação do usuário antes de sobrescrever
|
||||
3. Se mudanças <= 30%, atualize in-place
|
||||
|
||||
## Passo 4: Adicionar Metadados
|
||||
|
||||
Adicione um cabeçalho de freshness em cada codemap:
|
||||
|
||||
```markdown
|
||||
<!-- Generated: 2026-02-11 | Files scanned: 142 | Token estimate: ~800 -->
|
||||
```
|
||||
|
||||
## Passo 5: Salvar Relatório de Análise
|
||||
|
||||
Escreva um resumo em `.reports/codemap-diff.txt`:
|
||||
- Arquivos adicionados/removidos/modificados desde o último scan
|
||||
- Novas dependências detectadas
|
||||
- Mudanças de arquitetura (novas rotas, novos serviços etc.)
|
||||
- Alertas de obsolescência para docs sem atualização em 90+ dias
|
||||
|
||||
## Dicas
|
||||
|
||||
- Foque em **estrutura de alto nível**, não em detalhes de implementação
|
||||
- Prefira **caminhos de arquivo e assinaturas de função** em vez de blocos de código completos
|
||||
- Mantenha cada codemap abaixo de **1000 tokens** para carregamento eficiente de contexto
|
||||
- Use diagramas ASCII para fluxo de dados em vez de descrições verbosas
|
||||
- Rode após grandes adições de feature ou sessões de refatoração
|
||||
84
docs/pt-BR/commands/update-docs.md
Normal file
@@ -0,0 +1,84 @@
|
||||
# Atualizar Documentação
|
||||
|
||||
Sincronize a documentação com o codebase, gerando a partir de arquivos fonte da verdade.
|
||||
|
||||
## Passo 1: Identificar Fontes da Verdade
|
||||
|
||||
| Source | Generates |
|
||||
|--------|-----------|
|
||||
| `package.json` scripts | Available commands reference |
|
||||
| `.env.example` | Environment variable documentation |
|
||||
| `openapi.yaml` / route files | API endpoint reference |
|
||||
| Source code exports | Public API documentation |
|
||||
| `Dockerfile` / `docker-compose.yml` | Infrastructure setup docs |
|
||||
|
||||
## Passo 2: Gerar Referência de Scripts
|
||||
|
||||
1. Leia `package.json` (ou `Makefile`, `Cargo.toml`, `pyproject.toml`)
|
||||
2. Extraia todos os scripts/comandos com suas descrições
|
||||
3. Gere uma tabela de referência:
|
||||
|
||||
```markdown
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `npm run dev` | Start development server with hot reload |
|
||||
| `npm run build` | Production build with type checking |
|
||||
| `npm test` | Run test suite with coverage |
|
||||
```
|
||||
|
||||
## Passo 3: Gerar Documentação de Ambiente
|
||||
|
||||
1. Leia `.env.example` (ou `.env.template`, `.env.sample`)
|
||||
2. Extraia todas as variáveis e seus propósitos
|
||||
3. Categorize como required vs optional
|
||||
4. Documente formato esperado e valores válidos
|
||||
|
||||
```markdown
|
||||
| Variable | Required | Description | Example |
|
||||
|----------|----------|-------------|---------|
|
||||
| `DATABASE_URL` | Yes | PostgreSQL connection string | `postgres://user:pass@host:5432/db` |
|
||||
| `LOG_LEVEL` | No | Logging verbosity (default: info) | `debug`, `info`, `warn`, `error` |
|
||||
```
|
||||
|
||||
## Passo 4: Atualizar Guia de Contribuição
|
||||
|
||||
Gere ou atualize `docs/CONTRIBUTING.md` com:
|
||||
- Setup do ambiente de desenvolvimento (pré-requisitos, passos de instalação)
|
||||
- Scripts disponíveis e seus propósitos
|
||||
- Procedimentos de teste (como rodar, como escrever novos testes)
|
||||
- Enforcement de estilo de código (linter, formatter, hooks pre-commit)
|
||||
- Checklist de submissão de PR
|
||||
|
||||
## Passo 5: Atualizar Runbook
|
||||
|
||||
Gere ou atualize `docs/RUNBOOK.md` com:
|
||||
- Procedimentos de deploy (passo a passo)
|
||||
- Endpoints de health check e monitoramento
|
||||
- Problemas comuns e suas correções
|
||||
- Procedimentos de rollback
|
||||
- Caminhos de alerta e escalonamento
|
||||
|
||||
## Passo 6: Checagem de Obsolescência
|
||||
|
||||
1. Encontre arquivos de documentação sem modificação há 90+ dias
|
||||
2. Cruze com mudanças recentes no código-fonte
|
||||
3. Sinalize docs potencialmente desatualizadas para revisão manual
|
||||
|
||||
## Passo 7: Mostrar Resumo
|
||||
|
||||
```
|
||||
Documentation Update
|
||||
──────────────────────────────
|
||||
Updated: docs/CONTRIBUTING.md (scripts table)
|
||||
Updated: docs/ENV.md (3 new variables)
|
||||
Flagged: docs/DEPLOY.md (142 days stale)
|
||||
Skipped: docs/API.md (no changes detected)
|
||||
──────────────────────────────
|
||||
```
|
||||
|
||||
## Regras
|
||||
|
||||
- **Fonte única da verdade**: Sempre gere a partir do código, nunca edite manualmente seções geradas
|
||||
- **Preserve seções manuais**: Atualize apenas seções geradas; mantenha prosa escrita manualmente intacta
|
||||
- **Marque conteúdo gerado**: Use marcadores `<!-- AUTO-GENERATED -->` ao redor das seções geradas
|
||||
- **Não crie docs sem solicitação**: Só crie novos arquivos de docs se o comando solicitar explicitamente
|
||||
59
docs/pt-BR/commands/verify.md
Normal file
@@ -0,0 +1,59 @@
|
||||
# Comando Verification
|
||||
|
||||
Rode verificação abrangente no estado atual do codebase.
|
||||
|
||||
## Instruções
|
||||
|
||||
Execute a verificação nesta ordem exata:
|
||||
|
||||
1. **Build Check**
|
||||
- Rode o comando de build deste projeto
|
||||
- Se falhar, reporte erros e PARE
|
||||
|
||||
2. **Type Check**
|
||||
- Rode o TypeScript/type checker
|
||||
- Reporte todos os erros com file:line
|
||||
|
||||
3. **Lint Check**
|
||||
- Rode o linter
|
||||
- Reporte warnings e errors
|
||||
|
||||
4. **Test Suite**
|
||||
- Rode todos os testes
|
||||
- Reporte contagem de pass/fail
|
||||
- Reporte percentual de cobertura
|
||||
|
||||
5. **Console.log Audit**
|
||||
- Procure por console.log em arquivos de código-fonte
|
||||
- Reporte localizações
|
||||
|
||||
6. **Git Status**
|
||||
- Mostre mudanças não commitadas
|
||||
- Mostre arquivos modificados desde o último commit
|
||||
|
||||
## Saída
|
||||
|
||||
Produza um relatório conciso de verificação:
|
||||
|
||||
```
|
||||
VERIFICATION: [PASS/FAIL]
|
||||
|
||||
Build: [OK/FAIL]
|
||||
Types: [OK/X errors]
|
||||
Lint: [OK/X issues]
|
||||
Tests: [X/Y passed, Z% coverage]
|
||||
Secrets: [OK/X found]
|
||||
Logs: [OK/X console.logs]
|
||||
|
||||
Ready for PR: [YES/NO]
|
||||
```
|
||||
|
||||
Se houver problemas críticos, liste-os com sugestões de correção.
|
||||
|
||||
## Argumentos
|
||||
|
||||
$ARGUMENTS podem ser:
|
||||
- `quick` - Apenas build + types
|
||||
- `full` - Todas as checagens (padrão)
|
||||
- `pre-commit` - Checagens relevantes para commits
|
||||
- `pre-pr` - Checagens completas mais security scan
|
||||
100
docs/pt-BR/examples/CLAUDE.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# Exemplo de CLAUDE.md de Projeto
|
||||
|
||||
Este é um exemplo de arquivo CLAUDE.md no nível de projeto. Coloque-o na raiz do seu projeto.
|
||||
|
||||
## Visão Geral do Projeto
|
||||
|
||||
[Descrição breve do seu projeto - o que ele faz, stack tecnológica]
|
||||
|
||||
## Regras Críticas
|
||||
|
||||
### 1. Organização de Código
|
||||
|
||||
- Muitos arquivos pequenos em vez de poucos arquivos grandes
|
||||
- Alta coesão, baixo acoplamento
|
||||
- 200-400 linhas típico, 800 máximo por arquivo
|
||||
- Organize por feature/domínio, não por tipo
|
||||
|
||||
### 2. Estilo de Código
|
||||
|
||||
- Sem emojis em código, comentários ou documentação
|
||||
- Imutabilidade sempre - nunca mutar objetos ou arrays
|
||||
- Sem console.log em código de produção
|
||||
- Tratamento de erro adequado com try/catch
|
||||
- Validação de entrada com Zod ou similar
|
||||
|
||||
### 3. Testes
|
||||
|
||||
- TDD: escreva testes primeiro
|
||||
- Cobertura mínima de 80%
|
||||
- Testes unitários para utilitários
|
||||
- Testes de integração para APIs
|
||||
- Testes E2E para fluxos críticos
|
||||
|
||||
### 4. Segurança
|
||||
|
||||
- Sem segredos hardcoded
|
||||
- Variáveis de ambiente para dados sensíveis
|
||||
- Validar toda entrada de usuário
|
||||
- Apenas queries parametrizadas
|
||||
- Proteção CSRF habilitada
|
||||
|
||||
## Estrutura de Arquivos
|
||||
|
||||
```
|
||||
src/
|
||||
|-- app/ # Next.js app router
|
||||
|-- components/ # Reusable UI components
|
||||
|-- hooks/ # Custom React hooks
|
||||
|-- lib/ # Utility libraries
|
||||
|-- types/ # TypeScript definitions
|
||||
```
|
||||
|
||||
## Padrões-Chave
|
||||
|
||||
### Formato de Resposta de API
|
||||
|
||||
```typescript
|
||||
interface ApiResponse<T> {
|
||||
success: boolean
|
||||
data?: T
|
||||
error?: string
|
||||
}
|
||||
```
|
||||
|
||||
### Tratamento de Erro
|
||||
|
||||
```typescript
|
||||
try {
|
||||
const result = await operation()
|
||||
return { success: true, data: result }
|
||||
} catch (error) {
|
||||
console.error('Operation failed:', error)
|
||||
return { success: false, error: 'User-friendly message' }
|
||||
}
|
||||
```
|
||||
|
||||
## Variáveis de Ambiente
|
||||
|
||||
```bash
|
||||
# Required
|
||||
DATABASE_URL=
|
||||
API_KEY=
|
||||
|
||||
# Optional
|
||||
DEBUG=false
|
||||
```
|
||||
|
||||
## Comandos Disponíveis
|
||||
|
||||
- `/tdd` - Fluxo de desenvolvimento orientado a testes
|
||||
- `/plan` - Criar plano de implementação
|
||||
- `/code-review` - Revisar qualidade de código
|
||||
- `/build-fix` - Corrigir erros de build
|
||||
|
||||
## Fluxo Git
|
||||
|
||||
- Conventional commits: `feat:`, `fix:`, `refactor:`, `docs:`, `test:`
|
||||
- Nunca commitar direto na main
|
||||
- PRs exigem revisão
|
||||
- Todos os testes devem passar antes do merge
|
||||
308
docs/pt-BR/examples/django-api-CLAUDE.md
Normal file
@@ -0,0 +1,308 @@
|
||||
# Django REST API — CLAUDE.md de Projeto
|
||||
|
||||
> Exemplo real para uma API Django REST Framework com PostgreSQL e Celery.
|
||||
> Copie para a raiz do seu projeto e customize para seu serviço.
|
||||
|
||||
## Visão Geral do Projeto
|
||||
|
||||
**Stack:** Python 3.12+, Django 5.x, Django REST Framework, PostgreSQL, Celery + Redis, pytest, Docker Compose
|
||||
|
||||
**Arquitetura:** Design orientado a domínio com apps por domínio de negócio. DRF para camada de API, Celery para tarefas assíncronas, pytest para testes. Todos os endpoints retornam JSON — sem renderização de templates.
|
||||
|
||||
## Regras Críticas
|
||||
|
||||
### Convenções Python
|
||||
|
||||
- Type hints em todas as assinaturas de função — use `from __future__ import annotations`
|
||||
- Sem `print()` statements — use `logging.getLogger(__name__)`
|
||||
- f-strings para formatação, nunca `%` ou `.format()`
|
||||
- Use `pathlib.Path` e não `os.path` para operações de arquivo
|
||||
- Imports ordenados com isort: stdlib, third-party, local (enforced by ruff)
|
||||
|
||||
### Banco de Dados
|
||||
|
||||
- Todas as queries usam Django ORM — SQL bruto só com `.raw()` e queries parametrizadas
|
||||
- Migrations versionadas no git — nunca use `--fake` em produção
|
||||
- Use `select_related()` e `prefetch_related()` para prevenir queries N+1
|
||||
- Todos os models devem ter auto-fields `created_at` e `updated_at`
|
||||
- Índices em qualquer campo usado em `filter()`, `order_by()` ou cláusulas `WHERE`
|
||||
|
||||
```python
|
||||
# BAD: N+1 query
|
||||
orders = Order.objects.all()
|
||||
for order in orders:
|
||||
print(order.customer.name) # hits DB for each order
|
||||
|
||||
# GOOD: Single query with join
|
||||
orders = Order.objects.select_related("customer").all()
|
||||
```
|
||||
|
||||
### Autenticação
|
||||
|
||||
- JWT via `djangorestframework-simplejwt` — access token (15 min) + refresh token (7 days)
|
||||
- Permission classes em toda view — nunca confiar no padrão
|
||||
- Use `IsAuthenticated` como base e adicione permissões customizadas para acesso por objeto
|
||||
- Token blacklisting habilitado para logout
|
||||
|
||||
### Serializers
|
||||
|
||||
- Use `ModelSerializer` para CRUD simples, `Serializer` para validação complexa
|
||||
- Separe serializers de leitura e escrita quando input/output diferirem
|
||||
- Valide no nível de serializer, não na view — views devem ser enxutas
|
||||
|
||||
```python
|
||||
class CreateOrderSerializer(serializers.Serializer):
|
||||
product_id = serializers.UUIDField()
|
||||
quantity = serializers.IntegerField(min_value=1, max_value=100)
|
||||
|
||||
def validate_product_id(self, value):
|
||||
if not Product.objects.filter(id=value, active=True).exists():
|
||||
raise serializers.ValidationError("Product not found or inactive")
|
||||
return value
|
||||
|
||||
class OrderDetailSerializer(serializers.ModelSerializer):
|
||||
customer = CustomerSerializer(read_only=True)
|
||||
product = ProductSerializer(read_only=True)
|
||||
|
||||
class Meta:
|
||||
model = Order
|
||||
fields = ["id", "customer", "product", "quantity", "total", "status", "created_at"]
|
||||
```
|
||||
|
||||
### Tratamento de Erro
|
||||
|
||||
- Use DRF exception handler para respostas de erro consistentes
|
||||
- Exceções customizadas de regra de negócio em `core/exceptions.py`
|
||||
- Nunca exponha detalhes internos de erro para clientes
|
||||
|
||||
```python
|
||||
# core/exceptions.py
|
||||
from rest_framework.exceptions import APIException
|
||||
|
||||
class InsufficientStockError(APIException):
|
||||
status_code = 409
|
||||
default_detail = "Insufficient stock for this order"
|
||||
default_code = "insufficient_stock"
|
||||
```
|
||||
|
||||
### Estilo de Código
|
||||
|
||||
- Sem emojis em código ou comentários
|
||||
- Tamanho máximo de linha: 120 caracteres (enforced by ruff)
|
||||
- Classes: PascalCase, funções/variáveis: snake_case, constantes: UPPER_SNAKE_CASE
|
||||
- Views enxutas — lógica de negócio em funções de serviço ou métodos do model
|
||||
|
||||
## Estrutura de Arquivos
|
||||
|
||||
```
|
||||
config/
|
||||
settings/
|
||||
base.py # Shared settings
|
||||
local.py # Dev overrides (DEBUG=True)
|
||||
production.py # Production settings
|
||||
urls.py # Root URL config
|
||||
celery.py # Celery app configuration
|
||||
apps/
|
||||
accounts/ # User auth, registration, profile
|
||||
models.py
|
||||
serializers.py
|
||||
views.py
|
||||
services.py # Business logic
|
||||
tests/
|
||||
test_views.py
|
||||
test_services.py
|
||||
factories.py # Factory Boy factories
|
||||
orders/ # Order management
|
||||
models.py
|
||||
serializers.py
|
||||
views.py
|
||||
services.py
|
||||
tasks.py # Celery tasks
|
||||
tests/
|
||||
products/ # Product catalog
|
||||
models.py
|
||||
serializers.py
|
||||
views.py
|
||||
tests/
|
||||
core/
|
||||
exceptions.py # Custom API exceptions
|
||||
permissions.py # Shared permission classes
|
||||
pagination.py # Custom pagination
|
||||
middleware.py # Request logging, timing
|
||||
tests/
|
||||
```
|
||||
|
||||
## Padrões-Chave
|
||||
|
||||
### Camada de Serviço
|
||||
|
||||
```python
|
||||
# apps/orders/services.py
|
||||
from django.db import transaction
|
||||
|
||||
def create_order(*, customer, product_id: uuid.UUID, quantity: int) -> Order:
|
||||
"""Create an order with stock validation and payment hold."""
|
||||
product = Product.objects.select_for_update().get(id=product_id)
|
||||
|
||||
if product.stock < quantity:
|
||||
raise InsufficientStockError()
|
||||
|
||||
with transaction.atomic():
|
||||
order = Order.objects.create(
|
||||
customer=customer,
|
||||
product=product,
|
||||
quantity=quantity,
|
||||
total=product.price * quantity,
|
||||
)
|
||||
product.stock -= quantity
|
||||
product.save(update_fields=["stock", "updated_at"])
|
||||
|
||||
# Async: send confirmation email
|
||||
send_order_confirmation.delay(order.id)
|
||||
return order
|
||||
```
|
||||
|
||||
### Padrão de View
|
||||
|
||||
```python
|
||||
# apps/orders/views.py
|
||||
class OrderViewSet(viewsets.ModelViewSet):
|
||||
permission_classes = [IsAuthenticated]
|
||||
pagination_class = StandardPagination
|
||||
|
||||
def get_serializer_class(self):
|
||||
if self.action == "create":
|
||||
return CreateOrderSerializer
|
||||
return OrderDetailSerializer
|
||||
|
||||
def get_queryset(self):
|
||||
return (
|
||||
Order.objects
|
||||
.filter(customer=self.request.user)
|
||||
.select_related("product", "customer")
|
||||
.order_by("-created_at")
|
||||
)
|
||||
|
||||
def perform_create(self, serializer):
|
||||
order = create_order(
|
||||
customer=self.request.user,
|
||||
product_id=serializer.validated_data["product_id"],
|
||||
quantity=serializer.validated_data["quantity"],
|
||||
)
|
||||
serializer.instance = order
|
||||
```
|
||||
|
||||
### Padrão de Teste (pytest + Factory Boy)
|
||||
|
||||
```python
|
||||
# apps/orders/tests/factories.py
|
||||
import factory
|
||||
from apps.accounts.tests.factories import UserFactory
|
||||
from apps.products.tests.factories import ProductFactory
|
||||
|
||||
class OrderFactory(factory.django.DjangoModelFactory):
|
||||
class Meta:
|
||||
model = "orders.Order"
|
||||
|
||||
customer = factory.SubFactory(UserFactory)
|
||||
product = factory.SubFactory(ProductFactory, stock=100)
|
||||
quantity = 1
|
||||
total = factory.LazyAttribute(lambda o: o.product.price * o.quantity)
|
||||
|
||||
# apps/orders/tests/test_views.py
|
||||
import pytest
|
||||
from rest_framework.test import APIClient
|
||||
|
||||
@pytest.mark.django_db
|
||||
class TestCreateOrder:
|
||||
def setup_method(self):
|
||||
self.client = APIClient()
|
||||
self.user = UserFactory()
|
||||
self.client.force_authenticate(self.user)
|
||||
|
||||
def test_create_order_success(self):
|
||||
product = ProductFactory(price=29_99, stock=10)
|
||||
response = self.client.post("/api/orders/", {
|
||||
"product_id": str(product.id),
|
||||
"quantity": 2,
|
||||
})
|
||||
assert response.status_code == 201
|
||||
assert response.data["total"] == 59_98
|
||||
|
||||
def test_create_order_insufficient_stock(self):
|
||||
product = ProductFactory(stock=0)
|
||||
response = self.client.post("/api/orders/", {
|
||||
"product_id": str(product.id),
|
||||
"quantity": 1,
|
||||
})
|
||||
assert response.status_code == 409
|
||||
|
||||
def test_create_order_unauthenticated(self):
|
||||
self.client.force_authenticate(None)
|
||||
response = self.client.post("/api/orders/", {})
|
||||
assert response.status_code == 401
|
||||
```
|
||||
|
||||
## Variáveis de Ambiente
|
||||
|
||||
```bash
|
||||
# Django
|
||||
SECRET_KEY=
|
||||
DEBUG=False
|
||||
ALLOWED_HOSTS=api.example.com
|
||||
|
||||
# Database
|
||||
DATABASE_URL=postgres://user:pass@localhost:5432/myapp
|
||||
|
||||
# Redis (Celery broker + cache)
|
||||
REDIS_URL=redis://localhost:6379/0
|
||||
|
||||
# JWT
|
||||
JWT_ACCESS_TOKEN_LIFETIME=15 # minutes
|
||||
JWT_REFRESH_TOKEN_LIFETIME=10080 # minutes (7 days)
|
||||
|
||||
# Email
|
||||
EMAIL_BACKEND=django.core.mail.backends.smtp.EmailBackend
|
||||
EMAIL_HOST=smtp.example.com
|
||||
```
|
||||
|
||||
## Estratégia de Teste
|
||||
|
||||
```bash
|
||||
# Run all tests
|
||||
pytest --cov=apps --cov-report=term-missing
|
||||
|
||||
# Run specific app tests
|
||||
pytest apps/orders/tests/ -v
|
||||
|
||||
# Run with parallel execution
|
||||
pytest -n auto
|
||||
|
||||
# Only failing tests from last run
|
||||
pytest --lf
|
||||
```
|
||||
|
||||
## Workflow ECC
|
||||
|
||||
```bash
|
||||
# Planning
|
||||
/plan "Add order refund system with Stripe integration"
|
||||
|
||||
# Development with TDD
|
||||
/tdd # pytest-based TDD workflow
|
||||
|
||||
# Review
|
||||
/python-review # Python-specific code review
|
||||
/security-scan # Django security audit
|
||||
/code-review # General quality check
|
||||
|
||||
# Verification
|
||||
/verify # Build, lint, test, security scan
|
||||
```
|
||||
|
||||
## Fluxo Git
|
||||
|
||||
- `feat:` novas features, `fix:` correções de bug, `refactor:` mudanças de código
|
||||
- Branches de feature a partir da `main`, PRs obrigatórios
|
||||
- CI: ruff (lint + format), mypy (types), pytest (tests), safety (dep check)
|
||||
- Deploy: imagem Docker, gerenciada via Kubernetes ou Railway
|
||||
267
docs/pt-BR/examples/go-microservice-CLAUDE.md
Normal file
@@ -0,0 +1,267 @@
|
||||
# Go Microservice — CLAUDE.md de Projeto
|
||||
|
||||
> Exemplo real para um microserviço Go com PostgreSQL, gRPC e Docker.
|
||||
> Copie para a raiz do seu projeto e customize para seu serviço.
|
||||
|
||||
## Visão Geral do Projeto
|
||||
|
||||
**Stack:** Go 1.22+, PostgreSQL, gRPC + REST (grpc-gateway), Docker, sqlc (SQL type-safe), Wire (injeção de dependência)
|
||||
|
||||
**Arquitetura:** Clean architecture com camadas domain, repository, service e handler. gRPC como transporte principal com gateway REST para clientes externos.
|
||||
|
||||
## Regras Críticas
|
||||
|
||||
### Convenções Go
|
||||
|
||||
- Siga Effective Go e o guia Go Code Review Comments
|
||||
- Use `errors.New` / `fmt.Errorf` com `%w` para wrapping — nunca string matching em erros
|
||||
- Sem funções `init()` — inicialização explícita em `main()` ou construtores
|
||||
- Sem estado global mutável — passe dependências via construtores
|
||||
- Context deve ser o primeiro parâmetro e propagado por todas as camadas
|
||||
|
||||
### Banco de Dados
|
||||
|
||||
- Todas as queries em `queries/` como SQL puro — sqlc gera código Go type-safe
|
||||
- Migrations em `migrations/` com golang-migrate — nunca alterar banco diretamente
|
||||
- Use transações para operações multi-etapa via `pgx.Tx`
|
||||
- Todas as queries devem usar placeholders parametrizados (`$1`, `$2`) — nunca string formatting
|
||||
|
||||
### Tratamento de Erro
|
||||
|
||||
- Retorne erros, não use panic — panic só para casos realmente irrecuperáveis
|
||||
- Faça wrap de erros com contexto: `fmt.Errorf("creating user: %w", err)`
|
||||
- Defina sentinel errors em `domain/errors.go` para lógica de negócio
|
||||
- Mapeie erros de domínio para gRPC status codes na camada de handler
|
||||
|
||||
```go
|
||||
// Domain layer — sentinel errors
|
||||
var (
|
||||
ErrUserNotFound = errors.New("user not found")
|
||||
ErrEmailTaken = errors.New("email already registered")
|
||||
)
|
||||
|
||||
// Handler layer — map to gRPC status
|
||||
func toGRPCError(err error) error {
|
||||
switch {
|
||||
case errors.Is(err, domain.ErrUserNotFound):
|
||||
return status.Error(codes.NotFound, err.Error())
|
||||
case errors.Is(err, domain.ErrEmailTaken):
|
||||
return status.Error(codes.AlreadyExists, err.Error())
|
||||
default:
|
||||
return status.Error(codes.Internal, "internal error")
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Estilo de Código
|
||||
|
||||
- Sem emojis em código ou comentários
|
||||
- Tipos e funções exportados devem ter doc comments
|
||||
- Mantenha funções abaixo de 50 linhas — extraia helpers
|
||||
- Use table-driven tests para toda lógica com múltiplos casos
|
||||
- Prefira `struct{}` para canais de sinal, não `bool`
|
||||
|
||||
## Estrutura de Arquivos
|
||||
|
||||
```
|
||||
cmd/
|
||||
server/
|
||||
main.go # Entrypoint, Wire injection, graceful shutdown
|
||||
internal/
|
||||
domain/ # Business types and interfaces
|
||||
user.go # User entity and repository interface
|
||||
errors.go # Sentinel errors
|
||||
service/ # Business logic
|
||||
user_service.go
|
||||
user_service_test.go
|
||||
repository/ # Data access (sqlc-generated + custom)
|
||||
postgres/
|
||||
user_repo.go
|
||||
user_repo_test.go # Integration tests with testcontainers
|
||||
handler/ # gRPC + REST handlers
|
||||
grpc/
|
||||
user_handler.go
|
||||
rest/
|
||||
user_handler.go
|
||||
config/ # Configuration loading
|
||||
config.go
|
||||
proto/ # Protobuf definitions
|
||||
user/v1/
|
||||
user.proto
|
||||
queries/ # SQL queries for sqlc
|
||||
user.sql
|
||||
migrations/ # Database migrations
|
||||
001_create_users.up.sql
|
||||
001_create_users.down.sql
|
||||
```
|
||||
|
||||
## Padrões-Chave
|
||||
|
||||
### Interface de Repositório
|
||||
|
||||
```go
|
||||
type UserRepository interface {
|
||||
Create(ctx context.Context, user *User) error
|
||||
FindByID(ctx context.Context, id uuid.UUID) (*User, error)
|
||||
FindByEmail(ctx context.Context, email string) (*User, error)
|
||||
Update(ctx context.Context, user *User) error
|
||||
Delete(ctx context.Context, id uuid.UUID) error
|
||||
}
|
||||
```
|
||||
|
||||
### Serviço com Injeção de Dependência
|
||||
|
||||
```go
|
||||
type UserService struct {
|
||||
repo domain.UserRepository
|
||||
hasher PasswordHasher
|
||||
logger *slog.Logger
|
||||
}
|
||||
|
||||
func NewUserService(repo domain.UserRepository, hasher PasswordHasher, logger *slog.Logger) *UserService {
|
||||
return &UserService{repo: repo, hasher: hasher, logger: logger}
|
||||
}
|
||||
|
||||
func (s *UserService) Create(ctx context.Context, req CreateUserRequest) (*domain.User, error) {
|
||||
existing, err := s.repo.FindByEmail(ctx, req.Email)
|
||||
if err != nil && !errors.Is(err, domain.ErrUserNotFound) {
|
||||
return nil, fmt.Errorf("checking email: %w", err)
|
||||
}
|
||||
if existing != nil {
|
||||
return nil, domain.ErrEmailTaken
|
||||
}
|
||||
|
||||
hashed, err := s.hasher.Hash(req.Password)
|
||||
if err != nil {
|
||||
return nil, fmt.Errorf("hashing password: %w", err)
|
||||
}
|
||||
|
||||
user := &domain.User{
|
||||
ID: uuid.New(),
|
||||
Name: req.Name,
|
||||
Email: req.Email,
|
||||
Password: hashed,
|
||||
}
|
||||
if err := s.repo.Create(ctx, user); err != nil {
|
||||
return nil, fmt.Errorf("creating user: %w", err)
|
||||
}
|
||||
return user, nil
|
||||
}
|
||||
```
|
||||
|
||||
### Table-Driven Tests
|
||||
|
||||
```go
|
||||
func TestUserService_Create(t *testing.T) {
|
||||
tests := []struct {
|
||||
name string
|
||||
req CreateUserRequest
|
||||
setup func(*MockUserRepo)
|
||||
wantErr error
|
||||
}{
|
||||
{
|
||||
name: "valid user",
|
||||
req: CreateUserRequest{Name: "Alice", Email: "alice@example.com", Password: "secure123"},
|
||||
setup: func(m *MockUserRepo) {
|
||||
m.On("FindByEmail", mock.Anything, "alice@example.com").Return(nil, domain.ErrUserNotFound)
|
||||
m.On("Create", mock.Anything, mock.Anything).Return(nil)
|
||||
},
|
||||
wantErr: nil,
|
||||
},
|
||||
{
|
||||
name: "duplicate email",
|
||||
req: CreateUserRequest{Name: "Alice", Email: "taken@example.com", Password: "secure123"},
|
||||
setup: func(m *MockUserRepo) {
|
||||
m.On("FindByEmail", mock.Anything, "taken@example.com").Return(&domain.User{}, nil)
|
||||
},
|
||||
wantErr: domain.ErrEmailTaken,
|
||||
},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
repo := new(MockUserRepo)
|
||||
tt.setup(repo)
|
||||
svc := NewUserService(repo, &bcryptHasher{}, slog.Default())
|
||||
|
||||
_, err := svc.Create(context.Background(), tt.req)
|
||||
|
||||
if tt.wantErr != nil {
|
||||
assert.ErrorIs(t, err, tt.wantErr)
|
||||
} else {
|
||||
assert.NoError(t, err)
|
||||
}
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Variáveis de Ambiente
|
||||
|
||||
```bash
|
||||
# Database
|
||||
DATABASE_URL=postgres://user:pass@localhost:5432/myservice?sslmode=disable
|
||||
|
||||
# gRPC
|
||||
GRPC_PORT=50051
|
||||
REST_PORT=8080
|
||||
|
||||
# Auth
|
||||
JWT_SECRET= # Load from vault in production
|
||||
TOKEN_EXPIRY=24h
|
||||
|
||||
# Observability
|
||||
LOG_LEVEL=info # debug, info, warn, error
|
||||
OTEL_ENDPOINT= # OpenTelemetry collector
|
||||
```
|
||||
|
||||
## Estratégia de Teste
|
||||
|
||||
```bash
|
||||
/go-test # TDD workflow for Go
|
||||
/go-review # Go-specific code review
|
||||
/go-build # Fix build errors
|
||||
```
|
||||
|
||||
### Comandos de Teste
|
||||
|
||||
```bash
|
||||
# Unit tests (fast, no external deps)
|
||||
go test ./internal/... -short -count=1
|
||||
|
||||
# Integration tests (requires Docker for testcontainers)
|
||||
go test ./internal/repository/... -count=1 -timeout 120s
|
||||
|
||||
# All tests with coverage
|
||||
go test ./... -coverprofile=coverage.out -count=1
|
||||
go tool cover -func=coverage.out # summary
|
||||
go tool cover -html=coverage.out # browser
|
||||
|
||||
# Race detector
|
||||
go test ./... -race -count=1
|
||||
```
|
||||
|
||||
## Workflow ECC
|
||||
|
||||
```bash
|
||||
# Planning
|
||||
/plan "Add rate limiting to user endpoints"
|
||||
|
||||
# Development
|
||||
/go-test # TDD with Go-specific patterns
|
||||
|
||||
# Review
|
||||
/go-review # Go idioms, error handling, concurrency
|
||||
/security-scan # Secrets and vulnerabilities
|
||||
|
||||
# Before merge
|
||||
go vet ./...
|
||||
staticcheck ./...
|
||||
```
|
||||
|
||||
## Fluxo Git
|
||||
|
||||
- `feat:` novas features, `fix:` correções de bug, `refactor:` mudanças de código
|
||||
- Branches de feature a partir da `main`, PRs obrigatórios
|
||||
- CI: `go vet`, `staticcheck`, `go test -race`, `golangci-lint`
|
||||
- Deploy: imagem Docker gerada no CI e publicada em Kubernetes
|
||||
285
docs/pt-BR/examples/rust-api-CLAUDE.md
Normal file
@@ -0,0 +1,285 @@
|
||||
# Serviço de API Rust — CLAUDE.md de Projeto
|
||||
|
||||
> Exemplo real para um serviço de API Rust com Axum, PostgreSQL e Docker.
|
||||
> Copie para a raiz do seu projeto e customize para seu serviço.
|
||||
|
||||
## Visão Geral do Projeto
|
||||
|
||||
**Stack:** Rust 1.78+, Axum (web framework), SQLx (banco assíncrono), PostgreSQL, Tokio (runtime assíncrono), Docker
|
||||
|
||||
**Arquitetura:** Arquitetura em camadas com separação handler → service → repository. Axum para HTTP, SQLx para SQL verificado em tempo de compilação, middleware Tower para preocupações transversais.
|
||||
|
||||
## Regras Críticas
|
||||
|
||||
### Convenções Rust
|
||||
|
||||
- Use `thiserror` para erros de library, `anyhow` apenas em crates binários ou testes
|
||||
- Sem `.unwrap()` ou `.expect()` em código de produção — propague erros com `?`
|
||||
- Prefira `&str` a `String` em parâmetros de função; retorne `String` quando houver transferência de ownership
|
||||
- Use `clippy` com `#![deny(clippy::all, clippy::pedantic)]` — corrija todos os warnings
|
||||
- Derive `Debug` em todos os tipos públicos; derive `Clone`, `PartialEq` só quando necessário
|
||||
- Sem blocos `unsafe` sem justificativa com comentário `// SAFETY:`
|
||||
|
||||
### Banco de Dados
|
||||
|
||||
- Todas as queries usam macros SQLx `query!` ou `query_as!` — verificadas em compile time contra o schema
|
||||
- Migrations em `migrations/` com `sqlx migrate` — nunca alterar banco diretamente
|
||||
- Use `sqlx::Pool<Postgres>` como estado compartilhado — nunca criar conexão por requisição
|
||||
- Todas as queries usam placeholders parametrizados (`$1`, `$2`) — nunca string formatting
|
||||
|
||||
```rust
|
||||
// BAD: String interpolation (SQL injection risk)
|
||||
let q = format!("SELECT * FROM users WHERE id = '{}'", id);
|
||||
|
||||
// GOOD: Parameterized query, compile-time checked
|
||||
let user = sqlx::query_as!(User, "SELECT * FROM users WHERE id = $1", id)
|
||||
.fetch_optional(&pool)
|
||||
.await?;
|
||||
```
|
||||
|
||||
### Tratamento de Erro
|
||||
|
||||
- Defina enum de erro de domínio por módulo com `thiserror`
|
||||
- Mapeie erros para respostas HTTP via `IntoResponse` — nunca exponha detalhes internos
|
||||
- Use `tracing` para logs estruturados — nunca `println!` ou `eprintln!`
|
||||
|
||||
```rust
|
||||
use thiserror::Error;
|
||||
|
||||
#[derive(Debug, Error)]
|
||||
pub enum AppError {
|
||||
#[error("Resource not found")]
|
||||
NotFound,
|
||||
#[error("Validation failed: {0}")]
|
||||
Validation(String),
|
||||
#[error("Unauthorized")]
|
||||
Unauthorized,
|
||||
#[error(transparent)]
|
||||
Internal(#[from] anyhow::Error),
|
||||
}
|
||||
|
||||
impl IntoResponse for AppError {
|
||||
fn into_response(self) -> Response {
|
||||
let (status, message) = match &self {
|
||||
Self::NotFound => (StatusCode::NOT_FOUND, self.to_string()),
|
||||
Self::Validation(msg) => (StatusCode::BAD_REQUEST, msg.clone()),
|
||||
Self::Unauthorized => (StatusCode::UNAUTHORIZED, self.to_string()),
|
||||
Self::Internal(err) => {
|
||||
tracing::error!(?err, "internal error");
|
||||
(StatusCode::INTERNAL_SERVER_ERROR, "Internal error".into())
|
||||
}
|
||||
};
|
||||
(status, Json(json!({ "error": message }))).into_response()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Testes
|
||||
|
||||
- Testes unitários em módulos `#[cfg(test)]` dentro de cada arquivo fonte
|
||||
- Testes de integração no diretório `tests/` usando PostgreSQL real (Testcontainers ou Docker)
|
||||
- Use `#[sqlx::test]` para testes de banco com migration e rollback automáticos
|
||||
- Faça mock de serviços externos com `mockall` ou `wiremock`
|
||||
|
||||
### Estilo de Código
|
||||
|
||||
- Tamanho máximo de linha: 100 caracteres (enforced by rustfmt)
|
||||
- Agrupe imports: `std`, crates externas, `crate`/`super` — separados por linha em branco
|
||||
- Módulos: um arquivo por módulo, `mod.rs` só para re-exports
|
||||
- Tipos: PascalCase, funções/variáveis: snake_case, constantes: UPPER_SNAKE_CASE
|
||||
|
||||
## Estrutura de Arquivos
|
||||
|
||||
```
|
||||
src/
|
||||
main.rs # Entrypoint, server setup, graceful shutdown
|
||||
lib.rs # Re-exports for integration tests
|
||||
config.rs # Environment config with envy or figment
|
||||
router.rs # Axum router with all routes
|
||||
middleware/
|
||||
auth.rs # JWT extraction and validation
|
||||
logging.rs # Request/response tracing
|
||||
handlers/
|
||||
mod.rs # Route handlers (thin — delegate to services)
|
||||
users.rs
|
||||
orders.rs
|
||||
services/
|
||||
mod.rs # Business logic
|
||||
users.rs
|
||||
orders.rs
|
||||
repositories/
|
||||
mod.rs # Database access (SQLx queries)
|
||||
users.rs
|
||||
orders.rs
|
||||
domain/
|
||||
mod.rs # Domain types, error enums
|
||||
user.rs
|
||||
order.rs
|
||||
migrations/
|
||||
001_create_users.sql
|
||||
002_create_orders.sql
|
||||
tests/
|
||||
common/mod.rs # Shared test helpers, test server setup
|
||||
api_users.rs # Integration tests for user endpoints
|
||||
api_orders.rs # Integration tests for order endpoints
|
||||
```
|
||||
|
||||
## Padrões-Chave
|
||||
|
||||
### Handler (Enxuto)
|
||||
|
||||
```rust
|
||||
async fn create_user(
|
||||
State(ctx): State<AppState>,
|
||||
Json(payload): Json<CreateUserRequest>,
|
||||
) -> Result<(StatusCode, Json<UserResponse>), AppError> {
|
||||
let user = ctx.user_service.create(payload).await?;
|
||||
Ok((StatusCode::CREATED, Json(UserResponse::from(user))))
|
||||
}
|
||||
```
|
||||
|
||||
### Service (Lógica de Negócio)
|
||||
|
||||
```rust
|
||||
impl UserService {
|
||||
pub async fn create(&self, req: CreateUserRequest) -> Result<User, AppError> {
|
||||
if self.repo.find_by_email(&req.email).await?.is_some() {
|
||||
return Err(AppError::Validation("Email already registered".into()));
|
||||
}
|
||||
|
||||
let password_hash = hash_password(&req.password)?;
|
||||
let user = self.repo.insert(&req.email, &req.name, &password_hash).await?;
|
||||
|
||||
Ok(user)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Repository (Acesso a Dados)
|
||||
|
||||
```rust
|
||||
impl UserRepository {
|
||||
pub async fn find_by_email(&self, email: &str) -> Result<Option<User>, sqlx::Error> {
|
||||
sqlx::query_as!(User, "SELECT * FROM users WHERE email = $1", email)
|
||||
.fetch_optional(&self.pool)
|
||||
.await
|
||||
}
|
||||
|
||||
pub async fn insert(
|
||||
&self,
|
||||
email: &str,
|
||||
name: &str,
|
||||
password_hash: &str,
|
||||
) -> Result<User, sqlx::Error> {
|
||||
sqlx::query_as!(
|
||||
User,
|
||||
r#"INSERT INTO users (email, name, password_hash)
|
||||
VALUES ($1, $2, $3) RETURNING *"#,
|
||||
email, name, password_hash,
|
||||
)
|
||||
.fetch_one(&self.pool)
|
||||
.await
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Teste de Integração
|
||||
|
||||
```rust
|
||||
#[tokio::test]
|
||||
async fn test_create_user() {
|
||||
let app = spawn_test_app().await;
|
||||
|
||||
let response = app
|
||||
.client
|
||||
.post(&format!("{}/api/v1/users", app.address))
|
||||
.json(&json!({
|
||||
"email": "alice@example.com",
|
||||
"name": "Alice",
|
||||
"password": "securepassword123"
|
||||
}))
|
||||
.send()
|
||||
.await
|
||||
.expect("Failed to send request");
|
||||
|
||||
assert_eq!(response.status(), StatusCode::CREATED);
|
||||
let body: serde_json::Value = response.json().await.unwrap();
|
||||
assert_eq!(body["email"], "alice@example.com");
|
||||
}
|
||||
|
||||
#[tokio::test]
|
||||
async fn test_create_user_duplicate_email() {
|
||||
let app = spawn_test_app().await;
|
||||
// Create first user
|
||||
create_test_user(&app, "alice@example.com").await;
|
||||
// Attempt duplicate
|
||||
let response = create_user_request(&app, "alice@example.com").await;
|
||||
assert_eq!(response.status(), StatusCode::BAD_REQUEST);
|
||||
}
|
||||
```
|
||||
|
||||
## Variáveis de Ambiente
|
||||
|
||||
```bash
|
||||
# Server
|
||||
HOST=0.0.0.0
|
||||
PORT=8080
|
||||
RUST_LOG=info,tower_http=debug
|
||||
|
||||
# Database
|
||||
DATABASE_URL=postgres://user:pass@localhost:5432/myapp
|
||||
|
||||
# Auth
|
||||
JWT_SECRET=your-secret-key-min-32-chars
|
||||
JWT_EXPIRY_HOURS=24
|
||||
|
||||
# Optional
|
||||
CORS_ALLOWED_ORIGINS=http://localhost:3000
|
||||
```
|
||||
|
||||
## Estratégia de Teste
|
||||
|
||||
```bash
|
||||
# Run all tests
|
||||
cargo test
|
||||
|
||||
# Run with output
|
||||
cargo test -- --nocapture
|
||||
|
||||
# Run specific test module
|
||||
cargo test api_users
|
||||
|
||||
# Check coverage (requires cargo-llvm-cov)
|
||||
cargo llvm-cov --html
|
||||
open target/llvm-cov/html/index.html
|
||||
|
||||
# Lint
|
||||
cargo clippy -- -D warnings
|
||||
|
||||
# Format check
|
||||
cargo fmt -- --check
|
||||
```
|
||||
|
||||
## Workflow ECC
|
||||
|
||||
```bash
|
||||
# Planning
|
||||
/plan "Add order fulfillment with Stripe payment"
|
||||
|
||||
# Development with TDD
|
||||
/tdd # cargo test-based TDD workflow
|
||||
|
||||
# Review
|
||||
/code-review # Rust-specific code review
|
||||
/security-scan # Dependency audit + unsafe scan
|
||||
|
||||
# Verification
|
||||
/verify # Build, clippy, test, security scan
|
||||
```
|
||||
|
||||
## Fluxo Git
|
||||
|
||||
- `feat:` novas features, `fix:` correções de bug, `refactor:` mudanças de código
|
||||
- Branches de feature a partir da `main`, PRs obrigatórios
|
||||
- CI: `cargo fmt --check`, `cargo clippy`, `cargo test`, `cargo audit`
|
||||
- Deploy: Docker multi-stage build com base `scratch` ou `distroless`
|
||||
166
docs/pt-BR/examples/saas-nextjs-CLAUDE.md
Normal file
@@ -0,0 +1,166 @@
|
||||
# Aplicação SaaS — CLAUDE.md de Projeto
|
||||
|
||||
> Exemplo real para uma aplicação SaaS com Next.js + Supabase + Stripe.
|
||||
> Copie para a raiz do seu projeto e customize para sua stack.
|
||||
|
||||
## Visão Geral do Projeto
|
||||
|
||||
**Stack:** Next.js 15 (App Router), TypeScript, Supabase (auth + DB), Stripe (billing), Tailwind CSS, Playwright (E2E)
|
||||
|
||||
**Arquitetura:** Server Components por padrão. Client Components apenas para interatividade. API routes para webhooks e server actions para mutações.
|
||||
|
||||
## Regras Críticas
|
||||
|
||||
### Banco de Dados
|
||||
|
||||
- Todas as queries usam cliente Supabase com RLS habilitado — nunca bypass de RLS
|
||||
- Migrations em `supabase/migrations/` — nunca modificar banco diretamente
|
||||
- Use `select()` com lista explícita de colunas, não `select('*')`
|
||||
- Todas as queries user-facing devem incluir `.limit()` para evitar resultados sem limite
|
||||
|
||||
### Autenticação
|
||||
|
||||
- Use `createServerClient()` de `@supabase/ssr` em Server Components
|
||||
- Use `createBrowserClient()` de `@supabase/ssr` em Client Components
|
||||
- Rotas protegidas checam `getUser()` — nunca confiar só em `getSession()` para auth
|
||||
- Middleware em `middleware.ts` renova tokens de auth em toda requisição
|
||||
|
||||
### Billing
|
||||
|
||||
- Handler de webhook Stripe em `app/api/webhooks/stripe/route.ts`
|
||||
- Nunca confiar em preço do cliente — sempre buscar do Stripe server-side
|
||||
- Status da assinatura checado via coluna `subscription_status`, sincronizada por webhook
|
||||
- Usuários free tier: 3 projetos, 100 chamadas de API/dia
|
||||
|
||||
### Estilo de Código
|
||||
|
||||
- Sem emojis em código ou comentários
|
||||
- Apenas padrões imutáveis — spread operator, nunca mutar
|
||||
- Server Components: sem diretiva `'use client'`, sem `useState`/`useEffect`
|
||||
- Client Components: `'use client'` no topo, mínimo possível — extraia lógica para hooks
|
||||
- Prefira schemas Zod para toda validação de entrada (API routes, formulários, env vars)
|
||||
|
||||
## Estrutura de Arquivos
|
||||
|
||||
```
|
||||
src/
|
||||
app/
|
||||
(auth)/ # Auth pages (login, signup, forgot-password)
|
||||
(dashboard)/ # Protected dashboard pages
|
||||
api/
|
||||
webhooks/ # Stripe, Supabase webhooks
|
||||
layout.tsx # Root layout with providers
|
||||
components/
|
||||
ui/ # Shadcn/ui components
|
||||
forms/ # Form components with validation
|
||||
dashboard/ # Dashboard-specific components
|
||||
hooks/ # Custom React hooks
|
||||
lib/
|
||||
supabase/ # Supabase client factories
|
||||
stripe/ # Stripe client and helpers
|
||||
utils.ts # General utilities
|
||||
types/ # Shared TypeScript types
|
||||
supabase/
|
||||
migrations/ # Database migrations
|
||||
seed.sql # Development seed data
|
||||
```
|
||||
|
||||
## Padrões-Chave
|
||||
|
||||
### Formato de Resposta de API
|
||||
|
||||
```typescript
|
||||
type ApiResponse<T> =
|
||||
| { success: true; data: T }
|
||||
| { success: false; error: string; code?: string }
|
||||
```
|
||||
|
||||
### Padrão de Server Action
|
||||
|
||||
```typescript
|
||||
'use server'
|
||||
|
||||
import { z } from 'zod'
|
||||
import { createServerClient } from '@/lib/supabase/server'
|
||||
|
||||
const schema = z.object({
|
||||
name: z.string().min(1).max(100),
|
||||
})
|
||||
|
||||
export async function createProject(formData: FormData) {
|
||||
const parsed = schema.safeParse({ name: formData.get('name') })
|
||||
if (!parsed.success) {
|
||||
return { success: false, error: parsed.error.flatten() }
|
||||
}
|
||||
|
||||
const supabase = await createServerClient()
|
||||
const { data: { user } } = await supabase.auth.getUser()
|
||||
if (!user) return { success: false, error: 'Unauthorized' }
|
||||
|
||||
const { data, error } = await supabase
|
||||
.from('projects')
|
||||
.insert({ name: parsed.data.name, user_id: user.id })
|
||||
.select('id, name, created_at')
|
||||
.single()
|
||||
|
||||
if (error) return { success: false, error: 'Failed to create project' }
|
||||
return { success: true, data }
|
||||
}
|
||||
```
|
||||
|
||||
## Variáveis de Ambiente
|
||||
|
||||
```bash
|
||||
# Supabase
|
||||
NEXT_PUBLIC_SUPABASE_URL=
|
||||
NEXT_PUBLIC_SUPABASE_ANON_KEY=
|
||||
SUPABASE_SERVICE_ROLE_KEY= # Server-only, never expose to client
|
||||
|
||||
# Stripe
|
||||
STRIPE_SECRET_KEY=
|
||||
STRIPE_WEBHOOK_SECRET=
|
||||
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=
|
||||
|
||||
# App
|
||||
NEXT_PUBLIC_APP_URL=http://localhost:3000
|
||||
```
|
||||
|
||||
## Estratégia de Teste
|
||||
|
||||
```bash
|
||||
/tdd # Unit + integration tests for new features
|
||||
/e2e # Playwright tests for auth flow, billing, dashboard
|
||||
/test-coverage # Verify 80%+ coverage
|
||||
```
|
||||
|
||||
### Fluxos E2E Críticos
|
||||
|
||||
1. Sign up → verificação de e-mail → criação do primeiro projeto
|
||||
2. Login → dashboard → operações CRUD
|
||||
3. Upgrade de plano → Stripe checkout → assinatura ativa
|
||||
4. Webhook: assinatura cancelada → downgrade para free tier
|
||||
|
||||
## Workflow ECC
|
||||
|
||||
```bash
|
||||
# Planning a feature
|
||||
/plan "Add team invitations with email notifications"
|
||||
|
||||
# Developing with TDD
|
||||
/tdd
|
||||
|
||||
# Before committing
|
||||
/code-review
|
||||
/security-scan
|
||||
|
||||
# Before release
|
||||
/e2e
|
||||
/test-coverage
|
||||
```
|
||||
|
||||
## Fluxo Git
|
||||
|
||||
- `feat:` novas features, `fix:` correções de bug, `refactor:` mudanças de código
|
||||
- Branches de feature a partir da `main`, PRs obrigatórios
|
||||
- CI roda: lint, type-check, unit tests, E2E tests
|
||||
- Deploy: preview da Vercel em PR, produção no merge para `main`
|
||||
109
docs/pt-BR/examples/user-CLAUDE.md
Normal file
@@ -0,0 +1,109 @@
|
||||
# Exemplo de CLAUDE.md no Nível de Usuário
|
||||
|
||||
Este é um exemplo de arquivo CLAUDE.md no nível de usuário. Coloque em `~/.claude/CLAUDE.md`.
|
||||
|
||||
Configurações de nível de usuário se aplicam globalmente em todos os projetos. Use para:
|
||||
- Preferências pessoais de código
|
||||
- Regras universais que você sempre quer aplicar
|
||||
- Links para suas regras modulares
|
||||
|
||||
---
|
||||
|
||||
## Filosofia Central
|
||||
|
||||
Você é Claude Code. Eu uso agentes e skills especializados para tarefas complexas.
|
||||
|
||||
**Princípios-Chave:**
|
||||
1. **Agent-First**: Delegue trabalho complexo para agentes especializados
|
||||
2. **Execução Paralela**: Use ferramenta Task com múltiplos agentes quando possível
|
||||
3. **Planejar Antes de Executar**: Use Plan Mode para operações complexas
|
||||
4. **Test-Driven**: Escreva testes antes da implementação
|
||||
5. **Security-First**: Nunca comprometa segurança
|
||||
|
||||
---
|
||||
|
||||
## Regras Modulares
|
||||
|
||||
Diretrizes detalhadas em `~/.claude/rules/`:
|
||||
|
||||
| Rule File | Contents |
|
||||
|-----------|----------|
|
||||
| security.md | Security checks, secret management |
|
||||
| coding-style.md | Immutability, file organization, error handling |
|
||||
| testing.md | TDD workflow, 80% coverage requirement |
|
||||
| git-workflow.md | Commit format, PR workflow |
|
||||
| agents.md | Agent orchestration, when to use which agent |
|
||||
| patterns.md | API response, repository patterns |
|
||||
| performance.md | Model selection, context management |
|
||||
| hooks.md | Hooks System |
|
||||
|
||||
---
|
||||
|
||||
## Agentes Disponíveis
|
||||
|
||||
Localizados em `~/.claude/agents/`:
|
||||
|
||||
| Agent | Purpose |
|
||||
|-------|---------|
|
||||
| planner | Feature implementation planning |
|
||||
| architect | System design and architecture |
|
||||
| tdd-guide | Test-driven development |
|
||||
| code-reviewer | Code review for quality/security |
|
||||
| security-reviewer | Security vulnerability analysis |
|
||||
| build-error-resolver | Build error resolution |
|
||||
| e2e-runner | Playwright E2E testing |
|
||||
| refactor-cleaner | Dead code cleanup |
|
||||
| doc-updater | Documentation updates |
|
||||
|
||||
---
|
||||
|
||||
## Preferências Pessoais
|
||||
|
||||
### Privacidade
|
||||
- Sempre anonimizar logs; nunca colar segredos (API keys/tokens/passwords/JWTs)
|
||||
- Revise a saída antes de compartilhar - remova qualquer dado sensível
|
||||
|
||||
### Estilo de Código
|
||||
- Sem emojis em código, comentários ou documentação
|
||||
- Prefira imutabilidade - nunca mutar objetos ou arrays
|
||||
- Muitos arquivos pequenos em vez de poucos arquivos grandes
|
||||
- 200-400 linhas típico, 800 máximo por arquivo
|
||||
|
||||
### Git
|
||||
- Conventional commits: `feat:`, `fix:`, `refactor:`, `docs:`, `test:`
|
||||
- Sempre testar localmente antes de commitar
|
||||
- Commits pequenos e focados
|
||||
|
||||
### Testes
|
||||
- TDD: escreva testes primeiro
|
||||
- Cobertura mínima de 80%
|
||||
- Unit + integration + E2E para fluxos críticos
|
||||
|
||||
### Captura de Conhecimento
|
||||
- Notas pessoais de debug, preferências e contexto temporário → auto memory
|
||||
- Conhecimento de time/projeto (decisões de arquitetura, mudanças de API, runbooks de implementação) → seguir estrutura de docs já existente no projeto
|
||||
- Se a tarefa atual já produzir docs/comentários/exemplos relevantes, não duplique o mesmo conhecimento em outro lugar
|
||||
- Se não houver local óbvio de docs no projeto, pergunte antes de criar um novo doc de topo
|
||||
|
||||
---
|
||||
|
||||
## Integração com Editor
|
||||
|
||||
Eu uso Zed como editor principal:
|
||||
- Agent Panel para rastreamento de arquivos
|
||||
- CMD+Shift+R para command palette
|
||||
- Vim mode habilitado
|
||||
|
||||
---
|
||||
|
||||
## Métricas de Sucesso
|
||||
|
||||
Você tem sucesso quando:
|
||||
- Todos os testes passam (80%+ de cobertura)
|
||||
- Não há vulnerabilidades de segurança
|
||||
- O código é legível e manutenível
|
||||
- Os requisitos do usuário são atendidos
|
||||
|
||||
---
|
||||
|
||||
**Filosofia**: Design agent-first, execução paralela, planejar antes de agir, testar antes de codar, segurança sempre.
|
||||
50
docs/pt-BR/rules/agents.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# Orquestração de Agentes
|
||||
|
||||
## Agentes Disponíveis
|
||||
|
||||
Localizados em `~/.claude/agents/`:
|
||||
|
||||
| Agente | Propósito | Quando Usar |
|
||||
|--------|-----------|-------------|
|
||||
| planner | Planejamento de implementação | Recursos complexos, refatoração |
|
||||
| architect | Design de sistema | Decisões arquiteturais |
|
||||
| tdd-guide | Desenvolvimento orientado a testes | Novos recursos, correção de bugs |
|
||||
| code-reviewer | Revisão de código | Após escrever código |
|
||||
| security-reviewer | Análise de segurança | Antes de commits |
|
||||
| build-error-resolver | Corrigir erros de build | Quando o build falha |
|
||||
| e2e-runner | Testes E2E | Fluxos críticos do usuário |
|
||||
| refactor-cleaner | Limpeza de código morto | Manutenção de código |
|
||||
| doc-updater | Documentação | Atualização de docs |
|
||||
| rust-reviewer | Revisão de código Rust | Projetos Rust |
|
||||
|
||||
## Uso Imediato de Agentes
|
||||
|
||||
Sem necessidade de prompt do usuário:
|
||||
1. Solicitações de recursos complexos - Use o agente **planner**
|
||||
2. Código acabado de escrever/modificar - Use o agente **code-reviewer**
|
||||
3. Correção de bug ou novo recurso - Use o agente **tdd-guide**
|
||||
4. Decisão arquitetural - Use o agente **architect**
|
||||
|
||||
## Execução Paralela de Tarefas
|
||||
|
||||
SEMPRE use execução paralela de Task para operações independentes:
|
||||
|
||||
```markdown
|
||||
# BOM: Execução paralela
|
||||
Iniciar 3 agentes em paralelo:
|
||||
1. Agente 1: Análise de segurança do módulo de autenticação
|
||||
2. Agente 2: Revisão de desempenho do sistema de cache
|
||||
3. Agente 3: Verificação de tipos dos utilitários
|
||||
|
||||
# RUIM: Sequencial quando desnecessário
|
||||
Primeiro agente 1, depois agente 2, depois agente 3
|
||||
```
|
||||
|
||||
## Análise Multi-Perspectiva
|
||||
|
||||
Para problemas complexos, use subagentes com papéis divididos:
|
||||
- Revisor factual
|
||||
- Engenheiro sênior
|
||||
- Especialista em segurança
|
||||
- Revisor de consistência
|
||||
- Verificador de redundância
|
||||
48
docs/pt-BR/rules/coding-style.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# Estilo de Código
|
||||
|
||||
## Imutabilidade (CRÍTICO)
|
||||
|
||||
SEMPRE crie novos objetos, NUNCA modifique os existentes:
|
||||
|
||||
```
|
||||
// Pseudocódigo
|
||||
ERRADO: modificar(original, campo, valor) → altera o original in-place
|
||||
CORRETO: atualizar(original, campo, valor) → retorna nova cópia com a alteração
|
||||
```
|
||||
|
||||
Justificativa: Dados imutáveis previnem efeitos colaterais ocultos, facilita a depuração e permite concorrência segura.
|
||||
|
||||
## Organização de Arquivos
|
||||
|
||||
MUITOS ARQUIVOS PEQUENOS > POUCOS ARQUIVOS GRANDES:
|
||||
- Alta coesão, baixo acoplamento
|
||||
- 200-400 linhas típico, 800 máximo
|
||||
- Extrair utilitários de módulos grandes
|
||||
- Organizar por recurso/domínio, não por tipo
|
||||
|
||||
## Tratamento de Erros
|
||||
|
||||
SEMPRE trate erros de forma abrangente:
|
||||
- Trate erros explicitamente em cada nível
|
||||
- Forneça mensagens de erro amigáveis no código voltado para UI
|
||||
- Registre contexto detalhado de erro no lado do servidor
|
||||
- Nunca engula erros silenciosamente
|
||||
|
||||
## Validação de Entrada
|
||||
|
||||
SEMPRE valide nas fronteiras do sistema:
|
||||
- Valide toda entrada do usuário antes de processar
|
||||
- Use validação baseada em schema onde disponível
|
||||
- Falhe rapidamente com mensagens de erro claras
|
||||
- Nunca confie em dados externos (respostas de API, entrada do usuário, conteúdo de arquivo)
|
||||
|
||||
## Checklist de Qualidade de Código
|
||||
|
||||
Antes de marcar o trabalho como concluído:
|
||||
- [ ] O código é legível e bem nomeado
|
||||
- [ ] Funções são pequenas (< 50 linhas)
|
||||
- [ ] Arquivos são focados (< 800 linhas)
|
||||
- [ ] Sem aninhamento profundo (> 4 níveis)
|
||||
- [ ] Tratamento adequado de erros
|
||||
- [ ] Sem valores hardcoded (use constantes ou config)
|
||||
- [ ] Sem mutação (padrões imutáveis usados)
|
||||
24
docs/pt-BR/rules/git-workflow.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Fluxo de Trabalho Git
|
||||
|
||||
## Formato de Mensagem de Commit
|
||||
```
|
||||
<tipo>: <descrição>
|
||||
|
||||
<corpo opcional>
|
||||
```
|
||||
|
||||
Tipos: feat, fix, refactor, docs, test, chore, perf, ci
|
||||
|
||||
Nota: Atribuição desabilitada globalmente via ~/.claude/settings.json.
|
||||
|
||||
## Fluxo de Trabalho de Pull Request
|
||||
|
||||
Ao criar PRs:
|
||||
1. Analisar o histórico completo de commits (não apenas o último commit)
|
||||
2. Usar `git diff [branch-base]...HEAD` para ver todas as alterações
|
||||
3. Rascunhar resumo abrangente do PR
|
||||
4. Incluir plano de teste com TODOs
|
||||
5. Fazer push com a flag `-u` se for uma nova branch
|
||||
|
||||
> Para o processo de desenvolvimento completo (planejamento, TDD, revisão de código) antes de operações git,
|
||||
> veja [development-workflow.md](./development-workflow.md).
|
||||
30
docs/pt-BR/rules/hooks.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Sistema de Hooks
|
||||
|
||||
## Tipos de Hook
|
||||
|
||||
- **PreToolUse**: Antes da execução da ferramenta (validação, modificação de parâmetros)
|
||||
- **PostToolUse**: Após a execução da ferramenta (auto-formatação, verificações)
|
||||
- **Stop**: Quando a sessão termina (verificação final)
|
||||
|
||||
## Permissões de Auto-Aceite
|
||||
|
||||
Use com cautela:
|
||||
- Habilite para planos confiáveis e bem definidos
|
||||
- Desabilite para trabalho exploratório
|
||||
- Nunca use a flag dangerously-skip-permissions
|
||||
- Configure `allowedTools` em `~/.claude.json` em vez disso
|
||||
|
||||
## Melhores Práticas para TodoWrite
|
||||
|
||||
Use a ferramenta TodoWrite para:
|
||||
- Rastrear progresso em tarefas com múltiplos passos
|
||||
- Verificar compreensão das instruções
|
||||
- Habilitar direcionamento em tempo real
|
||||
- Mostrar etapas de implementação granulares
|
||||
|
||||
A lista de tarefas revela:
|
||||
- Etapas fora de ordem
|
||||
- Itens faltando
|
||||
- Itens extras desnecessários
|
||||
- Granularidade incorreta
|
||||
- Requisitos mal interpretados
|
||||
31
docs/pt-BR/rules/patterns.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Padrões Comuns
|
||||
|
||||
## Projetos Skeleton
|
||||
|
||||
Ao implementar novas funcionalidades:
|
||||
1. Buscar projetos skeleton bem testados
|
||||
2. Usar agentes paralelos para avaliar opções:
|
||||
- Avaliação de segurança
|
||||
- Análise de extensibilidade
|
||||
- Pontuação de relevância
|
||||
- Planejamento de implementação
|
||||
3. Clonar a melhor opção como fundação
|
||||
4. Iterar dentro da estrutura comprovada
|
||||
|
||||
## Padrões de Design
|
||||
|
||||
### Padrão Repository
|
||||
|
||||
Encapsular acesso a dados atrás de uma interface consistente:
|
||||
- Definir operações padrão: findAll, findById, create, update, delete
|
||||
- Implementações concretas lidam com detalhes de armazenamento (banco de dados, API, arquivo, etc.)
|
||||
- A lógica de negócios depende da interface abstrata, não do mecanismo de armazenamento
|
||||
- Habilita troca fácil de fontes de dados e simplifica testes com mocks
|
||||
|
||||
### Formato de Resposta da API
|
||||
|
||||
Use um envelope consistente para todas as respostas de API:
|
||||
- Incluir indicador de sucesso/status
|
||||
- Incluir o payload de dados (nullable em caso de erro)
|
||||
- Incluir campo de mensagem de erro (nullable em caso de sucesso)
|
||||
- Incluir metadados para respostas paginadas (total, página, limite)
|
||||
55
docs/pt-BR/rules/performance.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# Otimização de Desempenho
|
||||
|
||||
## Estratégia de Seleção de Modelo
|
||||
|
||||
**Haiku 4.5** (90% da capacidade do Sonnet, 3x economia de custo):
|
||||
- Agentes leves com invocação frequente
|
||||
- Programação em par e geração de código
|
||||
- Agentes worker em sistemas multi-agente
|
||||
|
||||
**Sonnet 4.6** (Melhor modelo para codificação):
|
||||
- Trabalho principal de desenvolvimento
|
||||
- Orquestrando fluxos de trabalho multi-agente
|
||||
- Tarefas de codificação complexas
|
||||
|
||||
**Opus 4.5** (Raciocínio mais profundo):
|
||||
- Decisões arquiteturais complexas
|
||||
- Requisitos máximos de raciocínio
|
||||
- Pesquisa e análise
|
||||
|
||||
## Gerenciamento da Janela de Contexto
|
||||
|
||||
Evite os últimos 20% da janela de contexto para:
|
||||
- Refatoração em grande escala
|
||||
- Implementação de recursos abrangendo múltiplos arquivos
|
||||
- Depuração de interações complexas
|
||||
|
||||
Tarefas com menor sensibilidade ao contexto:
|
||||
- Edições de arquivo único
|
||||
- Criação de utilitários independentes
|
||||
- Atualizações de documentação
|
||||
- Correções de bugs simples
|
||||
|
||||
## Pensamento Estendido + Modo de Plano
|
||||
|
||||
O pensamento estendido está habilitado por padrão, reservando até 31.999 tokens para raciocínio interno.
|
||||
|
||||
Controle o pensamento estendido via:
|
||||
- **Toggle**: Option+T (macOS) / Alt+T (Windows/Linux)
|
||||
- **Config**: Defina `alwaysThinkingEnabled` em `~/.claude/settings.json`
|
||||
- **Limite de orçamento**: `export MAX_THINKING_TOKENS=10000`
|
||||
- **Modo verbose**: Ctrl+O para ver a saída de pensamento
|
||||
|
||||
Para tarefas complexas que requerem raciocínio profundo:
|
||||
1. Garantir que o pensamento estendido esteja habilitado (habilitado por padrão)
|
||||
2. Habilitar **Modo de Plano** para abordagem estruturada
|
||||
3. Usar múltiplas rodadas de crítica para análise minuciosa
|
||||
4. Usar subagentes com papéis divididos para perspectivas diversas
|
||||
|
||||
## Resolução de Problemas de Build
|
||||
|
||||
Se o build falhar:
|
||||
1. Use o agente **build-error-resolver**
|
||||
2. Analise mensagens de erro
|
||||
3. Corrija incrementalmente
|
||||
4. Verifique após cada correção
|
||||
29
docs/pt-BR/rules/security.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# Diretrizes de Segurança
|
||||
|
||||
## Verificações de Segurança Obrigatórias
|
||||
|
||||
Antes de QUALQUER commit:
|
||||
- [ ] Sem segredos hardcoded (chaves de API, senhas, tokens)
|
||||
- [ ] Todas as entradas do usuário validadas
|
||||
- [ ] Prevenção de injeção SQL (queries parametrizadas)
|
||||
- [ ] Prevenção de XSS (HTML sanitizado)
|
||||
- [ ] Proteção CSRF habilitada
|
||||
- [ ] Autenticação/autorização verificada
|
||||
- [ ] Rate limiting em todos os endpoints
|
||||
- [ ] Mensagens de erro não vazam dados sensíveis
|
||||
|
||||
## Gerenciamento de Segredos
|
||||
|
||||
- NUNCA hardcode segredos no código-fonte
|
||||
- SEMPRE use variáveis de ambiente ou um gerenciador de segredos
|
||||
- Valide que os segredos necessários estão presentes na inicialização
|
||||
- Rotacione quaisquer segredos que possam ter sido expostos
|
||||
|
||||
## Protocolo de Resposta a Segurança
|
||||
|
||||
Se um problema de segurança for encontrado:
|
||||
1. PARE imediatamente
|
||||
2. Use o agente **security-reviewer**
|
||||
3. Corrija problemas CRÍTICOS antes de continuar
|
||||
4. Rotacione quaisquer segredos expostos
|
||||
5. Revise toda a base de código por problemas similares
|
||||
29
docs/pt-BR/rules/testing.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# Requisitos de Teste
|
||||
|
||||
## Cobertura Mínima de Teste: 80%
|
||||
|
||||
Tipos de Teste (TODOS obrigatórios):
|
||||
1. **Testes Unitários** - Funções individuais, utilitários, componentes
|
||||
2. **Testes de Integração** - Endpoints de API, operações de banco de dados
|
||||
3. **Testes E2E** - Fluxos críticos do usuário (framework escolhido por linguagem)
|
||||
|
||||
## Desenvolvimento Orientado a Testes (TDD)
|
||||
|
||||
Fluxo de trabalho OBRIGATÓRIO:
|
||||
1. Escreva o teste primeiro (VERMELHO)
|
||||
2. Execute o teste - deve FALHAR
|
||||
3. Escreva a implementação mínima (VERDE)
|
||||
4. Execute o teste - deve PASSAR
|
||||
5. Refatore (MELHORE)
|
||||
6. Verifique cobertura (80%+)
|
||||
|
||||
## Resolução de Falhas de Teste
|
||||
|
||||
1. Use o agente **tdd-guide**
|
||||
2. Verifique o isolamento de teste
|
||||
3. Verifique se os mocks estão corretos
|
||||
4. Corrija a implementação, não os testes (a menos que os testes estejam errados)
|
||||
|
||||
## Suporte de Agentes
|
||||
|
||||
- **tdd-guide** - Use PROATIVAMENTE para novos recursos, aplica escrever-testes-primeiro
|
||||
160
docs/tr/AGENTS.md
Normal file
@@ -0,0 +1,160 @@
|
||||
# Everything Claude Code (ECC) — Agent Talimatları
|
||||
|
||||
Bu, yazılım geliştirme için 28 özel agent, 116 skill, 59 command ve otomatik hook iş akışları sağlayan **üretime hazır bir AI kodlama eklentisidir**.
|
||||
|
||||
**Sürüm:** 1.9.0
|
||||
|
||||
## Temel İlkeler
|
||||
|
||||
1. **Agent-Öncelikli** — Alan görevleri için özel agentlara delege edin
|
||||
2. **Test-Odaklı** — Uygulamadan önce testler yazın, %80+ kapsama gereklidir
|
||||
3. **Güvenlik-Öncelikli** — Güvenlikten asla taviz vermeyin; tüm girdileri doğrulayın
|
||||
4. **Değişmezlik** — Her zaman yeni nesneler oluşturun, mevcut olanları asla değiştirmeyin
|
||||
5. **Çalıştırmadan Önce Planlayın** — Karmaşık özellikleri kod yazmadan önce planlayın
|
||||
|
||||
## Mevcut Agentlar
|
||||
|
||||
| Agent | Amaç | Ne Zaman Kullanılır |
|
||||
|-------|---------|-------------|
|
||||
| planner | Uygulama planlaması | Karmaşık özellikler, yeniden düzenleme |
|
||||
| architect | Sistem tasarımı ve ölçeklenebilirlik | Mimari kararlar |
|
||||
| tdd-guide | Test-odaklı geliştirme | Yeni özellikler, hata düzeltmeleri |
|
||||
| code-reviewer | Kod kalitesi ve sürdürülebilirlik | Kod yazma/değiştirme sonrası |
|
||||
| security-reviewer | Güvenlik açığı tespiti | Commitlerden önce, hassas kod |
|
||||
| build-error-resolver | Build/tip hatalarını düzeltme | Build başarısız olduğunda |
|
||||
| e2e-runner | Uçtan uca Playwright testi | Kritik kullanıcı akışları |
|
||||
| refactor-cleaner | Ölü kod temizleme | Kod bakımı |
|
||||
| doc-updater | Dokümantasyon ve codemaps | Dokümanları güncelleme |
|
||||
| docs-lookup | Dokümantasyon ve API referans araştırması | Kütüphane/API dokümantasyon soruları |
|
||||
| cpp-reviewer | C++ kod incelemesi | C++ projeleri |
|
||||
| cpp-build-resolver | C++ build hataları | C++ build başarısızlıkları |
|
||||
| go-reviewer | Go kod incelemesi | Go projeleri |
|
||||
| go-build-resolver | Go build hataları | Go build başarısızlıkları |
|
||||
| kotlin-reviewer | Kotlin kod incelemesi | Kotlin/Android/KMP projeleri |
|
||||
| kotlin-build-resolver | Kotlin/Gradle build hataları | Kotlin build başarısızlıkları |
|
||||
| database-reviewer | PostgreSQL/Supabase uzmanı | Şema tasarımı, sorgu optimizasyonu |
|
||||
| python-reviewer | Python kod incelemesi | Python projeleri |
|
||||
| java-reviewer | Java ve Spring Boot kod incelemesi | Java/Spring Boot projeleri |
|
||||
| java-build-resolver | Java/Maven/Gradle build hataları | Java build başarısızlıkları |
|
||||
| chief-of-staff | İletişim önceliklendirme ve taslaklar | Çok kanallı email, Slack, LINE, Messenger |
|
||||
| loop-operator | Otonom döngü yürütme | Döngüleri güvenli çalıştırma, takılmaları izleme, müdahale |
|
||||
| harness-optimizer | Harness yapılandırma ayarlama | Güvenilirlik, maliyet, verimlilik |
|
||||
| rust-reviewer | Rust kod incelemesi | Rust projeleri |
|
||||
| rust-build-resolver | Rust build hataları | Rust build başarısızlıkları |
|
||||
| pytorch-build-resolver | PyTorch runtime/CUDA/eğitim hataları | PyTorch build/eğitim başarısızlıkları |
|
||||
| typescript-reviewer | TypeScript/JavaScript kod incelemesi | TypeScript/JavaScript projeleri |
|
||||
|
||||
## Agent Orkestrasyonu
|
||||
|
||||
Agentları kullanıcı istemi olmadan proaktif olarak kullanın:
|
||||
- Karmaşık özellik istekleri → **planner**
|
||||
- Yeni yazılan/değiştirilen kod → **code-reviewer**
|
||||
- Hata düzeltme veya yeni özellik → **tdd-guide**
|
||||
- Mimari karar → **architect**
|
||||
- Güvenlik açısından hassas kod → **security-reviewer**
|
||||
- Çok kanallı iletişim önceliklendirme → **chief-of-staff**
|
||||
- Otonom döngüler / döngü izleme → **loop-operator**
|
||||
- Harness yapılandırma güvenilirliği ve maliyeti → **harness-optimizer**
|
||||
|
||||
Bağımsız işlemler için paralel yürütme kullanın — birden fazla agenti aynı anda başlatın.
|
||||
|
||||
## Güvenlik Kuralları
|
||||
|
||||
**HERHANGİ BİR committen önce:**
|
||||
- Sabit kodlanmış sırlar yok (API anahtarları, şifreler, tokenlar)
|
||||
- Tüm kullanıcı girdileri doğrulanmış
|
||||
- SQL injection koruması (parametreli sorgular)
|
||||
- XSS koruması (sanitize edilmiş HTML)
|
||||
- CSRF koruması etkin
|
||||
- Kimlik doğrulama/yetkilendirme doğrulanmış
|
||||
- Tüm endpointlerde hız sınırlama
|
||||
- Hata mesajları hassas veri sızdırmıyor
|
||||
|
||||
**Sır yönetimi:** Sırları asla sabit kodlamayın. Ortam değişkenlerini veya bir sır yöneticisini kullanın. Başlangıçta gerekli sırları doğrulayın. İfşa edilen sırları hemen döndürün.
|
||||
|
||||
**Güvenlik sorunu bulunursa:** DUR → security-reviewer agentini kullan → KRİTİK sorunları düzelt → ifşa edilen sırları döndür → kod tabanını benzer sorunlar için incele.
|
||||
|
||||
## Kodlama Stili
|
||||
|
||||
**Değişmezlik (KRİTİK):** Her zaman yeni nesneler oluşturun, asla değiştirmeyin. Değişiklikler uygulanmış yeni kopyalar döndürün.
|
||||
|
||||
**Dosya organizasyonu:** Az sayıda büyük dosya yerine çok sayıda küçük dosya. Tipik 200-400 satır, maksimum 800. Tipe göre değil, özelliğe/alana göre düzenleyin. Yüksek bağlılık, düşük bağımlılık.
|
||||
|
||||
**Hata yönetimi:** Her seviyede hataları ele alın. UI kodunda kullanıcı dostu mesajlar sağlayın. Sunucu tarafında detaylı bağlamı loglayın. Hataları asla sessizce yutmayın.
|
||||
|
||||
**Girdi doğrulama:** Sistem sınırlarında tüm kullanıcı girdilerini doğrulayın. Şema tabanlı doğrulama kullanın. Net mesajlarla hızlı başarısız olun. Harici verilere asla güvenmeyin.
|
||||
|
||||
**Kod kalite kontrol listesi:**
|
||||
- Fonksiyonlar küçük (<50 satır), dosyalar odaklı (<800 satır)
|
||||
- Derin iç içe geçme yok (>4 seviye)
|
||||
- Düzgün hata yönetimi, sabit kodlanmış değerler yok
|
||||
- Okunabilir, iyi adlandırılmış tanımlayıcılar
|
||||
|
||||
## Test Gereksinimleri
|
||||
|
||||
**Minimum kapsama: %80**
|
||||
|
||||
Test tipleri (hepsi gereklidir):
|
||||
1. **Unit testler** — Bireysel fonksiyonlar, yardımcı programlar, bileşenler
|
||||
2. **Integration testler** — API endpointleri, veritabanı işlemleri
|
||||
3. **E2E testler** — Kritik kullanıcı akışları
|
||||
|
||||
**TDD iş akışı (zorunlu):**
|
||||
1. Önce test yaz (KIRMIZI) — test BAŞARISIZ olmalı
|
||||
2. Minimal uygulama yaz (YEŞİL) — test BAŞARILI olmalı
|
||||
3. Yeniden düzenle (İYİLEŞTİR) — %80+ kapsama doğrula
|
||||
|
||||
Başarısızlık sorunlarını giderin: test izolasyonunu kontrol edin → mocklarını doğrulayın → uygulamayı düzeltin (testleri değil, testler yanlış olmadıkça).
|
||||
|
||||
## Geliştirme İş Akışı
|
||||
|
||||
1. **Planlama** — Planner agentini kullanın, bağımlılıkları ve riskleri belirleyin, aşamalara bölün
|
||||
2. **TDD** — tdd-guide agentini kullanın, önce testleri yazın, uygulayın, yeniden düzenleyin
|
||||
3. **İnceleme** — code-reviewer agentini hemen kullanın, KRİTİK/YÜKSEK sorunları ele alın
|
||||
4. **Bilgiyi doğru yerde yakalayın**
|
||||
- Kişisel hata ayıklama notları, tercihler ve geçici bağlam → otomatik bellek
|
||||
- Takım/proje bilgisi (mimari kararlar, API değişiklikleri, runbook'lar) → projenin mevcut doküman yapısı
|
||||
- Mevcut görev zaten ilgili dokümanları veya kod yorumlarını üretiyorsa, aynı bilgiyi başka yerde çoğaltmayın
|
||||
- Açık bir proje doküman konumu yoksa, yeni bir üst düzey dosya oluşturmadan önce sorun
|
||||
5. **Commit** — Conventional commits formatı, kapsamlı PR özetleri
|
||||
|
||||
## Git İş Akışı
|
||||
|
||||
**Commit formatı:** `<type>: <description>` — Tipler: feat, fix, refactor, docs, test, chore, perf, ci
|
||||
|
||||
**PR iş akışı:** Tam commit geçmişini analiz edin → kapsamlı özet taslağı oluşturun → test planı ekleyin → `-u` bayrağıyla pushlayın.
|
||||
|
||||
## Mimari Desenler
|
||||
|
||||
**API yanıt formatı:** Başarı göstergesi, veri yükü, hata mesajı ve sayfalandırma metadatası içeren tutarlı zarf.
|
||||
|
||||
**Repository deseni:** Veri erişimini standart arayüz arkasında kapsülleyin (findAll, findById, create, update, delete). İş mantığı depolama mekanizmasına değil, soyut arayüze bağlıdır.
|
||||
|
||||
**Skeleton projeleri:** Savaş testinden geçmiş şablonları arayın, paralel agentlarla değerlendirin (güvenlik, genişletilebilirlik, uygunluk), en iyi eşleşmeyi klonlayın, kanıtlanmış yapı içinde yineleyin.
|
||||
|
||||
## Performans
|
||||
|
||||
**Bağlam yönetimi:** Büyük yeniden düzenlemeler ve çok dosyalı özellikler için bağlam penceresinin son %20'sinden kaçının. Daha düşük hassasiyet gerektiren görevler (tekli düzenlemeler, dokümanlar, basit düzeltmeler) daha yüksek kullanımı tolere eder.
|
||||
|
||||
**Build sorun giderme:** build-error-resolver agentini kullanın → hataları analiz edin → artımlı olarak düzeltin → her düzeltmeden sonra doğrulayın.
|
||||
|
||||
## Proje Yapısı
|
||||
|
||||
```
|
||||
agents/ — 28 özel subagent
|
||||
skills/ — 115 iş akışı skillleri ve alan bilgisi
|
||||
commands/ — 59 slash command
|
||||
hooks/ — Tetikleyici tabanlı otomasyonlar
|
||||
rules/ — Her zaman uyulması gereken kurallar (ortak + dile özel)
|
||||
scripts/ — Platformlar arası Node.js yardımcı programları
|
||||
mcp-configs/ — 14 MCP sunucu yapılandırması
|
||||
tests/ — Test paketi
|
||||
```
|
||||
|
||||
## Başarı Metrikleri
|
||||
|
||||
- Tüm testler %80+ kapsama ile geçer
|
||||
- Güvenlik açığı yoktur
|
||||
- Kod okunabilir ve sürdürülebilirdir
|
||||
- Performans kabul edilebilirdir
|
||||
- Kullanıcı gereksinimleri karşılanmıştır
|
||||
149
docs/tr/CHANGELOG.md
Normal file
@@ -0,0 +1,149 @@
|
||||
# Değişiklik Günlüğü
|
||||
|
||||
## 1.9.0 - 2026-03-20
|
||||
|
||||
### Öne Çıkanlar
|
||||
|
||||
- Manifest tabanlı pipeline ve SQLite state store ile seçici kurulum mimarisi.
|
||||
- 6 yeni ajan ve dile özgü kurallarla 10+ ekosisteme genişletilmiş dil kapsamı.
|
||||
- Bellek azaltma, sandbox düzeltmeleri ve 5 katmanlı döngü koruması ile sağlamlaştırılmış Observer güvenilirliği.
|
||||
- Beceri evrimi ve session adaptörleri ile kendini geliştiren beceriler temeli.
|
||||
|
||||
### Yeni Ajanlar
|
||||
|
||||
- `typescript-reviewer` — TypeScript/JavaScript kod inceleme uzmanı (#647)
|
||||
- `pytorch-build-resolver` — PyTorch runtime, CUDA ve eğitim hatası çözümü (#549)
|
||||
- `java-build-resolver` — Maven/Gradle build hatası çözümü (#538)
|
||||
- `java-reviewer` — Java ve Spring Boot kod incelemesi (#528)
|
||||
- `kotlin-reviewer` — Kotlin/Android/KMP kod incelemesi (#309)
|
||||
- `kotlin-build-resolver` — Kotlin/Gradle build hataları (#309)
|
||||
- `rust-reviewer` — Rust kod incelemesi (#523)
|
||||
- `rust-build-resolver` — Rust build hatası çözümü (#523)
|
||||
- `docs-lookup` — Dokümantasyon ve API referans araştırması (#529)
|
||||
|
||||
### Yeni Beceriler
|
||||
|
||||
- `pytorch-patterns` — PyTorch derin öğrenme iş akışları (#550)
|
||||
- `documentation-lookup` — API referans ve kütüphane dokümanı araştırması (#529)
|
||||
- `bun-runtime` — Bun runtime kalıpları (#529)
|
||||
- `nextjs-turbopack` — Next.js Turbopack iş akışları (#529)
|
||||
- `mcp-server-patterns` — MCP sunucu tasarım kalıpları (#531)
|
||||
- `data-scraper-agent` — AI destekli genel veri toplama (#503)
|
||||
- `team-builder` — Takım kompozisyon becerisi (#501)
|
||||
- `ai-regression-testing` — AI regresyon test iş akışları (#433)
|
||||
- `claude-devfleet` — Çok ajanlı orkestrasyon (#505)
|
||||
- `blueprint` — Çok oturumlu yapı planlaması
|
||||
- `everything-claude-code` — Öz-referansiyel ECC becerisi (#335)
|
||||
- `prompt-optimizer` — Prompt optimizasyon becerisi (#418)
|
||||
- 8 Evos operasyonel alan becerisi (#290)
|
||||
- 3 Laravel becerisi (#420)
|
||||
- VideoDB becerileri (#301)
|
||||
|
||||
### Yeni Komutlar
|
||||
|
||||
- `/docs` — Dokümantasyon arama (#530)
|
||||
- `/aside` — Yan konuşma (#407)
|
||||
- `/prompt-optimize` — Prompt optimizasyonu (#418)
|
||||
- `/resume-session`, `/save-session` — Oturum yönetimi
|
||||
- Kontrol listesi tabanlı holistik karar ile `learn-eval` iyileştirmeleri
|
||||
|
||||
### Yeni Kurallar
|
||||
|
||||
- Java dil kuralları (#645)
|
||||
- PHP kural paketi (#389)
|
||||
- Perl dil kuralları ve becerileri (kalıplar, güvenlik, test)
|
||||
- Kotlin/Android/KMP kuralları (#309)
|
||||
- C++ dil desteği (#539)
|
||||
- Rust dil desteği (#523)
|
||||
|
||||
### Altyapı
|
||||
|
||||
- Manifest çözümlemesi ile seçici kurulum mimarisi (`install-plan.js`, `install-apply.js`) (#509, #512)
|
||||
- Kurulu bileşenleri izlemek için sorgu CLI'si ile SQLite state store (#510)
|
||||
- Yapılandırılmış oturum kaydı için session adaptörleri (#511)
|
||||
- Kendini geliştiren beceriler için beceri evrimi temeli (#514)
|
||||
- Deterministik puanlama ile orkestrasyon harness (#524)
|
||||
- CI'da katalog sayısı kontrolü (#525)
|
||||
- Tüm 109 beceri için install manifest doğrulaması (#537)
|
||||
- PowerShell installer wrapper (#532)
|
||||
- `--target antigravity` bayrağı ile Antigravity IDE desteği (#332)
|
||||
- Codex CLI özelleştirme scriptleri (#336)
|
||||
|
||||
### Hata Düzeltmeleri
|
||||
|
||||
- 6 dosyada 19 CI test hatasının çözümü (#519)
|
||||
- Install pipeline, orchestrator ve repair'da 8 test hatasının düzeltmesi (#564)
|
||||
- Azaltma, yeniden giriş koruması ve tail örneklemesi ile Observer bellek patlaması (#536)
|
||||
- Haiku çağrısı için Observer sandbox erişim düzeltmesi (#661)
|
||||
- Worktree proje ID uyumsuzluğu düzeltmesi (#665)
|
||||
- Observer lazy-start mantığı (#508)
|
||||
- Observer 5 katmanlı döngü önleme koruması (#399)
|
||||
- Hook taşınabilirliği ve Windows .cmd desteği
|
||||
- Biome hook optimizasyonu — npx yükü elimine edildi (#359)
|
||||
- InsAIts güvenlik hook'u opt-in yapıldı (#370)
|
||||
- Windows spawnSync export düzeltmesi (#431)
|
||||
- instinct CLI için UTF-8 kodlama düzeltmesi (#353)
|
||||
- Hook'larda secret scrubbing (#348)
|
||||
|
||||
### Çeviriler
|
||||
|
||||
- Korece (ko-KR) çeviri — README, ajanlar, komutlar, beceriler, kurallar (#392)
|
||||
- Çince (zh-CN) dokümantasyon senkronizasyonu (#428)
|
||||
|
||||
### Katkıda Bulunanlar
|
||||
|
||||
- @ymdvsymd — observer sandbox ve worktree düzeltmeleri
|
||||
- @pythonstrup — biome hook optimizasyonu
|
||||
- @Nomadu27 — InsAIts güvenlik hook'u
|
||||
- @hahmee — Korece çeviri
|
||||
- @zdocapp — Çince çeviri senkronizasyonu
|
||||
- @cookiee339 — Kotlin ekosistemi
|
||||
- @pangerlkr — CI iş akışı düzeltmeleri
|
||||
- @0xrohitgarg — VideoDB becerileri
|
||||
- @nocodemf — Evos operasyonel becerileri
|
||||
- @swarnika-cmd — topluluk katkıları
|
||||
|
||||
## 1.8.0 - 2026-03-04
|
||||
|
||||
### Öne Çıkanlar
|
||||
|
||||
- Güvenilirlik, eval disiplini ve otonom döngü operasyonlarına odaklanan harness-first sürüm.
|
||||
- Hook runtime artık profil tabanlı kontrol ve hedefli hook devre dışı bırakmayı destekliyor.
|
||||
- NanoClaw v2, model yönlendirme, beceri hot-load, dallanma, arama, sıkıştırma, dışa aktarma ve metrikler ekliyor.
|
||||
|
||||
### Çekirdek
|
||||
|
||||
- Yeni komutlar eklendi: `/harness-audit`, `/loop-start`, `/loop-status`, `/quality-gate`, `/model-route`.
|
||||
- Yeni beceriler eklendi:
|
||||
- `agent-harness-construction`
|
||||
- `agentic-engineering`
|
||||
- `ralphinho-rfc-pipeline`
|
||||
- `ai-first-engineering`
|
||||
- `enterprise-agent-ops`
|
||||
- `nanoclaw-repl`
|
||||
- `continuous-agent-loop`
|
||||
- Yeni ajanlar eklendi:
|
||||
- `harness-optimizer`
|
||||
- `loop-operator`
|
||||
|
||||
### Hook Güvenilirliği
|
||||
|
||||
- Sağlam yedek arama ile SessionStart root çözümlemesi düzeltildi.
|
||||
- Oturum özet kalıcılığı, transcript payload'ın mevcut olduğu `Stop`'a taşındı.
|
||||
- Quality-gate ve cost-tracker hook'ları eklendi.
|
||||
- Kırılgan inline hook tek satırlıkları özel script dosyalarıyla değiştirildi.
|
||||
- `ECC_HOOK_PROFILE` ve `ECC_DISABLED_HOOKS` kontrolleri eklendi.
|
||||
|
||||
### Platformlar Arası
|
||||
|
||||
- Doküman uyarı mantığında Windows-safe yol işleme iyileştirildi.
|
||||
- Etkileşimsiz takılmaları önlemek için Observer döngü davranışı sağlamlaştırıldı.
|
||||
|
||||
### Notlar
|
||||
|
||||
- `autonomous-loops`, bir sürüm için uyumluluk takma adı olarak tutuldu; `continuous-agent-loop` kanonik isimdir.
|
||||
|
||||
### Katkıda Bulunanlar
|
||||
|
||||
- [zarazhangrui](https://github.com/zarazhangrui) tarafından ilham alındı
|
||||
- [humanplane](https://github.com/humanplane) tarafından homunculus-ilhamlı
|
||||
60
docs/tr/CLAUDE.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# CLAUDE.md
|
||||
|
||||
Bu dosya, bu depodaki kodlarla çalışırken Claude Code'a (claude.ai/code) rehberlik sağlar.
|
||||
|
||||
## Projeye Genel Bakış
|
||||
|
||||
Bu bir **Claude Code plugin**'idir - üretime hazır agent'lar, skill'ler, hook'lar, komutlar, kurallar ve MCP konfigürasyonlarından oluşan bir koleksiyondur. Proje, Claude Code kullanarak yazılım geliştirme için test edilmiş iş akışları sağlar.
|
||||
|
||||
## Testleri Çalıştırma
|
||||
|
||||
```bash
|
||||
# Tüm testleri çalıştır
|
||||
node tests/run-all.js
|
||||
|
||||
# Tekil test dosyalarını çalıştır
|
||||
node tests/lib/utils.test.js
|
||||
node tests/lib/package-manager.test.js
|
||||
node tests/hooks/hooks.test.js
|
||||
```
|
||||
|
||||
## Mimari
|
||||
|
||||
Proje, birkaç temel bileşen halinde organize edilmiştir:
|
||||
|
||||
- **agents/** - Delegasyon için özelleşmiş alt agent'lar (planner, code-reviewer, tdd-guide, vb.)
|
||||
- **skills/** - İş akışı tanımları ve alan bilgisi (coding standards, patterns, testing)
|
||||
- **commands/** - Kullanıcılar tarafından çağrılan slash komutları (/tdd, /plan, /e2e, vb.)
|
||||
- **hooks/** - Tetikleyici tabanlı otomasyonlar (session persistence, pre/post-tool hooks)
|
||||
- **rules/** - Her zaman takip edilmesi gereken yönergeler (security, coding style, testing requirements)
|
||||
- **mcp-configs/** - Harici entegrasyonlar için MCP server konfigürasyonları
|
||||
- **scripts/** - Hook'lar ve kurulum için platformlar arası Node.js yardımcı araçları
|
||||
- **tests/** - Script'ler ve yardımcı araçlar için test suite
|
||||
|
||||
## Temel Komutlar
|
||||
|
||||
- `/tdd` - Test-driven development iş akışı
|
||||
- `/plan` - Uygulama planlaması
|
||||
- `/e2e` - E2E testleri oluştur ve çalıştır
|
||||
- `/code-review` - Kalite incelemesi
|
||||
- `/build-fix` - Build hatalarını düzelt
|
||||
- `/learn` - Oturumlardan kalıpları çıkar
|
||||
- `/skill-create` - Git geçmişinden skill'ler oluştur
|
||||
|
||||
## Geliştirme Notları
|
||||
|
||||
- Package manager algılama: npm, pnpm, yarn, bun (`CLAUDE_PACKAGE_MANAGER` env var veya proje config ile yapılandırılabilir)
|
||||
- Platformlar arası: Node.js script'leri aracılığıyla Windows, macOS, Linux desteği
|
||||
- Agent formatı: YAML frontmatter ile Markdown (name, description, tools, model)
|
||||
- Skill formatı: Ne zaman kullanılır, nasıl çalışır, örnekler için açık bölümler içeren Markdown
|
||||
- Hook formatı: Matcher koşulları ve command/notification hook'ları ile JSON
|
||||
|
||||
## Katkıda Bulunma
|
||||
|
||||
CONTRIBUTING.md'deki formatları takip edin:
|
||||
- Agents: Frontmatter ile Markdown (name, description, tools, model)
|
||||
- Skills: Açık bölümler (When to Use, How It Works, Examples)
|
||||
- Commands: Description frontmatter ile Markdown
|
||||
- Hooks: Matcher ve hooks array ile JSON
|
||||
|
||||
Dosya isimlendirme: tire ile küçük harfler (örn., `python-reviewer.md`, `tdd-workflow.md`)
|
||||
104
docs/tr/CODE_OF_CONDUCT.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# Katkıda Bulunanlar Sözleşmesi Davranış Kuralları
|
||||
|
||||
## Taahhüdümüz
|
||||
|
||||
Üyeler, katkıda bulunanlar ve liderler olarak, topluluğumuza katılımı yaş, beden
|
||||
ölçüsü, görünür veya görünmez engellilik, etnik köken, cinsiyet özellikleri, cinsiyet
|
||||
kimliği ve ifadesi, deneyim seviyesi, eğitim, sosyo-ekonomik durum,
|
||||
milliyet, kişisel görünüm, ırk, din veya cinsel kimlik
|
||||
ve yönelim fark etmeksizin herkes için tacizden arınmış bir deneyim haline getirmeyi taahhüt ediyoruz.
|
||||
|
||||
Açık, misafirperver, çeşitli, kapsayıcı ve sağlıklı bir topluluğa katkıda bulunacak şekilde hareket etmeyi ve etkileşimde bulunmayı taahhüt ediyoruz.
|
||||
|
||||
## Standartlarımız
|
||||
|
||||
Topluluğumuz için olumlu bir ortama katkıda bulunan davranış örnekleri şunlardır:
|
||||
|
||||
* Diğer insanlara karşı empati ve nezaket göstermek
|
||||
* Farklı görüşlere, bakış açılarına ve deneyimlere saygılı olmak
|
||||
* Yapıcı geri bildirimi vermek ve zarifçe kabul etmek
|
||||
* Hatalarımızdan etkilenenlerden sorumluluğu kabul etmek ve özür dilemek,
|
||||
ve deneyimden öğrenmek
|
||||
* Sadece bireyler olarak bizim için değil, genel
|
||||
topluluk için en iyi olana odaklanmak
|
||||
|
||||
Kabul edilemez davranış örnekleri şunlardır:
|
||||
|
||||
* Cinselleştirilmiş dil veya görsellerin kullanımı ve her türlü cinsel ilgi veya
|
||||
yaklaşımlar
|
||||
* Trollük, aşağılayıcı veya hakaret içeren yorumlar ve kişisel veya politik saldırılar
|
||||
* Kamusal veya özel taciz
|
||||
* Başkalarının fiziksel veya e-posta adresi gibi özel bilgilerini
|
||||
açık izinleri olmadan yayınlamak
|
||||
* Profesyonel bir ortamda makul şekilde uygunsuz
|
||||
kabul edilebilecek diğer davranışlar
|
||||
|
||||
## Uygulama Sorumlulukları
|
||||
|
||||
Topluluk liderleri, kabul edilebilir davranış standartlarımızı netleştirmekten ve uygulamaktan sorumludur ve uygunsuz, tehditkar, saldırgan
|
||||
veya zararlı buldukları herhangi bir davranışa yanıt olarak uygun ve adil düzeltici eylemde bulunacaklardır.
|
||||
|
||||
Topluluk liderleri, bu Davranış Kuralları'na uygun olmayan yorumları, commit'leri, kodu, wiki düzenlemelerini, issue'ları ve diğer katkıları kaldırma, düzenleme veya reddetme hakkına ve sorumluluğuna sahiptir ve uygun olduğunda moderasyon
|
||||
kararlarının nedenlerini iletecektir.
|
||||
|
||||
## Kapsam
|
||||
|
||||
Bu Davranış Kuralları tüm topluluk alanlarında geçerlidir ve ayrıca bir kişi topluluğu kamusal alanlarda resmi olarak temsil ettiğinde de geçerlidir.
|
||||
Topluluğumuzu temsil etme örnekleri arasında resmi bir e-posta adresinin kullanılması,
|
||||
resmi bir sosyal medya hesabı aracılığıyla gönderi paylaşılması veya çevrimiçi veya çevrimdışı bir etkinlikte atanmış
|
||||
temsilci olarak hareket etmek yer alır.
|
||||
|
||||
## Uygulama
|
||||
|
||||
Taciz edici, rahatsız edici veya başka şekilde kabul edilemez davranış örnekleri,
|
||||
uygulamadan sorumlu topluluk liderlerine
|
||||
bildirilebilir.
|
||||
Tüm şikayetler hızlı ve adil bir şekilde incelenecek ve araştırılacaktır.
|
||||
|
||||
Tüm topluluk liderleri, herhangi bir olayı bildiren kişinin gizliliğine ve güvenliğine saygı göstermekle yükümlüdür.
|
||||
|
||||
## Uygulama Kılavuzları
|
||||
|
||||
Topluluk liderleri, bu Davranış Kuralları'nın ihlali olduğunu düşündükleri herhangi bir eylemin sonuçlarını belirlerken bu Topluluk Etki Kılavuzları'nı takip edecektir:
|
||||
|
||||
### 1. Düzeltme
|
||||
|
||||
**Topluluk Etkisi**: Uygunsuz dilin kullanımı veya toplulukta profesyonel olmayan veya hoş karşılanmayan diğer davranışlar.
|
||||
|
||||
**Sonuç**: Topluluk liderlerinden özel, yazılı bir uyarı, ihlalin doğası etrafında netlik sağlamak ve davranışın neden uygunsuz olduğuna dair bir açıklama. Kamuya açık bir özür talep edilebilir.
|
||||
|
||||
### 2. Uyarı
|
||||
|
||||
**Topluluk Etkisi**: Tek bir olay veya bir dizi eylem yoluyla ihlal.
|
||||
|
||||
**Sonuç**: Devam eden davranışın sonuçlarıyla birlikte bir uyarı. Belirli bir süre boyunca, Davranış Kuralları'nı uygulayan kişilerle istenmeyen etkileşim de dahil olmak üzere ilgili kişilerle etkileşim yok. Bu, topluluk alanlarındaki etkileşimlerin yanı sıra sosyal medya gibi harici kanallardan kaçınmayı içerir. Bu şartların ihlali geçici veya
|
||||
kalıcı bir yasağa yol açabilir.
|
||||
|
||||
### 3. Geçici Yasak
|
||||
|
||||
**Topluluk Etkisi**: Sürekli uygunsuz davranış da dahil olmak üzere topluluk standartlarının ciddi ihlali.
|
||||
|
||||
**Sonuç**: Belirli bir süre boyunca toplulukla herhangi bir etkileşim veya kamusal iletişimden geçici bir yasak. Bu süre boyunca, Davranış Kuralları'nı uygulayan kişilerle istenmeyen etkileşim de dahil olmak üzere ilgili kişilerle kamusal veya
|
||||
özel etkileşime izin verilmez.
|
||||
Bu şartların ihlali kalıcı bir yasağa yol açabilir.
|
||||
|
||||
### 4. Kalıcı Yasak
|
||||
|
||||
**Topluluk Etkisi**: Sürekli uygunsuz davranış, bir bireyin taciz edilmesi veya birey sınıflarına karşı saldırganlık veya aşağılamayı içeren topluluk standartlarının ihlal kalıbının gösterilmesi.
|
||||
|
||||
**Sonuç**: Topluluk içindeki herhangi bir kamusal etkileşimden kalıcı bir yasak.
|
||||
|
||||
## Atıf
|
||||
|
||||
Bu Davranış Kuralları, [Contributor Covenant][homepage]'ın
|
||||
2.0 sürümünden uyarlanmıştır, şu adreste mevcuttur:
|
||||
<https://www.contributor-covenant.org/version/2/0/code_of_conduct.html>.
|
||||
|
||||
Topluluk Etki Kılavuzları, [Mozilla'nın davranış kuralları
|
||||
uygulama merdiveni](https://github.com/mozilla/diversity)'nden ilham almıştır.
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
|
||||
Bu davranış kuralları hakkında sık sorulan soruların cevapları için SSS'ye bakın:
|
||||
<https://www.contributor-covenant.org/faq>. Çeviriler şu adreste mevcuttur:
|
||||
<https://www.contributor-covenant.org/translations>.
|
||||
461
docs/tr/CONTRIBUTING.md
Normal file
@@ -0,0 +1,461 @@
|
||||
# Everything Claude Code'a Katkıda Bulunma
|
||||
|
||||
Katkıda bulunmak istediğiniz için teşekkürler! Bu repo, Claude Code kullanıcıları için bir topluluk kaynağıdır.
|
||||
|
||||
## İçindekiler
|
||||
|
||||
- [Ne Arıyoruz](#ne-arıyoruz)
|
||||
- [Hızlı Başlangıç](#hızlı-başlangıç)
|
||||
- [Skill'lere Katkıda Bulunma](#skilllere-katkıda-bulunma)
|
||||
- [Agent'lara Katkıda Bulunma](#agentlara-katkıda-bulunma)
|
||||
- [Hook'lara Katkıda Bulunma](#hooklara-katkıda-bulunma)
|
||||
- [Command'lara Katkıda Bulunma](#commandlara-katkıda-bulunma)
|
||||
- [MCP ve dokümantasyon (örn. Context7)](#mcp-ve-dokümantasyon-örn-context7)
|
||||
- [Cross-Harness ve Çeviriler](#cross-harness-ve-çeviriler)
|
||||
- [Pull Request Süreci](#pull-request-süreci)
|
||||
|
||||
---
|
||||
|
||||
## Ne Arıyoruz
|
||||
|
||||
### Agent'lar
|
||||
Belirli görevleri iyi yöneten yeni agent'lar:
|
||||
- Dile özgü reviewer'lar (Python, Go, Rust)
|
||||
- Framework uzmanları (Django, Rails, Laravel, Spring)
|
||||
- DevOps uzmanları (Kubernetes, Terraform, CI/CD)
|
||||
- Alan uzmanları (ML pipeline'ları, data engineering, mobil)
|
||||
|
||||
### Skill'ler
|
||||
Workflow tanımları ve alan bilgisi:
|
||||
- Dil en iyi uygulamaları
|
||||
- Framework pattern'leri
|
||||
- Test stratejileri
|
||||
- Mimari kılavuzları
|
||||
|
||||
### Hook'lar
|
||||
Faydalı otomasyonlar:
|
||||
- Linting/formatlama hook'ları
|
||||
- Güvenlik kontrolleri
|
||||
- Doğrulama hook'ları
|
||||
- Bildirim hook'ları
|
||||
|
||||
### Command'lar
|
||||
Faydalı workflow'ları çağıran slash command'lar:
|
||||
- Deployment command'ları
|
||||
- Test command'ları
|
||||
- Kod üretim command'ları
|
||||
|
||||
---
|
||||
|
||||
## Hızlı Başlangıç
|
||||
|
||||
```bash
|
||||
# 1. Fork ve clone
|
||||
gh repo fork affaan-m/everything-claude-code --clone
|
||||
cd everything-claude-code
|
||||
|
||||
# 2. Branch oluştur
|
||||
git checkout -b feat/my-contribution
|
||||
|
||||
# 3. Katkınızı ekleyin (aşağıdaki bölümlere bakın)
|
||||
|
||||
# 4. Yerel olarak test edin
|
||||
cp -r skills/my-skill ~/.claude/skills/ # skill'ler için
|
||||
# Ardından Claude Code ile test edin
|
||||
|
||||
# 5. PR gönderin
|
||||
git add . && git commit -m "feat: add my-skill" && git push -u origin feat/my-contribution
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Skill'lere Katkıda Bulunma
|
||||
|
||||
Skill'ler, Claude Code'un bağlama göre yüklediği bilgi modülleridir.
|
||||
|
||||
### Dizin Yapısı
|
||||
|
||||
```
|
||||
skills/
|
||||
└── your-skill-name/
|
||||
└── SKILL.md
|
||||
```
|
||||
|
||||
### SKILL.md Şablonu
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: your-skill-name
|
||||
description: Skill listesinde gösterilen kısa açıklama
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Skill Başlığınız
|
||||
|
||||
Bu skill'in neyi kapsadığına dair kısa genel bakış.
|
||||
|
||||
## Temel Kavramlar
|
||||
|
||||
Temel pattern'leri ve yönergeleri açıklayın.
|
||||
|
||||
## Kod Örnekleri
|
||||
|
||||
\`\`\`typescript
|
||||
// Pratik, test edilmiş örnekler ekleyin
|
||||
function example() {
|
||||
// İyi yorumlanmış kod
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
## En İyi Uygulamalar
|
||||
|
||||
- Uygulanabilir yönergeler
|
||||
- Yapılması ve yapılmaması gerekenler
|
||||
- Kaçınılması gereken yaygın hatalar
|
||||
|
||||
## Ne Zaman Kullanılır
|
||||
|
||||
Bu skill'in uygulandığı senaryoları açıklayın.
|
||||
```
|
||||
|
||||
### Skill Kontrol Listesi
|
||||
|
||||
- [ ] Tek bir alan/teknolojiye odaklanmış
|
||||
- [ ] Pratik kod örnekleri içeriyor
|
||||
- [ ] 500 satırın altında
|
||||
- [ ] Net bölüm başlıkları kullanıyor
|
||||
- [ ] Claude Code ile test edilmiş
|
||||
|
||||
### Örnek Skill'ler
|
||||
|
||||
| Skill | Amaç |
|
||||
|-------|---------|
|
||||
| `coding-standards/` | TypeScript/JavaScript pattern'leri |
|
||||
| `frontend-patterns/` | React ve Next.js en iyi uygulamaları |
|
||||
| `backend-patterns/` | API ve veritabanı pattern'leri |
|
||||
| `security-review/` | Güvenlik kontrol listesi |
|
||||
|
||||
---
|
||||
|
||||
## Agent'lara Katkıda Bulunma
|
||||
|
||||
Agent'lar, Task tool üzerinden çağrılan özelleşmiş asistanlardır.
|
||||
|
||||
### Dosya Konumu
|
||||
|
||||
```
|
||||
agents/your-agent-name.md
|
||||
```
|
||||
|
||||
### Agent Şablonu
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: your-agent-name
|
||||
description: Bu agent'ın ne yaptığı ve Claude'un onu ne zaman çağırması gerektiği. Spesifik olun!
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
Siz bir [rol] uzmanısınız.
|
||||
|
||||
## Rolünüz
|
||||
|
||||
- Birincil sorumluluk
|
||||
- İkincil sorumluluk
|
||||
- YAPMADIĞINIZ şeyler (sınırlar)
|
||||
|
||||
## Workflow
|
||||
|
||||
### Adım 1: Anlama
|
||||
Göreve nasıl yaklaşıyorsunuz.
|
||||
|
||||
### Adım 2: Uygulama
|
||||
İşi nasıl gerçekleştiriyorsunuz.
|
||||
|
||||
### Adım 3: Doğrulama
|
||||
Sonuçları nasıl doğruluyorsunuz.
|
||||
|
||||
## Çıktı Formatı
|
||||
|
||||
Kullanıcıya ne döndürüyorsunuz.
|
||||
|
||||
## Örnekler
|
||||
|
||||
### Örnek: [Senaryo]
|
||||
Girdi: [kullanıcının sağladığı]
|
||||
Eylem: [yaptığınız]
|
||||
Çıktı: [döndürdüğünüz]
|
||||
```
|
||||
|
||||
### Agent Alanları
|
||||
|
||||
| Alan | Açıklama | Seçenekler |
|
||||
|-------|-------------|---------|
|
||||
| `name` | Küçük harf, tire ile ayrılmış | `code-reviewer` |
|
||||
| `description` | Ne zaman çağrılacağına karar vermek için kullanılır | Spesifik olun! |
|
||||
| `tools` | Sadece gerekli olanlar | `Read, Write, Edit, Bash, Grep, Glob, WebFetch, Task`, veya agent MCP kullanıyorsa MCP tool isimleri (örn. `mcp__context7__resolve-library-id`, `mcp__context7__query-docs`) |
|
||||
| `model` | Karmaşıklık seviyesi | `haiku` (basit), `sonnet` (kodlama), `opus` (karmaşık) |
|
||||
|
||||
### Örnek Agent'lar
|
||||
|
||||
| Agent | Amaç |
|
||||
|-------|---------|
|
||||
| `tdd-guide.md` | Test odaklı geliştirme |
|
||||
| `code-reviewer.md` | Kod incelemesi |
|
||||
| `security-reviewer.md` | Güvenlik taraması |
|
||||
| `build-error-resolver.md` | Build hatalarını düzeltme |
|
||||
|
||||
---
|
||||
|
||||
## Hook'lara Katkıda Bulunma
|
||||
|
||||
Hook'lar, Claude Code olayları tarafından tetiklenen otomatik davranışlardır.
|
||||
|
||||
### Dosya Konumu
|
||||
|
||||
```
|
||||
hooks/hooks.json
|
||||
```
|
||||
|
||||
### Hook Türleri
|
||||
|
||||
| Tür | Tetikleyici | Kullanım Alanı |
|
||||
|------|---------|----------|
|
||||
| `PreToolUse` | Tool çalışmadan önce | Doğrulama, uyarı, engelleme |
|
||||
| `PostToolUse` | Tool çalıştıktan sonra | Formatlama, kontrol, bildirim |
|
||||
| `SessionStart` | Oturum başladığında | Bağlam yükleme |
|
||||
| `Stop` | Oturum sona erdiğinde | Temizleme, denetim |
|
||||
|
||||
### Hook Formatı
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"PreToolUse": [
|
||||
{
|
||||
"matcher": "tool == \"Bash\" && tool_input.command matches \"rm -rf /\"",
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "echo '[Hook] ENGELLENDİ: Tehlikeli komut' && exit 1"
|
||||
}
|
||||
],
|
||||
"description": "Tehlikeli rm komutlarını engelle"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Matcher Sözdizimi
|
||||
|
||||
```javascript
|
||||
// Belirli tool'ları eşleştir
|
||||
tool == "Bash"
|
||||
tool == "Edit"
|
||||
tool == "Write"
|
||||
|
||||
// Girdi pattern'lerini eşleştir
|
||||
tool_input.command matches "npm install"
|
||||
tool_input.file_path matches "\\.tsx?$"
|
||||
|
||||
// Koşulları birleştir
|
||||
tool == "Bash" && tool_input.command matches "git push"
|
||||
```
|
||||
|
||||
### Hook Örnekleri
|
||||
|
||||
```json
|
||||
// tmux dışında dev server'ları engelle
|
||||
{
|
||||
"matcher": "tool == \"Bash\" && tool_input.command matches \"npm run dev\"",
|
||||
"hooks": [{"type": "command", "command": "echo 'Dev server'lar için tmux kullanın' && exit 1"}],
|
||||
"description": "Dev server'ların tmux'ta çalışmasını sağla"
|
||||
}
|
||||
|
||||
// TypeScript düzenledikten sonra otomatik formatla
|
||||
{
|
||||
"matcher": "tool == \"Edit\" && tool_input.file_path matches \"\\.tsx?$\"",
|
||||
"hooks": [{"type": "command", "command": "npx prettier --write \"$file_path\""}],
|
||||
"description": "TypeScript dosyalarını düzenlemeden sonra formatla"
|
||||
}
|
||||
|
||||
// git push öncesi uyar
|
||||
{
|
||||
"matcher": "tool == \"Bash\" && tool_input.command matches \"git push\"",
|
||||
"hooks": [{"type": "command", "command": "echo '[Hook] Push yapmadan önce değişiklikleri gözden geçirin'"}],
|
||||
"description": "Push öncesi gözden geçirme hatırlatıcısı"
|
||||
}
|
||||
```
|
||||
|
||||
### Hook Kontrol Listesi
|
||||
|
||||
- [ ] Matcher spesifik (aşırı geniş değil)
|
||||
- [ ] Net hata/bilgi mesajları içeriyor
|
||||
- [ ] Doğru çıkış kodlarını kullanıyor (`exit 1` engeller, `exit 0` izin verir)
|
||||
- [ ] Kapsamlı test edilmiş
|
||||
- [ ] Açıklama içeriyor
|
||||
|
||||
---
|
||||
|
||||
## Command'lara Katkıda Bulunma
|
||||
|
||||
Command'lar, `/command-name` ile kullanıcı tarafından çağrılan eylemlerdir.
|
||||
|
||||
### Dosya Konumu
|
||||
|
||||
```
|
||||
commands/your-command.md
|
||||
```
|
||||
|
||||
### Command Şablonu
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: /help'te gösterilen kısa açıklama
|
||||
---
|
||||
|
||||
# Command Adı
|
||||
|
||||
## Amaç
|
||||
|
||||
Bu command'ın ne yaptığı.
|
||||
|
||||
## Kullanım
|
||||
|
||||
\`\`\`
|
||||
/your-command [args]
|
||||
\`\`\`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. İlk adım
|
||||
2. İkinci adım
|
||||
3. Son adım
|
||||
|
||||
## Çıktı
|
||||
|
||||
Kullanıcının aldığı.
|
||||
```
|
||||
|
||||
### Örnek Command'lar
|
||||
|
||||
| Command | Amaç |
|
||||
|---------|---------|
|
||||
| `commit.md` | Git commit'leri oluştur |
|
||||
| `code-review.md` | Kod değişikliklerini incele |
|
||||
| `tdd.md` | TDD workflow'u |
|
||||
| `e2e.md` | E2E test |
|
||||
|
||||
---
|
||||
|
||||
## MCP ve dokümantasyon (örn. Context7)
|
||||
|
||||
Skill'ler ve agent'lar, sadece eğitim verilerine güvenmek yerine güncel verileri çekmek için **MCP (Model Context Protocol)** tool'larını kullanabilir. Bu özellikle dokümantasyon için faydalıdır.
|
||||
|
||||
- **Context7**, `resolve-library-id` ve `query-docs`'u açığa çıkaran bir MCP server'ıdır. Kullanıcı kütüphaneler, framework'ler veya API'ler hakkında sorduğunda, cevapların güncel dokümantasyonu ve kod örneklerini yansıtması için kullanın.
|
||||
- Canlı dokümantasyona bağlı **skill'lere** katkıda bulunurken (örn. kurulum, API kullanımı), ilgili MCP tool'larının nasıl kullanılacağını açıklayın (örn. kütüphane ID'sini çözümle, ardından dokümantasyonu sorgula) ve pattern olarak `documentation-lookup` skill'ine veya Context7'ye işaret edin.
|
||||
- Dokümantasyon/API sorularını yanıtlayan **agent'lara** katkıda bulunurken, agent'ın tool'larına Context7 MCP tool isimlerini ekleyin (örn. `mcp__context7__resolve-library-id`, `mcp__context7__query-docs`) ve çözümle → sorgula workflow'unu belgeleyin.
|
||||
- **mcp-configs/mcp-servers.json** bir Context7 girişi içerir; kullanıcılar `documentation-lookup` skill'ini (`skills/documentation-lookup/` içinde) ve `/docs` command'ını kullanmak için bunu harness'lerinde (örn. Claude Code, Cursor) etkinleştirir.
|
||||
|
||||
---
|
||||
|
||||
## Cross-Harness ve Çeviriler
|
||||
|
||||
### Skill alt kümeleri (Codex ve Cursor)
|
||||
|
||||
ECC, diğer harness'ler için skill alt kümeleri içerir:
|
||||
|
||||
- **Codex:** `.agents/skills/` — `agents/openai.yaml` içinde listelenen skill'ler Codex tarafından yüklenir.
|
||||
- **Cursor:** `.cursor/skills/` — Cursor için bir skill alt kümesi paketlenmiştir.
|
||||
|
||||
Codex veya Cursor'da kullanılabilir olması gereken **yeni bir skill eklediğinizde**:
|
||||
|
||||
1. Skill'i her zamanki gibi `skills/your-skill-name/` altına ekleyin.
|
||||
2. **Codex**'te kullanılabilir olması gerekiyorsa, `.agents/skills/` altına ekleyin (skill dizinini kopyalayın veya referans ekleyin) ve gerekirse `agents/openai.yaml` içinde referans verildiğinden emin olun.
|
||||
3. **Cursor**'da kullanılabilir olması gerekiyorsa, Cursor'un düzenine göre `.cursor/skills/` altına ekleyin.
|
||||
|
||||
Beklenen yapı için bu dizinlerdeki mevcut skill'leri kontrol edin. Bu alt kümeleri senkronize tutmak manuel bir işlemdir; bunları güncellediyseniz PR'ınızda belirtin.
|
||||
|
||||
### Çeviriler
|
||||
|
||||
Çeviriler `docs/` altında bulunur (örn. `docs/zh-CN`, `docs/zh-TW`, `docs/ja-JP`). Çevrilmiş agent'ları, command'ları veya skill'leri değiştirirseniz, ilgili çeviri dosyalarını güncellemeyi veya bakımcıların ya da çevirmenlerin bunları güncelleyebilmesi için bir issue açmayı düşünün.
|
||||
|
||||
---
|
||||
|
||||
## Pull Request Süreci
|
||||
|
||||
### 1. PR Başlık Formatı
|
||||
|
||||
```
|
||||
feat(skills): add rust-patterns skill
|
||||
feat(agents): add api-designer agent
|
||||
feat(hooks): add auto-format hook
|
||||
fix(skills): update React patterns
|
||||
docs: improve contributing guide
|
||||
```
|
||||
|
||||
### 2. PR Açıklaması
|
||||
|
||||
```markdown
|
||||
## Özet
|
||||
Ne eklediğiniz ve neden.
|
||||
|
||||
## Tür
|
||||
- [ ] Skill
|
||||
- [ ] Agent
|
||||
- [ ] Hook
|
||||
- [ ] Command
|
||||
|
||||
## Test
|
||||
Bunu nasıl test ettiniz.
|
||||
|
||||
## Kontrol Listesi
|
||||
- [ ] Format yönergelerini takip ediyor
|
||||
- [ ] Claude Code ile test edildi
|
||||
- [ ] Hassas bilgi yok (API anahtarları, yollar)
|
||||
- [ ] Net açıklamalar
|
||||
```
|
||||
|
||||
### 3. İnceleme Süreci
|
||||
|
||||
1. Bakımcılar 48 saat içinde inceler
|
||||
2. İstenirse geri bildirimlere cevap verin
|
||||
3. Onaylandığında, main'e merge edilir
|
||||
|
||||
---
|
||||
|
||||
## Yönergeler
|
||||
|
||||
### Yapın
|
||||
- Katkıları odaklanmış ve modüler tutun
|
||||
- Net açıklamalar ekleyin
|
||||
- Göndermeden önce test edin
|
||||
- Mevcut pattern'leri takip edin
|
||||
- Bağımlılıkları belgeleyin
|
||||
|
||||
### Yapmayın
|
||||
- Hassas veri eklemeyin (API anahtarları, token'lar, yollar)
|
||||
- Aşırı karmaşık veya niş config'ler eklemeyin
|
||||
- Test edilmemiş katkılar göndermeyin
|
||||
- Mevcut işlevselliğin kopyalarını oluşturmayın
|
||||
|
||||
---
|
||||
|
||||
## Dosya Adlandırma
|
||||
|
||||
- Tire ile küçük harf kullanın: `python-reviewer.md`
|
||||
- Açıklayıcı olun: `tdd-workflow.md` değil `workflow.md`
|
||||
- İsim, dosya adıyla eşleşsin
|
||||
|
||||
---
|
||||
|
||||
## Sorularınız mı var?
|
||||
|
||||
- **Issue'lar:** [github.com/affaan-m/everything-claude-code/issues](https://github.com/affaan-m/everything-claude-code/issues)
|
||||
- **X/Twitter:** [@affaanmustafa](https://x.com/affaanmustafa)
|
||||
|
||||
---
|
||||
|
||||
Katkıda bulunduğunuz için teşekkürler! Birlikte harika bir kaynak oluşturalım.
|
||||
457
docs/tr/README.md
Normal file
@@ -0,0 +1,457 @@
|
||||
# Everything Claude Code
|
||||
|
||||
[](https://github.com/affaan-m/everything-claude-code/stargazers)
|
||||
[](https://github.com/affaan-m/everything-claude-code/network/members)
|
||||
[](https://github.com/affaan-m/everything-claude-code/graphs/contributors)
|
||||
[](https://www.npmjs.com/package/ecc-universal)
|
||||
[](https://www.npmjs.com/package/ecc-agentshield)
|
||||
[](https://github.com/marketplace/ecc-tools)
|
||||
[](../../LICENSE)
|
||||

|
||||

|
||||

|
||||

|
||||

|
||||

|
||||

|
||||
|
||||
> **50K+ yıldız** | **6K+ fork** | **30 katkıda bulunan** | **6 dil desteği** | **Anthropic Hackathon Kazananı**
|
||||
|
||||
---
|
||||
|
||||
<div align="center">
|
||||
|
||||
**🌐 Dil / Language / 语言 / 語言**
|
||||
|
||||
[**English**](../../README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](../ja-JP/README.md) | [한국어](../ko-KR/README.md) | [**Türkçe**](README.md)
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
**AI agent harness'ları için performans optimizasyon sistemi. Anthropic hackathon kazananından.**
|
||||
|
||||
Sadece konfigürasyon dosyaları değil. Tam bir sistem: skill'ler, instinct'ler, memory optimizasyonu, sürekli öğrenme, güvenlik taraması ve araştırma odaklı geliştirme. 10+ ay boyunca gerçek ürünler inşa ederken yoğun günlük kullanımla evrimleşmiş production-ready agent'lar, hook'lar, command'lar, rule'lar ve MCP konfigürasyonları.
|
||||
|
||||
**Claude Code**, **Codex**, **Cowork** ve diğer AI agent harness'larında çalışır.
|
||||
|
||||
---
|
||||
|
||||
## Rehberler
|
||||
|
||||
Bu repository yalnızca ham kodu içerir. Rehberler her şeyi açıklıyor.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2012378465664745795">
|
||||
<img src="../../assets/images/guides/shorthand-guide.png" alt="Everything Claude Code Kısa Rehberi" />
|
||||
</a>
|
||||
</td>
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2014040193557471352">
|
||||
<img src="../../assets/images/guides/longform-guide.png" alt="Everything Claude Code Uzun Rehberi" />
|
||||
</a>
|
||||
</td>
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2033263813387223421">
|
||||
<img src="../../assets/images/security/security-guide-header.png" alt="Agentic Güvenlik Kısa Rehberi" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="center"><b>Kısa Rehber</b><br/>Kurulum, temeller, felsefe. <b>İlk önce bunu okuyun.</b></td>
|
||||
<td align="center"><b>Uzun Rehber</b><br/>Token optimizasyonu, memory kalıcılığı, eval'ler, paralelleştirme.</td>
|
||||
<td align="center"><b>Güvenlik Rehberi</b><br/>Saldırı vektörleri, sandboxing, sanitizasyon, CVE'ler, AgentShield.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
| Konu | Öğrenecekleriniz |
|
||||
|------|------------------|
|
||||
| Token Optimizasyonu | Model seçimi, system prompt daraltma, background process'ler |
|
||||
| Memory Kalıcılığı | Oturumlar arası bağlamı otomatik kaydet/yükle hook'ları |
|
||||
| Sürekli Öğrenme | Oturumlardan otomatik pattern çıkarma ve yeniden kullanılabilir skill'lere dönüştürme |
|
||||
| Verification Loop'ları | Checkpoint vs sürekli eval'ler, grader tipleri, pass@k metrikleri |
|
||||
| Paralelleştirme | Git worktree'ler, cascade metodu, instance'ları ne zaman ölçeklendirmeli |
|
||||
| Subagent Orkestrasyonu | Context problemi, iterative retrieval pattern |
|
||||
|
||||
---
|
||||
|
||||
## Yenilikler
|
||||
|
||||
### v1.9.0 — Seçici Kurulum & Dil Genişlemesi (Mar 2026)
|
||||
|
||||
- **Seçici kurulum mimarisi** — `install-plan.js` ve `install-apply.js` ile manifest-tabanlı kurulum pipeline'ı, hedefli component kurulumu için. State store neyin kurulu olduğunu takip eder ve artımlı güncellemelere olanak sağlar.
|
||||
- **6 yeni agent** — `typescript-reviewer`, `pytorch-build-resolver`, `java-build-resolver`, `java-reviewer`, `kotlin-reviewer`, `kotlin-build-resolver` dil desteğini 10 dile çıkarıyor.
|
||||
- **Yeni skill'ler** — Deep learning iş akışları için `pytorch-patterns`, API referans araştırması için `documentation-lookup`, modern JS toolchain'leri için `bun-runtime` ve `nextjs-turbopack`, artı 8 operasyonel domain skill ve `mcp-server-patterns`.
|
||||
- **Session & state altyapısı** — Query CLI ile SQLite state store, yapılandırılmış kayıt için session adapter'ları, kendini geliştiren skill'ler için skill evolution foundation.
|
||||
- **Orkestrasyon iyileştirmesi** — Harness audit skorlaması deterministik hale getirildi, orkestrasyon durumu ve launcher uyumluluğu sağlamlaştırıldı, 5 katmanlı koruma ile observer loop önleme.
|
||||
- **Observer güvenilirliği** — Throttling ve tail sampling ile memory patlaması düzeltmesi, sandbox erişim düzeltmesi, lazy-start mantığı ve re-entrancy koruması.
|
||||
- **12 dil ekosistemi** — Mevcut TypeScript, Python, Go ve genel rule'lara Java, PHP, Perl, Kotlin/Android/KMP, C++ ve Rust için yeni rule'lar eklendi.
|
||||
- **Topluluk katkıları** — Korece ve Çince çeviriler, security hook, biome hook optimizasyonu, video işleme skill'leri, operasyonel skill'ler, PowerShell installer, Antigravity IDE desteği.
|
||||
- **CI sağlamlaştırma** — 19 test hatası düzeltmesi, katalog sayısı zorunluluğu, kurulum manifest validasyonu ve tam test suite yeşil.
|
||||
|
||||
### v1.8.0 — Harness Performans Sistemi (Mar 2026)
|
||||
|
||||
- **Harness-first release** — ECC artık açıkça bir agent harness performans sistemi olarak çerçevelendi, sadece bir config paketi değil.
|
||||
- **Hook güvenilirlik iyileştirmesi** — SessionStart root fallback, Stop-phase session özetleri ve kırılgan inline one-liner'lar yerine script-tabanlı hook'lar.
|
||||
- **Hook runtime kontrolleri** — `ECC_HOOK_PROFILE=minimal|standard|strict` ve `ECC_DISABLED_HOOKS=...` hook dosyalarını düzenlemeden runtime gating için.
|
||||
- **Yeni harness command'ları** — `/harness-audit`, `/loop-start`, `/loop-status`, `/quality-gate`, `/model-route`.
|
||||
- **NanoClaw v2** — Model routing, skill hot-load, session branch/search/export/compact/metrics.
|
||||
- **Çapraz harness paritesi** — Claude Code, Cursor, OpenCode ve Codex app/CLI arasında davranış sıkılaştırıldı.
|
||||
- **997 internal test geçiyor** — Hook/runtime refactor ve uyumluluk güncellemelerinden sonra tam suite yeşil.
|
||||
|
||||
[Tam değişiklik günlüğü için Releases bölümüne bakın](https://github.com/affaan-m/everything-claude-code/releases).
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Hızlı Başlangıç
|
||||
|
||||
2 dakikadan kısa sürede başlayın:
|
||||
|
||||
### Adım 1: Plugin'i Kurun
|
||||
|
||||
```bash
|
||||
# Marketplace ekle
|
||||
/plugin marketplace add affaan-m/everything-claude-code
|
||||
|
||||
# Plugin'i kur
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
### Adım 2: Rule'ları Kurun (Gerekli)
|
||||
|
||||
> ⚠️ **Önemli:** Claude Code plugin'leri `rule`'ları otomatik olarak dağıtamaz. Manuel olarak kurmalısınız:
|
||||
|
||||
```bash
|
||||
# Önce repo'yu klonlayın
|
||||
git clone https://github.com/affaan-m/everything-claude-code.git
|
||||
cd everything-claude-code
|
||||
|
||||
# Bağımlılıkları kurun (paket yöneticinizi seçin)
|
||||
npm install # veya: pnpm install | yarn install | bun install
|
||||
|
||||
# macOS/Linux
|
||||
./install.sh typescript # veya python veya golang veya swift veya php
|
||||
# ./install.sh typescript python golang swift php
|
||||
# ./install.sh --target cursor typescript
|
||||
# ./install.sh --target antigravity typescript
|
||||
```
|
||||
|
||||
```powershell
|
||||
# Windows PowerShell
|
||||
.\install.ps1 typescript # veya python veya golang veya swift veya php
|
||||
# .\install.ps1 typescript python golang swift php
|
||||
# .\install.ps1 --target cursor typescript
|
||||
# .\install.ps1 --target antigravity typescript
|
||||
|
||||
# npm-installed uyumluluk entry point'i de çapraz platform çalışır
|
||||
npx ecc-install typescript
|
||||
```
|
||||
|
||||
Manuel kurulum talimatları için `rules/` klasöründeki README'ye bakın.
|
||||
|
||||
### Adım 3: Kullanmaya Başlayın
|
||||
|
||||
```bash
|
||||
# Bir command deneyin (plugin kurulumu namespace'li form kullanır)
|
||||
/everything-claude-code:plan "Kullanıcı kimlik doğrulaması ekle"
|
||||
|
||||
# Manuel kurulum (Seçenek 2) daha kısa formu kullanır:
|
||||
# /plan "Kullanıcı kimlik doğrulaması ekle"
|
||||
|
||||
# Mevcut command'ları kontrol edin
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
✨ **Bu kadar!** Artık 28 agent, 116 skill ve 59 command'a erişiminiz var.
|
||||
|
||||
---
|
||||
|
||||
## 🌐 Çapraz Platform Desteği
|
||||
|
||||
Bu plugin artık **Windows, macOS ve Linux**'u tam olarak destekliyor, ana IDE'ler (Cursor, OpenCode, Antigravity) ve CLI harness'lar arasında sıkı entegrasyon ile birlikte. Tüm hook'lar ve script'ler maksimum uyumluluk için Node.js ile yeniden yazıldı.
|
||||
|
||||
### Paket Yöneticisi Algılama
|
||||
|
||||
Plugin, tercih ettiğiniz paket yöneticisini (npm, pnpm, yarn veya bun) otomatik olarak algılar, aşağıdaki öncelik sırasıyla:
|
||||
|
||||
1. **Ortam değişkeni**: `CLAUDE_PACKAGE_MANAGER`
|
||||
2. **Proje config**: `.claude/package-manager.json`
|
||||
3. **package.json**: `packageManager` alanı
|
||||
4. **Lock dosyası**: package-lock.json, yarn.lock, pnpm-lock.yaml veya bun.lockb'den algılama
|
||||
5. **Global config**: `~/.claude/package-manager.json`
|
||||
6. **Fallback**: İlk mevcut paket yöneticisi
|
||||
|
||||
Tercih ettiğiniz paket yöneticisini ayarlamak için:
|
||||
|
||||
```bash
|
||||
# Ortam değişkeni ile
|
||||
export CLAUDE_PACKAGE_MANAGER=pnpm
|
||||
|
||||
# Global config ile
|
||||
node scripts/setup-package-manager.js --global pnpm
|
||||
|
||||
# Proje config ile
|
||||
node scripts/setup-package-manager.js --project bun
|
||||
|
||||
# Mevcut ayarı algıla
|
||||
node scripts/setup-package-manager.js --detect
|
||||
```
|
||||
|
||||
Veya Claude Code'da `/setup-pm` command'ını kullanın.
|
||||
|
||||
### Hook Runtime Kontrolleri
|
||||
|
||||
Sıkılığı ayarlamak veya belirli hook'ları geçici olarak devre dışı bırakmak için runtime flag'lerini kullanın:
|
||||
|
||||
```bash
|
||||
# Hook sıkılık profili (varsayılan: standard)
|
||||
export ECC_HOOK_PROFILE=standard
|
||||
|
||||
# Devre dışı bırakılacak hook ID'leri (virgülle ayrılmış)
|
||||
export ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📦 İçindekiler
|
||||
|
||||
Bu repo bir **Claude Code plugin'i** - doğrudan kurun veya component'leri manuel olarak kopyalayın.
|
||||
|
||||
```
|
||||
everything-claude-code/
|
||||
|-- .claude-plugin/ # Plugin ve marketplace manifest'leri
|
||||
| |-- plugin.json # Plugin metadata ve component path'leri
|
||||
| |-- marketplace.json # /plugin marketplace add için marketplace kataloğu
|
||||
|
|
||||
|-- agents/ # Delegation için 28 özel subagent
|
||||
| |-- planner.md # Feature implementasyon planlama
|
||||
| |-- architect.md # Sistem tasarım kararları
|
||||
| |-- tdd-guide.md # Test-driven development
|
||||
| |-- code-reviewer.md # Kalite ve güvenlik incelemesi
|
||||
| |-- security-reviewer.md # Güvenlik açığı analizi
|
||||
| |-- build-error-resolver.md
|
||||
| |-- e2e-runner.md # Playwright E2E testing
|
||||
| |-- refactor-cleaner.md # Ölü kod temizleme
|
||||
| |-- doc-updater.md # Dokümantasyon senkronizasyonu
|
||||
| |-- docs-lookup.md # Dokümantasyon/API arama
|
||||
| |-- chief-of-staff.md # İletişim triajı ve taslaklar
|
||||
| |-- loop-operator.md # Otonom loop çalıştırma
|
||||
| |-- harness-optimizer.md # Harness config ayarlama
|
||||
| |-- ve daha fazlası...
|
||||
|
|
||||
|-- skills/ # İş akışı tanımları ve domain bilgisi
|
||||
| |-- coding-standards/ # Dil en iyi uygulamaları
|
||||
| |-- backend-patterns/ # API, veritabanı, caching pattern'leri
|
||||
| |-- frontend-patterns/ # React, Next.js pattern'leri
|
||||
| |-- security-review/ # Güvenlik kontrol listesi
|
||||
| |-- tdd-workflow/ # TDD metodolojisi
|
||||
| |-- continuous-learning/ # Oturumlardan otomatik pattern çıkarma
|
||||
| |-- django-patterns/ # Django pattern'leri
|
||||
| |-- golang-patterns/ # Go deyimleri ve en iyi uygulamalar
|
||||
| |-- ve 100+ daha fazla skill...
|
||||
|
|
||||
|-- commands/ # Hızlı çalıştırma için slash command'lar
|
||||
| |-- tdd.md # /tdd - Test-driven development
|
||||
| |-- plan.md # /plan - Implementasyon planlama
|
||||
| |-- e2e.md # /e2e - E2E test oluşturma
|
||||
| |-- code-review.md # /code-review - Kalite incelemesi
|
||||
| |-- build-fix.md # /build-fix - Build hatalarını düzelt
|
||||
| |-- ve 50+ daha fazla command...
|
||||
|
|
||||
|-- rules/ # Her zaman uyulması gereken kurallar (~/.claude/rules/ içine kopyalayın)
|
||||
| |-- README.md # Yapı genel bakışı ve kurulum rehberi
|
||||
| |-- common/ # Dilden bağımsız prensipler
|
||||
| | |-- coding-style.md # Immutability, dosya organizasyonu
|
||||
| | |-- git-workflow.md # Commit formatı, PR süreci
|
||||
| | |-- testing.md # TDD, %80 coverage gereksinimi
|
||||
| | |-- performance.md # Model seçimi, context yönetimi
|
||||
| | |-- patterns.md # Tasarım pattern'leri
|
||||
| | |-- hooks.md # Hook mimarisi
|
||||
| | |-- agents.md # Ne zaman subagent'lara delege edilmeli
|
||||
| | |-- security.md # Zorunlu güvenlik kontrolleri
|
||||
| |-- typescript/ # TypeScript/JavaScript özel
|
||||
| |-- python/ # Python özel
|
||||
| |-- golang/ # Go özel
|
||||
| |-- swift/ # Swift özel
|
||||
| |-- php/ # PHP özel
|
||||
|
|
||||
|-- hooks/ # Trigger-tabanlı otomasyonlar
|
||||
| |-- hooks.json # Tüm hook'ların config'i
|
||||
| |-- memory-persistence/ # Session lifecycle hook'ları
|
||||
| |-- strategic-compact/ # Compaction önerileri
|
||||
|
|
||||
|-- scripts/ # Çapraz platform Node.js script'leri
|
||||
| |-- lib/ # Paylaşılan yardımcılar
|
||||
| |-- hooks/ # Hook implementasyonları
|
||||
| |-- setup-package-manager.js # Interaktif PM kurulumu
|
||||
|
|
||||
|-- mcp-configs/ # MCP server konfigürasyonları
|
||||
| |-- mcp-servers.json # GitHub, Supabase, Vercel, Railway, vb.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🗺️ Hangi Agent'ı Kullanmalıyım?
|
||||
|
||||
Nereden başlayacağınızdan emin değil misiniz? Bu hızlı referansı kullanın:
|
||||
|
||||
| Yapmak istediğim... | Bu command'ı kullan | Kullanılan agent |
|
||||
|---------------------|---------------------|------------------|
|
||||
| Yeni bir feature planla | `/everything-claude-code:plan "Auth ekle"` | planner |
|
||||
| Sistem mimarisi tasarla | `/everything-claude-code:plan` + architect agent | architect |
|
||||
| Önce testlerle kod yaz | `/tdd` | tdd-guide |
|
||||
| Yazdığım kodu incele | `/code-review` | code-reviewer |
|
||||
| Başarısız bir build'i düzelt | `/build-fix` | build-error-resolver |
|
||||
| End-to-end testler çalıştır | `/e2e` | e2e-runner |
|
||||
| Güvenlik açıklarını bul | `/security-scan` | security-reviewer |
|
||||
| Ölü kodu kaldır | `/refactor-clean` | refactor-cleaner |
|
||||
| Dokümantasyonu güncelle | `/update-docs` | doc-updater |
|
||||
| Go kodu incele | `/go-review` | go-reviewer |
|
||||
| Python kodu incele | `/python-review` | python-reviewer |
|
||||
|
||||
### Yaygın İş Akışları
|
||||
|
||||
**Yeni bir feature başlatma:**
|
||||
```
|
||||
/everything-claude-code:plan "OAuth ile kullanıcı kimlik doğrulaması ekle"
|
||||
→ planner implementasyon planı oluşturur
|
||||
/tdd → tdd-guide önce-test-yaz'ı zorunlu kılar
|
||||
/code-review → code-reviewer çalışmanızı kontrol eder
|
||||
```
|
||||
|
||||
**Bir hatayı düzeltme:**
|
||||
```
|
||||
/tdd → tdd-guide: hatayı yeniden üreten başarısız bir test yaz
|
||||
→ düzeltmeyi uygula, testin geçtiğini doğrula
|
||||
/code-review → code-reviewer: regresyonları yakala
|
||||
```
|
||||
|
||||
**Production'a hazırlanma:**
|
||||
```
|
||||
/security-scan → security-reviewer: OWASP Top 10 denetimi
|
||||
/e2e → e2e-runner: kritik kullanıcı akışı testleri
|
||||
/test-coverage → %80+ coverage doğrula
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ❓ SSS
|
||||
|
||||
<details>
|
||||
<summary><b>Hangi agent/command'ların kurulu olduğunu nasıl kontrol ederim?</b></summary>
|
||||
|
||||
```bash
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
Bu, plugin'den mevcut tüm agent'ları, command'ları ve skill'leri gösterir.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Hook'larım çalışmıyor / "Duplicate hooks file" hatası alıyorum</b></summary>
|
||||
|
||||
Bu en yaygın sorundur. `.claude-plugin/plugin.json`'a bir `"hooks"` alanı **EKLEMEYİN**. Claude Code v2.1+ kurulu plugin'lerden `hooks/hooks.json`'ı otomatik olarak yükler. Açıkça belirtmek duplicate algılama hatalarına neden olur. Bkz. [#29](https://github.com/affaan-m/everything-claude-code/issues/29), [#52](https://github.com/affaan-m/everything-claude-code/issues/52), [#103](https://github.com/affaan-m/everything-claude-code/issues/103).
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Context window'um küçülüyor / Claude context'ten tükeniyor</b></summary>
|
||||
|
||||
Çok fazla MCP server context'inizi tüketiyor. Her MCP tool açıklaması 200k window'unuzdan token tüketir, potansiyel olarak ~70k'ya düşürür.
|
||||
|
||||
**Düzeltme:** Kullanılmayan MCP'leri proje başına devre dışı bırakın:
|
||||
```json
|
||||
// Projenizin .claude/settings.json dosyasında
|
||||
{
|
||||
"disabledMcpServers": ["supabase", "railway", "vercel"]
|
||||
}
|
||||
```
|
||||
|
||||
10'dan az MCP etkin ve 80'den az aktif tool tutun.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Sadece bazı component'leri kullanabilir miyim (örn. sadece agent'lar)?</b></summary>
|
||||
|
||||
Evet. Seçenek 2'yi (manuel kurulum) kullanın ve yalnızca ihtiyacınız olanı kopyalayın:
|
||||
|
||||
```bash
|
||||
# Sadece agent'lar
|
||||
cp everything-claude-code/agents/*.md ~/.claude/agents/
|
||||
|
||||
# Sadece rule'lar
|
||||
cp -r everything-claude-code/rules/common/* ~/.claude/rules/
|
||||
```
|
||||
|
||||
Her component tamamen bağımsızdır.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Bu Cursor / OpenCode / Codex / Antigravity ile çalışır mı?</b></summary>
|
||||
|
||||
Evet. ECC çapraz platformdur:
|
||||
- **Cursor**: `.cursor/` içinde önceden çevrilmiş config'ler. [Cursor IDE Desteği](#cursor-ide-desteği) bölümüne bakın.
|
||||
- **OpenCode**: `.opencode/` içinde tam plugin desteği. [OpenCode Desteği](#-opencode-desteği) bölümüne bakın.
|
||||
- **Codex**: macOS app ve CLI için birinci sınıf destek. PR [#257](https://github.com/affaan-m/everything-claude-code/pull/257)'ye bakın.
|
||||
- **Antigravity**: İş akışları, skill'ler ve `.agent/` içinde düzleştirilmiş rule'lar için sıkı entegre kurulum.
|
||||
- **Claude Code**: Native — bu birincil hedeftir.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Yeni bir skill veya agent'a nasıl katkıda bulunurum?</b></summary>
|
||||
|
||||
[CONTRIBUTING.md](../../CONTRIBUTING.md)'ye bakın. Kısa versiyon:
|
||||
1. Repo'yu fork'layın
|
||||
2. `skills/your-skill-name/SKILL.md` içinde skill'inizi oluşturun (YAML frontmatter ile)
|
||||
3. Veya `agents/your-agent.md` içinde bir agent oluşturun
|
||||
4. Ne yaptığını ve ne zaman kullanılacağını açıklayan net bir açıklamayla PR gönderin
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Testleri Çalıştırma
|
||||
|
||||
Plugin kapsamlı bir test suite içerir:
|
||||
|
||||
```bash
|
||||
# Tüm testleri çalıştır
|
||||
node tests/run-all.js
|
||||
|
||||
# Bireysel test dosyalarını çalıştır
|
||||
node tests/lib/utils.test.js
|
||||
node tests/lib/package-manager.test.js
|
||||
node tests/hooks/hooks.test.js
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🤝 Katkıda Bulunma
|
||||
|
||||
**Katkılar beklenir ve teşvik edilir.**
|
||||
|
||||
Bu repo bir topluluk kaynağı olmayı amaçlar. Eğer şunlara sahipseniz:
|
||||
- Yararlı agent'lar veya skill'ler
|
||||
- Akıllı hook'lar
|
||||
- Daha iyi MCP konfigürasyonları
|
||||
- İyileştirilmiş rule'lar
|
||||
|
||||
Lütfen katkıda bulunun! Rehber için [CONTRIBUTING.md](../../CONTRIBUTING.md)'ye bakın.
|
||||
|
||||
### Katkı Fikirleri
|
||||
|
||||
- Dile özel skill'ler (Rust, C#, Kotlin, Java) — Go, Python, Perl, Swift ve TypeScript zaten dahil
|
||||
- Framework'e özel config'ler (Rails, FastAPI, NestJS) — Django, Spring Boot, Laravel zaten dahil
|
||||
- DevOps agent'ları (Kubernetes, Terraform, AWS, Docker)
|
||||
- Test stratejileri (farklı framework'ler, görsel regresyon)
|
||||
- Domain'e özel bilgi (ML, data engineering, mobile)
|
||||
|
||||
---
|
||||
|
||||
## 📄 Lisans
|
||||
|
||||
MIT - Özgürce kullanın, ihtiyaç duyduğunuz gibi değiştirin, yapabiliyorsanız geri katkıda bulunun.
|
||||
|
||||
---
|
||||
|
||||
**Bu repo size yardımcı olduysa yıldızlayın. Her iki rehberi de okuyun. Harika bir şey yapın.**
|
||||
53
docs/tr/SECURITY.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# Güvenlik Politikası
|
||||
|
||||
## Desteklenen Sürümler
|
||||
|
||||
| Sürüm | Destekleniyor |
|
||||
| ------- | ------------------ |
|
||||
| 1.9.x | :white_check_mark: |
|
||||
| 1.8.x | :white_check_mark: |
|
||||
| < 1.8 | :x: |
|
||||
|
||||
## Güvenlik Açığı Bildirimi
|
||||
|
||||
ECC'de bir güvenlik açığı keşfederseniz, lütfen sorumlu bir şekilde bildirin.
|
||||
|
||||
**Güvenlik açıkları için herkese açık GitHub issue açmayın.**
|
||||
|
||||
Bunun yerine, **security@ecc.tools** adresine aşağıdaki bilgilerle e-posta gönderin:
|
||||
|
||||
- Güvenlik açığının açıklaması
|
||||
- Yeniden oluşturma adımları
|
||||
- Etkilenen sürüm(ler)
|
||||
- Potansiyel etki değerlendirmesi
|
||||
|
||||
Beklentileriniz:
|
||||
|
||||
- 48 saat içinde **onay**
|
||||
- 7 gün içinde **durum güncellemesi**
|
||||
- Kritik sorunlar için 30 gün içinde **düzeltme veya azaltma**
|
||||
|
||||
Güvenlik açığı kabul edilirse:
|
||||
|
||||
- Sürüm notlarında size teşekkür edeceğiz (anonim kalmayı tercih etmiyorsanız)
|
||||
- Sorunu zamanında düzelteceğiz
|
||||
- Açıklama zamanlamasını sizinle koordine edeceğiz
|
||||
|
||||
Güvenlik açığı reddedilirse, nedenini açıklayacağız ve başka bir yere bildirilmesi gerekip gerekmediği konusunda rehberlik sağlayacağız.
|
||||
|
||||
## Kapsam
|
||||
|
||||
Bu politika aşağıdakileri kapsar:
|
||||
|
||||
- ECC eklentisi ve bu depodaki tüm script'ler
|
||||
- Makinenizde çalışan hook script'leri
|
||||
- Install/uninstall/repair yaşam döngüsü script'leri
|
||||
- ECC ile birlikte gelen MCP konfigürasyonları
|
||||
- AgentShield güvenlik tarayıcısı ([github.com/affaan-m/agentshield](https://github.com/affaan-m/agentshield))
|
||||
|
||||
## Güvenlik Kaynakları
|
||||
|
||||
- **AgentShield**: Agent konfigürasyonunuzu güvenlik açıkları için tarayın — `npx ecc-agentshield scan`
|
||||
- **Güvenlik Kılavuzu**: [The Shorthand Guide to Everything Agentic Security](./the-security-guide.md)
|
||||
- **OWASP MCP Top 10**: [owasp.org/www-project-mcp-top-10](https://owasp.org/www-project-mcp-top-10/)
|
||||
- **OWASP Agentic Applications Top 10**: [genai.owasp.org](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)
|
||||