Item detail
github.com

Fission-AI/OpenSpec

Fission-AI/OpenSpec is a developer tool that RepoRadar is tracking in its Coding Workflows section, currently rated Gold tier with a 'try now' verdict. Its strongest signal is workflow potential, scored 10.0 out of 10.

Score8.7
Popularity88.0
Riskconditional
TierGold
Score breakdown
Usefulness9.0
Novelty8.0
Momentum9.0
Maturity8.6
Open-source/build8.4
Evidence8.0
Workflow potential10.0
Setup ease6.4

Popularity is tracked separately. Support, ads, sponsorships, and tips never affect these signals.

Why it matters

Useful for teams that want AI coding work to leave behind clear scope, intent, and change history instead of disappearing into chat transcripts.

Who should use it

Developers who want AI coding runs to produce durable artifacts instead of one-off chat output Teams introducing spec-driven workflows to Claude Code, Codex, or other coding assistants Engineering leads who need a reviewable change proposal before agent work starts Builders comparing process-heavy and process-light approaches to AI coding

Who should skip it

Skip Fission-AI/OpenSpec unless the captured evidence suggests it solves a problem you are actively working on.

About this signal

Fission-AI/OpenSpec is tracked by RepoRadar as a developer tool in the Coding Workflows section. First seen 2026-06-27; the source record was last checked on 2026-06-27. The current verdict is 'try now' with a Gold tier and moderate setup difficulty. The standout signals for Fission-AI/OpenSpec are workflow potential (10.0) and practical usefulness (9.0), while setup ease (6.4) trails — that balance shapes where it fits best. This page summarizes the public evidence on the linked source page and states where additional review is still needed.

How this item is evaluated

The Fission-AI/OpenSpec record combines a 8.7/10 composite score with separate popularity (88.0), risk (conditional), and setup (moderate) signals. See the scoring methodology for the current weights and evidence definitions.

Putting this into practice? Read How to evaluate an AI tool before you adopt it for the checklist behind this score.

Risk explanation

It is designed to steer real code changes through AI assistants, so test it in a non-critical repo before you make it part of a production delivery path; A strong spec workflow can still add process overhead if the team applies it to tiny fixes that do not need proposal or task artifacts; The framework improves structure, not judgment, so reviewers still need to verify that the assistant's plan matches the codebase reality.

Evidence links
Closest alternatives / related signals
spec-driven-development codex claude-code cli developer-workflows brownfield mit
Verification record

What RepoRadar actually verified

Tested in a bounded workflow

Bounded representative workflow retained by RepoRadar verification harness. Last checked 2026-07-14T00:53:27.671356Z.

passed · cohort-20260713-openspec-strict-change-workflow

Tester
RepoRadar automated local verification harness
Started
2026-07-14T00:53:20.089221Z
Completed
2026-07-14T00:53:27.671356Z
Environment
Windows 10 AMD64; Python 3.11.9; credential-stripped child environment; disposable home/cache
Install/setup time
1 minute(s)
Evidence scope
Bounded representative workflow
Cleanup
Per-check temporary home and work directory removed. Shared cohort package cache removed.
Actions exercised
  • Created a disposable home, work directory, and isolated package cache with credential-like environment variables excluded.
  • Created 1 synthetic fixture file(s) inside the disposable work directory; retained hashes prove the exact inputs.
  • Initialized a repo-local OpenSpec root with --tools none so no agent integration or user configuration was touched.
  • Created one change, authored proposal, design, specification, and task artifacts, confirmed all four were complete, and ran strict non-interactive validation.
  • Executed bounded check: Initialize OpenSpec without agent integrations, create a synthetic health-contract change, complete all four planning artifacts, and pass strict validation.
  • Captured the complete sanitized stdout, stderr, exit status, artifact checks, and 7.58-second wall time.
