spec-converge

Solid

Iteratively review an instar-development spec with multi-angle internal reviewers (security, scalability, adversarial, integration, decision-completeness, lessons-aware) and real cross-model external reviewers routed through the agent's own installed CLIs (codex → GPT-tier, gemini → Gemini-tier; one pass per available family) until convergence, then produce a comprehensive ELI10 convergence report. Output is a spec tagged review-convergence — one of the two tags /instar-dev requires before it will touch instar source. NOT user-invocable; run by the instar-developing agent before any spec-driven /instar-dev work.

AI & Automation 75 stars 18 forks Updated today MIT

Install

View on GitHub

Quality Score: 81/100

Stars 20%
63
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# /spec-converge **Audience:** the instar-developing agent. End users do not invoke this. Throughout this document, "the agent" refers to the instar-developing agent running the skill. --- ## What this skill does Takes a spec file, runs multiple parallel reviewers against it, updates the spec to address their findings, runs another round, and repeats until convergence. Produces a final converged spec and a comprehensive human-readable report. The purpose is to catch architectural, security, adversarial, scalability, and integration issues BEFORE code is written, not after. The single-reviewer pattern used by `/instar-dev`'s existing second-pass step has proven too narrow in practice — a four-reviewer parallel audit on the integrated-being ledger PR surfaced 14 serious issues that a single reviewer had missed. This skill bakes that multi-angle pattern in as the structural default for any substantive instar-dev work. ## When it runs Before `/instar-dev` touches any instar source, the change's spec must pass through this skill. `/instar-dev`'s pre-commit hook refuses work unless: 1. The spec file has a `review-convergence: <timestamp>` entry in its frontmatter, written by this skill on successful convergence. 2. The spec file has an `approved: true` entry in its frontmatter, written by the user after reading the convergence report. Both tags must be present. Without them, `/instar-dev` is blocked. ## Input One argument: the path to the spec file, relative to the insta...

Details

Author
JKHeadley
Repository
JKHeadley/instar
Created
5 months ago
Last Updated
today
Language
TypeScript
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

instar-dev

Instar-specific development skill used by the instar-developing agent (Echo, or any agent assigned instar-dev responsibilities). Wraps /build with mandatory side-effects review, signal-vs-authority principle check, and artifact generation. Structural enforcement via pre-commit/pre-push hooks — the instar repo refuses commits and pushes that didn't come through this skill. NOT a user-facing skill — end users should never invoke it.

75 Updated today
JKHeadley
Testing & QA Solid

converge

Spec↔code convergence scan. Use after implementation to verify the ACTUAL codebase matches the spec/plan — detects missing backends, dead buttons, partial wiring, scope creep. Classifies gaps (missing/partial/contradicts/unrequested), appends remediation tasks, loops until converged. The direct answer to 'the UI renders but nothing works' syndrome.

81 Updated 4 days ago
Rune-kit
AI & Automation Listed

spec-interviewer

Turn a vague software idea into a complete, build-ready specification set through a deep structured interview, then hand it to an AI coding agent. Use this whenever someone describes an app, product, system, or feature they want to build but hasn't nailed down the details — including phrasings like "I want to build X", "help me plan an app", "I have an idea for a system", "help me think through the features", "write a PRD/spec/requirements doc", or when they hand over a rough one-paragraph description and expect something buildable back. Also use it to extend an existing spec set with new modules, or to audit a spec that a coding agent keeps misinterpreting. The skill interviews module by module (roles, flows, rules, data, states, contracts, edge cases, UI), pushes back on gaps and scope creep, and emits numbered module specs plus a foundations doc, decision log, and progress tracker written specifically so Claude Code can build from them without guessing.

0 Updated today
chowjustin