# OpenSpec

Keep current specifications alongside reviewed change proposals and deltas when evolving agreed behavior.

ID: openspec
Language: en
Revision: 1
Translation source revision: 1
Canonical: https://kickoff.jujin.dev/en/catalog/openspec/

## Why: the goal or problem

A pottery workshop site lets members book sessions and receive confirmation. Adding rescheduling must preserve confirmation rules. Its maintainer wants to review exactly what changes and retain that decision; a direct label edit would need less documentation.

## How: work toward a solution

Keep the current confirmation requirement. Propose a rescheduling rule, record its added scenario and tasks, review, implement, and check both behaviors. Reconcile the specification and archive the change.

## What: the concept

OpenSpec organizes specifications and change artifacts for coding agents. Artifacts can be revised as understanding improves. It supports new projects too; maintained deltas and setup cost must justify its use.

[Source](https://github.com/Fission-AI/OpenSpec)

---

# Go further

Optional reading · separate from the overview

## Selection & comparison

This example prioritizes the difference between current behavior and a proposed change. OpenSpec keeps specifications and change artifacts that can evolve together. Spec Kit may fit a team prioritizing its specification-to-implementation process; Superpowers emphasizes repeatable execution skills. Existing instructions may suffice for a bounded correction. OpenSpec also supports new projects; “existing project” is an example, not a hard eligibility rule. Compare compatibility and maintenance cost rather than vendor claims about competing tools.

## Applications

The workshop already confirms each booking. The proposed rule allows a member to move a booking at least 24 hours before the session; this threshold is a fictional accepted product choice. Record the added rescheduling scenario while preserving confirmation behavior. The change contains a proposal, specification delta, design, and tasks. Check the accepted time boundary and unchanged confirmation behavior. Review synchronization of the delta into current specifications and keep the archived rationale.

## Implementation & cautions

In the external agent, inspect the current official installation and supported-tool documentation, runtime, project, and existing setup. Install only the selected scope under existing authority, initialize the appropriate integration, and review generated files. The CLI performs setup and artifact operations; the agent writes and applies the change through its installed workflow. Invocation spelling depends on the tool; use the form printed for the selected integration. Confirm an actual planning artifact was produced. Verification commands depend on the installed profile, so do not assume every optional command exists. Archiving or checked task boxes do not prove working behavior: run the project’s relevant checks and report gaps. Reuse these artifacts for kickoff’s planning and work records.

## Evidence

- [OpenSpec README](https://github.com/Fission-AI/OpenSpec) — OpenSpec uses project specifications and change artifacts, documents installation, and supports agent-specific invocation. (Checked: 2026-10-08)
- [OpenSpec workflows](https://github.com/Fission-AI/OpenSpec/blob/main/docs/workflows.md) — Planning artifacts can be refined; implementation, specification synchronization, and archiving are distinct actions. (Checked: 2026-10-08)
- [OpenSpec supported tools](https://github.com/Fission-AI/OpenSpec/blob/main/docs/supported-tools.md) — Generated integration paths and invocation syntax vary by agent. (Checked: 2026-10-08)