# Software Lifecycle

How to work in a Software Lifecycle project (the `software-lifecycle` starter pack)...

- Repository: https://github.com/inkeep/open-knowledge (4756 stars)
- Category: Design
- License: GPL-3.0
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add inkeep/open-knowledge --skill software-lifecycle -g -a claude-code -y`
Codex: `npx skills add inkeep/open-knowledge --skill software-lifecycle -g -a codex -y`
Cursor: `npx skills add inkeep/open-knowledge --skill software-lifecycle -g -a cursor -y`
Gemini CLI: `npx skills add inkeep/open-knowledge --skill software-lifecycle -g -a gemini-cli -y`

## Description

How to work in a Software Lifecycle project (the `software-lifecycle` starter pack): proposals → decisions → specs → postmortems, plus guides. Read when the project has these folders, or when asked how this project is organized. Carries the doc lifecycle, status flows, and per-folder agent behaviors so that guidance does not live inside template bodies or folder descriptions. The five workflows, frame a proposal, write a spec, record a decision, write a postmortem, review a design, each ship as their own sibling skill in this pack. Complements the platform `open-knowledge` skill; does not replace it.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Software Lifecycle pack, how to work here

This project holds the doc lifecycle for an engineering team or OSS project. The flow is **proposals → decisions → specs → postmortems**, with **guides** as the how-to bucket. This skill holds the workflow so templates and folder descriptions stay clean.

> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation, this layers the lifecycle conventions on top.

## The flow

```
proposals/    in-flight RFC-shape design proposals
   ↓ accepted
decisions/    frozen ADRs (the record of what was decided)
   ↓ derived
specs/        implementation specs for accepted proposals
   ↓ when things break
postmortems/  blameless incident write-ups
guides/       how-to / onboarding / runbooks (referenced throughout)
```

## Per-folder rules + agent behaviors

**`proposals/`**, One file per proposal (`0001-feature-name.md`). Status flows `draft → fcp → accepted/rejected`. An accepted proposal graduates to a record in `decisions/`. Shape: Motivation / Design / Drawbacks / Alternatives / Unresolved questions. *Agent: when a proposal sits at `status: draft` more than 14 days, surface it for the author to advance, park, or close.*

**`decisions/`**, Architecture Decision Records (MADR / Nygard shape). Frozen once accepted. One file per decision (`NNNN-title.md`); status `proposed/accepted/deprecated/superseded`. A new decision that supersedes an older one links back via `Supersedes:`. *Agent: on a new decision, scan existing records touching the same subsystem and surface `Supersedes:` candidates before commit.*

The rest: https://github.com/inkeep/open-knowledge/blob/HEAD/packages/server/assets/skills/packs/software-lifecycle/SKILL.md