360 Secure SkillHub
360 安全技能中心

Sharpagent Engineering Lifecycle

该 Skill 是一套纯文本的工程开发纪律:把工作拆成 SPEC、PLAN、BUILD、VERIFY、REVIEW、SHIP 六阶段,规定各阶段输出物、验收标准与质量门禁,并加入假设披露、范围控制、反自我欺骗检查与回滚复盘要求。不含脚本或外部服务调用。

yezhaowang888-stack
yezhaowang888-stack
热度 23.37
最近更新 2026-05-11 17:48:15
分类:开发依赖:纯提示词应用场景:代码生成 / 代码审查 / DevOps / 工作流 ...

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add sharpagent-engineering-lifecycle
Metadata
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

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