software-lifecycle

Organizes engineering documentation across proposals, decisions, specs, postmortems, and guides.

Updated Sep 7, 2026
One-click install
npx skills add https://github.com/jcafeitosa/anxionOS --skill software-lifecycle-jcafeitosa
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: software-lifecycle
Source: https://github.com/jcafeitosa/anxionOS/tree/main/.cursor/skills/software-lifecycle
Command: npx skills add https://github.com/jcafeitosa/anxionOS --skill software-lifecycle-jcafeitosa

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineering teams lose track of why decisions were made and how designs evolved because proposals, ADRs, specs, and postmortems live in scattered, inconsistent documents. This Skill defines the doc lifecycle and per-folder conventions so every artifact follows a predictable status flow. ## Core Features & Use Cases - Lifecycle Conventions: Defines the flow from proposals (draft → fcp → accepted/rejected) to frozen ADRs, derived specs, and blameless postmortems, with guides as the how-to bucket. - Per-Folder Agent Behaviors: Encodes proactive rules such as surfacing stale draft proposals after 14 days, suggesting Supersedes links for new decisions, and stubbing guides from postmortem action items. - Workflow Routing: Points to five sibling skills (frame-a-proposal, write-a-spec, record-a-decision, write-a-postmortem, review-a-design) so procedural guidance loads only when needed. - Use Case: A team member asks how to document an accepted RFC; the Skill explains graduating the proposal into a MADR-shaped decision record and deriving a spec-kit style spec folder. ## Quick Start Ask the agent how to document a new design proposal in this project and follow the proposals folder conventions it describes.

Frequently Asked Questions about software-lifecycle

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure engineering design docs in a project?▼

Use the proposals → decisions → specs → postmortems flow: draft an RFC-shaped proposal, graduate accepted ones into frozen ADRs, derive spec-kit style spec folders, and write blameless postmortems for incidents. Guides hold how-to and runbook content.

What is the difference between a proposal and a decision record?▼

A proposal is an in-flight design document with status draft, fcp, accepted, or rejected. A decision record is a frozen MADR or Nygard-shaped ADR capturing what was actually decided, with statuses proposed, accepted, deprecated, or superseded.

Does this skill work without the OpenKnowledge MCP server?▼

No. The skill requires an agent host with the OpenKnowledge MCP server configured, and it is installed project-local via ok seed --pack software-lifecycle. The platform open-knowledge skill still governs all markdown operations.

How do I write an ADR that replaces an older decision?▼

Create a new file in decisions/ named NNNN-title.md and link back to the older record with a Supersedes field. The skill instructs agents to scan existing records touching the same subsystem and surface Supersedes candidates before commit.

When should I write a postmortem versus a guide?▼

Write a postmortem after an incident using the blameless Google SRE shape: summary, timeline, root cause, and action items. Write a guide for how-to, onboarding, or runbook content, and keep its last_verified field current so stale guides surface in reviews.