vibe-spec-sync

vibe-spec-sync is a skill for Claude Code from ash1794/vibe-engineering. It costs 90 tokens per session (2,090 once invoked), scanned A, original, MIT.

A specification-alignment aid that compares written requirements with implementation code and staged changes. A specification is a document describing what the software should do.

In plain words
What is it for?
Use it to audit a finished implementation, check staged changes before committing, and update a specification after approved decisions.
Why use it?
It finds places where code and documentation disagree, then can update the specification after approval. This keeps a completed change represented consistently in its code, tests, and documentation.

Skill for Claude Code

Written for Claude Code: user-invocable in frontmatter.

Part of the vibe-engineering plugin — 33 skills shipped together

Good fit Use it to audit a finished implementation, check staged changes before committing, and update a specification after approved decisions.

Compare 6 skills from other repositories ↓
Install with agentmods
npx agentmods add skills/ash1794/vibe-engineering/vibe-spec-sync
Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent
npx skills add ash1794/vibe-engineering --skill vibe-spec-sync
Clone the repo
git clone --depth 1 https://github.com/ash1794/vibe-engineering

Made for: Claude Code.

Or install vibe-engineering, the plugin that ships this one along with the rest of its 33 skills.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for vibe-spec-sync

README.md
[![agentmods](https://agentmods.dev/badge/skills/ash1794/vibe-engineering/vibe-spec-sync/github.svg)](https://agentmods.dev/skills/ash1794/vibe-engineering/vibe-spec-sync)
Your own site
<a href="https://agentmods.dev/skills/ash1794/vibe-engineering/vibe-spec-sync"><img src="https://agentmods.dev/badge/skills/ash1794/vibe-engineering/vibe-spec-sync/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

agentmods 80×15 button for vibe-spec-sync

Your own site · 80×15
<a href="https://agentmods.dev/skills/ash1794/vibe-engineering/vibe-spec-sync"><img src="https://agentmods.dev/badge/skills/ash1794/vibe-engineering/vibe-spec-sync.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 90 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,090 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00090 $0.02090
Opus 5.5 $0.00036 $0.00836
Sonnet 5.5 $0.00018 $0.00418
Haiku 4.5 $0.00009 $0.00209

Measured 8d ago against content hash cdf00c6d602c, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

vibe-spec-sync scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/vibe-engineering/skills/vibe-spec-sync/SKILL.md · 181 lines

How it starts

The opening of the file, as written. The whole thing — 181 lines — stays where its author put it; the contents beside it link to each section on GitHub.

vibe-spec-sync

Code changes. Specs don't update themselves. This skill closes the loop.

When to Use This Skill

  • Audit mode: implementation of a spec or design doc is claimed complete, after a major refactor, or when debugging behavior that may not match the spec
  • Sync mode: before committing, to detect spec drift from staged changes
  • Sync mode: after approving decisions (from vibe-decision-journal), to sync them back to the spec
  • Periodically, to confirm the spec still reflects reality

When NOT to Use This Skill

  • No spec exists (write one first, or use vibe-doc-quality-gate to bootstrap)
  • Prototype/spike code with no spec commitment
  • Spec is explicitly labeled as aspirational/future-state
  • Code was intentionally diverged, with the reasons documented

Modes

/vibe-spec-sync            # Sync mode: staged changes vs spec (default)
/vibe-spec-sync --audit    # Audit mode: full spec vs implementation, no edits

Prerequisites

The project must have:

  • A specification document (markdown) — configured in step 1
  • Implementation code that the spec describes
  • Optionally: a test suite with requirement traceability markers (# req:[ID])

Steps

Step 1: Locate Spec and Code (both modes)

  1. Find the spec — Look for:

    • spec.md, SPEC.md, *_spec.md in project root or docs/
    • Design docs in docs/design/, docs/architecture/
    • Ask user if ambiguous: "Which document is the authoritative spec?"
  2. Find the implementation — The code files the spec describes

  3. Find the decision log — docs/decisions/decisions.jsonl (from vibe-decision-journal)

Audit Mode (--audit)

Read-only. Nothing is edited.

  1. For each requirement or section in the spec, find the corresponding code and check whether it matches exactly.
  2. Record each divergence as a gap:
    • ID: GAP-[SECTION]-[NNN] (e.g., GAP-AUTH-001)
    • Type: Missing (spec says X, code has nothing) / Incorrect (spec says X, code does Y) / Extra (code does X, spec is silent)
    • Severity: Critical / High / Medium / Low
    • Evidence: the spec quote and the code file:line
  3. Report using the Audit Report format below. For 10+ gaps, hand them to vibe-gap-closure-loop. To accept an Extra or Incorrect item as the new intended behavior, run sync mode on it.

Read the full file on GitHub · 181 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 8d ago Changed · +32 tokens per session cdf00c6d602c
  2. 20d ago First seen · 181 lines · 58 tokens per session scan A e77d6dd2d08a

Subscribe to this mod's changes

vibe-spec-sync is a skill published in the GitHub repository ash1794/vibe-engineering (164 stars, last pushed 8d ago), licensed MIT. It adds 90 tokens to every session and 2,090 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-26.

Related

Other skills, from other repositories

pre-pr-audit

Pre-PR confidence audit with 5-dimension scoring. Use when: final check before commit/push/PR, evaluating PR readiness, assessing test quality + risk + coverage holistically. Triggers: pre-pr, readiness check, confidence audit, final verification, ready to PR, how confident. Not for: code review (use…

sd0xdev/sd0x-harness · 95 tokens

brooks-test

Test quality review drawing on twelve classic engineering books — with primary focus on xUnit Test Patterns, The Art of Unit Testing, How Google Tests Software, and Working Effectively with Legacy Code — that diagnoses structural problems in an existing test suite: brittleness, mock abuse, coverage illusions, slow…

hyhmrright/brooks-lint · 161 tokens

test-review

Test coverage review via Codex exec. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.

sd0xdev/sd0x-harness · 56 tokens

precommit

Pre-commit checks — lint:fix -> build -> test.

sd0xdev/sd0x-harness · 15 tokens

pr-comment

Post friendly review comments to a GitHub PR — prepare locally, preview, then submit as atomic review. Use when: posting code review comments, giving PR feedback, sending inline suggestions. Not for: reading existing reviews (use load-pr-review), creating PRs (use create-pr), PR status (use pr-summary).

sd0xdev/sd0x-harness · 67 tokens

precommit-fast

Quick pre-commit checks — lint:fix -> test.

sd0xdev/sd0x-harness · 15 tokens