Feature Sets

Each subfolder is one Feature Set — a themed goal, elaborated once at Inception, then fanned out into Features that repeat through Construction and Release.

A single Feature is a legitimate Feature Set on its own — the wrapper earns its place when it needs the schema-first gate, has its own business justification, and stands alone as a customer-announceable thing. If a proposed entry has no schema impact (or a trivial one) and no broader theme, it belongs in ../improvements/ instead, regardless of how it was initially framed — don't let "it's only one Feature" pull it into feature-sets/ on its own.

A Feature Set folder holds only what that set adds or changes relative to root — it is not a full copy of current state. Root (../schema/, ../adrs/, ../product/) is the single source of truth for "what's true now"; a Feature Set is a diff against it.

Index

Feature Set	Status	Notes
absence-management-mvp	Reverse-engineered placeholder, no PM review yet	Seeded from GitHub issue #397 + 5 sub-issues — no PRD exists for this Feature Set; content is verbatim from the issues only, to be progressively expanded.

feature-sets/<feature-set-slug>/
  concept.md              # business case, justification (Inception) — owner, product-manager, issue-url
  schema-changes.md       # proposed delta to ../schema/ — status in frontmatter
  software-design/        # this set's overall design: design.md (main design file), adr-*.md (design decisions), plus supporting files
  <feature-slug>/
    spec.md                # scope, value, acceptance — owner, product-manager, issue-url
    test-plan.md
    implementation-plan.md  # Nova Architect's output from the Feature Spec → implementation handoff

There is no checklist.md. The Feature Closure Checklist is enforced on the GitHub Issue itself via signed-off.dev, not a markdown file in this repo — see github-private/docs/ai-dlc/project-plan.md's "Discussion — Feature Closure Checklist convention" for the full mechanism.

Frontmatter

Every tracked file carries owner: <name> (@<github-username>) at minimum (always an engineer). concept.md and spec.md additionally carry product-manager: <name> (@<github-username>) and issue-url: <GitHub issue URL> — the Commitment Meeting issue for that Feature Set/Feature. The @handle keeps the field matchable against an issue's actual GitHub assignee (the source of truth on conflict); omit it only if the person has no GitHub account in the org.

schema-changes.md and files under software-design/ (e.g. adr-*.md) additionally carry the delta-file lifecycle block:

---
owner: <name> (@<github-username>)
feature_set: <slug>
status: proposed | applied | superseded
applied_date: <date or null>
supersedes: [<file>, ...]   # optional, if this delta revises an earlier one
---

These files are a permanent record — never deleted or moved once applied. proposed means not yet true; applied means it has been merged into root and is safe to treat as historical confirmation of current state; superseded means a later delta replaced it.

Starting skeletons live with the skills that generate them, not in this repo: skills-product/.claude/skills/nova-feature-set/templates/ (concept.md, schema-changes.md, software-design/adr-example.md) and skills-product/.claude/skills/nova-feature/templates/ (spec.md, test-plan.md). See github-private/docs/ai-dlc/repo-convention.md for the full convention this layout follows — check there before scaffolding, since decisions made there may run ahead of this file.