SharpAgent Engineering Lifecycle v1.0.0
Tells your agent how to work. Not scattered prompts — a complete engineering discipline from "what are we building" to "safe deployment." Inspired by addyosmani/agent-skills (⭐39K), fused with SharpAgent five-factor review, calibration framework, and content safety.
Core Operating Rules
These rules apply across ALL phases. Non-negotiable.
1. Surface Assumptions
Before implementing anything non-trivial, explicitly state:
ASSUMPTIONS I'M MAKING:
1. [assumption 1]
2. [assumption 2]
→ Correct me now or I'll proceed with these.
2. Manage Confusion Actively
When encountering inconsistencies, conflicting requirements, or unclear specs:
- STOP. Don't guess.
- Name the confusion.
- Present the tradeoff or clarifying question.
- Wait for resolution.
3. Push Back When Warranted
You're not a yes-machine. When an approach has clear problems:
- Point it out directly + quantify the impact
- Propose an alternative
- Accept the human's override if they decide with full context
4. Enforce Simplicity
100 lines that work beat 1000 lines that are "elegant." After each step, ask: could this be fewer lines? Is this abstraction worth it?
5. Scope Discipline
Touch only what you're asked to touch. No comment cleaning, no adjacent refactoring, no unsolicited "improvements."
6. Verify > Assume
"Seems right" is never sufficient. Passing tests, build output, or runtime data, or it's not done.
Contract
contract:
name: sharpagent-engineering-lifecycle
version: "1.0.0"
category: workflow
trust_level: verified
reads:
- Project
- Task
- Goal
writes:
- Task
- Document
preconditions:
- "Task or feature description must be provided"
- "Access to file system for reading/writing code"
postconditions:
- "All lifecycle phases completed or explicitly skipped"
- "Verification gates passed for completed phases"
calibration:
default_mode: professional
modes_supported: [professional, deep]
compliance:
jurisdiction: global
safety_level: standard
lifecycle:
status: active
publish_as: SharpAgent
Lifecycle: 6 Phases · 12+ Skills
[1. SPEC] → [2. PLAN] → [3. BUILD] → [4. VERIFY] → [5. REVIEW] → [6. SHIP]
Phase 1: SPEC — Spec First
Core principle: Never code without a spec.
Each step's output is the next step's input.
Idea input
↓
[1.1 Idea Refinement] — Divergent/convergent thinking, refine fuzzy concepts
↓
[1.2 Specification Document] — PRD: goals, architecture, interfaces, boundaries, test strategy
↓
[1.3 Five-Factor Review] — Every core assumption passes five-factor verification
↓
Output: spec.md + approved_by
1.1 Idea Refinement
- Divergent: list all possibilities (no feasibility filter)
- Convergent: select 1-3 most valuable directions
- Output: concrete proposal (1-2 paragraphs)
1.2 Specification
- Goals & metrics (how do we measure success)
- Architecture highlights
- Interface design (contract-first)
- Boundaries (what's out of scope)
- Test strategy (unit/integration/E2E tiers)
- Rollback plan
1.3 Five-Factor Review
- Every core assumption gets a five-factor check
- 🔗 Source: what's the assumption based on?
- 🧠 Logic: is the reasoning chain complete?
- 🌍 Compliance: any compliance risks?
- 🏳️ Interest: hidden bias in this choice?
- 🔄 Cross: do other approaches support this assumption?
Phase 2: PLAN — Decompose
Core principle: Big tasks break into small, independently verifiable pieces.
Spec document
↓
[2.1 Task Breakdown] — Split into independently verifiable tasks
↓
[2.2 Dependency Sorting] — Order by dependency graph
↓
[2.3 Acceptance Criteria] — Clear "done" definition per task
↓
Output: tasks.md + acceptance_criteria
2.1 Task Breakdown
- Each task ≤ one evening's work
- Natural commit boundaries
- Independently testable and verifiable
2.2 Dependency Sorting
- Directed Acyclic Graph (DAG) structure
- Parallel tasks marked
- Critical path identified
2.3 Acceptance Criteria
- Explicit "how do we know it's done"
- Anti-pattern: "it works" → "unit test coverage ≥ 80%"
Phase 3: BUILD — Incremental
Core principle: Thin slices, one commit at a time, safety first.
Task list
↓
[3.1 Thin-Slice Coding] — One slice at a time
↓
[3.2 Auto-Write Tests] — Each slice carries tests
↓
[3.3 Contract Validation] — Interfaces/types/boundaries match spec
↓
[3.4 Anti-Self-Deception Check] — Adversarial review of your own code
↓
Output: code_commit + test_result + contract_check
3.1 Thin-Slice Coding
- 1-2 files at a time
- Atomic commits
- Rollback safety is the baseline
3.2 Auto-Write Tests
- Tests are proof, not overhead
- Red-Green-Refactor (TDD cycle)
- Every function has corresponding tests
3.3 Contract Validation
- Interface signatures match spec
- Type safety verified
- Boundary values handled
- Error paths return properly
3.4 Anti-Self-Deception Check
- Adversarial review of code you just wrote
- "Did I cut corners?" "What edge case did I miss?" "Really covered by tests?"
Phase 4: VERIFY — Prove It Works
Core principle: All verification must be repeatable, every round must have evidence.
Build output
↓
[4.1 Unit Tests] — All logic paths covered
↓
[4.2 Integration Verification] — Component interaction tests
↓
[4.3 End-to-End Tests] — Critical paths E2E
↓
[4.4 Security Scan] — OWASP Top 10 check
↓
Output: test_report.md
4.1 Unit Tests
- 100% core logic path coverage
- Boundary conditions tested
- Error paths tested
4.2 Integration
- Module interface tests
- Data flow verification
- External dependency mock validation
4.3 End-to-End
- Critical user paths
- Error scenarios
- Performance baseline
4.4 Security Scan
- Input validation
- Permission checks
- Sensitive info exposure
Phase 5: REVIEW — Gate Check
Core principle: Five-axis review. Every axis must pass.
Verification output
↓
[5.1 Code Quality] — Clean/readable/maintainable
↓
[5.2 Architecture Consistency] — Matches spec
↓
[5.3 Performance Assessment] — Measure first, optimize second
↓
[5.4 Security Review] — OWASP + least privilege
↓
[5.5 Documentation Update] — Log what changed and why
↓
Output: review_report.md + approval_gate
5.1 Code Quality
- Functions < 30 lines
- Meaningful naming conventions
- Comments say "why" not "what"
- No dead code
5.2 Architecture Consistency
- Matches spec's architecture design
- No unapproved new dependencies
- No layer violations
5.3 Performance Assessment
- Measure before optimizing
- Before/after comparison data
- Optimize bottlenecks only
5.4 Security Review
- OWASP Top 10 checklist
- Least privilege principle
- No hardcoded secrets
5.5 Documentation Update
- Spec updated (matches actual implementation)
- ADR (Architecture Decision Record)
- API docs updated if interface changed
Phase 6: SHIP — Safe Deployment
Core principle: Faster AND safer is good. Faster WITHOUT safety is not.
Gate approval
↓
[6.1 Pre-Launch Checklist] — Item-by-item confirmation
↓
[6.2 Progressive Rollout] — Blue-green / canary
↓
[6.3 Monitoring Setup] — Key metrics post-launch
↓
[6.4 Rollback Plan] — Immediate revert if something breaks
↓
[6.5 Retrospective] — Record what was learned (success or failure)
↓
Output: release_notes.md + postmortem.md
6.1 Pre-Launch Checklist
- ✅ All tests passing
- ✅ Rollback script ready
- ✅ Version bumped
- ✅ CHANGELOG updated
- ✅ Monitoring metrics configured
6.2 Progressive Rollout
- 1% → 10% → 50% → 100%
- Observation period at each stage
- Stop immediately if anomalies found
6.3 Monitoring Setup
- Key business metrics
- Error rate
- Latency changes
- Resource usage
6.4 Rollback Plan
- Rollback steps in release notes
- Rollback script already tested
- Post-rollback verification steps
6.5 Retrospective
- Success or failure, log it as [LRN/ERR]
- Success: what went well? How to replicate?
- Failure: root cause? How to prevent?
Phase Quick Reference
| Phase | What | Output | Time Est. |
|---|---|---|---|
| SPEC | Requirements → Spec → Five-factor | spec.md | 1-2h |
| PLAN | Breakdown → Sort → Acceptance | tasks.md | 0.5-1h |
| BUILD | Slice → Code → Test → Anti-self-check | code + tests | 2-6h |
| VERIFY | Unit → Integration → E2E → Security | test_report.md | 1-2h |
| REVIEW | Five-axis → Approval | review_report.md | 1h |
| SHIP | Checklist → Canary → Monitor → Retro | release_notes.md | 1h |
Quality Gates
| Gate | Check | Must pass to proceed to |
|---|---|---|
| Spec gate | All core assumptions five-factor reviewed | Plan |
| Plan gate | Every task has acceptance criteria | Build |
| Code gate | TDD + contract validation + anti-self-deception | Verify |
| Verify gate | Unit/Integration/E2E/Security all pass | Review |
| Review gate | All five axes green | Ship |
| Ship gate | Pre-launch checklist all ✅ | Deploy |
Integration Points
Five-Factor Review
- Phase 1 embeds five-factor review (every core assumption)
- Phase 5 review can trigger five-factor checks
Calibration Framework
- Output style fully controlled by calibration
- Deep mode: thorough detailed analysis
- Professional mode: standard output
Content Safety
- Phase 4 security scan integrates content safety engine
- Phase 6 rollback plan includes security incident response
Edge Cases
| Situation | Action |
|---|---|
| Tiny change (rename a variable) | Skip SPEC/PLAN, go straight to BUILD+VERIFY+REVIEW |
| Hotfix (production outage) | May skip phases, but retrospective must catch up |
| Unfamiliar tech stack | Invest time in Source-Driven Development in SPEC phase |
| Frequent requirement changes | Each change goes back to SPEC phase |
| Single-line change | Fast track: BUILD(minimal) → VERIFY → REVIEW → SHIP |
Version History
- v1.0.0 — Initial release. 6-phase engineering pipeline, 12+ skills, 3-tier quality gate system.
SharpAgent · MIT-0 · 2026-05-11