| name | description |
|---|---|
engineer-in-a-box |
Canonical engineering workflow for feature development. Design before you code. Review before you ship. Test before you submit. Use when helping engineers plan, implement, review, test, or submit feature work through a structured process. |
Engineer in a Box is a disciplined workflow for feature development that emphasizes architectural thinking, code quality, and systematic validation. It enforces a sequence of deliberate steps: design the solution, implement it following the design, review the implementation for correctness, test thoroughly, and submit with confidence.
Follow these five steps in order. Each step has clear entrance criteria (what you need before starting) and exit criteria (what you should have when done).
When to start: You have a feature request and understand the requirements.
What to do: Think carefully about architecture before writing code. Consider:
- How does this fit into the existing system?
- What are the edge cases?
- What could go wrong?
- Is there a simpler approach?
Exit criteria: You have a clear design that you understand and can articulate. Document key decisions and trade-offs.
When to start: Design is complete and reviewed.
What to do: Write the code for the feature. Follow the design closely. Keep it simple. Don't gold-plate or add features that weren't in the design.
Exit criteria: The implementation is complete, matches the design, and is ready for review.
When to start: Implementation is complete.
What to do: Review the implementation. Check for:
- Does it match the design?
- Are there obvious bugs or issues?
- Is it readable and maintainable?
- Are there security concerns?
Exit criteria: Review is complete. Either approve for testing or request changes.
When to start: Implementation has passed review.
What to do: Write and run tests:
- Unit tests for new code
- Integration tests if needed
- Run the full test suite
- Fix any regressions
Exit criteria: All tests pass. No regressions. Test coverage is appropriate for the changes.
When to start: Tests pass.
What to do: Submit for merge:
- Final check:
git status,git diff - Commit with a clear message
- Follow your role's git workflow for landing code
Exit criteria: Code is merged and deployed.
Apply this workflow when:
- Implementing a new feature
- Making significant changes to existing code
- Working on code that impacts other teams or systems
- You want to ensure quality and minimize post-deployment issues
Skip steps only if you have a documented reason (e.g., skipping design for trivial bug fixes, skipping full test suite for emergency hotfixes).