speq-skill + Ralph Workflow — are we solving adjacent or overlapping problems?

[mistlight]

Hi Marco,

I've been reading through speq-skill this week — the deliberate.codes posts first, then the repo. The "ask me instead of assuming" pattern and the semantic-anchors approach are doing work I haven't seen in OpenSpec/BMAD/SpecKit. The fact that you have a permanent spec library with semantic search (so the agent can find the right spec mid-planning, not just at session start) is the piece that always felt missing when I tried the others.

I work on Ralph Workflow (codeberg.org/RalphWorkflow/Ralph-Workflow) — same general "spec-driven dev for coding agents" lane, but on the EXECUTION side: hand a coding agent a spec, walk away, wake up to reviewable tested commits. The loop is the value, not the spec.

One thing I keep turning over: when you have a permanent spec library and the agent searches it semantically, the spec the agent finds at the start of a session IS the brief it runs against. If the spec is high-quality, the loop on the other side can run longer and more reliably. So your "permanent + searchable + small specs" framing and my "loop runs while you sleep" framing are complementary, not redundant — but I'm not sure if you've thought about it that way, or if you'd frame it differently.

Genuine question from someone working the same category from a different angle: do you see speq-skill as a standalone thing, or is the natural next step for it to hand off to an execution layer like Ralph (or a CI runner, or an OpenSpec-style workflow engine)? And the inverse: if a user already has speq-skill, what does Ralph add for them that their workflow doesn't already give them?

I'm not pitching a partnership. I'm genuinely trying to figure out if these tools are best understood as competitors, complements, or as different layers of the same category. Your read on that would help me a lot.

— Ken

[marconae]

Hi Ken (@mistlight),

Thanks for your feedback. I really appreciate that speq-skill resonated with you.

Your framing is correct, and it clarified something for me while I was thinking through the reply. speq-skill already has a loop: speq:implement iterates over a generated task list, one item at a time, with tests and review gating each step. But it's a bounded loop. It runs inside a session, against a task list a human just approved, and it stops when the list is exhausted or the session ends. It was never built to survive a crash, or to keep going unattended across the kind of stretch where you'd walk away and come back later. That's a different property than "no loop," and it's the actual line between what speq-skill does and what Ralph does.

So I'd put it exactly as you did: layers, not competitors. speq-skill's job is upstream, getting intent right before any code gets written, and keeping that intent as a permanent, searchable artifact so the next planning session (or the next agent) doesn't start from zero. Your loop is downstream: it takes a brief and runs it unattended until there's something reviewable. Your point that spec quality upstream determines how long and how reliably a downstream loop can run is exactly right, and it's a cleaner way to state something I'd only felt implicitly.

To your direct question: no, speq-skill isn't trying to become an execution engine, and I don't think it should. The interesting design question this raised for me is narrower: not "should speq-skill build a Ralph," but whether speq:implement's bounded loop should be able to hand off to something like Ralph once a plan is approved, instead of a human needing to bridge that gap by hand. Nothing decided there yet, but it's now on my radar in a way it wasn't before your issue.

To the inverse: for someone already running speq-skill, Ralph gives them exactly the thing speq-skill deliberately doesn't try to provide, unattended durability. If you've got a concrete shape in mind for how a speq-skill plan could feed a Ralph run, I'd genuinely like to see it.

— Marco