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:

text

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#

text

[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.

text

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.

text

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.

text

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.

text

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.

text

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.

text

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#

PhaseWhatOutputTime Est.SPECRequirements → Spec → Five-factorspec.md1-2hPLANBreakdown → Sort → Acceptancetasks.md0.5-1hBUILDSlice → Code → Test → Anti-self-checkcode + tests2-6hVERIFYUnit → Integration → E2E → Securitytest_report.md1-2hREVIEWFive-axis → Approvalreview_report.md1hSHIPChecklist → Canary → Monitor → Retrorelease_notes.md1h

Quality Gates#

GateCheckMust pass to proceed toSpec gateAll core assumptions five-factor reviewedPlanPlan gateEvery task has acceptance criteriaBuildCode gateTDD + contract validation + anti-self-deceptionVerifyVerify gateUnit/Integration/E2E/Security all passReviewReview gateAll five axes greenShipShip gatePre-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#

SituationActionTiny change (rename a variable)Skip SPEC/PLAN, go straight to BUILD+VERIFY+REVIEWHotfix (production outage)May skip phases, but retrospective must catch upUnfamiliar tech stackInvest time in Source-Driven Development in SPEC phaseFrequent requirement changesEach change goes back to SPEC phaseSingle-line changeFast 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