Advanced OpenSpec: Expanded Workflows, Verify Loops, and Custom Schemas

TL;DR

• The default OpenSpec core profile is enough for most teams at first: explore, propose, apply, sync, and archive.
• The expanded workflow commands are useful when you want more control over artifact creation, more explicit verification, parallel change handling, or guided onboarding.
• Use /opsx:continue when you want to review artifacts one at a time. Use /opsx:ff when the scope is clear and you want the full planning pack quickly.
• Use /opsx:verify before archive when implementation drift is the risk: tasks may be checked off, but the code may still disagree with the spec or design.
• Use /opsx:bulk-archive only when multiple completed changes are ready and you need OpenSpec to reason about spec merge order and conflicts.
• Extend OpenSpec in layers:
  • openspec/config.yaml for team context and rules
  • custom templates when the default artifact wording is close but not quite right
  • custom schemas when your team needs different artifacts or dependencies
• My default rule: do not create a custom schema until you have repeated evidence that project config is not enough.

What You Will Learn Here

By the end of this article, you should be able to:

• explain when OpenSpec’s core profile is enough and when expanded workflows help
• choose between /opsx:new, /opsx:continue, and /opsx:ff
• use /opsx:verify as a review loop before archive
• understand where /opsx:bulk-archive fits in parallel work
• design a small custom schema with a new artifact dependency graph
• validate and apply a custom workflow without forking OpenSpec itself
• explain the trade-off to engineers and PMs without turning OpenSpec into ceremony

On July 1, 2026, I reviewed the current OpenSpec docs for OPSX, commands, concepts, customization, supported tools, and the first article in this series. Command names, profile behavior, schema fields, dependency behavior, and customization mechanics are source-backed. The workflow recommendations and rollout advice are my synthesis.

One terminology caveat: OpenSpec docs often describe the workflow names as /opsx:propose, /opsx:continue, and so on. The commands reference also notes that some tools expose different command syntax, such as hyphenated variants in Cursor. In this article I use the /opsx:* names as the workflow labels. Use the exact command surface generated for your AI tool.

Why Go Beyond the Core Profile?

The first article in this series focused on getting started:

/opsx:explore
  -> /opsx:propose
  -> /opsx:apply
  -> /opsx:archive

That path is intentionally small. It is the right default for teams learning OpenSpec.

The advanced features become useful when the workflow itself starts to matter:

You need staged review
  -> create artifacts one at a time

You need faster planning for a clear change
  -> fast-forward all artifacts

You need confidence before archive
  -> verify implementation against artifacts

You have multiple active changes
  -> name changes explicitly, sync carefully, bulk-archive when ready

Your team process has a missing artifact
  -> add config, then templates, then a custom schema if needed

The expanded workflow is not “more mature” by default. It is more explicit. Use it when that explicitness removes risk.

Core vs Expanded Profile

OpenSpec’s docs describe the default global profile as core.

core profile
  /opsx:explore
  /opsx:propose
  /opsx:apply
  /opsx:sync
  /opsx:archive

The expanded commands are enabled through profile configuration:

openspec config profile
openspec update

Expanded commands include:

expanded workflow commands
  /opsx:new
  /opsx:continue
  /opsx:ff
  /opsx:verify
  /opsx:bulk-archive
  /opsx:onboard

OpenSpec’s supported-tools docs are clear that generated skills and commands are profile-dependent and delivery-dependent. After changing profiles, run openspec update inside the project so your AI assistant gets the regenerated guidance.

The Expanded Workflow Map

Here is the mental model:

idea
  |
  |-- unclear? ----------------------.
  |                                  |
  v                                  |
/opsx:explore                       |
  |                                  |
  v                                  |
/opsx:new <change>                  |
  |                                  |
  |-- careful path --> /opsx:continue repeated
  |                                  |
  |-- fast path -----> /opsx:ff
  |
  v
/opsx:apply
  |
  v
/opsx:verify
  |
  |-- drift found? --> update code or artifacts, then verify again
  |
  v
