Quality Standards

Configure review gates, readiness thresholds, and quality requirements for your specifications.

SpecForge enforces quality through configurable review gates at two checkpoints: Planning Review (before implementation starts) and Implementation Review (after all tickets are completed). You control how strict these gates are through the project’s quality configuration.

Configure quality standards from the Settings > Quality Standards page in the dashboard, or via the CLI and MCP tools.

Planning Gate

The Planning Gate evaluates whether a specification is ready for implementation.


{
  "requirePlanningReview": true,
  "readinessThreshold": 70,
  "epicVerificationSeverity": "error",
  "requireBlueprintCoverage": true,
  "requireDependencyValidation": true,
  "maxFeatureTestRatio": 3
}

Options

Option	Type	Default	Description
`requirePlanningReview`	boolean	`true`	Whether the planning gate must pass before the spec can advance to `ready`. When `false`, you can skip directly to implementation.
`readinessThreshold`	number (0-100)	`70`	Minimum average readiness score across all epics. Each epic is scored on ticket completeness, dependencies, and acceptance criteria.
`epicVerificationSeverity`	`"error"` \| `"warning"`	`"error"`	Whether epic-level issues (missing descriptions, empty epics) block the review or appear as warnings.
`requireBlueprintCoverage`	boolean	`true`	Requires a minimum 1:2 blueprint-to-epic ratio. If you have 6 epics, at least 3 blueprints must be linked. See Blueprints for guidance on which types to use.
`requireDependencyValidation`	boolean	`true`	Runs circular dependency checks and validates that all cross-epic links resolve correctly.
`maxFeatureTestRatio`	number	`3`	Maximum ratio of feature tickets to test tickets. A value of `3` means for every 3 feature tickets, at least 1 test ticket must exist.

✅ Start with defaults. They represent a balance between rigor and speed. Raise thresholds as your team gains confidence with the workflow.

Implementation Gate

The Implementation Gate evaluates completed work against the original specification.


{
  "requireImplementationReview": true,
  "gates": {
    "steps": true,
    "acceptance_criteria": true,
    "file_delivery": true,
    "git_evidence": true,
    "tests": true
  },
  "gitEvidence": "required",
  "testEvidence": "summary",
  "maxReviewAttempts": 3
}

Options

Option	Type	Default	Description
`requireImplementationReview`	boolean	`true`	Whether the implementation gate must pass before the spec can advance to `completed`.
`gates`	object	all `true`	Enable or disable individual quality checks. See gate details below.
`gitEvidence`	`"required"` \| `"recommended"` \| `"none"`	`"required"`	How strictly git evidence (linked commits and PRs) is enforced.
`testEvidence`	`"summary"` \| `"discretized"` \| `"verbose"`	`"summary"`	Detail level for test result reporting in reviews.
`maxReviewAttempts`	number	`3`	Maximum review retries before requiring manual intervention. Prevents infinite loops on fundamentally flawed specifications.

Gate Details

Each gate in the gates object controls a specific quality check during Implementation Review:

Gate	What it checks
`steps`	Were all implementation steps in each ticket completed?
`acceptance_criteria`	Were all acceptance criteria in each ticket satisfied?
`file_delivery`	Were all expected file changes (creates, modifications, deletions) reported?
`git_evidence`	Are commits and/or pull requests linked to tickets?
`tests`	Were test results submitted for tickets that require them?

⚠️ Disabling gates reduces review coverage. If you disable acceptance_criteria, the review won’t verify whether tickets actually meet their stated requirements. Disable deliberately, not casually.

Git Evidence Modes

Mode	Behavior
`"required"`	Every ticket must have at least one linked commit or PR. Missing evidence fails the review.
`"recommended"`	Missing evidence produces a warning but doesn’t fail the review.
`"none"`	Git evidence is not checked.

Test Evidence Modes

Mode	Behavior
`"summary"`	Shows pass/fail counts per ticket.
`"discretized"`	Shows individual test case results grouped by ticket.
`"verbose"`	Shows full test output including stdout and error messages.

Configuration Profiles

Different situations call for different quality settings. Here are common configurations:

Prototyping

Speed matters more than ceremony. Lower thresholds, disable git evidence, skip blueprint coverage.


{
  "requirePlanningReview": true,
  "readinessThreshold": 60,
  "requireBlueprintCoverage": false,
  "requireImplementationReview": true,
  "gates": {
    "steps": true,
    "acceptance_criteria": true,
    "file_delivery": true,
    "git_evidence": false,
    "tests": false
  },
  "gitEvidence": "none",
  "testEvidence": "summary",
  "maxReviewAttempts": 5
}

Why keep Planning Review enabled even for prototypes? Because a bad decomposition wastes more time than a quick review costs. Lowering the threshold to 60 lets you pass with rougher plans while still catching circular dependencies and empty epics.

Standard Development

The defaults. Balanced between rigor and velocity. Good for teams getting started with SpecForge.


{
  "requirePlanningReview": true,
  "readinessThreshold": 70,
  "requireBlueprintCoverage": true,
  "requireDependencyValidation": true,
  "requireImplementationReview": true,
  "gitEvidence": "required",
  "testEvidence": "summary",
  "maxReviewAttempts": 3
}

Production-Grade

Maximum rigor. Higher thresholds, stricter test evidence, lower feature-to-test ratio. Use for specifications that will ship to users.


{
  "requirePlanningReview": true,
  "readinessThreshold": 85,
  "epicVerificationSeverity": "error",
  "requireBlueprintCoverage": true,
  "requireDependencyValidation": true,
  "maxFeatureTestRatio": 2,
  "requireImplementationReview": true,
  "gates": {
    "steps": true,
    "acceptance_criteria": true,
    "file_delivery": true,
    "git_evidence": true,
    "tests": true
  },
  "gitEvidence": "required",
  "testEvidence": "discretized",
  "maxReviewAttempts": 3
}

The key difference: readinessThreshold: 85 catches marginal plans that would squeak through at 70. testEvidence: "discretized" shows individual test results so reviewers can spot weak coverage. maxFeatureTestRatio: 2 enforces more test tickets relative to feature tickets.

Autonomous at Scale

For large specifications (20+ epics, 100+ tickets) running with Agent Teams. Trust the structure, verify the output.


{
  "requirePlanningReview": true,
  "readinessThreshold": 90,
  "requireBlueprintCoverage": true,
  "maxFeatureTestRatio": 2,
  "requireImplementationReview": true,
  "gitEvidence": "required",
  "testEvidence": "verbose",
  "maxReviewAttempts": 5
}

At this scale, the planning threshold is critical — a structural issue at 100 tickets is exponentially more expensive to fix post-implementation than at 10 tickets. testEvidence: "verbose" gives full output for debugging failures. maxReviewAttempts: 5 gives more room because large specs are more likely to need iteration.

Configuring via CLI

View the current configuration:


specforge configure reviewConfig

Set individual values:


# Raise the planning threshold
specforge configure reviewConfig.readinessThreshold 85
 
# Disable git evidence for prototyping
specforge configure reviewConfig.gates.git_evidence false
 
# Change test evidence level
specforge configure reviewConfig.testEvidence verbose

📖 Quality standards apply at the project level. All specifications within a project share the same review configuration. For the complete configuration schema, see Configuration Schema.

Quality Standards

Planning Gate

Options

Implementation Gate

Options

Gate Details

Git Evidence Modes

Test Evidence Modes

Configuration Profiles

Prototyping

Standard Development

Production-Grade

Autonomous at Scale

Configuring via CLI

See Also