Using OpenSpec as a Claude Code skill inside Personal AI Infrastructure

[mellanon]

TL;DR

I wrapped OpenSpec’s spec-first methodology into a Claude Code skill, so spec definition, iteration, and validation become an explicit capability Claude can invoke inside a Personal AI Infrastructure. It’s been a surprisingly clean way to reduce ambiguity and make LLM-driven work more repeatable. I’d love feedback on whether this feels like a natural extension of OpenSpec and how it could be shaped further.

⸻

Hi OpenSpec folks 👋

I wanted to share an interesting way I’ve been applying the OpenSpec methodology — not just as a repo-level workflow, but wrapped up as a Claude Code skill inside the Personal AI Infrastructure project.

🔗 Context / example:
SpecFirst Development Discussion
⸻

What I did

I took the OpenSpec approach (specs as the source of truth, changes as structured evolution) and packaged it into a Claude Code skill that:

• Guides Claude to work spec-first, before any implementation
• Treats specs as executable intent, not just documentation
• Couples spec definition, iteration, and validation into a repeatable skill workflow

Instead of OpenSpec being “a thing you run in a repo”, it becomes a capability Claude can invoke as part of a broader personal AI system.

⸻

Why this felt like a good fit

OpenSpec’s clarity around:

• intent → specification → change
• explicit deltas instead of implicit drift
• testability driven from spec language

maps extremely well to how Claude Code skills are used in practice. It gives the model strong rails:

• What am I allowed to change?
• What does success mean?
• What am I doing in which order?
• How do I know I’m done?

In practice, this significantly reduced ambiguity and improved consistency across iterations.

⸻

Why I’m sharing

I’d really appreciate input from folks here to help shape this idea further:

• Does this feel like a natural extension of OpenSpec’s philosophy?
• Have you experimented with embedding OpenSpec into agent or skill workflows (Claude Code or otherwise)?
• Does thinking of OpenSpec as an LLM capability pattern (not just tooling) resonate?

Any feedback, critiques, or suggestions would be hugely helpful.

⸻

My take (brief)

This feels like a promising way to:

• operationalize specs inside AI systems,
• make LLM behavior more predictable,
• and reduce the “prompt drift” that creeps into longer-running workflows.

But I’m very much in exploration mode, so input from this community would be awesome.

[real-lazy-coder]

I was thinking about this too. How have your result been using this approach?

[mellanon]

It's been working quite well actually! Developed SpecFirst and Jira skills and worked on v1.1.0 for the Context Skill in the Personal AI Infrastructure project. Give it a whirl

[real-lazy-coder]

My initial thought is that Claude Code Skills could assist with keeping specs up to date when changes are made outside of the OpenSpec ecosystem. Having a skill that can update specs when it identifies a change in the codebase that violates a current spec.

[TabishB]

Hey @mellanon! Sorry I just saw this.

Have you experimented with embedding OpenSpec into agent or skill workflows (Claude Code or otherwise)?

Yes, there will be be skills added to OpenSpec soon, especially now that it's a formal standard. There's some work happening in the background to refactor a lot of OpenSpec so haven't had a chance to do this yet, but soon!

Does thinking of OpenSpec as an LLM capability pattern (not just tooling) resonate?

Haha of course! To be honest we've been applying the "Skills" approach way before it was Introduced by Anthropic. Including progressive disclosure ;)

If you take a look when openspec is intiialized we edit the root AGENTS.md or CLAUDE.md and add a small note to tell agents to reference /openspec/AGENTS.md where we tell the agent how to use openspec! This is very close to what would be in a skill itself.

But not that the approach is solidified we can convert that convention doc into proper skills.