# Feature Developer

> 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.

- Skill: `rodrigos-dev/feature-developer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rodrigos-dev/feature-developer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rodrigos-dev/feature-developer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Rodrigos-dev (https://skillmd.com/u/rodrigos-dev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/rodrigos-dev/feature-developer

---


# 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)

1. **Ler regras** (global e local)
2. **Ler convenções do projeto** (CONVENTIONS.MD, .editorconfig, ou equivalente)
3. **Ler `auditoria/02-architecture.md`** (plano aprovado)
4. **Ler `auditoria/03-tasks.md`** (tarefas a executar)
5. **Identificar padrão existente** do projeto

## Fluxo de Execução

### Para Cada Tarefa do 03-tasks.md

1. **Marcar como `[~]`** (em andamento)
2. **Ler contexto** da tarefa (arquitetura, dependências)
3. **Verificar padrão** existente no projeto
4. **Implementar** seguindo convenções
5. **Marcar como `[x]`** (concluída)
6. **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:
- [ ] Li o `02-architecture.md`
- [ ] Li o `03-tasks.md`
- [ ] Identifiquei o framework/linguagem do projeto
- [ ] Identifiquei o padrão de estrutura de pastas
- [ ] Identifiquei convenções de nomenclatura
- [ ] Entendi as dependências

### Durante a implementação:
- [ ] Sigo a estrutura de pastas do projeto
- [ ] Uso o padrão de componentes/classes do projeto
- [ ] Sigo a convenção de nomenclatura existente
- [ ] Sigo o padrão de comunicação (Service → Repository, etc)
- [ ] Implemento testes no padrão do projeto
- [ ] Não invento padrões novos

### Depois de implementar:
- [ ] Código é pequeno e focado (responsabilidade única)
- [ ] Templates/Views são semânticos
- [ ] Estilos seguem o padrão do projeto
- [ ] Sem tipos implícitos (`any`, `var`, etc)
- [ ] Testes escritos
- [ ] Lint/build passa

## 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