stage-workflow-governance

Enforce stage lifecycle governance and block edits for CLOSED or HARDENED specs.

Updated Apr 10, 2026
One-click install
npx skills add https://github.com/majedsiefalnasr/bunyan-app-cursor --skill stage-workflow-governance
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: stage-workflow-governance
Source: https://github.com/majedsiefalnasr/bunyan-app-cursor/tree/main/.agents/skills/stage-workflow-governance
Command: npx skills add https://github.com/majedsiefalnasr/bunyan-app-cursor --skill stage-workflow-governance

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Stage governance ensures safe, auditable control over stage mutations, preventing unauthorized or accidental edits to specs.

Core Features & Use Cases

  • Stage status validation: Enforces OPEN, COMMITTED, CLOSED, HARDENED lifecycles before changes.
  • Guardrails for edits: Blocks edits when stages are CLOSED or HARDENED, and requires explicit approvals for COMMITTED stages.
  • Audit and documentation: Encourages ADR-style documentation of significant transitions and rationale.

Quick Start

Before editing any spec, verify the current stage status in .specify/ and follow the governance rules.

Frequently Asked Questions about stage-workflow-governance

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

FAQPage Schema
How do I prevent unauthorized edits to specs after they are committed?

Spec governance prevents unauthorized edits by enforcing lifecycle stages. It requires explicit approvals for COMMITTED specs and blocks modifications when stages reach CLOSED or HARDENED states.

What is the stage lifecycle workflow for managing spec integrity?

Stage lifecycle workflow manages spec integrity through OPEN, COMMITTED, CLOSED, and HARDENED stages. It checks the .specify/ directory for current status before allowing mutations or lifecycle transitions.

How do I document significant changes during stage transitions?

Document significant changes during stage transitions using ADR documentation. The governance workflow advocates Architecture Decision Records to capture rationale and audit trails for lifecycle mutations.

Can I modify a spec if its current status is CLOSED or HARDENED?

You cannot modify a spec when its stage status is CLOSED or HARDENED. The governance guardrails block all changes to these stages to protect spec integrity and prevent accidental edits.

Why does my workflow require explicit approval before editing a COMMITTED spec?

Explicit approval is required before editing COMMITTED specs to ensure safe, auditable control over stage mutations. This governance rule prevents unauthorized or accidental changes to committed specifications.