From bkit — AI Native Development OS
Design and implement backend APIs with Zero Script QA validation using structured logs instead of test scripts. Supports both custom implementation and bkend.ai BaaS integration.
How this skill is triggered — by the user, by Claude, or both
Slash command
/bkit:phase-4-apibkit:qa-monitorThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
> Backend API implementation and script-free QA
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
npx claudepluginhub popup-studio-ai/bkit-claude-code --plugin bkitDesigns consistent RESTful APIs covering conventions, HTTP methods, naming, versioning strategies, response formats, status codes, error handling, and pagination patterns.
Designs consistent, evolvable REST APIs with correct resource naming, HTTP methods, status codes, versioning, pagination, and error format.
Initializes fullstack projects using bkend.ai BaaS for authentication, database, and API integration. Includes init, guide, and help actions; scaffolds Next.js apps with Tailwind CSS and TypeScript.