Preface

When developing with AI coding agents, common pain points are not in the code itself, but in the delivery process: what tasks changed, why they changed, how they were verified—these facts are scattered in chat logs; the review process might run in degraded mode or depend on specific environments, yet is treated as a complete independent review; release readiness often relies on a verbal judgment. By the time you want to review or hand over, the context is hard to rebuild.

software-project-governance targets these issues: moving planning, review, risk, quality, and release control from chat memory to a checkable governance directory. In the DSH “Everything is a Plugin” ecosystem, it is a plugin for workflow direction. Below, it is introduced in the order of positioning, features, installation, and usage.

What is it

software-project-governance is an open-source project maintained by peterwangze, licensed under MIT. The one-sentence positioning in the README is: “AI coding delivery trust layer for evidence-backed planning, review, risk, quality, and release control”—providing an evidence-backed planning, review, risk, quality, and release control layer for AI coding delivery.

The package.json version is 0.78.1, private: true, positioned as an agent-neutral npm package identifier (owner scope, not indicating belonging to a specific agent), consumed by the zcode plugin host and dsh plugin (pnpm) carrier; the plugin interface is located in the skills/ and commands/ directories; package.json itself only carries package identifiers and has no executable content.

The target audience given in the README: marketplace reviewers, AI coding users, and teams needing a repeatable way to prevent drift, missing evidence, weak review loops, and premature release claims.

Core Features

README summarizes four points:

  1. Evidence-backed delivery: Every meaningful task carries four types of facts—what changed, why changed, how verified, and remaining risks.
  2. Gate and risk control: Centralized management of stage gates, task status, risks, decisions, and release readiness, rather than scattered in chat memory.
  3. Reviewer separation with degraded-mode honesty: Distinguishing between true independent reviews and degraded/dependency-based executions, not wrapping all agents as fully supported.
  4. 5-minute orientation: Start with /governance, initialize .governance/ directory, agent restores state and checks gates, only surfacing key decisions.

There are a few peripheral areas:

  • Multi-agent loading paths: Claude Code, Codex, Gemini CLI, opencode, and Chrys all have corresponding loading methods and initial verification commands.
  • Web console: The web-console command family provides a read-only local dashboard. Starting from 0.56.1, it reads real governance data instead of hardcoded mock values.
  • DSH bundle integration: package.json contains dsh.bundle.patch (./cordis.patch.yml) and a dsh.skills list, covering code-review, design-review, main-workflow, okr, pr-faq, release-checklist, release-review, requirement-clarification, requirement-review, retro-meeting, retro-review, six-pager, software-project-governance, as well as stage-* series like stage-architecture, stage-cicd, stage-development, stage-initiation, distributed across skills/ and commands/ directories.
  • Presets: classic-phase-gate is the active default compatible preset; dynamic-flow-gate is non-default and only actively selected (opt-in); this release does not migrate any projects.

Installation & Enablement

The installation command given in README is based on the shared Claude/zcode marketplace protocol (starting from 0.62.0; earlier 0.56.0 zcode local plugin interface has been replaced by this protocol path):

/plugin marketplace add peterwangze/software-project-governance

Taking Claude Code as an example, the full path in the README is: first add this repository as a Claude plugin marketplace, then install software-project-governance@spg.

Need to state truthfully: The gathered materials did not show a DSH-specific installation command. The description in package.json indicates this package is consumed by the dsh plugin (pnpm) carrier, but DSH-side specific installation steps are not covered in the materials, so the repository README takes precedence.

After installation, verify first. Claude Code corresponds to two commands:

python adapters/claude/launch.py
python skills/software-project-governance/infra/verify_workflow.py check-agent-adapters --runtime

The first launches the Claude adapter, the second checks the runtime state of the agent adapters. Codex, Gemini CLI, opencode, and Chrys each have one line of loading path and verification command in the README, similar format, not elaborated one by one. Note: Loading readiness is not equivalent to official approval, marketplace approval, or generic/complete runtime support.

Typical Usage

  1. Initialize governance directory. Start with /governance in the project, the plugin initializes .governance/, the agent restores state and checks gates, only surfacing key decisions.

  2. Use the local Web console. The command family has four entry points:

web-console --status
web-console --start [--install]
web-console --summary-link
web-console --governance-entry

--status checks status; --start [--install] starts the console; --summary-link provides a read-only summary link for tasks, stages, and sessions; --governance-entry restores the product entry, manually starting or reusing the local Web console when /governance is run and reporting the URL. The dashboard remains read-only overall.

  1. Preview lifecycle migration. The migration tool only supports dry-run:
dynamic-lifecycle-migration --target <path> --dry-run

After the above steps, task evidence, stage gates, and risk records all fall into .governance/, and subsequent sessions can restore state based on this.

Applicable Scenarios & Notes

Suitable for two types of users:

  • Teams or individuals using AI coding agents for delivery who want task evidence, stage gates, and risks to be recorded centrally, so reviews and handovers don’t rely on flipping through chat logs.
  • Marketplace reviewers or plugin authors who need a repeatable way to verify delivery claims.

Note before use, the README’s declaration of its boundaries is quite frank:

  1. RISK-036, RISK-037, and RISK-039 are still open: no official approval, no marketplace approval, no two real project external verification all passing, no Codex Desktop lifecycle passing, no project migration, no 1.0.0 production-ready declaration.
  2. External verification is conservative: dry-run preview reaches READY_FOR_REVIEW, but installed state verification still has target-native blocking; non-game preset generalization is still partial support.
  3. classic-phase-gate is still the default preset, dynamic-flow-gate is only opt-in, and the release will not automatically migrate any projects.
  4. Version information takes the repository as the standard: package.json is 0.78.1, README body narrative goes up to 0.62.0; the README and package.json captured this time are both truncated, so complete installation instructions and configuration items may not be covered.

Security is the same as general plugins: the plugin runs with the current dsh process permissions; source code and license should be checked before installation. This project’s license is MIT, and the source code is public on GitHub.

Conclusion

The value of software-project-governance lies in turning “delivery trustworthiness” from chat memory into checkable evidence, gate controls, and risk records, and actively marking the parts it has not yet achieved. The project is still before 1.0.0, risk items are not closed, it is recommended to introduce as needed after understanding the boundaries.

  • Community Directory Page: https://www.skillhub.cn/plugins/peterwangze/software-project-governance
  • GitHub: https://github.com/peterwangze/software-project-governance