From rkit
Skill for designing and implementing backend APIs. Includes Zero Script QA methodology for validating APIs without test scripts. Use proactively when user needs to design or implement backend APIs. Triggers: API design, REST API, backend, endpoint, API 설계, API設計, API设计, diseño de API, diseño API, diseño de backend, conception API, conception d'API, backend, API-Design, API-Entwurf, Backend, progettazione API, design API, backend Do NOT use for: frontend-only projects, static websites, or Starter level projects.
npx claudepluginhub solitasroh/rkit --plugin rkitThis skill is limited to using the following tools:
> Backend API implementation and script-free QA
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Backend API implementation and script-free QA
Implement backend APIs that can store and retrieve data. Validate with structured logs instead of test scripts.
docs/02-design/
└── api-spec.md # API specification
src/api/ # API implementation
├── routes/
├── controllers/
└── services/
docs/03-analysis/
└── api-qa.md # QA results
| Level | Application Method |
|---|---|
| Starter | Skip this Phase (no API) |
| Dynamic | Use bkend.ai BaaS (see below) |
| Enterprise | Implement APIs directly |
claude mcp add bkend --transport http https://api.bkend.ai/mcp
Natural language request: "Create a users table with name(required), email(required, unique), age fields"
-> MCP backend_table_create auto-invoked
| Method | Endpoint | Description |
|---|---|---|
| GET | /v1/data/{table} | List (filter, sort, page) |
| POST | /v1/data/{table} | Create data |
| GET | /v1/data/{table}/{id} | Get single |
| PATCH | /v1/data/{table}/{id} | Partial update |
| DELETE | /v1/data/{table}/{id} | Delete |
Required Headers: x-project-id, x-environment, Authorization
Reference MCP tools 3_howto_implement_auth and 6_code_examples_auth
Instead of writing test scripts, validate with structured debug logs
[API] POST /api/users
[INPUT] { "email": "test@test.com", "name": "Test" }
[PROCESS] Email duplicate check → Passed
[PROCESS] Password hash → Complete
[PROCESS] DB save → Success
[OUTPUT] { "id": 1, "email": "test@test.com" }
[RESULT] ✅ Success
Advantages:
- Save test code writing time
- See actual behavior with your eyes
- Easy debugging
REpresentational State Transfer - an architecture style for designing web services.
| Principle | Description | Example |
|---|---|---|
| 1. Client-Server | Separation of concerns between client and server | UI ↔ Data storage separated |
| 2. Stateless | Each request is independent, server doesn't store client state | Auth token included with each request |
| 3. Cacheable | Responses must indicate if cacheable | Cache-Control header |
| 4. Uniform Interface | Interact through consistent interface | Detailed below |
| 5. Layered System | Allow layered system architecture | Load balancer, proxy |
| 6. Code on Demand | (Optional) Server can send code to client | JavaScript delivery |
The core of RESTful APIs is a uniform interface.
✅ Good (nouns, plural)
GET /users # User list
GET /users/123 # Specific user
POST /users # Create user
PUT /users/123 # Update user
DELETE /users/123 # Delete user
❌ Bad (using verbs)
GET /getUsers
POST /createUser
POST /deleteUser/123
| Method | Purpose | Idempotent | Safe |
|---|---|---|---|
GET | Read | ✅ | ✅ |
POST | Create | ❌ | ❌ |
PUT | Full update | ✅ | ❌ |
PATCH | Partial update | ❌ | ❌ |
DELETE | Delete | ✅ | ❌ |
Idempotent: Same result even if requested multiple times Safe: Doesn't change server state
2xx Success
├── 200 OK # Success (read, update)
├── 201 Created # Creation success
└── 204 No Content # Success but no response body (delete)
4xx Client Error
├── 400 Bad Request # Invalid request (validation failure)
├── 401 Unauthorized # Authentication required
├── 403 Forbidden # No permission
├── 404 Not Found # Resource not found
└── 409 Conflict # Conflict (duplicate, etc.)
5xx Server Error
├── 500 Internal Error # Internal server error
└── 503 Service Unavailable # Service unavailable
// Success response
{
"data": {
"id": 123,
"email": "user@example.com",
"name": "John Doe"
},
"meta": {
"timestamp": "2026-01-08T10:00:00Z"
}
}
// Error response
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Email format is invalid.",
"details": [
{ "field": "email", "message": "Please enter a valid email" }
]
}
}
// List response (pagination)
{
"data": [...],
"pagination": {
"page": 1,
"limit": 20,
"total": 100,
"totalPages": 5
}
}
1. Use lowercase
✅ /users/123/orders
❌ /Users/123/Orders
2. Use hyphens (-), avoid underscores (_)
✅ /user-profiles
❌ /user_profiles
3. Express hierarchical relationships
✅ /users/123/orders/456
4. Filtering via query parameters
✅ /users?status=active&sort=created_at
❌ /users/active/sort/created_at
5. Version management
✅ /api/v1/users
✅ Header: Accept: application/vnd.api+json;version=1
| Tool | Features |
|---|---|
| OpenAPI (Swagger) | Industry standard, auto documentation |
| Postman | Testing + documentation |
| Insomnia | Lightweight API client |
templates/pipeline/phase-4-api.template.mdtemplates/pipeline/zero-script-qa.template.mdPhase 5: Design System → APIs are ready, now build UI components