| 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