Initial commit
This commit is contained in:
23
commands/apidog.md
Normal file
23
commands/apidog.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
name: apidog
|
||||
description: Synchronize API specifications with Apidog. Analyzes existing schemas, creates OpenAPI specs, and imports them to your Apidog project.
|
||||
---
|
||||
|
||||
You must use the Task tool to launch the **apidog** agent to handle this request.
|
||||
|
||||
The apidog agent will:
|
||||
1. Verify APIDOG_PROJECT_ID environment variable is set
|
||||
2. Fetch current API specification from Apidog
|
||||
3. Analyze existing schemas and identify reuse opportunities
|
||||
4. Create a new OpenAPI specification with proper schema references
|
||||
5. Save the spec to a temporary directory
|
||||
6. Import the spec to Apidog
|
||||
7. Provide a validation URL and summary
|
||||
|
||||
**Important**: This command requires the following environment variables:
|
||||
- `APIDOG_PROJECT_ID`: Your Apidog project ID
|
||||
- `APIDOG_API_TOKEN`: Your Apidog API token
|
||||
|
||||
If these are not set, the agent will guide you on how to configure them.
|
||||
|
||||
Launch the apidog agent now with the user's request.
|
||||
513
commands/implement-api.md
Normal file
513
commands/implement-api.md
Normal file
@@ -0,0 +1,513 @@
|
||||
---
|
||||
description: Full-cycle API implementation with multi-agent orchestration, architecture planning, implementation, testing, and quality gates
|
||||
allowed-tools: Task, AskUserQuestion, Bash, Read, TodoWrite, Glob, Grep
|
||||
---
|
||||
|
||||
## Mission
|
||||
|
||||
Orchestrate a complete API feature implementation workflow using specialized agents with built-in quality gates and feedback loops. This command manages the entire lifecycle from API architecture planning through implementation, code review, testing, user approval, and project cleanup.
|
||||
|
||||
## CRITICAL: Orchestrator Constraints
|
||||
|
||||
**You are an ORCHESTRATOR, not an IMPLEMENTER.**
|
||||
|
||||
**✅ You MUST:**
|
||||
- Use Task tool to delegate ALL implementation work to agents
|
||||
- Use Bash to run git commands (status, diff, log)
|
||||
- Use Read/Glob/Grep to understand context
|
||||
- Use TodoWrite to track workflow progress
|
||||
- Use AskUserQuestion for user approval gates
|
||||
- Coordinate agent workflows and feedback loops
|
||||
|
||||
**❌ You MUST NOT:**
|
||||
- Write or edit ANY code files directly (no Write, no Edit tools)
|
||||
- Implement features yourself
|
||||
- Fix bugs yourself
|
||||
- Create new files yourself
|
||||
- Modify existing code yourself
|
||||
- "Quickly fix" small issues - always delegate to backend-developer
|
||||
|
||||
**Delegation Rules:**
|
||||
- ALL architecture planning → api-architect agent
|
||||
- ALL code changes → backend-developer agent
|
||||
- ALL code reviews → senior-code-reviewer agent (if available from frontend plugin)
|
||||
- ALL testing → backend-developer agent (or test-architect if available)
|
||||
- If you find yourself about to use Write or Edit tools, STOP and delegate to the appropriate agent instead.
|
||||
|
||||
## Feature Request
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Multi-Agent Orchestration Workflow
|
||||
|
||||
### PRELIMINARY: Check for Code Analysis Tools (Recommended)
|
||||
|
||||
**Before starting implementation, check if the code-analysis plugin is available:**
|
||||
|
||||
Try to detect if `code-analysis` plugin is installed by checking if codebase-detective agent or semantic-code-search tools are available.
|
||||
|
||||
**If code-analysis plugin is NOT available:**
|
||||
|
||||
Inform the user with this message:
|
||||
|
||||
```
|
||||
💡 Recommendation: Install Code Analysis Plugin
|
||||
|
||||
For best results investigating existing code patterns, services, and architecture,
|
||||
we recommend installing the code-analysis plugin.
|
||||
|
||||
Benefits:
|
||||
- 🔍 Semantic code search (find services/repositories by functionality)
|
||||
- 🕵️ Codebase detective agent (understand existing patterns)
|
||||
- 📊 40% faster codebase investigation
|
||||
- 🎯 Better understanding of where to integrate new features
|
||||
|
||||
Installation (2 commands):
|
||||
/plugin marketplace add MadAppGang/claude-code
|
||||
/plugin install code-analysis@mag-claude-plugins
|
||||
|
||||
Repository: https://github.com/MadAppGang/claude-code
|
||||
|
||||
You can continue without it, but investigation of existing code will be less efficient.
|
||||
```
|
||||
|
||||
**If code-analysis plugin IS available:**
|
||||
|
||||
Great! You can use the codebase-detective agent and semantic-code-search skill during
|
||||
architecture planning to investigate existing patterns and find the best integration points.
|
||||
|
||||
**Then proceed with the implementation workflow regardless of plugin availability.**
|
||||
|
||||
---
|
||||
|
||||
### STEP 0: Initialize Global Workflow Todo List (MANDATORY FIRST STEP)
|
||||
|
||||
**BEFORE** starting any phase, you MUST create a global workflow todo list using TodoWrite to track the entire implementation lifecycle:
|
||||
|
||||
```
|
||||
TodoWrite with the following items:
|
||||
- content: "PHASE 1: Launch api-architect for API architecture planning"
|
||||
status: "in_progress"
|
||||
activeForm: "PHASE 1: Launching api-architect for API architecture planning"
|
||||
- content: "PHASE 1: User approval gate - wait for plan approval"
|
||||
status: "pending"
|
||||
activeForm: "PHASE 1: Waiting for user approval of architecture plan"
|
||||
- content: "PHASE 2: Launch backend-developer for implementation"
|
||||
status: "pending"
|
||||
activeForm: "PHASE 2: Launching backend-developer for implementation"
|
||||
- content: "PHASE 3: Run quality checks (format, lint, typecheck)"
|
||||
status: "pending"
|
||||
activeForm: "PHASE 3: Running quality checks"
|
||||
- content: "PHASE 4: Run tests (unit and integration)"
|
||||
status: "pending"
|
||||
activeForm: "PHASE 4: Running tests"
|
||||
- content: "PHASE 5: Launch code review (if available)"
|
||||
status: "pending"
|
||||
activeForm: "PHASE 5: Launching code review"
|
||||
- content: "PHASE 6: User acceptance - present implementation for approval"
|
||||
status: "pending"
|
||||
activeForm: "PHASE 6: Presenting implementation for user approval"
|
||||
- content: "PHASE 7: Finalize implementation"
|
||||
status: "pending"
|
||||
activeForm: "PHASE 7: Finalizing implementation"
|
||||
```
|
||||
|
||||
**Update this todo list** as you progress through phases:
|
||||
- Mark items as "completed" immediately after finishing each phase
|
||||
- Mark the next phase as "in_progress" before starting it
|
||||
- Add new items if additional steps are discovered
|
||||
|
||||
---
|
||||
|
||||
### PHASE 1: Architecture Planning with api-architect
|
||||
|
||||
**Objective:** Create comprehensive API architecture plan before implementation.
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. **Gather Context**
|
||||
- Read existing API structure (if any)
|
||||
- Review database schema (Prisma schema)
|
||||
- Check for existing patterns and conventions
|
||||
|
||||
2. **Launch api-architect Agent**
|
||||
```
|
||||
Use Task tool with agent: api-architect
|
||||
Prompt: "Create a comprehensive API architecture plan for: [feature description]
|
||||
|
||||
Context:
|
||||
- Existing API patterns: [summarize from codebase]
|
||||
- Database schema: [summarize existing models]
|
||||
- Authentication: [current auth strategy]
|
||||
|
||||
Please design:
|
||||
1. Database schema (Prisma models)
|
||||
2. API endpoints (routes, methods, request/response contracts)
|
||||
3. Authentication & authorization requirements
|
||||
4. Validation schemas (Zod)
|
||||
5. Error handling strategy
|
||||
6. Implementation roadmap
|
||||
|
||||
Save documentation to ai-docs/ for reference during implementation."
|
||||
```
|
||||
|
||||
3. **Review Architecture Plan**
|
||||
- Agent will create comprehensive plan in ai-docs/
|
||||
- Review database schema design
|
||||
- Review API endpoint specifications
|
||||
- Review implementation phases
|
||||
|
||||
4. **User Approval Gate**
|
||||
```
|
||||
Use AskUserQuestion:
|
||||
- Question: "The api-architect has created a comprehensive plan (see ai-docs/).
|
||||
Do you approve this architecture, or should we make adjustments?"
|
||||
- Options:
|
||||
* "Approve and proceed with implementation"
|
||||
* "Request changes to the plan"
|
||||
* "Cancel implementation"
|
||||
```
|
||||
|
||||
**If "Request changes":**
|
||||
- Get user feedback
|
||||
- Re-launch api-architect with adjusted requirements
|
||||
- Return to approval gate
|
||||
|
||||
**If "Cancel":**
|
||||
- Stop workflow
|
||||
- Clean up any created files
|
||||
|
||||
**If "Approve":**
|
||||
- Mark PHASE 1 as completed
|
||||
- Proceed to PHASE 2
|
||||
|
||||
---
|
||||
|
||||
### PHASE 2: Implementation with backend-developer
|
||||
|
||||
**Objective:** Implement the API features according to the approved architecture plan.
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. **Prepare Implementation Context**
|
||||
- Read architecture plan from ai-docs/
|
||||
- Prepare database schema (Prisma)
|
||||
- Identify implementation phases from plan
|
||||
|
||||
2. **Launch backend-developer Agent**
|
||||
```
|
||||
Use Task tool with agent: backend-developer
|
||||
Prompt: "Implement the API feature according to the architecture plan in ai-docs/[plan-file].
|
||||
|
||||
Implementation checklist:
|
||||
1. Update Prisma schema (if database changes needed)
|
||||
2. Run prisma generate and create migration
|
||||
3. Create Zod validation schemas (src/schemas/)
|
||||
4. Implement repository layer (src/database/repositories/)
|
||||
5. Implement service layer (src/services/)
|
||||
6. Implement controller layer (src/controllers/)
|
||||
7. Create routes (src/routes/)
|
||||
8. Add authentication/authorization middleware (if needed)
|
||||
9. Write unit tests (tests/unit/)
|
||||
10. Write integration tests (tests/integration/)
|
||||
|
||||
Follow these principles:
|
||||
- Layered architecture: routes → controllers → services → repositories
|
||||
- Security: validate all inputs, hash passwords, use JWT
|
||||
- Error handling: use custom error classes
|
||||
- Type safety: strict TypeScript, Zod schemas
|
||||
- Testing: comprehensive unit and integration tests
|
||||
|
||||
Run quality checks (format, lint, typecheck, tests) before completing."
|
||||
```
|
||||
|
||||
3. **Monitor Implementation**
|
||||
- backend-developer will work through implementation phases
|
||||
- Each layer will be created following best practices
|
||||
- Quality checks will be run automatically
|
||||
|
||||
4. **Review Implementation Results**
|
||||
- Check that all files were created
|
||||
- Verify layered architecture was followed
|
||||
- Confirm quality checks passed
|
||||
|
||||
**Mark PHASE 2 as completed, proceed to PHASE 3**
|
||||
|
||||
---
|
||||
|
||||
### PHASE 3: Quality Checks
|
||||
|
||||
**Objective:** Ensure code quality through automated checks.
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. **Run Biome Format**
|
||||
```bash
|
||||
bun run format
|
||||
```
|
||||
- Verify no formatting issues
|
||||
- All code should be consistently formatted
|
||||
|
||||
2. **Run Biome Lint**
|
||||
```bash
|
||||
bun run lint
|
||||
```
|
||||
- Verify no linting errors or warnings
|
||||
- If issues found, delegate fixes to backend-developer
|
||||
|
||||
3. **Run TypeScript Type Check**
|
||||
```bash
|
||||
bun run typecheck
|
||||
```
|
||||
- Verify no type errors
|
||||
- If issues found, delegate fixes to backend-developer
|
||||
|
||||
**If any check fails:**
|
||||
- Re-launch backend-developer to fix issues
|
||||
- Re-run quality checks
|
||||
- Do NOT proceed until all checks pass
|
||||
|
||||
**Mark PHASE 3 as completed, proceed to PHASE 4**
|
||||
|
||||
---
|
||||
|
||||
### PHASE 4: Testing
|
||||
|
||||
**Objective:** Run tests to verify functionality.
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. **Run Unit Tests**
|
||||
```bash
|
||||
bun test tests/unit
|
||||
```
|
||||
- Verify all unit tests pass
|
||||
- Check test coverage (if configured)
|
||||
|
||||
2. **Run Integration Tests**
|
||||
```bash
|
||||
bun test tests/integration
|
||||
```
|
||||
- Verify all integration tests pass
|
||||
- Ensure API endpoints work correctly
|
||||
|
||||
3. **Run All Tests**
|
||||
```bash
|
||||
bun test
|
||||
```
|
||||
- Verify complete test suite passes
|
||||
|
||||
**If any test fails:**
|
||||
- Re-launch backend-developer to investigate and fix
|
||||
- Re-run tests
|
||||
- Do NOT proceed until all tests pass
|
||||
|
||||
**Mark PHASE 4 as completed, proceed to PHASE 5**
|
||||
|
||||
---
|
||||
|
||||
### PHASE 5: Code Review (Optional)
|
||||
|
||||
**Objective:** Get expert code review if review agents are available.
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. **Check for Review Agents**
|
||||
- Check if senior-code-reviewer agent is available (from frontend plugin)
|
||||
- Check if codex-reviewer agent is available (from frontend plugin)
|
||||
|
||||
2. **Launch Code Review (if available)**
|
||||
```
|
||||
Use Task tool with agent: senior-code-reviewer (or codex-reviewer)
|
||||
Prompt: "Review the backend API implementation focusing on:
|
||||
1. Security (authentication, authorization, validation)
|
||||
2. Architecture (layered design, separation of concerns)
|
||||
3. Error handling (custom errors, global handler)
|
||||
4. Type safety (TypeScript strict mode, Zod schemas)
|
||||
5. Testing (coverage, test quality)
|
||||
6. Performance (database queries, caching)
|
||||
7. Best practices (Bun, Hono, Prisma patterns)
|
||||
|
||||
Provide actionable feedback for improvements."
|
||||
```
|
||||
|
||||
3. **Review Feedback**
|
||||
- Read review agent's feedback
|
||||
- Identify critical vs. optional improvements
|
||||
|
||||
4. **Apply Critical Improvements**
|
||||
- If critical issues found, re-launch backend-developer to fix
|
||||
- Re-run quality checks and tests
|
||||
|
||||
**Mark PHASE 5 as completed, proceed to PHASE 6**
|
||||
|
||||
---
|
||||
|
||||
### PHASE 6: User Acceptance
|
||||
|
||||
**Objective:** Present implementation to user for final approval.
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. **Prepare Summary**
|
||||
- List all files created/modified
|
||||
- Summarize implementation (what was built)
|
||||
- Highlight key features
|
||||
- Confirm all quality checks passed
|
||||
- Confirm all tests passed
|
||||
|
||||
2. **Git Status Check**
|
||||
```bash
|
||||
git status
|
||||
git diff
|
||||
```
|
||||
- Show user what changed
|
||||
- Provide context for review
|
||||
|
||||
3. **User Approval Gate**
|
||||
```
|
||||
Use AskUserQuestion:
|
||||
- Question: "The API implementation is complete. All quality checks and tests passed.
|
||||
|
||||
Summary:
|
||||
[List key features implemented]
|
||||
|
||||
Files modified: [count]
|
||||
Tests: [passing]
|
||||
Quality checks: [all passed]
|
||||
|
||||
What would you like to do next?"
|
||||
- Options:
|
||||
* "Accept and finalize"
|
||||
* "Request changes or improvements"
|
||||
* "Manual testing needed - pause here"
|
||||
```
|
||||
|
||||
**If "Request changes":**
|
||||
- Get user feedback on specific changes
|
||||
- Re-launch backend-developer with change requests
|
||||
- Re-run quality checks and tests
|
||||
- Return to approval gate
|
||||
|
||||
**If "Manual testing needed":**
|
||||
- Provide instructions for manual testing
|
||||
- Pause workflow
|
||||
- Wait for user to continue
|
||||
|
||||
**If "Accept":**
|
||||
- Mark PHASE 6 as completed
|
||||
- Proceed to PHASE 7
|
||||
|
||||
---
|
||||
|
||||
### PHASE 7: Finalization
|
||||
|
||||
**Objective:** Finalize implementation and prepare for deployment.
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. **Final Verification**
|
||||
- Confirm all quality checks still pass
|
||||
- Confirm all tests still pass
|
||||
- Review git status
|
||||
|
||||
2. **Documentation Check**
|
||||
- Verify API documentation is up to date
|
||||
- Check that ai-docs/ contains architecture plan
|
||||
- Ensure README or API docs reflect new endpoints
|
||||
|
||||
3. **Deployment Readiness** (Optional)
|
||||
```
|
||||
Ask user: "Would you like guidance on deploying this API to production?"
|
||||
|
||||
If yes, provide:
|
||||
- Docker build command
|
||||
- Prisma migration deployment command
|
||||
- Environment variables needed
|
||||
- AWS ECS deployment steps (if applicable)
|
||||
```
|
||||
|
||||
4. **Completion Summary**
|
||||
Present final summary:
|
||||
```
|
||||
✅ API Implementation Complete
|
||||
|
||||
What was built:
|
||||
[List features]
|
||||
|
||||
Files created/modified:
|
||||
[List key files]
|
||||
|
||||
Database changes:
|
||||
[List Prisma migrations]
|
||||
|
||||
Tests:
|
||||
Unit: [count] passing
|
||||
Integration: [count] passing
|
||||
|
||||
Quality:
|
||||
✅ Formatted (Biome)
|
||||
✅ Linted (Biome)
|
||||
✅ Type-checked (TypeScript)
|
||||
✅ Tested (Bun)
|
||||
|
||||
Next steps:
|
||||
- Review and commit changes: git add . && git commit
|
||||
- Create pull request (if using git workflow)
|
||||
- Deploy to staging/production
|
||||
- Update API documentation
|
||||
```
|
||||
|
||||
**Mark PHASE 7 as completed**
|
||||
|
||||
---
|
||||
|
||||
## Error Recovery
|
||||
|
||||
If any phase fails:
|
||||
|
||||
1. **Identify the issue**
|
||||
- Read error messages
|
||||
- Check logs
|
||||
- Review what went wrong
|
||||
|
||||
2. **Delegate fix to appropriate agent**
|
||||
- Implementation bugs → backend-developer
|
||||
- Architecture issues → api-architect
|
||||
- Test failures → backend-developer
|
||||
|
||||
3. **Re-run affected phases**
|
||||
- After fix, re-run quality checks
|
||||
- Re-run tests
|
||||
- Ensure everything passes before proceeding
|
||||
|
||||
4. **Never skip phases**
|
||||
- Each phase builds on previous phases
|
||||
- Skipping phases risks incomplete or broken implementation
|
||||
|
||||
## Success Criteria
|
||||
|
||||
Implementation is complete when:
|
||||
|
||||
- ✅ Architecture plan approved by user
|
||||
- ✅ All code implemented following layered architecture
|
||||
- ✅ Database schema updated (if needed) and migrated
|
||||
- ✅ All inputs validated with Zod schemas
|
||||
- ✅ Authentication/authorization implemented correctly
|
||||
- ✅ Custom error handling in place
|
||||
- ✅ All quality checks pass (format, lint, typecheck)
|
||||
- ✅ All tests pass (unit + integration)
|
||||
- ✅ Code review completed (if available)
|
||||
- ✅ User acceptance obtained
|
||||
- ✅ Documentation updated
|
||||
|
||||
## Remember
|
||||
|
||||
You are the **orchestrator**, not the implementer. Your job is to:
|
||||
- Coordinate specialized agents
|
||||
- Enforce quality gates
|
||||
- Manage user approvals
|
||||
- Ensure systematic completion
|
||||
- Never write code yourself - always delegate
|
||||
|
||||
The result should be production-ready, well-tested, secure API code that follows all best practices.
|
||||
580
commands/setup-project.md
Normal file
580
commands/setup-project.md
Normal file
@@ -0,0 +1,580 @@
|
||||
---
|
||||
description: Initialize a new Bun + TypeScript backend project with best practices setup (Hono, Prisma, Biome, testing, Docker)
|
||||
allowed-tools: Bash, Write, AskUserQuestion, TodoWrite, Read
|
||||
---
|
||||
|
||||
## Mission
|
||||
|
||||
Set up a production-ready Bun + TypeScript backend project from scratch with all necessary tooling, configuration, and project structure. This creates a solid foundation following industry best practices.
|
||||
|
||||
## Project Setup Request
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Workflow
|
||||
|
||||
### STEP 0: Initialize Todo List (MANDATORY FIRST STEP)
|
||||
|
||||
Create a todo list to track the setup process:
|
||||
|
||||
```
|
||||
TodoWrite with the following items:
|
||||
- content: "Gather project requirements and configuration preferences"
|
||||
status: "in_progress"
|
||||
activeForm: "Gathering project requirements"
|
||||
- content: "Initialize Bun project and install dependencies"
|
||||
status: "pending"
|
||||
activeForm: "Initializing Bun project"
|
||||
- content: "Configure TypeScript (strict mode)"
|
||||
status: "pending"
|
||||
activeForm: "Configuring TypeScript"
|
||||
- content: "Configure Biome (formatter + linter)"
|
||||
status: "pending"
|
||||
activeForm: "Configuring Biome"
|
||||
- content: "Set up Prisma with PostgreSQL"
|
||||
status: "pending"
|
||||
activeForm: "Setting up Prisma"
|
||||
- content: "Create project structure (folders)"
|
||||
status: "pending"
|
||||
activeForm: "Creating project structure"
|
||||
- content: "Create core utilities (errors, logger, config)"
|
||||
status: "pending"
|
||||
activeForm: "Creating core utilities"
|
||||
- content: "Set up Hono app and server"
|
||||
status: "pending"
|
||||
activeForm: "Setting up Hono app"
|
||||
- content: "Create middleware (error handler, logging, validation)"
|
||||
status: "pending"
|
||||
activeForm: "Creating middleware"
|
||||
- content: "Set up environment variables and configuration"
|
||||
status: "pending"
|
||||
activeForm: "Setting up environment configuration"
|
||||
- content: "Create Docker configuration"
|
||||
status: "pending"
|
||||
activeForm: "Creating Docker configuration"
|
||||
- content: "Set up testing infrastructure"
|
||||
status: "pending"
|
||||
activeForm: "Setting up testing"
|
||||
- content: "Create package.json scripts"
|
||||
status: "pending"
|
||||
activeForm: "Creating npm scripts"
|
||||
- content: "Create .gitignore and other config files"
|
||||
status: "pending"
|
||||
activeForm: "Creating config files"
|
||||
- content: "Create README.md with project documentation"
|
||||
status: "pending"
|
||||
activeForm: "Creating README"
|
||||
- content: "Initialize git repository"
|
||||
status: "pending"
|
||||
activeForm: "Initializing git"
|
||||
- content: "Run initial quality checks"
|
||||
status: "pending"
|
||||
activeForm: "Running quality checks"
|
||||
```
|
||||
|
||||
### STEP 1: Gather Requirements
|
||||
|
||||
Ask the user for project configuration preferences:
|
||||
|
||||
```
|
||||
Use AskUserQuestion with the following questions:
|
||||
|
||||
1. Project Name:
|
||||
Question: "What is the name of your backend project?"
|
||||
Options: [Let user type custom name]
|
||||
|
||||
2. Database:
|
||||
Question: "Which database will you use?"
|
||||
Options:
|
||||
- "PostgreSQL (recommended)"
|
||||
- "MySQL"
|
||||
- "SQLite (development only)"
|
||||
|
||||
3. Authentication:
|
||||
Question: "Do you need JWT authentication set up from the start?"
|
||||
Options:
|
||||
- "Yes, set up JWT authentication"
|
||||
- "No, I'll add it later"
|
||||
|
||||
4. Docker:
|
||||
Question: "Include Docker configuration for containerization?"
|
||||
Options:
|
||||
- "Yes, include Dockerfile and docker-compose.yml"
|
||||
- "No, skip Docker"
|
||||
|
||||
5. Additional Features:
|
||||
Question: "Which additional features would you like included?"
|
||||
Multi-select: true
|
||||
Options:
|
||||
- "Redis caching utilities"
|
||||
- "File upload handling"
|
||||
- "Email service integration"
|
||||
- "Health check endpoint"
|
||||
```
|
||||
|
||||
**Store answers** for use in setup steps.
|
||||
|
||||
### STEP 2: Initialize Bun Project
|
||||
|
||||
1. **Initialize project**
|
||||
```bash
|
||||
bun init -y
|
||||
```
|
||||
|
||||
2. **Install runtime dependencies**
|
||||
```bash
|
||||
bun add hono @hono/node-server
|
||||
bun add zod @prisma/client bcrypt jsonwebtoken pino
|
||||
```
|
||||
|
||||
If JWT authentication selected:
|
||||
```bash
|
||||
bun add bcrypt jsonwebtoken
|
||||
```
|
||||
|
||||
If Redis caching selected:
|
||||
```bash
|
||||
bun add ioredis
|
||||
```
|
||||
|
||||
3. **Install dev dependencies**
|
||||
```bash
|
||||
bun add -d @types/node @types/bun typescript prisma @biomejs/biome
|
||||
```
|
||||
|
||||
If JWT authentication selected:
|
||||
```bash
|
||||
bun add -d @types/bcrypt @types/jsonwebtoken
|
||||
```
|
||||
|
||||
### STEP 3: Configure TypeScript
|
||||
|
||||
Create `tsconfig.json` with strict configuration:
|
||||
|
||||
```json
|
||||
{
|
||||
"compilerOptions": {
|
||||
"target": "ES2022",
|
||||
"module": "ESNext",
|
||||
"lib": ["ES2022"],
|
||||
"moduleResolution": "bundler",
|
||||
"rootDir": "./src",
|
||||
"outDir": "./dist",
|
||||
"strict": true,
|
||||
"esModuleInterop": true,
|
||||
"skipLibCheck": true,
|
||||
"forceConsistentCasingInFileNames": true,
|
||||
"resolveJsonModule": true,
|
||||
"allowImportingTsExtensions": true,
|
||||
"noUnusedLocals": true,
|
||||
"noUnusedParameters": true,
|
||||
"noImplicitReturns": true,
|
||||
"noFallthroughCasesInSwitch": true,
|
||||
"types": ["bun-types"],
|
||||
"baseUrl": ".",
|
||||
"paths": {
|
||||
"@core/*": ["src/core/*"],
|
||||
"@database/*": ["src/database/*"],
|
||||
"@services/*": ["src/services/*"],
|
||||
"@/*": ["src/*"]
|
||||
}
|
||||
},
|
||||
"include": ["src/**/*"],
|
||||
"exclude": ["node_modules", "dist", "tests"]
|
||||
}
|
||||
```
|
||||
|
||||
### STEP 4: Configure Biome
|
||||
|
||||
1. **Initialize Biome**
|
||||
```bash
|
||||
bunx @biomejs/biome init
|
||||
```
|
||||
|
||||
2. **Update biome.json**
|
||||
```json
|
||||
{
|
||||
"$schema": "https://raw.githubusercontent.com/biomejs/biome/main/configuration_schema.json",
|
||||
"files": { "ignore": ["node_modules", "dist"] },
|
||||
"formatter": {
|
||||
"indentStyle": "space",
|
||||
"indentSize": 2,
|
||||
"lineWidth": 100,
|
||||
"quoteStyle": "single",
|
||||
"semicolons": "always"
|
||||
},
|
||||
"organizeImports": true,
|
||||
"javascript": { "formatter": { "trailingComma": "es5" } },
|
||||
"typescript": {
|
||||
"formatter": { "trailingComma": "es5" }
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### STEP 5: Set Up Prisma
|
||||
|
||||
1. **Initialize Prisma**
|
||||
```bash
|
||||
bunx prisma init
|
||||
```
|
||||
|
||||
2. **Update DATABASE_URL in .env** (based on database selection)
|
||||
|
||||
For PostgreSQL:
|
||||
```
|
||||
DATABASE_URL="postgresql://user:password@localhost:5432/dbname?schema=public"
|
||||
```
|
||||
|
||||
For MySQL:
|
||||
```
|
||||
DATABASE_URL="mysql://user:password@localhost:3306/dbname"
|
||||
```
|
||||
|
||||
For SQLite:
|
||||
```
|
||||
DATABASE_URL="file:./dev.db"
|
||||
```
|
||||
|
||||
3. **Create initial Prisma schema** in `prisma/schema.prisma`:
|
||||
- Update datasource provider based on database selection
|
||||
- Add example User model
|
||||
- Add Session model if JWT auth selected
|
||||
|
||||
### STEP 6: Create Project Structure
|
||||
|
||||
Create directory structure:
|
||||
|
||||
```bash
|
||||
mkdir -p src/{core,database/repositories,services,controllers,middleware,routes,schemas,types,utils}
|
||||
mkdir -p tests/{unit,integration,e2e}
|
||||
```
|
||||
|
||||
Result:
|
||||
```
|
||||
src/
|
||||
├── core/ # Core utilities
|
||||
├── database/
|
||||
│ ├── client.ts
|
||||
│ └── repositories/ # Data access layer
|
||||
├── services/ # Business logic
|
||||
├── controllers/ # HTTP handlers
|
||||
├── middleware/ # Middleware functions
|
||||
├── routes/ # API routes
|
||||
├── schemas/ # Zod validation schemas
|
||||
├── types/ # TypeScript types
|
||||
└── utils/ # Utility functions
|
||||
tests/
|
||||
├── unit/
|
||||
├── integration/
|
||||
└── e2e/
|
||||
```
|
||||
|
||||
### STEP 7: Create Core Utilities
|
||||
|
||||
1. **Error classes** (`src/core/errors.ts`)
|
||||
- ApiError base class
|
||||
- BadRequestError, UnauthorizedError, ForbiddenError, NotFoundError, ConflictError, ValidationError
|
||||
|
||||
2. **Logger** (`src/core/logger.ts`)
|
||||
- Pino logger with development/production config
|
||||
- Pretty printing in development
|
||||
|
||||
3. **Config** (`src/core/config.ts`)
|
||||
- Environment variable loading
|
||||
- Type-safe configuration object
|
||||
- Validation for required env vars
|
||||
|
||||
### STEP 8: Set Up Hono App
|
||||
|
||||
1. **Create Hono app** (`src/app.ts`)
|
||||
- Initialize Hono
|
||||
- Add CORS middleware
|
||||
- Add security headers middleware
|
||||
- Add request logging middleware
|
||||
- Add global error handler
|
||||
- Mount health check route (if selected)
|
||||
|
||||
2. **Create server** (`src/server.ts`)
|
||||
- Import Hono app
|
||||
- Set up graceful shutdown
|
||||
- Start server on configured port
|
||||
|
||||
### STEP 9: Create Middleware
|
||||
|
||||
1. **Error handler** (`src/middleware/errorHandler.ts`)
|
||||
- Global error handling
|
||||
- ApiError response formatting
|
||||
- Logging
|
||||
|
||||
2. **Validation middleware** (`src/middleware/validator.ts`)
|
||||
- validate() for request body
|
||||
- validateQuery() for query params
|
||||
|
||||
3. **Request logger** (`src/middleware/requestLogger.ts`)
|
||||
- Log incoming requests
|
||||
- Log responses with duration
|
||||
|
||||
4. **Security headers** (`src/middleware/security.ts`)
|
||||
- X-Content-Type-Options
|
||||
- X-Frame-Options
|
||||
- X-XSS-Protection
|
||||
- Strict-Transport-Security
|
||||
|
||||
5. **Authentication middleware** (if JWT selected) (`src/middleware/auth.ts`)
|
||||
- authenticate() middleware
|
||||
- authorize() middleware for role-based access
|
||||
|
||||
### STEP 10: Set Up Environment Configuration
|
||||
|
||||
1. **Create .env.example**
|
||||
```
|
||||
NODE_ENV=development
|
||||
PORT=3000
|
||||
DATABASE_URL=postgresql://user:password@localhost:5432/dbname
|
||||
JWT_SECRET=your-secret-key-change-in-production
|
||||
LOG_LEVEL=debug
|
||||
# Add REDIS_URL if Redis selected
|
||||
# Add other env vars based on selections
|
||||
```
|
||||
|
||||
2. **Create .env** (copy from .env.example)
|
||||
|
||||
3. **Update .gitignore** to exclude .env
|
||||
|
||||
### STEP 11: Create Docker Configuration (if selected)
|
||||
|
||||
1. **Create Dockerfile** (multi-stage build)
|
||||
- Base stage
|
||||
- Dependencies stage
|
||||
- Build stage
|
||||
- Runner stage
|
||||
- Health check
|
||||
|
||||
2. **Create docker-compose.yml**
|
||||
- App service
|
||||
- PostgreSQL service
|
||||
- Redis service (if selected)
|
||||
- Health checks
|
||||
- Volume mounts
|
||||
|
||||
3. **Create .dockerignore**
|
||||
|
||||
### STEP 12: Set Up Testing
|
||||
|
||||
1. **Create test utilities** (`tests/setup.ts`)
|
||||
- Test database connection
|
||||
- Test data factories
|
||||
- Cleanup utilities
|
||||
|
||||
2. **Create example tests**
|
||||
- Unit test example (`tests/unit/example.test.ts`)
|
||||
- Integration test example (`tests/integration/health.test.ts`)
|
||||
|
||||
### STEP 13: Create Package.json Scripts
|
||||
|
||||
Update `package.json` with comprehensive scripts:
|
||||
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"dev": "bun --hot src/server.ts",
|
||||
"start": "NODE_ENV=production bun src/server.ts",
|
||||
"build": "bun build src/server.ts --target bun --outdir dist",
|
||||
"test": "bun test",
|
||||
"test:watch": "bun test --watch",
|
||||
"test:coverage": "bun test --coverage",
|
||||
"lint": "biome lint --write",
|
||||
"format": "biome format --write",
|
||||
"check": "biome check --write",
|
||||
"typecheck": "tsc --noEmit",
|
||||
"db:generate": "prisma generate",
|
||||
"db:migrate": "prisma migrate dev",
|
||||
"db:migrate:deploy": "prisma migrate deploy",
|
||||
"db:studio": "prisma studio",
|
||||
"db:seed": "bun run src/database/seed.ts",
|
||||
"docker:build": "docker build -t [project-name] .",
|
||||
"docker:run": "docker-compose up",
|
||||
"docker:down": "docker-compose down"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### STEP 14: Create Configuration Files
|
||||
|
||||
1. **Create .gitignore**
|
||||
```
|
||||
node_modules/
|
||||
dist/
|
||||
.env
|
||||
.env.local
|
||||
*.log
|
||||
.DS_Store
|
||||
coverage/
|
||||
prisma/migrations/
|
||||
bun.lockb
|
||||
```
|
||||
|
||||
2. **Create .editorconfig** (optional)
|
||||
|
||||
3. **Create .vscode/settings.json** (Biome integration)
|
||||
```json
|
||||
{
|
||||
"editor.defaultFormatter": "biomejs.biome",
|
||||
"editor.formatOnSave": true,
|
||||
"editor.codeActionsOnSave": {
|
||||
"source.organizeImports.biome": true,
|
||||
"source.fixAll.biome": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### STEP 15: Create README.md
|
||||
|
||||
Create comprehensive README with:
|
||||
- Project description
|
||||
- Technology stack
|
||||
- Project structure
|
||||
- Prerequisites
|
||||
- Installation instructions
|
||||
- Development commands
|
||||
- Testing instructions
|
||||
- Docker instructions
|
||||
- Environment variables
|
||||
- API documentation (placeholder)
|
||||
- Contributing guidelines
|
||||
- License
|
||||
|
||||
### STEP 16: Initialize Git Repository
|
||||
|
||||
1. **Initialize git**
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
2. **Create initial commit**
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Initial project setup: Bun + TypeScript + Hono + Prisma"
|
||||
```
|
||||
|
||||
### STEP 17: Run Quality Checks
|
||||
|
||||
1. **Run Prisma generate**
|
||||
```bash
|
||||
bunx prisma generate
|
||||
```
|
||||
|
||||
2. **Run formatter**
|
||||
```bash
|
||||
bun run format
|
||||
```
|
||||
|
||||
3. **Run linter**
|
||||
```bash
|
||||
bun run lint
|
||||
```
|
||||
|
||||
4. **Run type checker**
|
||||
```bash
|
||||
bun run typecheck
|
||||
```
|
||||
|
||||
5. **Run tests**
|
||||
```bash
|
||||
bun test
|
||||
```
|
||||
|
||||
**Verify all checks pass** before finalizing.
|
||||
|
||||
### STEP 18: Completion Summary
|
||||
|
||||
Present final summary:
|
||||
|
||||
```
|
||||
✅ Project Setup Complete!
|
||||
|
||||
Project: [project-name]
|
||||
Stack: Bun + TypeScript + Hono + Prisma + [database]
|
||||
|
||||
Created:
|
||||
- ✅ Project structure (src/, tests/)
|
||||
- ✅ TypeScript configuration (strict mode)
|
||||
- ✅ Biome configuration (format + lint)
|
||||
- ✅ Prisma ORM setup ([database])
|
||||
- ✅ Hono web framework
|
||||
- ✅ Core utilities (errors, logger, config)
|
||||
- ✅ Middleware (validation, auth, logging, security)
|
||||
- ✅ Environment configuration
|
||||
- ✅ Testing infrastructure
|
||||
- ✅ [Docker configuration] (if selected)
|
||||
- ✅ [JWT authentication] (if selected)
|
||||
- ✅ [Redis caching] (if selected)
|
||||
- ✅ Git repository initialized
|
||||
|
||||
Next steps:
|
||||
1. Review .env and update with your database credentials
|
||||
2. Run database migration: bun run db:migrate
|
||||
3. Start development server: bun run dev
|
||||
4. Open http://localhost:3000/health to verify setup
|
||||
5. Begin implementing your API features!
|
||||
|
||||
Useful commands:
|
||||
- bun run dev # Start dev server with hot reload
|
||||
- bun run test # Run tests
|
||||
- bun run check # Format + lint
|
||||
- bun run db:studio # Open Prisma Studio
|
||||
- bun run docker:run # Start with Docker
|
||||
|
||||
Documentation:
|
||||
- See README.md for full documentation
|
||||
- See best-practices skill for development guidelines
|
||||
- Use /implement-api command to build features
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
Project setup is complete when:
|
||||
|
||||
- ✅ All dependencies installed
|
||||
- ✅ TypeScript configured (strict mode)
|
||||
- ✅ Biome configured (format + lint)
|
||||
- ✅ Prisma set up with database connection
|
||||
- ✅ Project structure created
|
||||
- ✅ Core utilities implemented
|
||||
- ✅ Hono app and server created
|
||||
- ✅ Middleware set up
|
||||
- ✅ Environment configuration created
|
||||
- ✅ Testing infrastructure ready
|
||||
- ✅ Docker configuration created (if selected)
|
||||
- ✅ All quality checks pass
|
||||
- ✅ Git repository initialized
|
||||
- ✅ README.md created
|
||||
|
||||
## Error Handling
|
||||
|
||||
If any step fails:
|
||||
|
||||
1. **Identify the issue**
|
||||
- Read error message
|
||||
- Check what command failed
|
||||
|
||||
2. **Common issues:**
|
||||
- Bun not installed → Install Bun first
|
||||
- Database connection failed → Update DATABASE_URL in .env
|
||||
- Port already in use → Change PORT in .env
|
||||
- Missing dependencies → Run `bun install`
|
||||
|
||||
3. **Recovery:**
|
||||
- Fix the issue
|
||||
- Re-run the failed step
|
||||
- Continue with remaining steps
|
||||
|
||||
## Remember
|
||||
|
||||
This command creates a **production-ready foundation**. After setup:
|
||||
- Use `/implement-api` to build features
|
||||
- Use `backend-developer` agent for implementation
|
||||
- Use `api-architect` agent for planning
|
||||
- Follow the best-practices skill for guidelines
|
||||
|
||||
The result is a clean, well-structured, fully-configured Bun backend project ready for feature development.
|
||||
Reference in New Issue
Block a user