majiayu000 Code Authoring
Apply these requirements when writing or reviewing code.
Architectural Principles
Simplicity over cleverness. Write obvious code the next developer understands immediately. Avoid premature abstractions.
Type safety is not cleverness. Use enums over magic strings, strongly-typed IDs where warranted, and proper error types over string parsing.
Conventions over configuration. Follow framework conventions and defaults. Do not invent custom patterns when standard ones exist.
Pragmatism over purity. Make practical trade-offs. Do not over-engineer for hypothetical requirements.
YAGNI. Implement only what is required. Do not add configuration for values that won't change, abstractions for single implementations, error handling for impossible states, defensive code against trusted internal callers, or features not requested.
Delete freely. Dead code, unused abstractions, and speculative features are liabilities. Remove them.
Fewer dependencies. Each package is maintenance burden. Prefer built-in framework features.
Explicit over implicit. Magic is hard to debug. Prefer clear, traceable code paths.
CLI Tools for Generation
Use framework-provided commands for file generation:
- .NET:
dotnet new,dotnet add package - Rails:
rails new,rails generate - Node.js:
npm init,npx create-* - Python:
pip install,poetry init
Incremental Development
Implement the minimum required. Do not add error handling for conditions that cannot occur, resilience when infrastructure handles failures, validation for inputs guaranteed by upstream systems, or configurability for values that never change.
Before adding defensive code:
- Is this a real possibility in this context?
- What happens without handling? If the job retries automatically, do not add handling.
- Did the spec explicitly require this?
Execution Context
| Context | Failure Strategy |
|---|---|
| HTTP endpoints | Handle errors, return appropriate status codes |
| Background jobs | Let exceptions bubble, scheduler retries automatically |
| Idempotent operations | Safe to fail and retry |
| Internal methods | Trust callers, do not re-validate |
For background jobs, assume retry-on-failure unless told otherwise. Do not add try/catch that swallows exceptions.
Research Requirements
Training data is outdated. Libraries evolve. Verify before implementing.
Before writing code using external packages:
- Check package versions in project files
- Use WebSearch to find current documentation for that version
- Verify async patterns—many libraries now have native async methods
- Check for breaking changes in major versions
Do not wrap sync methods in Task.Run() when native async exists. Do not hand-roll retry logic when libraries like Polly exist and retries are actually needed.
When uncertain about any API:
WebSearch: "[package name] [version] async methods"
WebSearch: "[package name] [version] best practices 2025"
Code Review
Before reviewing, identify packages and versions, then research current best practices.
Flag: sync-over-async patterns, deprecated APIs with modern replacements, manual implementations of built-in features.
Review Checklist
| Principle | Check |
|---|---|
| Current APIs | Modern async methods? No outdated patterns? |
| Simplicity | Obvious? Unnecessary abstractions? |
| Conventions | Following framework patterns? |
| Pragmatism | Over-engineered for hypotheticals? |
| Dead code | Anything unused to delete? |
| Dependencies | Can built-in features replace packages? |
Issue Priorities
| Priority | Description |
|---|---|
| Critical | Bugs, security issues, data loss risks |
| High | Performance problems, maintainability blockers |
| Medium | Convention violations, missing error handling |
| Low | Style preferences, minor optimizations |
Review Output
Use templates/code-review.md if available. Otherwise structure as:
- Summary (one paragraph)
- Issues (grouped by priority)
- Recommendations (prioritized list)