/opsx:archive

The important shift is that expanded workflows separate change creation from artifact generation.

The core path says:

propose = create the change + generate planning artifacts

The expanded path says:

new      = create the change folder
continue = create the next artifact
ff       = create all planning artifacts in dependency order

That separation is what gives you more control.

/opsx:new: Start the Change Without Filling Everything In

Use /opsx:new when you know a change exists but do not want the AI to generate the full artifact set yet.

/opsx:new add-tenant-audit-log

OpenSpec docs describe this as creating a change scaffold and a .openspec.yaml metadata file. The agent should then show what artifact is ready next.

Use it when:

• the change name is clear, but the scope is not
• you want to review the proposal before specs/design/tasks exist
• the team needs to agree on a domain boundary first
• you are trying a custom schema and want to see what artifact comes first

Example:

You: /opsx:new add-tenant-audit-log

AI:
  Created openspec/changes/add-tenant-audit-log/
  Schema: spec-driven
  Ready to create: proposal
  Use /opsx:continue to create it, or /opsx:ff to create all artifacts.

This is useful for PMs because it creates a named work item without pretending the whole plan is ready.

It is useful for engineers because it lets you keep the artifact graph honest.

/opsx:continue: Review One Artifact at a Time

Use /opsx:continue for complex or risky changes.

/opsx:continue add-tenant-audit-log

The commands doc says /opsx:continue queries the artifact dependency graph, shows ready vs blocked artifacts, creates the first ready artifact, reads dependencies for context, and shows what becomes available afterward.

For the default spec-driven schema, the shape is roughly:

