backend-code-review
🎯Skillfrom dauquangthanh/hanoi-rainbow
|Reviews backend code for potential issues, best practices, and code quality using AI-powered analysis within the Hanoi Rainbow spec-driven development framework.
Installation
npx skills add https://github.com/dauquangthanh/hanoi-rainbow --skill backend-code-reviewSkill Details
Overview
# 🌈 Hanoi Rainbow
*Drive Quality Together with AI-Powered Framework*
Stop guessing. Start specifying.
Turn your ideas into production-ready applications through clear specifications, not trial-and-error coding.
[](https://github.com/dauquangthanh/hanoi-rainbow/actions/workflows/release.yml)
[](https://github.com/dauquangthanh/hanoi-rainbow/stargazers)
[](https://github.com/dauquangthanh/hanoi-rainbow/blob/main/LICENSE)
[](https://dauquangthanh.github.io/hanoi-rainbow/)
---
Table of Contents
- [🤔 What is Spec-Driven Development?](#-what-is-spec-driven-development)
- [⚡ Get Started](#quick-start)
- [🤖 Supported AI Agents](#-supported-ai-agents)
- [🔧 Rainbow CLI Reference](#-rainbow-cli-reference)
- [📚 Core Philosophy](#spec-driven-development-sdd)
- [🌟 Development Phases](#-development-phases)
- [🔧 Prerequisites](#-prerequisites)
- [📖 Learn More](#-learn-more)
- [📋 Detailed Process](#-detailed-process)
- [🔍 Troubleshooting](#-troubleshooting)
- [👥 Maintainers](#-maintainers)
- [💬 Support](#-support)
- [🙏 Acknowledgements](#-acknowledgements)
- [📄 License](#-license)
💡 What is Spec-Driven Development?
Traditional approach: Write code first, figure it out as you go.
Spec-Driven approach: Define what you want first, then let AI build it right.
For decades, we treated specifications as throwaway notes—just a formality before the "real" coding began. Spec-Driven Development flips this around: your specification becomes the blueprint that directly generates working code, not just a suggestion.
> Think of it like architecture: You wouldn't build a house without blueprints. Why build software without clear specifications?
Development Approaches
Hanoi Rainbow supports both Greenfield (new projects) and Brownfield (existing projects) development:
```mermaid
flowchart LR
Start([Project Type?])
Start --> Greenfield[🌱 Greenfield
New Project]
Start --> Brownfield[🏗️ Brownfield
Existing Project]
Greenfield --> GF1[📋 Regulate
Set Principles]
GF1 --> GF2[🎯 Specify
Define Features]
GF2 --> GF3[🔍 Clarify
Refine Requirements]
GF3 --> GF4[📝 Architect
System Design]
GF4 --> GF5[📏 Standardize
Coding Rules]
GF5 --> GF6[🛠️ Design
Technical Plan]
GF6 --> GF7[📋 Taskify
Break Down Tasks]
GF7 --> GF8[⚡ Implement
Build Features]
GF8 --> GF9[✅ Test & Deploy]
Brownfield --> BF1[📚 Assess Context
Analyze Codebase]
BF1 --> BF2[📋 Regulate
Update Principles]
BF2 --> BF3[🎯 Specify
New Feature]
BF3 --> BF4[🔍 Clarify
Requirements]
BF4 --> BF5[🛠️ Design
Integration Plan]
BF5 --> BF6[📋 Taskify
Task Breakdown]
BF6 --> BF7[⚡ Implement
Add Feature]
BF7 --> BF8[✅ Test & Deploy]
style Greenfield fill:#90EE90
style Brownfield fill:#87CEEB
style GF8 fill:#FFD700
style BF7 fill:#FFD700
```
Greenfield projects start with establishing principles, architecture, and standards before building features. Brownfield projects begin with /rainbow.assess-context to understand existing architecture and patterns, then follow a streamlined workflow to add new features while maintaining consistency.
Key Differences:
| Aspect | 🌱 Greenfield | 🏗️ Brownfield |
|--------|--------------|---------------|
| Starting Point | Empty project | Existing codebase |
| Setup Phase | /rainbow.regulate | /rainbow.assess-context (once per project) |
| Focus | Establish foundations first | Integrate with existing patterns |
| Timeline | 2-4 weeks (MVP