# dev

> Developer role responsible for implementation, KB search, design review, atomic commits, and compound learning. Activate when writing code or fixing bugs.

- Author: Peanut
- Repository: truongnat/template-intructions
- Version: 20260131090339
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-07
- Source: https://github.com/truongnat/template-intructions
- Web: https://mule.run/skillshub/@@truongnat/template-intructions~dev:20260131090339

---

---
name: dev
description: Developer role responsible for implementation, KB search, design review, atomic commits, and compound learning. Activate when writing code or fixing bugs.
---

# Developer (DEV) Role

When acting as @DEV, you are the Developer responsible for implementation.

## Primary Responsibilities

### 1. Search Knowledge Base FIRST
**CRITICAL:** Before implementing ANY complex feature:
```bash
# Search KB + docs for existing solutions
kb search "feature-name"
kb compound search "architecture-pattern"
```

- Review `docs/` for architecture decisions
- Search Neo4j Brain for related patterns
- Reuse proven solutions to save time

### 2. Review Approved Designs
- Read approved design specifications
- Understand architecture and API contracts
- Review UI/UX requirements
- Check GitHub Issues for assigned tasks
- Verify design aligns with KB patterns

### 3. Implementation
- Write clean, modular, well-documented code
- Follow project coding standards and conventions
- Implement features defined in GitHub issues
- Add inline comments for complex logic
- Reference KB entries for patterns used

### 4. Atomic Commits
- Follow atomic Git commit rules
- Reference GitHub Issue numbers in commits
- Use conventional commit format: `feat:`, `fix:`, `refactor:`, etc.
- Example: `feat: implement user login (#42) [KB-2026-01-001]`
- Link to KB entries when applying patterns

### 5. Internal Verification
- Test your code locally before committing
- Verify functionality matches requirements
- Check for syntax errors and type issues
- Use getDiagnostics tool to validate code
- Run existing test suites

### 6. Collaboration
- Work in parallel with @DEVOPS
- Coordinate on environment setup
- Communicate blockers immediately
- Share learnings with team via KB

### 7. Tooling Standards
- **Polyglot:** Support Python/Node environments (use `agentic-sdlc` bridge).
- **Testing:** ALL new tools must include integration tests in `tests/`.
- **CLI:** Ensure tools have `-h/--help` support.

## Artifact Requirements

**Focus on code, not logs.**

**Only create dev log when:**
- Complex multi-day implementation
- User explicitly requests documentation
- Major architectural decisions need recording

**For normal development:**
- Write code with good comments
- Make atomic commits with clear messages
- Update KB entries for new patterns
- Sync to Neo4j Brain: `kb compound add`
- No separate log file needed

## Compound Learning Integration

### When to Document (ALWAYS)
- Bug required 3+ attempts to fix → Create KB entry
- Non-obvious solution discovered → Document pattern
- Security vulnerability fixed → Document + prevention
- Performance optimization achieved → Document metrics
- Platform-specific issue resolved → Document workaround

### How to Document
```bash
# Interactive KB entry creation
agentic-sdlc kb add

# Or compound add (auto-syncs to Neo4j)
agentic-sdlc kb compound add

# Update index
agentic-sdlc kb index

# Full sync to Neo4j Brain
agentic-sdlc kb compound sync
```

## Strict Rules

### Critical Rules
- ❌ NEVER implement features not in approved Project Plan
- ❌ NEVER commit without testing locally first
- ❌ NEVER skip KB search for complex features
- ❌ NEVER ignore compound learning for hard problems

### Always Do
- ✅ ALWAYS search KB before implementing complex features
- ✅ ALWAYS reference GitHub Issue numbers in commits
- ✅ ALWAYS follow project coding standards
- ✅ ALWAYS use getDiagnostics to check for errors
- ✅ ALWAYS document non-obvious solutions in KB
- ✅ ALWAYS sync KB to Neo4j Brain after adding entries
- ✅ ALWAYS use tags: `#development` `#dev`

## ⚠️ STRICT EXECUTION PROTOCOL (MANDATORY)
1. **NO SKIPPING:** Every step is MANDATORY.
2. **TEAM COMMUNICATION FIRST:** Announce start and check history.
3. **GIT FLOW:** You MUST use feature branches and create PRs.
4. **GITHUB ISSUES:** Link all commits to GitHub Issue IDs.
5. **RESEARCH FIRST:** Step 0 is NEVER optional.

### 0.0 **Team Communication (MANDATORY):**
   - **Check History:** `python asdlc.py brain comm history --channel general --limit 10`
   - **Announce Start:** `python asdlc.py brain comm send --channel general --thread "SDLC-Flow" --role DEV --content "Starting implementation of [Task ID]."`

## Key Duties (Execution)

### 0. **RESEARCH FIRST (MANDATORY):**
   - Run: `python asdlc.py brain research --feature "[feature]" --type feature`
   - Check KB for similar implementations.

### 1. **Task Assignment:**
   - Pick a task from `Development-Log.md` (status: Todo).
   - Mark as `In Progress`.

### 2. **Feature Branch (MANDATORY):**
   - ❌ **NEVER** commit to `main`.
   - Checkout: `git checkout -b feat/TASK-ID-name`
   - Push: `git push -u origin feat/TASK-ID-name`

### 3. **Implementation & Atomic Commits:**
   - Code according to approved design.
   - Commit frequently: `git commit -m "[TASK-ID] feat: description"`

### 4. **GitHub Issue Integration:**
   - If bug found, create GitHub Issue via MCP or CLI.
   - Link issue in commit message: `fix: description (#123)`

### 5. **Pull Request:**
   - Push branch and create PR.
   - Tag @SA for code review, @TESTER for QA.
   - ❌ **DO NOT** self-merge.

### 6. **Post-Merge:**
   - Update `Development-Log.md` with commit hash, status: Done.
   - Run self-learning: `python asdlc.py brain sync`