Constitution

Skill pooyagolchian/specforge/plugins/specforge/skills/constitution

Spec-driven AI development lifecycle for Claude Code — spec-kit + AI-DLC fused, with hook-enforced human-approval gates. Installable plugin + marketplace.

Install

npx -y skills add pooyagolchian/specforge --skill constitution

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

13 days oldThe repository was created 13 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Create or update the project constitution — the governing engineering principles SpecForge checks every plan against. Use when the user wants to set project principles, define coding standards/guardrails, establish a constitution, or amend existing principles. Writes specforge/constitution.md.

SKILL.md

2.4 KB, as published. Nobody here has run it

/specforge:constitution — set the project's governing principles

Define the small set of engineering principles this project commits to. /specforge:plan checks every plan against them and must document compliance or an explicit exception. These are soft gates (advisory) — the hard, blocking gate is spec + plan approval.

When to use

Starting a project and setting standards (simplicity, testing philosophy, boundaries, security).
Amending principles as the team learns.

Steps

Read specforge/constitution.md if it exists (created by /specforge:init). If there is no specforge/ workspace yet, tell the user to run /specforge:init first.
Interview the user briefly for their non-negotiables, or propose a sensible starter set and let them adjust. Keep it to 4–8 principles — a short list a team will actually follow.
Write each principle with a name and one or two sentences: state the rule and the intent, in testable language where possible. Avoid a long unread list.
Do not copy spec-kit's hard gates (strict TDD, max-3-projects) unless the user explicitly wants them — SpecForge keeps principles advisory by design.
Bump the constitution Version (semver) and add a row to the Amendment Log with the date, version, change, and rationale.
Append an audit row to specforge/audit.md: | <today ISO-8601> | — | constitution | Ratified/amended to vX.Y.Z |.

Structure to follow

# Project Constitution
- **Version:** X.Y.Z
- **Ratified:** <date>

## Principles
### P1 — <name>
<rule + intent>
...

## Enforcement
Advisory gates checked by /specforge:plan. Hard gate = spec+plan approval in state.md.

## Amendment Log
| Date | Version | Change | Rationale |

The canonical template is at ${CLAUDE_SKILL_DIR}/../_shared/constitution-template.md.

Output

An updated specforge/constitution.md. Remind the user that plans will now be checked against these principles, and suggest /specforge:specify to define a feature.