Best way to integrate Graphify with OpenSpec (explore/propose workflows?)

[cookie-bytes]

Hi all,

I’m exploring how to integrate Graphify into OpenSpec workflows, particularly around /opsx:explore and proposal generation.

The goal is to use Graphify as a structural/architecture context layer (dependency graphs, service relationships, event flows) that OpenSpec can leverage during exploration and when generating proposals/specs.

I can see a few possible integration approaches, but I’m not sure what the intended or recommended pattern is:

• Pre-generating Graphify outputs (graph.json / queries / explain results) and feeding them into OpenSpec context
• Wrapping explore with Graphify CLI calls (query/path/explain) before proposal generation
• Treating Graphify as a tool (MCP/function-calling style) that OpenSpec can invoke dynamically during exploration
• Extending OpenSpec “skills” or prompt instructions to require Graphify lookups during explore

My questions:

• Is there a preferred or “official” way you expect external tools like Graphify to be integrated into OpenSpec?
• Do you see Graphify as something that should run pre-exploration (context building) or be called dynamically during exploration?
• Are there plans for a tool/plugin interface for architecture/context providers like this?

Would really appreciate guidance on the intended extension points before I build a custom integration layer.

Thanks!

[alesky78]

Hi @cookie-bytes

OpenSpec already provides a built-in customization mechanism for defining and extending workflows.

Official documentation:
https://github.com/Fission-AI/OpenSpec/blob/main/docs/customization.md

From a logical and architectural perspective, the core idea is that you define:

the workflow itself
the actions/instructions executed at each step
the templates/artifacts generated by each step

OpenSpec essentially acts as an orchestrator that executes this workflow.

Even the default OpenSpec implementation is built using this same mechanism. In fact, you can copy the default workflow, create your own custom version, and then adapt or extend it according to your needs.

There are also a couple of useful videos from Hari Krishnan covering this topic:

Workflow customization and architecture:
https://www.youtube.com/watch?v=k01nbZfwB34&t=1s
Recently released another workflow example:
https://www.youtube.com/watch?v=y5oemaPsmOA

Given this model, I think the “best” integration approach really depends on:

your specific context
the maturity of your engineering team
whether you want to maintain a custom extension layer over time
how tightly coupled you want Graphify to be with the OpenSpec workflow

I can imagine several valid approaches.

1 - Extend the default workflow
You could start from the default OpenSpec workflow and integrate Graphify directly into it.

For example:
add a dedicated architecture-analysis step
generate Graphify artifacts/context before proposal generation
inject dependency graphs, event flows, or topology summaries into later workflow stages

This approach stays very aligned with the OpenSpec customization philosophy.

2 - Replace or customize the /opsx:explore phase

Another option would be to create a custom exploration prompt/workflow that replaces the default /opsx:explore behavior.
In this model, Graphify becomes part of your own exploration pipeline and context-building strategy rather than an external runtime tool.

Personally,
I think OpenSpec currently looks more workflow-driven than tool-runtime-driven, so integrating Graphify as part of the workflow/artifact generation layer may feel more natural than dynamic tool invocation.

That said, both approaches seem technically viable.

Hope this helps.

In any case, if you end up implementing a solution, it would be really valuable if you could share your experience and the actual outcomes of your work.

I had a meeting with GitHub last week where they presented their new pricing model to our company, and I assume we are all increasingly thinking about token usage and cost efficiency these days.

In that context, approaches such as RAG, LLM-based knowledge systems (“LLM wiki”), and Graphify-style architecture/context extraction become particularly interesting areas to explore in more depth.