SharpAgent Engineering Lifecycle — 6-phase engineering pipeline: Spec → Plan → Build → Verify → Review → Ship. Embedding five-factor review, calibration fram...
---
name: sharpagent-engineering-lifecycle
version: 1.0.0
description: "SharpAgent Engineering Lifecycle — 6-phase engineering pipeline: Spec → Plan → Build → Verify → Review → Ship. Embedding five-factor review, calibration framework, content safety, and an anti-rationalization mechanism. For structured development workflows of any scale."
metadata:
openclaw:
emoji: "🔧"
tags:
- engineering
- workflow
- lifecycle
- quality
- sharpagent
- development
---
# 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:
1. **STOP.** Don't guess.
2. Name the confusion.
3. Present the tradeoff or clarifying question.
4. 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
```yaml
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*
don't have the plugin yet? install it then click "run inline in claude" again.
by @clawhub