---
name: lifecycle-update
description: Propose an update to root lifecycle.yaml after concrete evidence of a major project change, such as first production delivery, a maintenance decision or retirement, or when reassessment is requested. Do not perform periodic lifecycle audits.
---

# Propose a lifecycle transition

Read the current root `lifecycle.yaml` and the bundled
[profile definitions](../lifecycle/references/profiles.md). Use
[the schema](../lifecycle/references/lifecycle.schema.json) for the proposed
declaration. Both lifecycle skills must be installed together; if these resources
are unavailable, report the missing installation rather than inventing policy.

Act on an observed event that materially changes the profile, or an explicit
reassessment request. Relevant events include actual first production delivery,
an explicit maintenance-only decision, confirmed retirement, or demonstrated
resolution of the fragility documented for `legacy`. Becoming older is not an
event and profiles need not advance sequentially.

Establish the event from an explicit user statement or evidence of the actual
operational target or distribution. Distinguish verified behavior from reported
behavior. A branch name, tag, merge, green CI run, deployment command, queued job,
or preview alone does not prove production delivery. A failed or rolled-back
rollout does not establish a lasting transition. Do not claim all users have
migrated or stopped using the project without evidence.

When a transition is justified, present:

- The current and proposed profile, with the concrete reason.
- The evidence and its source, including uncertainty that affects the choice.
- The minimal proposed YAML diff and resulting changes to how agents work.

Propose the change in the conversation, then wait for authorization to apply that
specific change, unless already authorized by the user's request. A report such
as "we deployed to production" supplies evidence; it is not by itself an
instruction to edit the declaration. Do not create a proposal file, open a PR,
or post a comment as a substitute for approval.

If approved, reread the declaration and ensure the proposal still applies. Update
only the authorized fields, preserving useful notes and comments. Check the
schema and the single-document, unique-key YAML format, then reread and apply the
new profile using `lifecycle`. Do not deploy, merge, publish, or perform a
migration as part of the metadata update.

When evidence is insufficient, leave the declaration unchanged and identify the
specific fact needed only if it affects ongoing work. Otherwise stay quiet.
Do not repeat a declined or deferred proposal in the same conversation without
new evidence or a request. Do not introduce polling, timestamps, transition logs
or periodic reminders.