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