proposal
  |-- specs
  |-- design
  `-- tasks after specs + design

In ASCII:

              proposal
                 |
        +--------+--------+
        |                 |
      specs             design
        |                 |
        +--------+--------+
                 |
               tasks
                 |
               apply

This lets the team pause at the right moments:

After proposal
  PM checks problem, scope, non-goals

After specs
  PM + QA check behavior and scenarios

After design
  engineers check architecture, dependencies, rollout risk

After tasks
  team checks review size and validation path

Use /opsx:continue when:

• requirements are ambiguous
• the feature touches security, payments, identity, data migrations, or external APIs
• you expect real product feedback before implementation
• you want to compare artifacts with a reviewer before the AI writes code

Do not use it just because it feels more serious. For small fixes, it can be too slow.

/opsx:ff: Fast-Forward When the Scope Is Already Clear

Use /opsx:ff when the change is small enough that reviewing each artifact separately does not add much value.

/opsx:ff fix-empty-state-copy

The commands doc describes /opsx:ff as creating all planning artifacts in dependency order, reading each dependency before creating the next artifact, and stopping when all apply-required artifacts are complete.

Good fits:

• small UI behavior changes
• straightforward bug fixes
• low-risk config changes
• features with well-understood patterns

Bad fits:

• authentication redesigns
• permission model changes
• payment flows
• data migrations
• unclear product scope

The decision is not “fast vs slow.” It is “do we need artifact-by-artifact review?”

Can the team review the whole plan in one pass?
  yes -> /opsx:ff
  no  -> /opsx:continue

/opsx:verify: The Advanced Command I Would Use Most

/opsx:verify checks whether the implementation matches the artifacts. The commands doc lists three dimensions:

• completeness
• correctness
• coherence

That maps nicely to real review questions:

Completeness
  Did we implement all requirements and tasks?
  Are the scenarios covered?

Correctness
  Does the behavior match the spec intent?
  Are edge cases handled?

Coherence
  Does the code reflect the design?
  Did implementation drift from the planned architecture?

Use it before archive:

/opsx:apply add-tenant-audit-log
/opsx:verify add-tenant-audit-log

If verify finds warnings, do not treat them as automatic blockers. Treat them as review inputs.

verify warning
  |
  |-- code is wrong
  |     -> fix code, keep artifact
  |
  |-- artifact is stale
  |     -> update proposal/spec/design/tasks
  |
  |-- warning is acceptable
        -> document why and archive

This is where OpenSpec becomes more than a planning prompt. The artifacts become a review contract.

/opsx:sync and /opsx:archive: Know the Difference

In the default loop, most teams can let archive handle spec syncing.

But it helps to know the difference:

/opsx:sync
  merges delta specs into openspec/specs/
  keeps the change active

/opsx:archive
  checks artifacts and tasks
  offers to sync if needed
  moves the change to openspec/changes/archive/

Manual sync is useful when:

• a long-running change updates specs that other changes need
• you want to review the spec merge separately
• multiple active changes depend on the updated base behavior

For quick changes, skip manual sync and archive when done.

/opsx:bulk-archive: Useful, but Not a Cleanup Button

/opsx:bulk-archive archives multiple completed changes at once. The commands doc says it lists completed changes, validates each one, detects spec conflicts, resolves conflicts by checking what is implemented, and archives in chronological order.

That is powerful, but it should not become a weekly garbage collection habit.

Use it when:

• several completed changes are waiting to archive
• parallel work touched overlapping spec domains
• you need the agent to inspect implementation before merging deltas

Avoid it when:

• tasks are incomplete
• changes are conceptually unrelated and risky
• reviewers have not looked at the individual artifacts
• spec conflicts are product decisions, not implementation details

My rule:

bulk-archive is for completed, reviewed work.
It is not for making messy active work disappear.

/opsx:onboard: Best for Learning, Not Process Enforcement

/opsx:onboard is a guided walkthrough. The commands doc says it scans your real codebase, finds small improvement opportunities, creates a real change, implements it, verifies it, archives it, and explains the steps.

That makes it valuable for:

• onboarding a developer to OpenSpec
• teaching a team the artifact lifecycle
• testing OpenSpec on a low-risk codebase slice
• demonstrating the workflow to PMs without a fake toy example

I would not use /opsx:onboard as the normal way to start every real feature. Its strength is narration and learning.

Use it once or twice. Then graduate to explicit workflows.

Advanced Pattern 1: Research-First Change

Some changes should not start with a proposal. They should start with a research artifact.

Examples:

• choose a payments provider
• evaluate SSO strategy
• compare vector database options
• decide whether to add Redis or use Postgres advisory locks

Default OpenSpec can still handle this with /opsx:explore, but a repeatable team process may deserve a custom schema.

Desired artifact flow:

research
  -> decision
  -> proposal
  -> specs
  -> design
  -> tasks
  -> apply

Why it helps:

• PMs see alternatives before one option becomes momentum
• engineers document rejected approaches
• future reviewers can understand why a path was chosen

Advanced Pattern 2: Compliance Review Before Tasks

For regulated or high-risk features, task generation may be too early until someone checks risk.

Desired artifact flow:

proposal
  -> specs
  -> design
  -> compliance-review
  -> tasks
  -> apply
  -> verify
  -> archive

Example artifact:

compliance-review.md
  - data categories touched
  - retention impact
  - audit logging requirement
  - security review owner
  - launch constraints

This is a good case for a custom schema because the dependency is real: tasks should depend on compliance-review, not just design.

Advanced Pattern 3: Migration-First Workflow

Data migrations deserve a different review surface.

Desired artifact flow:

proposal
  -> migration-plan
  -> rollback-plan
  -> specs
  -> design
  -> tasks
  -> verify

This helps prevent a common failure mode:

spec looks fine
design looks fine
tasks look fine
but rollback was never made explicit

Do not create this schema for every CRUD feature. Create it for teams that repeatedly ship risky data changes.

Extension Layers: Start Small

OpenSpec customization has three practical layers.

Layer 1: Project config
  openspec/config.yaml
  use for team context and per-artifact rules

Layer 2: Template changes
  openspec/schemas/<schema>/templates/*.md
  use when the artifact shape is close but needs better prompts

Layer 3: Custom schema
  openspec/schemas/<schema>/schema.yaml
  use when artifact types or dependencies must change

Start with project config.

schema: spec-driven

context: |
  Tech stack: TypeScript, Astro, React islands, Tailwind CSS.
  Product context: public devlog for engineers and PMs.
  Delivery: static build on Cloudflare Pages.

rules:
  proposal:
    - Include explicit non-goals.
    - Identify affected readers or user roles.
  specs:
    - Use Given/When/Then when behavior needs examples.
  design:
    - Mention migration, rollback, or launch risk when state changes.
  tasks:
    - Include build or validation commands.

Project config is enough when you only need better instructions.

Custom schema is for a different process.

How Custom Schemas Work

OpenSpec’s docs describe schemas as definitions for artifact types and dependencies. Custom schemas live under openspec/schemas/ and are version-controlled with your project.

The fastest path is to fork the built-in schema:

openspec schema fork spec-driven research-first

This creates something like:

openspec/schemas/research-first/
|-- schema.yaml
`-- templates/
    |-- proposal.md
    |-- spec.md
    |-- design.md
    `-- tasks.md

Then edit schema.yaml and templates.

You can also initialize a new schema:

openspec schema init research-first

Example: Build a Research-First Schema

Here is a practical custom schema for teams that compare options before implementation.

name: research-first
version: 1
description: Research and decision workflow before implementation planning

artifacts:
  - id: research
    generates: research.md
    description: Compare options, constraints, and unknowns
    template: research.md
    instruction: |
      Create a research brief before proposing implementation.
      Include alternatives, constraints, risks, and open questions.
    requires: []

  - id: decision
    generates: decision.md
    description: Record the chosen direction and rejected options
    template: decision.md
    instruction: |
      Summarize the selected approach and why alternatives were rejected.
      Mark assumptions that still need validation.
    requires:
      - research

  - id: proposal
    generates: proposal.md
    description: Scoped proposal informed by research and decision
    template: proposal.md
    instruction: |
      Create a concise proposal based on research.md and decision.md.
      Focus on intent, scope, non-goals, and affected users.
    requires:
      - decision

  - id: specs
    generates: specs/**/*.md
    description: Behavior delta specs
    template: spec.md
    requires:
      - proposal

  - id: design
    generates: design.md
    description: Technical design
    template: design.md
    requires:
      - proposal

  - id: tasks
    generates: tasks.md
    description: Implementation checklist
    template: tasks.md
    requires:
      - specs
      - design

apply:
  requires: [tasks]
  tracks: tasks.md

The artifact graph now looks like this:

research
   |
decision
   |
proposal
   |
   +--> specs ----+
   |              |
   +--> design ---+
                  |
                tasks
                  |
                apply

This is different from the default workflow because proposal is no longer the root. Research is.

Templates: Where the Quality Actually Lives

The schema defines the graph. Templates define the artifact shape.

For templates/research.md:

## Research Question

<!-- What decision are we trying to make? -->

## Options Compared

<!-- List realistic options. Include "do nothing" when relevant. -->

## Constraints

<!-- Product, engineering, security, cost, timeline, migration constraints. -->

## Findings

<!-- Source-backed findings. Use absolute dates for recent claims. -->

## Risks and Unknowns

<!-- What would make this recommendation wrong? -->

## Recommendation

<!-- Preferred option and why. Mark this as a recommendation, not a fact. -->

For templates/decision.md:

## Decision

<!-- What direction are we choosing? -->

## Why This Wins

<!-- Explain the trade-off, not just the choice. -->

## Rejected Options

<!-- Preserve useful context for future reviewers. -->

## Assumptions

<!-- What still needs validation during implementation? -->

## Reviewers

<!-- Product, engineering, security, data, or support stakeholders. -->

Good templates prevent vague artifacts. Weak templates just move vague prompting into markdown files.

Validate and Use the Schema

Before using a custom schema:

openspec schema validate research-first

The customization docs say validation checks schema syntax, referenced templates, circular dependencies, and artifact IDs.

To use it for one change:

/opsx:new choose-payment-provider --schema research-first
/opsx:continue choose-payment-provider

Or make it the project default in openspec/config.yaml:

schema: research-first

I would not make a custom schema the default until the team has tried it on a few changes.

Debugging Schema Resolution

If OpenSpec is not using the schema you expect, the customization docs describe schema resolution order:

1. CLI flag
2. change metadata in .openspec.yaml
3. openspec/config.yaml
4. default spec-driven schema

Use schema inspection commands when confused:

openspec schema which research-first
openspec schema which --all

This matters because a change created with one schema may keep that schema in its metadata even after you change the project default.

When Not to Extend OpenSpec

Do not create a custom schema because:

• one artifact had bad wording once
• one reviewer wanted a different heading
• the team is still learning the default workflow
• you want OpenSpec to enforce decisions humans have not agreed on

Use project config or template edits first.

Create a custom schema when:

• the same missing artifact appears in several changes
• tasks should not be generated until an extra review exists
• your team has a real dependency that the default schema cannot represent
• a custom workflow makes reviews smaller and clearer

The best custom schema is boring. It encodes a process your team already needs.

A Practical Rollout Plan for Advanced OpenSpec

I would roll this out in four steps:

Step 1: Use core profile for 2-3 changes
  learn the default artifact lifecycle

Step 2: Enable expanded workflows
  try /opsx:continue on one risky change
  try /opsx:ff on one clear change
  try /opsx:verify before archive

Step 3: Add project config
  add context and rules based on repeated review comments

Step 4: Fork or create a custom schema
  only after you know which artifact is missing

For PMs, the adoption question is:

Do we get earlier, clearer product review?

For engineers, the adoption question is:

Do artifacts reduce rework and implementation drift?

If the answer is no, simplify the workflow.

Advanced OpenSpec Checklist

Before adopting expanded workflows:

[ ] The team understands core OpenSpec first
[ ] The reason for expanded commands is explicit
[ ] Reviewers know which artifact they own
[ ] /opsx:verify is used before archive on risky work
[ ] Custom schemas are version-controlled
[ ] Schema validation is part of the workflow
[ ] The team can explain why config was not enough

Before creating a custom schema:

[ ] The missing artifact is repeated, not one-off
[ ] Dependencies are real, not decorative
[ ] Templates are clear and reviewable
[ ] The schema is tested on a low-risk change
[ ] The default schema remains available

Source Audit Notes

Source-backed claims in this article:

• core profile includes explore, propose, apply, sync, and archive.
• Expanded workflows include new, continue, ff, verify, bulk-archive, and onboard.
• /opsx:continue creates the next artifact based on dependency state.
• /opsx:ff creates planning artifacts in dependency order.
• /opsx:verify checks completeness, correctness, and coherence and does not block archive.
• /opsx:bulk-archive detects conflicts across completed changes and archives in chronological order.
• Custom schemas live under openspec/schemas/, can be forked or initialized, and can be validated.
• Schema resolution checks CLI flag, change metadata, project config, then default schema.

Editorial judgment in this article:

• Which commands to prefer for specific team scenarios.
• When to avoid custom schemas.
• The rollout sequence for advanced adoption.
• The examples for research-first, compliance review, and migration-first workflows.

Sources

Primary sources reviewed on July 1, 2026:

• Fission AI, OpenSpec OPSX workflow - OPSX philosophy, actions instead of phases, schema-driven workflow, artifact dependency model
• Fission AI, OpenSpec commands - default and expanded command behavior, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive, /opsx:onboard
• Fission AI, OpenSpec concepts - specs, changes, schemas, dependency graphs, built-in spec-driven schema
• Fission AI, OpenSpec customization - openspec/config.yaml, custom schemas, templates, schema validation, schema resolution
• Fission AI, OpenSpec supported tools - profile-dependent skill and command generation

Related reading on this site:

• How to Get Started with OpenSpec: Existing Projects, New Apps, and Common First Changes
• OpenSpec vs GitHub Spec Kit: A Side-by-Side Review of Spec-Driven Development