Dev Swarm Code Development

AI Builder - Code Development

This skill implements backlogs through a structured feature-driven approach. As a Software Engineer expert, you'll read backlog requirements, reference existing features, design implementation approach, write code, and create comprehensive documentation for the features knowledge base.

When to Use This Skill

• User asks to implement a backlog
• User requests to complete a feature, change, bug fix, or improvement
• User says "develop backlog X"
• User wants to implement work from sprint
• User asks to code a specific backlog item

Prerequisites

This skill requires:

• 04-prd/ - Product Requirements Document (business requirements and acceptance criteria)
• 07-tech-specs/ - Engineering standards and constraints
• 09-sprints/ folder with active sprint and backlogs
• features/ folder with features-index.md (existing features knowledge base)
• Understanding of the backlog type: FEATURE, CHANGE, BUG, or IMPROVE

Feature-Driven Development Workflow

CRITICAL: This skill follows a strict feature-driven approach where feature-name is the index for the entire project:

For Each Backlog:

1. Read backlog from 09-sprints/SPRINT-XX-descriptive-name/[BACKLOG_TYPE]-XX-[feature-name]-<sub-feature>.md
2. Extract the feature-name from the backlog file name
3. Read features/features-index.md to find the feature file
4. Read feature documentation in this order:
   • features/[feature-name].md - Feature definition (WHAT/WHY/SCOPE)
   • features/flows/[feature-name].md - User flows and process flows (if exists)
   • features/contracts/[feature-name].md - API/data contracts (if exists)
   • features/impl/[feature-name].md - Implementation notes (if exists)
5. Locate source code at src/ using features/impl/[feature-name].md
6. Implement the code following 07-tech-specs/
7. Update backlog with development notes

This approach ensures AI developers can work on large projects without reading all code at once.

Your Roles in This Skill

See dev-swarm/docs/general-dev-stage-rule.md for role selection guidance.

Role Communication

See dev-swarm/docs/general-dev-stage-rule.md for the required role announcement format.

Instructions

Follow these steps in order for coding development:

Step 0: Verify Prerequisites and Gather Context

IMPORTANT: Follow this exact order to efficiently locate all relevant context:

1. Identify the backlog:

   • User specifies which backlog to work on
   • Or you select next backlog from 09-sprints/ in order

   09-sprints/
   └── SPRINT-XX-descriptive-name/
       └── [BACKLOG_TYPE]-XX-[feature-name]-<sub-feature>.md
   

   • Locate the sprint README at 09-sprints/SPRINT-XX-descriptive-name/README.md for required progress log updates

2. Read the backlog file:

   • Understand task description and requirements
   • Note backlog type (FEATURE/CHANGE/BUG/IMPROVE)
   • Extract the feature-name from the file name (CRITICAL)
   • Verify Feature Name in backlog metadata matches the file name
   • If they do not match, stop and ask the user to confirm the correct feature name
   • Review test plan requirements
   • Identify acceptance criteria

3. Read source code structure standards:

   • Read dev-swarm/docs/source-code-structure.md for general guidelines
   • Note file naming conventions and directory structure

4. Read PRD and tech specs:

   • Read 04-prd/ (all markdown files) - Product requirements and acceptance criteria for the feature
   • Read 07-tech-specs/ (all markdown files) - Technical specifications and engineering standards
   • Understand the business context and technical constraints

5. Read feature documentation (using feature-name as index):

   • Read features/features-index.md to confirm feature exists
   • Read features/[feature-name].md - Feature definition (WHAT/WHY/SCOPE)
   • Read features/flows/[feature-name].md - User flows (if exists)
   • Read features/contracts/[feature-name].md - API contracts (if exists)
   • Read features/impl/[feature-name].md - Implementation notes (if exists)

6. Locate existing source code:

   • Use features/impl/[feature-name].md to find code locations
   • Navigate to src/ directory
   • Review existing code structure and patterns
   • Identify files to modify (CHANGE/BUG/IMPROVE) or create (FEATURE)

7. Understand codebase patterns:

   • Review existing code in src/ using locations from features/impl/[feature-name].md
   • Note architectural patterns and integration points

DO NOT read the entire codebase. Use features/impl/[feature-name].md to find only relevant files in src/.

Step 1: Design the Implementation

Before writing code, create the feature design document:

1. Create/Update file features/{feature-name}.md

   • If backlog type is feature and the related feature file is not exist, create new feature file
   • If backlog type is change/bug/improve or the feature file is exist, update existing feature file
   • Use the provided templates for consistency

2. Create/update flow and contract files if it is needed

   • features/flows/{feature-name}.md - User flows and process flows (when needed)
   • features/contracts/{feature-name}.md - API contracts and interfaces (when needed)

3. Present design to user for approval

   • Show the feature design document
   • Explain approach and rationale
   • Highlight any assumptions or decisions
   • Wait for user confirmation before proceeding

Step 2: Implement the Code (After User Confirms)

Once user approves the design:

1. Organize code in src/:

   • Follow dev-swarm/docs/source-code-structure.md for file organization guidelines
   • Place code in appropriate locations within src/
   • Use file naming conventions defined in source-code-structure.md

2. Write the code:

   • Implement according to the approved design
   • Follow coding standards
   • Write clean, modular, maintainable code
   • Include appropriate error handling
   • Avoid over-engineering (keep it simple)

3. Code quality guidelines:

   • Modular: Break code into small, focused functions/components
   • Readable: Clear variable names, self-documenting code
   • Simple: Don't add features not in requirements
   • Consistent: Match style of existing codebase
   • Secure: No XSS, SQL injection, command injection, or OWASP vulnerabilities
   • Tested: Code should be testable per backlog test plan

