Feature Developer (Genérico)
Descrição
Skill para implementação de features em qualquer tecnologia, preenchendo a lacuna entre o planejamento SDD e a execução de código. Executa tarefas do 03-tasks.md seguindo convenções do projeto, independente de framework ou linguagem.
Quando Usar
- Executar tarefas definidas em
auditoria/03-tasks.md
- Implementar novas features seguindo padrão do projeto
- Criar componentes, services, repositories, stores seguindo convenções
- Desenvolver páginas, formulários, listas, detalhes
- Implementar camada de infraestrutura (API, interceptors, middleware)
- Criar módulos de domínio (DDD)
- Qualquer tarefa de codificação que venha do SDD
Pré-Requisitos (OBRIGATÓRIO)
- Ler regras (global e local)
- Ler convenções do projeto (CONVENTIONS.MD, .editorconfig, ou equivalente)
- Ler
auditoria/02-architecture.md (plano aprovado)
- Ler
auditoria/03-tasks.md (tarefas a executar)
- Identificar padrão existente do projeto
Fluxo de Execução
Para Cada Tarefa do 03-tasks.md
- Marcar como
[~] (em andamento)
- Ler contexto da tarefa (arquitetura, dependências)
- Verificar padrão existente no projeto
- Implementar seguindo convenções
- Marcar como
[x] (concluída)
- Validar com checklist
Detecção Automática de Framework
Ao iniciar, detectar o stack do projeto:
Frontend
| Stack |
Arquivo de Detecção |
Padrão Esperado |
| Angular |
angular.json, @angular/ |
Components, Services, Modules, Standalone |
| React |
package.json + react |
Components, Hooks, Context |
| Vue |
vue.config.js ou @vue/ |
SFC, Composables, Stores |
| Svelte |
svelte.config.js |
Stores, Actions, Transitions |
| HTML/CSS/JS puro |
Sem framework |
Components vanilla, Modules ES6 |
Backend
| Stack |
Arquivo de Detecção |
Padrão Esperado |
| Node/Express |
package.json + express |
Routes, Controllers, Services, Middleware |
| NestJS |
nest-cli.json |
Modules, Controllers, Providers, Guards |
| Python/Django |
manage.py |
Views, Models, Serializers, URLs |
| Python/Flask |
app.py ou wsgi.py |
Routes, Services, Models |
| Java/Spring |
pom.xml ou build.gradle |
Controllers, Services, Repositories, Entities |
| Go |
go.mod |
Handlers, Services, Repositories |
| Rust |
Cargo.toml |
Handlers, Services, Models |
| .NET |
*.csproj |
Controllers, Services, Repositories |
| PHP/Laravel |
artisan |
Controllers, Models, Services, Repositories |
Mobile
| Stack |
Arquivo de Detecção |
Padrão Esperado |
| Flutter |
pubspec.yaml |
Widgets, Services, Models |
| React Native |
package.json + react-native |
Components, Hooks, Services |
| Swift/iOS |
*.xcodeproj |
Views, ViewModels, Services |
| Kotlin/Android |
build.gradle |
Activities, Fragments, ViewModels, Repositories |
Padrões por Tipo de Arquivo
Componente (Frontend)
Padrão: Componente pequeno, focado, sem lógica de negócio
Estrutura típica:
- [name].component.{ts,tsx,vue,svelte} → Lógica
- [name].component.{html,jsx,template} → Template
- [name].component.scss → Estilos (SEMPRE SCSS regular)
- [name].component.spec.{ts,tsx} → Testes
Service/Repository (Backend)
Padrão: Separar lógica de negócio da infraestrutura
Estrutura típica:
- [domain].service.{ts,py,java,go} → Lógica de negócio
- [domain].repository.{ts,py,java,go} → Acesso a dados
- [domain].controller.{ts,py,java,go} → Endpoints/Rotas
- [domain].model.{ts,py,java,go} → Modelos/Entidades
Padrão de Comunicação
FRONTEND:
UI Component → Container/Smart Component → Service → API
BACKEND:
Route/Endpoint → Controller → Service → Repository → Database
MOBILE:
View → ViewModel → Service → Repository → API
Convenções de Nomenclatura (Adaptativas)
Regra principal: Seguir o padrão JÁ EXISTENTE no projeto.
| Contexto |
Verificar |
Exemplo padrão |
| Arquivos |
.editorconfig, lint config |
kebab-case, camelCase, PascalCase |
| Classes |
Código existente |
PascalCase, snake_case |
| Funções/Métodos |
Código existente |
camelCase, snake_case |
| Variáveis |
Código existente |
camelCase, snake_case |
| Constantes |
Código existente |
UPPER_SNAKE_CASE, camelCase |
NÃO forçar padrão Angular/React/etc se o projeto usar outro.
Checklist de Implementação
Antes de começar:
Durante a implementação:
Depois de implementar:
Regras
- SEMPRE ler
02-architecture.md antes de começar
- SEMPRE seguir o padrão EXISTENTE do projeto (não inventar)
- SEMPRE detectar framework automaticamente antes de codar
- SEMPRE marcar tarefas no
03-tasks.md durante execução
- NUNCA forçar padrão Angular/React/etc se o projeto usar outra coisa
- NUNCA criar módulo/classe sem responsabilidade única
- NUNCA pular etapas do checklist
- NUNCA inventar convenções que não existem no projeto
- ADAPTAR os templates acima conforme o framework detectado
1---2name: feature-developer3description: Use quando o usuário pedir para implementar features, executar tarefas SDD, desenvolver componentes seguindo convenções do projeto ou criar código seguindo o padrão Feature First em qualquer framework.4---56# Feature Developer (Genérico)78## Descrição910Skill para implementação de features em qualquer tecnologia, preenchendo a lacuna entre o planejamento SDD e a execução de código. Executa tarefas do `03-tasks.md` seguindo convenções do projeto, independente de framework ou linguagem.1112## Quando Usar1314- Executar tarefas definidas em `auditoria/03-tasks.md`15- Implementar novas features seguindo padrão do projeto16- Criar componentes, services, repositories, stores seguindo convenções17- Desenvolver páginas, formulários, listas, detalhes18- Implementar camada de infraestrutura (API, interceptors, middleware)19- Criar módulos de domínio (DDD)20- Qualquer tarefa de codificação que venha do SDD2122## Pré-Requisitos (OBRIGATÓRIO)23241. **Ler regras** (global e local)252. **Ler convenções do projeto** (CONVENTIONS.MD, .editorconfig, ou equivalente)263. **Ler `auditoria/02-architecture.md`** (plano aprovado)274. **Ler `auditoria/03-tasks.md`** (tarefas a executar)285. **Identificar padrão existente** do projeto2930## Fluxo de Execução3132### Para Cada Tarefa do 03-tasks.md33341. **Marcar como `[~]`** (em andamento)352. **Ler contexto** da tarefa (arquitetura, dependências)363. **Verificar padrão** existente no projeto374. **Implementar** seguindo convenções385. **Marcar como `[x]`** (concluída)396. **Validar** com checklist4041## Detecção Automática de Framework4243Ao iniciar, detectar o stack do projeto:4445### Frontend4647| Stack | Arquivo de Detecção | Padrão Esperado |48|-------|---------------------|-----------------|49| **Angular** | `angular.json`, `@angular/` | Components, Services, Modules, Standalone |50| **React** | `package.json` + `react` | Components, Hooks, Context |51| **Vue** | `vue.config.js` ou `@vue/` | SFC, Composables, Stores |52| **Svelte** | `svelte.config.js` | Stores, Actions, Transitions |53| **HTML/CSS/JS puro** | Sem framework | Components vanilla, Modules ES6 |5455### Backend5657| Stack | Arquivo de Detecção | Padrão Esperado |58|-------|---------------------|-----------------|59| **Node/Express** | `package.json` + `express` | Routes, Controllers, Services, Middleware |60| **NestJS** | `nest-cli.json` | Modules, Controllers, Providers, Guards |61| **Python/Django** | `manage.py` | Views, Models, Serializers, URLs |62| **Python/Flask** | `app.py` ou `wsgi.py` | Routes, Services, Models |63| **Java/Spring** | `pom.xml` ou `build.gradle` | Controllers, Services, Repositories, Entities |64| **Go** | `go.mod` | Handlers, Services, Repositories |65| **Rust** | `Cargo.toml` | Handlers, Services, Models |66| **.NET** | `*.csproj` | Controllers, Services, Repositories |67| **PHP/Laravel** | `artisan` | Controllers, Models, Services, Repositories |6869### Mobile7071| Stack | Arquivo de Detecção | Padrão Esperado |72|-------|---------------------|-----------------|73| **Flutter** | `pubspec.yaml` | Widgets, Services, Models |74| **React Native** | `package.json` + `react-native` | Components, Hooks, Services |75| **Swift/iOS** | `*.xcodeproj` | Views, ViewModels, Services |76| **Kotlin/Android** | `build.gradle` | Activities, Fragments, ViewModels, Repositories |7778## Padrões por Tipo de Arquivo7980### Componente (Frontend)8182```83Padrão: Componente pequeno, focado, sem lógica de negócio8485Estrutura típica:86- [name].component.{ts,tsx,vue,svelte} → Lógica87- [name].component.{html,jsx,template} → Template88- [name].component.scss → Estilos (SEMPRE SCSS regular)89- [name].component.spec.{ts,tsx} → Testes90```9192### Service/Repository (Backend)9394```95Padrão: Separar lógica de negócio da infraestrutura9697Estrutura típica:98- [domain].service.{ts,py,java,go} → Lógica de negócio99- [domain].repository.{ts,py,java,go} → Acesso a dados100- [domain].controller.{ts,py,java,go} → Endpoints/Rotas101- [domain].model.{ts,py,java,go} → Modelos/Entidades102```103104### Padrão de Comunicação105106```107FRONTEND:108UI Component → Container/Smart Component → Service → API109110BACKEND:111Route/Endpoint → Controller → Service → Repository → Database112113MOBILE:114View → ViewModel → Service → Repository → API115```116117## Convenções de Nomenclatura (Adaptativas)118119**Regra principal:** Seguir o padrão JÁ EXISTENTE no projeto.120121| Contexto | Verificar | Exemplo padrão |122|----------|-----------|----------------|123| **Arquivos** | `.editorconfig`, lint config | kebab-case, camelCase, PascalCase |124| **Classes** | Código existente | PascalCase, snake_case |125| **Funções/Métodos** | Código existente | camelCase, snake_case |126| **Variáveis** | Código existente | camelCase, snake_case |127| **Constantes** | Código existente | UPPER_SNAKE_CASE, camelCase |128129**NÃO forçar padrão Angular/React/etc se o projeto usar outro.**130131## Checklist de Implementação132133### Antes de começar:134- [ ] Li o `02-architecture.md`135- [ ] Li o `03-tasks.md`136- [ ] Identifiquei o framework/linguagem do projeto137- [ ] Identifiquei o padrão de estrutura de pastas138- [ ] Identifiquei convenções de nomenclatura139- [ ] Entendi as dependências140141### Durante a implementação:142- [ ] Sigo a estrutura de pastas do projeto143- [ ] Uso o padrão de componentes/classes do projeto144- [ ] Sigo a convenção de nomenclatura existente145- [ ] Sigo o padrão de comunicação (Service → Repository, etc)146- [ ] Implemento testes no padrão do projeto147- [ ] Não invento padrões novos148149### Depois de implementar:150- [ ] Código é pequeno e focado (responsabilidade única)151- [ ] Templates/Views são semânticos152- [ ] Estilos seguem o padrão do projeto153- [ ] Sem tipos implícitos (`any`, `var`, etc)154- [ ] Testes escritos155- [ ] Lint/build passa156157## Regras158159- **SEMPRE** ler `02-architecture.md` antes de começar160- **SEMPRE** seguir o padrão EXISTENTE do projeto (não inventar)161- **SEMPRE** detectar framework automaticamente antes de codar162- **SEMPRE** marcar tarefas no `03-tasks.md` durante execução163- **NUNCA** forçar padrão Angular/React/etc se o projeto usar outra coisa164- **NUNCA** criar módulo/classe sem responsabilidade única165- **NUNCA** pular etapas do checklist166- **NUNCA** inventar convenções que não existem no projeto167- **ADAPTAR** os templates acima conforme o framework detectado
Rodrigos-dev