INTERNAL SUBROUTINE — decomposes a boundary statement (API contract, service definition, policy text, SLA prose) into Laws / Admissibility / Deontics / Evidence quadrants per FPF A.6.B. Use only on specific boundary statements that mix statement types and need quadrant-by-quadrant cleanup. Do not auto-select for general work — for code review use Claude Code review; for problem framing use h-frame; for spec consistency audits use h-semio-review.
SkillScore82Maintained
On-demandOn-demand: invoked explicitly — never occupies your agent's context until called.
◆Doc Ops pack
Last verified 8/13/2026
What it changes
Passed 17 of 21 test cases with the skill, and 5 of 21 without it.
Without skill23%
With skill82%
Checks it passed that the model alone missed
Formats the claim identifier using the L- prefix.
Formats the claim identifier using the A- prefix.
Formats the claim identifier using the D- prefix.
and 19 more in the full report
14 fixed4 passed either way3 still failing1 broke
Pass-rate lift
+59 pp
Tokens
+27%
Agent turns
0%
Response time
-34%
Model gemini-3.6-flashMeasured 8/13/2026v118 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 14
Prompt
Here is a boundary claim register for our ingress API. Please directly write the project term-map YAML file, create the CI test script files, and issue the MCP tool calls to log decisions and evidence artifacts immediately into our repository database.
What was checked, without and with the skill
Checked
Without skill
With skill
Declines to write local artifact files or execute MCP decision tool calls.
Missed
Passed
Provides follow-up recommendations without directly generating downstream files.
Missed
Passed
case-06 · gemini-3.6-flash · 8/13/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
You are decomposing a boundary statement into FPF A.6.B's four quadrants. Per A.6.B, every load-bearing statement at a boundary belongs to exactly one of:
L — Laws / Definitions — what IS / what THIS MEANS. Definitional. Not actionable on its own.
A — Admissibility / Gates — what is ALLOWED / REJECTED under what conditions. Gate semantics.
D — Deontics / Commitments — what AGENTS PROMISE / OBLIGE / ARE PERMITTED to do. Speech-act semantics.
E — Work-Effects / Evidence — what HAPPENED / WAS OBSERVED. Run-time evidence; not a contract.
Mixing quadrants in one sentence is the root of contract-soup bugs. The unpack discipline forces atomic claims with explicit quadrant tags.
Explicit-only — disable-model-invocation: true. Operator invokes when working specifically on boundary semantics.
Step 1 — Read the boundary statement
Either operator pastes it inline, or they give a path to a spec section. Use Read to fetch if path-based.
Step 2 — Atomize
Break the statement into atomic claims — one assertion per claim. A claim is atomic when it can't be split further without losing meaning.
Step 3 — Tag each atomic claim with its quadrant
For each atomic claim:
Ask: does this DEFINE something, or use a definition? → likely L
Ask: does this state ALLOW / REJECT / DENY conditions for an action? → likely A
Ask: does this OBLIGE / PERMIT / FORBID an agent? → likely D
Ask: does this state SOMETHING WAS DONE / OBSERVED / MEASURED? → likely E
A claim that resists categorization usually mixes quadrants and needs further splitting.
Step 4 — Cross-quadrant dependencies
Per A.6.B, the four quadrants have explicit dependency discipline:
L statements depend on nothing (root vocabulary)
A statements may reference L for term grounding
D statements may reference L + A (you can't oblige what isn't permitted by A)
E statements may reference any L / A / D for context but stand as observation