babysit-specs

Revise queued spec folders to match code shipped since their last commit.

Updated Sep 17, 2026
One-click install
npx skills add https://github.com/hkw2028/toy-project --skill babysit-specs-hkw2028
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: babysit-specs
Source: https://github.com/hkw2028/toy-project/tree/main/.agents/skills/babysit-specs
Command: npx skills add https://github.com/hkw2028/toy-project --skill babysit-specs-hkw2028

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Specs written for queued work go stale as earlier work ships: assumptions break, acceptance criteria get satisfied by other features, terms get renamed, and linked prototypes drift from the real product. This Skill audits each active spec folder against the current repository and brings it back in line without changing what the user approved. ## Core Features & Use Cases - Baseline comparison: Diffs each spec against its last commit and the current behavior of the surfaces it names, including rendering linked prototype.html files as screens rather than reading markup. - Meaning-preserving triage: Fixes stale points that preserve the approved meaning (renamed terms, already-satisfied criteria, moved paths) as overridable assumptions, and asks exactly one question at a time about points that would change what was approved. - Clean handoffs: Names affected tasks for re-cutting, flags drifted prototypes for regeneration, reports retirement candidates, and routes reusable decisions to project-knowledge without ever editing product source. - Use Case: After merging a notification-channels feature, run the Skill over docs/specs/ so the remaining digest-schedule spec is updated to the shipped terminology, its satisfied criteria are closed, and you are asked one focused question about the one constraint the shipped code contradicts. ## Quick Start Ask the assistant to run babysit-specs on docs/specs/ so every queued spec is compared against what shipped and revised or escalated accordingly.

Frequently Asked Questions about babysit-specs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I update stale specs after shipping related work?

Run babysit-specs with one or more spec folders, or none to cover every folder under docs/specs/. It compares each spec against its last commit and current code, fixes meaning-preserving drift as overridable assumptions, and asks one question per point that would change approved meaning.

How does the skill decide what to fix versus what to ask about?

The axis is whether the approved meaning survives. Renamed terms, already-satisfied criteria, and moved paths are fixed in place and marked as overridable assumptions. Changes to approved outcomes, constraints, or scope trigger a single question with a recommended answer, and the skill waits.

Can it compare a linked prototype against the current product?

Yes. It renders the linked prototype.html and compares screens and states against the running product surface. When no runnable surface exists it falls back to comparing code and design files, and records that the comparison was weaker.

What happens when a spec has never been committed?

The skill recognizes there is no baseline commit, compares the spec against the current repository state alone, and states in its report that the comparison was weaker for that reason. It never commits the spec itself to manufacture a baseline.

When should I not use babysit-specs?

Do not use it to shape a new spec from a problem and direction, which belongs to shape-idea, or to reconcile durable project context and retire shipped folders, which belongs to maintain-project-context. It also never edits product source, configuration, or dependencies.

Does babysit-specs delete specs whose criteria all pass?

No. It verifies each acceptance criterion against the current repository and reports the spec as a retirement candidate, but deleting the folder belongs to maintain-project-context or the user.