Observed results
  • Command exited 0 after 7.58 seconds.
  • OpenSpec reported every planning artifact done and returned one valid change with zero strict-validation failures.
  • Expected marker 'CHECK_OK change=add-health-check complete=true strict_valid=true artifacts=4' was observed in retained output.
  • Validated result.json: 3 required marker(s) present and 0 excluded marker(s) absent; size and SHA-256 are retained.
  • Validated openspec/changes/add-health-check/proposal.md: 3 required marker(s) present and 0 excluded marker(s) absent; size and SHA-256 are retained.
  • Validated openspec/changes/add-health-check/specs/service-health/spec.md: 3 required marker(s) present and 0 excluded marker(s) absent; size and SHA-256 are retained.
  • Validated openspec/changes/add-health-check/tasks.md: 2 required marker(s) present and 0 excluded marker(s) absent; size and SHA-256 are retained.
Observed strengths
  • The CLI exposed a deterministic, machine-readable change lifecycle from initialization through dependency-aware status and strict validation.
Friction
  • OpenSpec scaffolds metadata and status but artifact content still required explicit authoring; this workflow supplied controlled fixture Markdown rather than delegating it to an agent.
Limitations
  • The fixture validates a local spec-driven planning cycle only; it does not ask an AI agent to author the files, apply code changes, archive the change, use a shared store, or prove that the proposed service behavior was implemented.
  • This credential-free disposable workflow does not establish operator use, production scale, model quality, reliability under sustained use, or team adoption.

Pricing assessment: The pinned OpenSpec 1.6.0 CLI operated locally with agent tools disabled and no paid service, model, or account.

Privacy assessment: Only synthetic planning Markdown was created in the disposable work directory; --tools none prevented writes to agent integrations and no hosted store was used.

Open retained test log →

Verification sources

Longitudinal intelligence

How this decision record is moving

Raw history JSON →

38 dated snapshots retained from 2026-06-27 through 2026-08-13; see the snapshot index for explicit coverage gaps. Stars, version, release, pricing, integration, risk, maintenance, verdict, score, and momentum fields remain explicit even when a source has not reported them. Repository momentum is a normalized 0–10 RepoRadar signal; GitHub stars appear only where the popularity monitor retained exact timestamped observations.

RepoRadar score8.7 current · +0.0 net
Repository momentum10.0 current · +1.0 net
GitHub stars (observed)64,784 current · +4,082 net
GitHub stars64,784 exact observation
Versionv1.9.0
Last release2026-08-13T15:38:22Z
Maintenanceactive
Current riskconditional
Current verdicttry now
Pricing baselineNo structured commercial pricing baseline
Pricing checkedNot applicable or not recorded
Pricing freshnessNo dated commercial pricing review
Integrations baselineNo structured integrations recorded

Recent dated points

DateScoreMomentumStarsRiskVerdictMaintenance
2026-08-138.710.064,784conditionaltry nowactive
2026-08-128.710.064,671conditionaltry nowactive
2026-08-118.710.064,530conditionaltry nowactive
2026-08-108.710.064,430conditionaltry nowactive
2026-08-098.79.664,330conditionaltry nowactive
2026-08-088.710.064,252conditionaltry nowactive
2026-08-078.710.063,583conditionaltry nowactive
2026-08-068.79.0Not recordedconditionaltry nownot recorded
2026-08-058.79.0Not recordedconditionaltry nownot recorded
2026-08-048.710.063,583conditionaltry nowactive
2026-08-038.710.063,583conditionaltry nowactive
2026-08-028.79.663,447conditionaltry nowactive

Why the record changed

stars changed

Stars changed: 64671 → 64784.

version changed

Version changed: v1.8.0 → v1.9.0.

stars changed

Stars changed: 64530 → 64671.

stars changed

Stars changed: 64430 → 64530.

stars changed

Stars changed: 64330 → 64430.

stars changed

Stars changed: 64252 → 64330.

version changed

Version changed: v1.7.0 → v1.8.0.

stars changed

Stars changed: 63583 → 64252.

stars changed

Stars changed: 63447 → 63583.

stars changed

Stars changed: 63378 → 63447.

stars changed

Source-observed stars changed: 63331 → 63378. This reports the retained observation delta and does not infer why the upstream change occurred.

stars changed

Source-observed stars changed: 63330 → 63331. This reports the retained observation delta and does not infer why the upstream change occurred.