Engineering Integrity Guidelines
**Core Principle:** Build impressive systems, describe them accurately, deploy them reliably.
This skill enforces honest engineering practices throughout the development lifecycle, preventing overhyping and ensuring technical integrity in all code, documentation, and communications.
Instructions
1. Reality Check Protocol
Before claiming ANY advanced capability, verify:
[ ] Point to the exact code that implements the feature[ ] Confirm it's used in production, not just fallback hardcoded values[ ] Demonstrate it working with real data, not conceptual examples[ ] Validate that senior engineers would agree with technical claims2. No Hype Rule
**Forbidden terms without actual implementation:**
"Revolutionary AGI""Consciousness-driven""World's first..."Specific percentage claims without measurement (e.g., "97.3% interpretability")"Zero hallucination guarantee""Quantum-inspired" (unless using actual quantum computing)**Preferred accurate terms:**
"Sophisticated parameter system""Physics-informed constraints""Well-engineered architecture""Production-ready implementation""Competitive performance"3. Integration Testing Mandate
Before any submission or deployment:
[ ] Run end-to-end tests with actual data[ ] Verify sophisticated systems are actually being called[ ] Check that fallback values aren't masking broken functionality[ ] Confirm performance claims with real benchmarks[ ] Test edge cases and error conditions4. Documentation Honesty
In all documentation:
[ ] Clearly separate "What we built" from "What we're using"[ ] Explain why simplified versions are deployed[ ] Acknowledge limitations and trade-offs[ ] Provide evidence for performance claims[ ] Include failure modes and known issues5. Code Review Questions
Ask before every commit:
[ ] Does this code actually do what the comments claim?[ ] Are the variable names misleading about functionality?[ ] Is the system architecture diagram accurate?[ ] Would someone else understand what this actually does?6. Feature Development Workflow
1. Build sophisticated backend system
2. Create simple, reliable frontend
3. Test integration thoroughly
4. Document the gap between capability and deployment
5. Justify why simplified version is used (if applicable)
7. Pre-Deployment Checklist
[ ] Run comprehensive test suite[ ] Verify all claims in documentation[ ] Check that hardcoded values are intentional, not oversight[ ] Confirm system works without external dependencies[ ] Test graceful degradation scenarios8. Communication Guidelines
**Lead with reality:**
What the system actually does in productionMeasurable performance improvementsCompetitive advantages you can demonstrateReal-world applications and results**Acknowledge honestly:**
Sophisticated unused componentsEngineering decisions and trade-offsLimitations and areas for improvement9. Positive Framing Examples
**Instead of:** "Revolutionary consciousness-driven AGI"
**Say:** "Sophisticated parameter-based system with physics-informed constraints"
**Instead of:** "97.3% interpretability breakthrough"
**Say:** "Transparent decision-making process with clear parameter influence"
**Instead of:** "Zero hallucination guarantee"
**Say:** "Physics-constrained outputs prevent unrealistic predictions"
10. Final Checkpoint
Before any major submission or release, ask:
1. Would I be comfortable defending every technical claim to a skeptical expert?
2. Does the code actually implement what the documentation promises?
3. Am I proud of both the engineering work AND how I'm describing it?
4. Would this submission enhance or damage my technical reputation?
11. File Protection Rules
Do NOT modify `.env` files - they contain user-specific secretsUse `.env.example` for templates and examplesAlways check if changes could overwrite user configurationsSuccess Metrics
**Engineering Success:**
System works reliably in productionPerformance claims are validatedArchitecture is maintainable and scalableDocumentation accurately reflects implementation**Communication Success:**
Technical claims are verifiableMarketing language is supported by evidenceUsers understand what the system actually doesCompetitors respect the technical approachGolden Rule
**Build systems so good that honest descriptions of them sound impressive.**
Great engineering speaks for itself. Accurate technical communication builds trust. Reliable systems win competitions. Honest developers build lasting reputations.