agentleFS
vladcheckvladcheck/agentic/skills/opsx-spec-validate/SKILL.md

opsx-spec-validate

Skill1 starsChanged 10 days agoMITView on GitHub

Use when you need to validate if your openspec artifacts violate any specs defined by openspec.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every requirement has at least one scenario

    line 36
  2. Distinctive:

    No empty delta sections

    line 39
  3. Distinctive:

    Every new capability in proposal.md → has spec file in specs/

    line 42
  4. Distinctive:

    Every modified capability in proposal.md → has delta spec file in specs/

    line 43
  5. Distinctive:

    No extra spec files without corresponding proposal entries

    line 44
  6. Distinctive:

    No extra proposal entries without corresponding spec files

    line 45
  7. Distinctive:

    Ask a subagent to verify if your specs violate openspec conventions

    line 49

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Files to check

  • proposal.md - initial artifact
  • design.md - builds on proposal.md
  • specs/* - builds on proposal.md
  • tasks.md - builds on every spec above

Rules for proposal.md

  • Has sections: Why, What Changes, Capabilities (New + Modified), Impact
  • Capabilities use kebab-case names
  • Each new capability listed in New Capabilities has a corresponding spec file in specs/
  • Each modified capability listed in Modified Capabilities has a corresponding delta spec file in specs/
  • Breaking changes marked with BREAKING
  • Concise (1-2 pages)

Rules for design.md

  • Has sections: Context, Goals/Non-Goals, Decisions, Risks/Trade-offs, Migration Plan, Open Questions
  • Each Decision explains rationale (why X over Y?)
  • Risks have mitigation
  • Migration Plan has concrete steps
  • No empty sections

Rules for spec files (all)

  • Scenario headers: exactly 4 hashtags (#### Scenario: ...)
  • Requirement headers: exactly 3 hashtags (### Requirement: ...)
  • Every requirement has at least one scenario
  • SHALL/MUST for normative statements
  • Delta section headers valid: only ## ADDED, ## MODIFIED, ## REMOVED, ## RENAMED
  • No empty delta sections

Cross-artifact consistency

  • Every new capability in proposal.md → has spec file in specs/
  • Every modified capability in proposal.md → has delta spec file in specs/
  • No extra spec files without corresponding proposal entries
  • No extra proposal entries without corresponding spec files

Algorithm

  1. Ask a subagent to verify if your specs violate openspec conventions
  2. Fix violations

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.