Bkit Rules

bkit Core Rules (Detailed Reference)

Comprehensive rules for bkit's document-driven AI-native development methodology.

1. PDCA Auto-Apply Rules

Task Classification

Classify tasks to determine the appropriate PDCA level:

Classification Keywords

Design Document Check Flow

Before writing code, follow this decision tree:

1. Extract feature name from file path or user request
2. Check: docs/01-plan/features/{feature}.plan.md
3. Check: docs/02-design/features/{feature}.design.md
4. Decision:
   • If neither exists: suggest creating a plan first
   • If plan exists but no design: suggest creating a design
   • If both exist: reference design during implementation
   • If task is Quick Fix (<10 lines): skip PDCA, proceed directly

Pre-Write Rules

Before writing or editing any source code file:

1. Call bkit_pre_write_check(filePath) MCP tool
2. If response says design document exists: reference it during implementation
3. If response says no design document: suggest "Shall I create a design first?"
4. For major changes (>200 lines): ALWAYS suggest creating design first

Post-Write Guidance Rules

After significant code changes:

1. Call bkit_post_write(filePath, linesChanged) MCP tool
2. Follow the returned guidance
3. For features with design docs: suggest gap analysis
4. Format suggestion: "Consider running gap analysis: $pdca analyze {feature}"

2. Level Detection Rules

Detect project level based on directory structure and config files.

Enterprise (2+ conditions met)

• kubernetes/, terraform/, k8s/, or infra/ directories exist
• services/ folder with 2+ services
• turbo.json or pnpm-workspace.yaml
• docker-compose.yml
• .github/workflows/ (CI/CD)

Dynamic (1+ conditions met)

• lib/bkend/ or src/lib/bkend/ directory
• .mcp.json with bkend configuration
• supabase/ folder
• firebase.json
• api/ or backend/ directory
• docker-compose.yml (without K8s indicators)
• package.json containing: bkend, @supabase, firebase

Starter

None of the above conditions met. Default level for simple projects.

Level-Specific Behavior

Level Upgrade Signals

• Starter to Dynamic: "Add login", "Save data", "Admin page"
• Dynamic to Enterprise: "High traffic", "Microservices", "Own server"

3. 8-Language Trigger Keywords

bkit supports trigger detection in 8 languages:

Feature Keywords by Language

4. Naming Conventions

Code Naming Rules

Document Naming Rules

5. Code Quality Standards

Core Principles

• DRY: Extract to common function on 2nd use
• SRP: One function, one responsibility
• No Hardcoding: Use meaningful constants
• Extensibility: Write in generalized patterns

Pre-coding Checks

1. Does similar functionality exist? Search first
2. Check utils/, hooks/, components/ui/
3. Reuse if exists; create if not

Self-Check After Coding

• Same logic exists elsewhere?
• Can function be reused?
• Hardcoded values present?
• Function does only one thing?

When to Refactor

• Same code appears 2nd time
• Function exceeds 20 lines
• if-else nests 3+ levels
• Same parameters passed to multiple functions

Safety Rules

• NEVER commit .env, credentials, or secret files
• ALWAYS validate user input at system boundaries
• Prefer explicit error handling over silent failures
• Follow OWASP Top 10 guidelines for security:
  • Input validation (XSS, SQL Injection prevention)
  • Authentication/authorization handling
  • Sensitive data encryption
  • HTTPS enforcement
  • Rate limiting

6. MCP Tools Quick Reference

7. Response Style Guidelines

Include bkit Feature Usage Report

When PDCA is active, include at the end of responses:

---
bkit Status: {feature} | Phase: {phase} | Match Rate: {rate}%
Next: {suggested next action}

Level-Appropriate Formatting

• Starter: Include learning points, explain concepts simply
• Dynamic: Include PDCA status badges, checklists, next-step guidance
• Enterprise: Include tradeoff analysis, cost impact, deployment considerations