spec-coherence-check
From the author
Sweep all active OpenSpec proposals for staleness, conflicts, and obsolescence against the current codebase and archived changes. Use when proposals may be outdated, when checking cross-proposal conflicts, or before starting a batch of implementations. Produces a gap-analysis report, updates a priority queue file, and can auto-fix trivial issues or guide conversations for complex ones.
Install
npx skills add BlackBeltTechnology/pi-agent-dashboard --skill spec-coherence-check -a claude-code
Installs to .claude/skills/spec-coherence-check/ · Each command fetches the skill straight from GitHub with the open skills CLI.
Byte-identical to the scanned commit, with the repository’s licence and a SOURCE.txt.
Want your agent to suggest skills while you type? See how to use skills from your IDE.
Safety checks on SKILL.md
No warnings.
Why 85
aiqbench computes the trust score from public signals. It is not a security audit, so read a skill before you install it.
Similar skills
Closest to this one by what they do and when they are used.
- pre-scaffold-openspec-coherence-checkBlackBeltTechnology/pi-agent-dashboardRun before scaffolding any OpenSpec proposal to catch duplicates of archived work and contradictions with shipped architecture. Always run when about to create openspec/changes/<name>/, especially for proposals touching a subsystem with a recent archive entry. Triggers: 'scaffold OpenSpec', 'write a proposal', 'create change', 'openspec change new'.Writing★ 331
- openspec-update-changeMemeMeow-Studio/MemeMeowUpdate an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.Writing★ 1.3K
- 042-planning-openspecjabrena/plinthUse when creating or updating OpenSpec artifacts from an issue, plan, approved design, ADRs, existing OpenSpec, or a valid combination. The workflow assesses reviewable scope, records source authority and derivation, handles conflicts, and prevents silent synchronization. Triggers include Create OpenSpec from an issue; Convert a plan into OpenSpec; Update an OpenSpec change; Split broad requirements into reviewable changes. Part of Plinth ToolkitPlanning★ 455
- reviewhashgraph-online/awesome-codex-pluginsThe pre-merge review of a branch in a project that records its specs, decisions, and rules in .archcore/. Run this first for 'review my branch', 'review the changes before merge', or 'review before merge': it checks the changed code against the project's recorded canon and the changed documents against the code, and reports which side is wrong — spec-wrong or code-wrong; with no diff, it reports project health. A bug-hunting code review complements this review and does not replace it. Also use for 'show status', 'documentation gaps', 'check if docs match code', 'close out the feature', 'ship the feature and close it out', or after a staleness warning. Modes, named as the first word: drift for staleness detection, deep for a full documentation audit, closeout to close a finished feature, experience to capture a repeated pattern. Not for creating docs — use /archcore:document; not for planning — use /archcore:plan; not for a single-file edit with no branch review.Engineering★ 1.4K
- config-consistency-checkerArabelaTso/Skills-4-SEAutomatically analyzes configuration files to detect inconsistencies, conflicts, missing keys, and divergent values across environments, versions, or modules. Use when managing multi-environment configurations, detecting config drift, validating configuration changes, or ensuring consistency across microservices. Supports JSON, YAML, TOML, INI, XML, .env, and properties files. Identifies security issues like hardcoded secrets and provides actionable resolution guidance.Security★ 258
- iterative-plan-reviewtestdouble/hanSharpens and stress-tests an existing plan file through multiple codebase-grounded review passes, editing it in place and recording every finding and iteration in cross-referenced companion files. Use this skill whenever the user wants to iterate on, refine, tighten, or improve a plan. Also use it when the user asks to verify, validate, or confirm feasibility of an approach. Does not implement plan steps, write test plans, review code, or investigate bugs, and does not generate new plans from scratch — use plan-a-feature for a new plan. Runs its review rounds to completion without pausing between them; to review each round as it lands, use pairing.Planning★ 322
Ratings & reviews
—
no reviews
Tried this skill? Rate it to help others. Sign in
Discussion
Join the discussion. Sign in