4. What NOT to do:

   • Don't add extra features beyond requirements
   • Don't over-abstract or create unnecessary helpers
   • Don't add comments to code you didn't change
   • Don't refactor code outside scope of backlog
   • Don't add hypothetical error handling
   • Don't create backwards-compatibility hacks

5. For different backlog types:

   Feature (new functionality):

   • Create new files/components
   • Integrate with existing system
   • Follow established patterns

   Change (modify existing feature):

   • Update existing code
   • Maintain compatibility where needed
   • Update related code if necessary

   Bug (fix defect):

   • Fix the specific issue
   • Avoid changing unrelated code
   • Verify fix matches test plan

   Improve (optimize existing code):

   • Refactor/optimize as specified
   • Maintain same functionality
   • Document performance improvements

Step 3: Create Implementation Documentation

After code is complete, create implementation documentation:

1. Create features/impl/{feature-name}.md

   Files Changed:

   • List all files created or modified
   • For each file, note key changes
   • Use file paths, function names as keywords (NOT line numbers)

   Implementation Details:

   • Describe how the feature was implemented
   • Key functions/components created
   • Integration points with other features
   • Any important implementation decisions

   Code Structure:

   • Directory organization
   • Module/component breakdown
   • Dependencies added

   Key Functions/APIs:

   • List important functions with descriptions
   • Document key API endpoints
   • Note important classes/components

   Reference for Developers:

   • Quick keywords for code search
   • How to find relevant code
   • Common use patterns

2. Update features/{feature-name}.md if needed

   • Add any insights discovered during implementation
   • Note if actual implementation differs from design (explain why)
   • Keep it synchronized with current code

3. Update features/features-index.md if needed

4. Update or create src/README.md (Project Documentation):

   • IMPORTANT: Developers should maintain project documentation in src/README.md, NOT in the root README.md
   • Add or update feature documentation:
     • Feature overview and purpose
     • Installation and setup instructions
     • Usage examples and API documentation
     • Configuration options
     • Troubleshooting tips
   • Keep src/README.md as the primary technical reference for developers
   • Include links to features/ documentation for detailed specs

Step 4: Verify Against Test Plan

Before marking complete:

1. Review backlog test plan:

   • Ensure code meets all test requirements
   • Verify acceptance criteria are met

2. Self-test (if possible):

   • Run the code
   • Test key functionality
   • Verify no obvious errors

3. Document test status:

   • Note if manual testing was done
   • List any test results
   • Flag anything needing QA attention

Step 5: Update Backlog with Development Notes

CRITICAL: Update the backlog.md file to track development progress:

1. Update backlog status:

   • Change status from "Not Started" to "In Code Review"
   • Add a "Development Notes" section if not present

2. Document development findings:

   • Files Created/Modified: List all files changed with brief descriptions
   • Implementation Approach: Summarize how requirements were implemented
   • Key Decisions: Note any important technical decisions made
   • Integration Points: Document how code integrates with other features
   • Known Issues: Flag any potential issues for code review
   • Test Notes: Any preliminary testing done during development

3. Reference documentation created:

   • Link to features/[feature-name].md
   • Link to features/impl/[feature-name].md
   • Link to source code files in src/ (locations documented in features/impl/[feature-name].md)

4. Notify user:

   • Summarize what was implemented
   • Reference documentation created
   • Note any important decisions or tradeoffs
   • Suggest next step: "Ready for code review"

5. Update sprint README (README.md) (CRITICAL):

   • Update backlog status in the sprint backlog table
   • Append a log entry in the sprint progress log for the Development step

These backlog.md and sprint README updates create the audit trail for code review and testing phases.

Expected File Structure

project-root/
├── 09-sprints/
│   └── SPRINT-XX-descriptive-name/
│       └── [BACKLOG_TYPE]-XX-[feature-name]-<sub-feature>.md # Backlog entry point
│
├── features/                                # Features knowledge base
│   ├── features-index.md                   # Index of all features
│   ├── [feature-name].md                   # Feature definition (WHAT/WHY/SCOPE)
│   ├── flows/
│   │   └── [feature-name].md               # User flows (if needed)
│   ├── contracts/
│   │   └── [feature-name].md               # API contracts (if needed)
│   └── impl/
│       └── [feature-name].md               # Implementation notes (code locations)
│
└── src/                                     # Source code
    ├── README.md                            # Project documentation (maintained by developers)
    └── [organized per dev-swarm/docs/source-code-structure.md guidelines]

File Templates

1. features-index.md

# Features Index

- [feature name a](feature-name-a.md)
- [feature name b](feature-name-b.md)

2. feature.md

# Title

## Description

[The overview for this feature's implementation, for approval, codeo review, trouble shooting or further development]

## References
The details of this feature's implementation

* [flow](flows/feature-name.md)
* [contract](contracts/feature-name.md)
* [Implement](impl/feature-name.md)

3. flows/feature-name.md - help to understand the code logic

   • User flow diagrams (mermaid)
   • Process flows and sequence diagrams
   • State transitions
   • Integration flows

4. contracts/feature-name.md - the interface between services, pacakges, workflows

   • REST API used or endpoint definitions
   • Request/response schemas
   • Data models and database schemas
   • Event contracts

5. impl/feature-name.md - help to find the code location in the source code file for codeo review, trouble shooting or further development

   • searchable keywords - function name, class name, even comment text in the file
   • file path
   • Dependencies and integration details
   • Avoid citing line numbers in the code file as any code change will affect the line numbers