enforce-commandments

name	enforce-commandments
description	This skill should be ALWAYS ACTIVE during software development. It automatically enforces the 10 Engineering Commandments when the user is writing code, planning features, creating specifications, designing architecture, or reviewing code. Auto-activates on keywords like "implement", "build", "create", "refactor", "design", "architecture", "component", "service", "endpoint", or "module".

Engineering Commandments Enforcement

Enforce the 10 Engineering Commandments during all development activities. This skill auto-activates during code writing, planning, specification, and review.

The 10 Commandments

Ensure ALL outputs comply with:

1. Design for Failure

Systems should expect and gracefully handle failures

• Error boundaries and fallback states
• Retry logic with exponential backoff
• Circuit breakers for external dependencies
• Graceful degradation paths

2. Keep It Simple

Complexity breeds bugs that testing may not catch

• Prefer straightforward solutions over clever ones
• Avoid premature optimization
• Limit nesting depth (max 3 levels)
• One function = one purpose

3. Test Early and Often

Testing is not optional, it's fundamental

• Unit tests for all business logic
• Integration tests for critical paths
• Test plan BEFORE implementation
• No PR without test coverage

4. Build for Observability

You cannot improve what you cannot measure

• Structured logging (not console.log)
• Metrics for key operations
• Tracing for distributed flows
• Health check endpoints

5. Document Thy Intent

Code tells you how, documentation tells you why

• JSDoc/docstrings for public APIs
• README for each module/service
• ADRs for architectural decisions
• Comments explain WHY, not WHAT

6. Automate Everything Repeatable

All changes must be trackable and reversible

• CI/CD for all deployments
• Infrastructure as Code
• Database migrations (never manual DDL)
• Scripted environment setup

7. Secure by Design

Security is not an afterthought

• Input validation at boundaries
• Parameterized queries (no string concatenation)
• Secrets in environment, never code
• Principle of least privilege

8. Respect Data Consistency

Never trust external data

• Validate ALL external inputs
• Schema validation (Zod, JSON Schema)
• Idempotent operations where possible
• Transaction boundaries defined

9. Separate Concerns

Each component should have one clear responsibility

• Clear module boundaries
• Dependency injection
• Interface-based contracts
• No god objects/functions

10. Plan for Scale

Today's solution should work for tomorrow's load

• Stateless services where possible
• Async processing for heavy operations
• Pagination for list endpoints
• Cache strategies defined

Enforcement Gates

Apply the appropriate gate checklist based on the current activity. Detailed checklists are in references/:

• Specification/Planning -- Load references/specification-gate.md for the full pre-flight checklist (failure design, simplicity, test strategy, observability, security, scale)
• Implementation -- Load references/implementation-gate.md before marking tasks complete (error handling, complexity, testing, observability, security, data handling, separation of concerns, documentation)
• Code Review -- Load references/review-gate.md for the 10-question review lens (one per commandment)

Quick Reference

#	Commandment	Key Question
1	Design for Failure	"What happens when this fails?"
2	Keep It Simple	"Is there a simpler way?"
3	Test Early	"How will we test this?"
4	Observability	"Can we debug this in production?"
5	Document Intent	"Will future-me understand WHY?"
6	Automate	"Can this be scripted?"
7	Secure by Design	"What could be exploited?"
8	Data Consistency	"What if the input is garbage?"
9	Separate Concerns	"Does this do ONE thing?"
10	Plan for Scale	"What happens at 100x load?"