Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →m0n0x41d/h-spec
Manage Haft's typed specification lifecycle and source-currentness repair: inspect current SpecSections, draft or clarify carriers, classify FPF semantic fanout, record operator-requested spec changes, and cross explicit approve/rebaseline/reopen gates only with human authorization.
Passed 8 of 14 test cases with the skill, and 3 of 14 without it.
and 15 more in the full report
12 fixed1 passed either way6 still failing3 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
We want to relate an immutable specification edition 'sec-req-88' to a concrete bounded context 'bc-billing'. Which tool action should we call, and can this action be used to approve the section at the same time?
| Checked | Without skill | With skill |
|---|---|---|
| Instructs calling haft_spec_section with action project | Missed | Passed |
| States that projection cannot approve, edit, rebaseline, or reopen a section | Missed | Passed |
The instructions your model reads when the skill loads.
Call haft_spec_section(action="lifecycle") first. Ground drafts in repository
evidence, edit only the current carrier, run spec checks, and inspect lifecycle
again. TargetSystemSpec and SoftwareSystemSpec are Haft local-practice
carrier labels, not FPF Core kinds by label alone.
lifecycle and next_step are project/scope-level
ProjectSpecificationSet workflow projections. Never pass section_id to
them or treat project workflow readiness as the state of one named section.
Use haft_query(action="spec_trace", section_id="<id>") for the exact edition,
status, and baseline, and haft_query(action="spec_use", section_id="<id>", use_context="<concrete receiving use>") for stronger-use admission. The kernel
rejects an action-inapplicable section_id with these recovery routes.
If the MCP action is unavailable, use haft spec next --json or
haft spec status --json; never infer lifecycle from Markdown status fields.
When a spec request returns profile_underdetermined, preserve the exact
request and any supplied ScopeID. Treat recovery_surface=haft_onboard and
next_action as navigation only. Read haft_onboard(action="status");
needs_profile permits at most a non-binding review, while
profile_review_ready permits showing that review. Apply only after the
operator directly and unambiguously selects the exact reviewed profile and
scope; route that request through h-onboard without requiring a skill name.
After apply and any required restart retry the same specification request.
Unrelated draft or clarification
work may continue only when it does not rely on profile applicability. Never
infer or auto-admit a profile, select software for convenience, or invent
lifecycle state.
TargetSystemSpec is Required for every declared realization scope even
when its profile has entity_reference: none. The optional entity relation is
for exact EntityOfConcern memory, traceability, and stronger identity-bearing
use; never prepare a profile change merely to continue TargetSystemSpec
lifecycle. A response that still reports
missing_basis=admitted_target_system_relation comes from a stale runtime or
skill projection: rebuild or reconnect the exact candidate and retry the same
read-only request without asking the operator for a relation choice. Changing
an existing relation remains a separate profile effect when that relation is
test cases passed, vs 3 / 14 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.