Lifecycle approve plan

Approve the org plan and seed assignments

When to use

• On the opportunity, not an assignment. The leader has written the organization-wide execution plan and triaged out assignments that do not apply.
• The opportunity's current_stage is alignment_step_1. This skill re-reads that from the server and stops if it moved.
• The user says "approve the plan", "distribute to the teams", "seed the assignments".

This is the opportunity-level half of alignment. Its per-service half — a service owner accepting their refined brief — is lifecycle-accept-plan.

Binary check

Run command -v glassity before the first CLI call. If it is missing, stop and tell the user to install it with brew install glassity/tap/glassity or from https://github.com/glassity/cli/releases. No account yet? Sign up at app.glassity.cloud.

Pre-flight, no mutation

1. Re-read the authoritative state, because it can move between the moment the leader decides and the moment the request is sent:

   glassity --output=json opp show "<opportunity-id>"
   

   If current_stage is not alignment_step_1, or the plan is already approved, render:

   The opportunity moved under you (server says stage=<X>). Refresh and re-evaluate before retrying — nothing was mutated.

   Stop. Do not redeem any token.

2. Locate the org plan. The server pins the newest file matching plans/*-plan.md:

   ls plans/*-plan.md
   

   If there is none, stop and write plans/<YYYY-MM-DD>-<slug>-plan.md first. It carries the how: per-account decisions, recipients, thresholds, module structure, and the per-team checklist.

3. Commit the plan. Approval pins the plan's commit, so it has to be committed on the branch the server reads before you approve:

   git add plans/<file>
   git commit -m "Org execution plan"
   

   Then tell the user to push the branch and open a pull request, or to run the push themselves. Do not push on their behalf — an implicit push to a shared branch is not yours to make. Skip this step entirely if the plan is already committed and pushed.

Triage first — optional, each its own confirmation

Archive any assignment that needs no work before approving. Only suggested assignments are seeded, so archived ones drop out cleanly:

glassity --output=json opp transition "<assignment-id>" \
  --target-state archived \
  --comment "<why this account or service needs no work>"

Phase 1 — approve

glassity --output=json opp approve "<opportunity-id>"

Show the verbatim plan from stderr to the leader — it names the opportunity and the approval. Wait for an explicit "yes", then redeem phase 2 with --confirm-token=<token> in a separate invocation.

Approval pins the newest plans/*-plan.md, synthesizes a per-service brief into every suggested assignment, and advances those assignments to the second alignment sub-phase, where their owners run lifecycle-accept-plan.

Errors

The API returns {error: {code, message, remediation}}:

• plan_already_approved — already done; synthesis has run or is running.
• workspace_execution_required — this opportunity type does not support workspace execution, so approval does not apply to it.
• stale_state — the stage changed since the pre-flight. Redo from step 1.
• scope_violation — the credential is not scoped to this opportunity. Sign in again with glassity auth login.

Hard rule

Same discipline as opp-triage and lifecycle-accept-plan: never run phase 1 and phase 2 in one bash invocation, always show the verbatim plan from stderr, and wait for an explicit "yes". Approval is a fan-out — once it fires, every suggested assignment is seeded.