Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →magebyte-zero/spec-merger
Sync delta specs to main specs before closure. Invoke while an executing change has delta specs to merge into the main spec base, or when detecting spec drift across multiple changes.
Passed 15 of 18 test cases with the skill, and 9 of 18 without it.
and 7 more in the full report
8 fixed11 passed either way3 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are syncing a new capability `analytics` from `changes/analytics-v1/specs/analytics/spec.md` which includes a `## Purpose` header. Should this Purpose block be incorporated into the newly created main spec `specs/analytics/spec.md` or ignored?
| Checked | Without skill | With skill |
|---|---|---|
| Includes the delta Purpose block in the newly created baseline specification. | Missed | Passed |
The instructions your model reads when the skill loads.
Before executing a CLI line below, replace its leading SSF with node "<plugin-root>/scripts/spec-superflow.mjs"; <plugin-root> is the absolute directory two levels above this file. Never run SSF literally or call an ssf from PATH.
Before the final executing → closing transition, delta specs (ADDED/MODIFIED/REMOVED/RENAMED) must be published into the main spec base. changes/<change>/ remains the active workflow source; root specs/ is only the published baseline. Specs that aren't synced become lies. A change already in closing must not be routed to spec-merger.
Before SSF sync or any other write, run
SSF state get <change-dir> state.
Continue only when the persisted state is exactly executing. If it is
closing → STOP: "Closing is terminal. Do not route this change to spec-merger;
synchronization belongs before the final executing → closing transition." For
any other state, or if the state cannot be read → STOP and route through
workflow-start; do not perform side effects.
Run SSF sync <change-dir>. If conflicts are detected (same requirement modified by multiple changes), present the conflict list to the user for resolution order.
Each specs/<capability>/spec.md under the change folder contains delta operations under ## ADDED/MODIFIED/REMOVED/RENAMED Requirements.
## Purpose is an optional top-level delta extension. Use it only when creating a canonical main spec. When it is absent or empty, the sync result uses and reports a deterministic default Purpose so legacy delta specs remain usable. A delta Purpose must not overwrite an existing main spec Purpose.
ADDED: Append the requirement to the published baseline's ## Requirements. Create a canonical main spec if it does not exist.
MODIFIED: Match on ### Requirement: <name> and replace its description and scenarios. Flag if the requirement does not exist in the canonical baseline.
REMOVED: Remove the matched requirement from the published baseline. Flag if it does not exist.
RENAMED: Match the old name and change its header to the new name. Flag if the new name collides with an existing requirement.
test cases passed, vs 9 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.