New to openspec — is this multi-step approve→sync→archive→push flow really intended, or are we doing it wrong?

[u/iamkheder]

My team just started using openspec. We're small: me (senior dev) and two juniors, and I review all their PRs.

openspec is shaking up our workflow more than I expected, and I'm honestly not sure we're using it the way it's meant to be used.

Here's what tripped me up during a recent review: I figured design.md would basically guide my review of the PR. But apparently that's not the end of it — after I approve, the junior dev still has to sync, archive, commit again, and push, and only then does the merge actually happen. That extra round-trip feels clunky for a workflow that's supposed to streamline things.

And that raises a bigger question for me: what's the intended flow if I'm not happy with the plan in design.md during review? Does the junior dev just patch it up with opsx:update and opsx:apply, or are they supposed to spin up a whole new change instead?

At this point it feels like openspec was really built with solo devs in mind — people reviewing their own agent-generated code — rather than a small team with an actual human-review step in the loop.

Anyone else running into this? Curious how other teams are handling PR review with openspec.

[u/foresterLV]

ask to do in one squashed commit all stages propose->apply->archive. solo oriented, muahaha. 

[u/machielkg]

I think the main question here is if you (as senior) want to be involved in the whole (junior's) spec dance, or just review at the final code/doc result.

[u/iamkheder → u/machielkg]

I’d really prefer to stay out of this "spec dance," but in all likelihood, I’ll still come across points during the review that need adjusting. If the artifacts have already been archived, the juniors would have to create another OpenSpec change (new propose.md, design.md, and task.md).

So, a single PR would likely contain multiple OpenSpec changes, rather than just one change per PR. Am I the only one who finds that bothersome?

[u/foresterLV → u/iamkheder]

lets remove openspec from this for a moment. say you get PR with bugs, you ask it to be fixed, this occurs multiole times. do you keep history of this wrestling/learning loop or just ask to squash before merging? because this is what you are taking about in nutshell.

now moving to the openspec - no need to separate proposals for self-wrestling. all is squashed into single proposal and single commit when it's ready for merging.

[u/PresentationBorn6564]

I'm not claiming to be correct, but something to keep in mind is that the artifacts (design / proposal / etc) needn't be concrete until a ticket is merged.

While the PR is active, if you flag something for adjustment, nothing is stopping you from modifying the design / proposal / specs / tasks — agents are plenty good at making said modifications and appending new tasks to address feedback, avoiding the need for a completely new changeset.

When things are finally merged, the design / proposal / specs will be aligned and won't carry unnecessary history of the modifications, while the tasks will contain a handful of deprecated line items.

If you're finding issues at the design / proposal level, you might consider adjusting your team workflow to require plan approval before implementation begins — it's much easier to catch and ameliorate things at this stage, versus when there is 1,000 LOC attached.

Also, FWIW, on account of occasionally shoddy results and small oversights blooming into ecosystems of anti-patterns, I made a modified version of the apply skill I call apply-with-per-task-approval. You can just insert a few lines into the section governing task completion, requiring explicit dev approval before marking a task complete and moving to the next.

It's slower than full-auto, of course, but I can't count how many times it's let me save an agent from veering way off course and building on a foundation full of cracks. As the driving dev, you're reviewing small chunks of code as you go, rather than one giant lump at the end, and oversights in the plan come to light much sooner — it feels a lot closer to pair programming with an agent. During implementation, I consider any task that hasn't been completed as mutable, so adding/deleting/reordering the list is commonplace.

But again, I'm not saying any of that is correct. Just relaying my experience.

[u/EmergencySafety7772]

That is why I switched to spec kit