trust-principles
TRUST quality principles (Test-first, Readable, Unified, Secured, Trackable) ensuring production-ready code. Use when implementing, reviewing, testing, or evaluating code quality across all development phases.
When & Why to Use This Skill
The TRUST quality principles skill is a comprehensive framework designed to ensure production-ready code through five core pillars: Test-first, Readable, Unified, Secured, and Trackable. It empowers developers and teams to maintain high engineering standards by integrating rigorous testing, clear documentation, architectural consistency, robust security practices, and enhanced observability into every stage of the software development lifecycle (SDLC).
Use Cases
- Implementing Test-Driven Development (TDD) to clarify requirements and ensure code testability before the implementation phase.
- Conducting standardized code reviews to verify readability, descriptive naming, and adherence to project-specific conventions.
- Strengthening application security by enforcing strict input validation and preventing common vulnerabilities like SQL injection and XSS.
- Improving system maintainability and debugging efficiency through structured logging, code tagging (@FEAT, @COMP), and clear commit histories.
- Establishing unified architectural patterns and consistent error-handling strategies across large-scale, multi-developer projects.
| name | trust-principles |
|---|---|
| description | TRUST quality principles (Test-first, Readable, Unified, Secured, Trackable) ensuring production-ready code. Use when implementing, reviewing, testing, or evaluating code quality across all development phases. |
TRUST Quality Principles
Instructions
Apply all 5 principles
T - Test-First: Write tests before implementation R - Readable: Clear names and documentation U - Unified: Consistent patterns and conventions S - Secured: Input validation, no vulnerabilities T - Trackable: Tags, logs, clear commits
For implementation
- Write tests first (TDD)
- Use descriptive names
- Follow project patterns
- Validate all inputs
- Add tags and logs
For review
- Verify test coverage
- Check code clarity
- Ensure consistency
- Validate security
- Confirm documentation
Example
Python Example
# T - Test first
def test_validator():
assert Validator.validate({'id': '123'}) == True
# All TRUST principles applied
# @FEAT:order @COMP:validator @TYPE:utility # T - Trackable
class OrderValidator:
'''Validates orders before processing''' # R - Readable
def validate(self, order: dict) -> bool:
# S - Secured: Input validation
if not isinstance(order, dict):
raise TypeError("Order must be dict")
# U - Unified: Standard pattern
if 'order_id' not in order:
return False
# T - Trackable: Log
logger.info(f"Validated: {order['order_id']}")
return True
JavaScript/TypeScript Example
// T - Test first
test('validator validates orders', () => {
expect(validator.validate({id: '123'})).toBe(true);
});
// All TRUST principles applied
// @FEAT:order @COMP:validator @TYPE:utility // T - Trackable
class OrderValidator {
/**
* Validates orders before processing // R - Readable
*/
validate(order) {
// S - Secured: Input validation
if (typeof order !== 'object' || order === null) {
throw new TypeError('Order must be object');
}
// U - Unified: Standard pattern
if (!('orderId' in order)) {
return false;
}
// T - Trackable: Log
logger.info(`Validated: ${order.orderId}`);
return true;
}
}
Go Example
// T - Test first
func TestValidator(t *testing.T) {
order := map[string]string{"id": "123"}
if !validator.Validate(order) {
t.Error("Expected validation to pass")
}
}
// All TRUST principles applied
// @FEAT:order @COMP:validator @TYPE:utility // T - Trackable
// OrderValidator validates orders before processing // R - Readable
type OrderValidator struct{}
// Validate checks if order is valid
func (v *OrderValidator) Validate(order map[string]interface{}) bool {
// S - Secured: Input validation
if order == nil {
panic("Order must not be nil")
}
// U - Unified: Standard pattern
if _, ok := order["order_id"]; !ok {
return false
}
// T - Trackable: Log
logger.Info(fmt.Sprintf("Validated: %v", order["order_id"]))
return true
}
Checklist
[ ] T: Tests pass?
[ ] R: Clear and documented?
[ ] U: Follows conventions?
[ ] S: Security applied?
[ ] T: Tagged and logged?
Detailed Breakdown
T - Test-First (TDD)
Principle: Write tests before code
Benefits:
- Clarifies requirements
- Ensures testability
- Prevents over-engineering
- Documents expected behavior
Process:
- Write failing test
- Write minimal code to pass
- Refactor while keeping tests green
Example TDD Cycle:
# 1. Write failing test
def test_calculate_total():
cart = Cart([Item(price=10), Item(price=20)])
assert cart.calculate_total() == 30
# 2. Minimal implementation
class Cart:
def __init__(self, items):
self.items = items
def calculate_total(self):
return sum(item.price for item in self.items)
# 3. Refactor (extract method)
class Cart:
def __init__(self, items):
self.items = items
def calculate_total(self):
return self._sum_prices()
def _sum_prices(self):
return sum(item.price for item in self.items)
R - Readable
Principle: Code should read like prose
Guidelines:
- Descriptive names (no abbreviations)
- Clear function purposes
- Comments explain WHY, not WHAT
- Consistent formatting
Examples:
❌ Not Readable:
def prc(o): # What is prc? What is o?
t = 0
for i in o:
t += i['p'] * i['q']
return t
✅ Readable:
def calculate_order_total(order_items):
"""Calculate total price for all items in order"""
total = 0
for item in order_items:
total += item['price'] * item['quantity']
return total
Comment Quality:
❌ Bad comments (state the obvious):
# Increment counter
counter += 1
# Loop through users
for user in users:
✅ Good comments (explain WHY):
# Batch size of 100 prevents memory overflow on large datasets
BATCH_SIZE = 100
# Retry 3 times because payment gateway has transient failures
MAX_RETRIES = 3
U - Unified (Consistency)
Principle: Follow project patterns consistently
Areas of Consistency:
Naming Conventions
# ✅ Consistent get_user() get_order() get_product() # ❌ Inconsistent get_user() fetchOrder() retrieve_product()Error Handling
# ✅ Consistent pattern def get_user(id): if not id: raise ValueError("ID required") # ... def get_order(id): if not id: raise ValueError("ID required") # ...Project Structure
✅ Unified architecture services/ user_service.py order_service.py product_service.py ❌ Inconsistent architecture services/user_service.py order_manager.py product/handler.pyAPI Responses
// ✅ Consistent format {"data": {...}, "error": null} {"data": null, "error": "Error message"} // ❌ Inconsistent format {"user": {...}} {"error": "Error"} {"success": true, "result": {...}}
S - Secured
Principle: Never trust input, always validate
Security Checklist:
Input Validation
def process_payment(amount, currency): # Validate types if not isinstance(amount, (int, float)): raise TypeError("Amount must be numeric") # Validate ranges if amount <= 0: raise ValueError("Amount must be positive") # Validate enums if currency not in ['USD', 'EUR', 'GBP']: raise ValueError("Invalid currency")SQL Injection Prevention
# ❌ Vulnerable query = f"SELECT * FROM users WHERE id = '{user_id}'" # ✅ Secure query = "SELECT * FROM users WHERE id = ?" db.execute(query, [user_id])XSS Prevention
# ❌ Vulnerable return f"<h1>Hello {user_name}</h1>" # ✅ Secure (auto-escaped) return render_template('hello.html', name=user_name)Password Security
# ❌ Weak password_hash = hashlib.md5(password.encode()).hexdigest() # ✅ Secure import bcrypt password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt())
Reference: See @security-checklist skill for complete guide
T - Trackable
Principle: Make debugging easy
Components:
Tags (Code organization)
# @FEAT:payment @COMP:service @TYPE:core class PaymentService: passLogging (Runtime information)
# Appropriate log levels logger.debug("Detailed diagnostic info") logger.info("Normal operation milestone") logger.warning("Something unexpected but handled") logger.error("Error that needs attention")Commits (Change history)
# ✅ Clear commit git commit -m "Add payment validation for negative amounts (Issue #42)" # ❌ Unclear commit git commit -m "fix stuff"Monitoring (Observability)
# Add metrics for critical operations def process_payment(amount): start_time = time.time() try: result = payment_gateway.charge(amount) metrics.record('payment.success', 1) return result except Exception as e: metrics.record('payment.failure', 1) raise finally: duration = time.time() - start_time metrics.record('payment.duration', duration)
Reference: See @tag-based-search skill for tagging guide
TRUST Review Checklist
For code-reviewer:
## TRUST Principles Review
### T - Test-First
- [ ] Tests exist for new code?
- [ ] Tests were written before implementation (when possible)?
- [ ] All tests pass?
- [ ] Edge cases covered?
### R - Readable
- [ ] Function/variable names descriptive?
- [ ] Complex logic explained with comments?
- [ ] Code flows logically?
- [ ] No magic numbers (constants defined)?
### U - Unified
- [ ] Follows project naming conventions?
- [ ] Error handling consistent with codebase?
- [ ] Architecture patterns maintained?
- [ ] API response format consistent?
### S - Secured
- [ ] All inputs validated?
- [ ] No SQL injection vulnerabilities?
- [ ] No XSS vulnerabilities?
- [ ] Passwords hashed (if applicable)?
- [ ] No hardcoded secrets?
### T - Trackable
- [ ] Tags added (@FEAT, @COMP, @TYPE)?
- [ ] Appropriate logging?
- [ ] Commit message clear?
- [ ] Metrics/monitoring added (if critical)?
**Overall:** [APPROVED | NEEDS_REVISION]
Integration with Workflow
Step 3 (Implementation):
- Apply all 5 TRUST principles
- Verify with self-checklist
Step 4 (Code Review):
- code-reviewer uses TRUST checklist
- NEEDS_REVISION if any principle violated
Step 7 (Testing):
- T (Test-First) verified through test execution
- Edge cases confirmed
Step 8 (Test Review):
- test-reviewer confirms test quality
- Ensures tests validate TRUST principles
For detailed principles, see reference.md For more examples, see examples.md