Backend Lifecycle Execution
Purpose
- Run
/implement-equivalent backend lifecycle directly in Claude. - Preserve the original lifecycle controls without subagents.
Execution Contract
This skill follows the non-entry execution contract standard.
Required contract_extensions: lifecycle_scale, required_docs.
See codex-execution-contract.md and non-entry-execution-contract-template.md for full rules.
input:
objective: "Execute medium backend lifecycle"
contract_extensions: { lifecycle_scale: "medium", required_docs: ["Design Doc", "Work Plan"] }
output:
status: "completed"
quality_gate:
gate_id: "backend-lifecycle-doc-check"
gate_type: "implementation"
trigger: "post-phase validation"
criteria:
- "Required lifecycle documents are complete"
- "Lifecycle contract fields remain aligned"
result: "pass"
evidence:
- "Required docs completed"
blockers: []
branching:
on_pass: "handoff"
on_fail: "revise"
max_cycles: 2
contract_extensions: { lifecycle_scale: "medium", required_docs: ["Design Doc", "Work Plan"] }
Contract Compliance
Emit structured output compliant with codex-execution-contract.md.
Always include required fields: status, summary, changed_files, tests, quality_gate, blockers, next_actions.
Include required extension echo fields in contract_extensions: lifecycle_scale, required_docs.
Treat missing required fields or invalid status values as contract violations and regenerate before handoff.
Template reference: non-entry-execution-contract-template.md.
Validate required input fields from non-entry-execution-contract-template.md (objective, scope, constraints, acceptance_criteria, allowed_commands, sandbox_mode) before proceeding.
Scale Determination
| Scale | Affected files | Required docs |
|---|---|---|
| Small | 1-2 | simplified plan |
| Medium | 3-5 | Design Doc + Work Plan |
| Large | 6+ | PRD + Design Doc + Work Plan (+ ADR when needed) |
ADR is required when architecture, technology, or data flow changes.
Lifecycle Flow
Large
- Requirement clarification and scope confirmation.
- PRD creation/update.
- PRD review with
[Stop: pre-design-approval]+[Approve: design-approval]. - ADR creation when needed.
- ADR review with
[Stop: pre-design-approval]+[Approve: design-approval]. - Design Doc creation.
- Cross-document consistency check.
- Design handoff with
[Stop: pre-design-approval]+[Approve: design-approval]. - Test skeleton planning (integration and E2E).
- Work plan creation.
- Implementation boundary with
[Stop: pre-implementation-approval]+[Approve: implementation-start]. - Implementation loop via
backend-task-quality-loop.
Medium
- Requirement clarification and scale confirmation.
- Design Doc creation.
- Review and consistency check.
- Design handoff with
[Stop: pre-design-approval]+[Approve: design-approval]. - Test skeleton planning.
- Work plan creation.
- Implementation boundary with
[Stop: pre-implementation-approval]+[Approve: implementation-start]. - Implementation loop via
backend-task-quality-loop.
Small
- Simplified plan creation.
- Implementation boundary with
[Stop: pre-implementation-approval]+[Approve: implementation-start]. - Implementation loop via
backend-task-quality-loop.
Requirement Change Handling
- If new requirements alter scope or design assumptions, emit
[Stop: requirement-change-detected]+[Approve: route-selection]. - Re-run scale determination and restart lifecycle from the correct phase.
Mandatory Checks Before Implementation Loop
- Build and test tooling availability.
- Commit strategy availability.
- Quality gate definition (format/lint/static/build/tests).
Hard Rules
- Never bypass
[Stop: pre-design-approval]+[Approve: design-approval]on document phases. - Never skip quality gate before claiming task completion.
- Never continue implementation when requirement changes are unresolved.
Stop/Approval Protocol
Use canonical markers [Stop: <Gate Name>] and classify each stop as approval_gate or escalation_gate.
Use normalized stop payloads with status, full gate record fields required by stop-approval-section-template.md (including gate_name, gate_type, trigger, ask_method, required_user_action, resume_if, fallback_if_rejected), and quality_gate.result.
approval_gate resumes only with explicit user approved: true; escalation_gate resumes only after user direction/reroute.
Respect the batch boundary: emit [Stop: pre-implementation-approval] before any autonomous implementation loop.
Set max_revision_cycles: 2; if exceeded, escalate and require human intervention.
Template reference: ../workflow-entry/references/stop-approval-section-template.md.
Stop points for this skill:
[Stop: pre-design-approval](approval_gate)[Stop: pre-implementation-approval](approval_gate)[Stop: high-risk-change](approval_gate)[Stop: requirement-change-detected](escalation_gate)[Stop: quality-gate-failed](escalation_gate)[Stop: revision-limit-reached](escalation_gate)
Quality Gate Evidence
Orchestrator ownership: this skill emits quality_gate evidence and decides pass/fail/blocked branching.
Use canonical gate fields (gate_id, gate_type, trigger, criteria, result, evidence, blockers, branching) per template.
Normalize local outcomes to result: pass|fail|blocked before handoff.
If result: blocked, emit [Stop: quality-gate-failed] and pause autonomous flow.
Use gate-type branching.max_cycles limits from quality-gate-evidence-template.md (default 2, stricter limits win).
Map gate_type based on the current lifecycle phase:
- Document creation and review phases:
gate_type: document - Cross-phase consistency checks:
gate_type: consistency - Implementation and post-change validation:
gate_type: implementation
Converted and distributed by TomeVault — claim your Tome and manage your conversions.