Boundary case check

Skill ralfyishere/piensalo/micro-skills/boundary-case-check

PIÉNSALO is the open artificial cortex for AI—reduce context tokens, verify response quality, expand when needed, and safely fall back.

Install

npx -y skills add ralfyishere/piensalo --skill boundary-case-check

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

For any rule-like deliverable — code, regex, query, formula, validator, policy — enumerate the boundary inputs (empty, zero, one, max, duplicate, malformed, hostile) and actually exercise the most breakable three before shipping. Activate when the deliverable is executable or rule-like and will meet inputs the author didn't type.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.6 KB, 453 tokens by cl100k_base, as published. Nobody here has run it

boundary-case-check

Trigger (observable): The deliverable is executable or rule-like: a function, regex, SQL query, spreadsheet formula, matching rule, allowlist/denylist, or threshold policy that will meet inputs the author didn't type.

When NOT to activate: Pure prose deliverables with no input domain; throwaway one-off commands already run against their only real input; boundaries already covered by an existing executed test suite named in the session.

Procedure

Write down the input domain the artifact will actually face — types, ranges, encodings, adversarial sources — not just the examples in the prompt.
Enumerate boundary candidates mechanically: empty, zero, one element, duplicates, maximum size, negative, unicode/odd encoding, wrong type, and (for guards/filters) the hostile input designed to slip through.
Rank by breakage likelihood and pick the top three.
Exercise them for real — run the code, test the regex against the string, execute the query on edge rows. A predicted outcome is not a result; quote actual output.
Report the three outcomes with the artifact; fix or scope-document any failure before shipping.

Required output

Three named boundary cases with actual (not predicted) outcomes, attached to the deliverable; failures fixed or the artifact's valid domain narrowed explicitly.

Verification

Three or more boundary cases were actually executed, with quoted real output.
Each failing boundary case is fixed or converted into an explicit stated domain restriction — never left as a silent gap.

Known risk: False confidence from testing three convenient edges rather than the three most breakable ones. Mitigation: the ranking step, plus one hostile case being mandatory for guards.

Max intended cost: ≤250 added output tokens; three real executions.

Evidence status: EXPERIMENTALLY_TESTED — micro-skill repair content lifted a weak model on procedural tasks in controlled runs; the effect is task-concentrated, and automatic router selection of micro-skills is a separate, unproven layer.

Lineage: Derived from two documented reasoning-failure modes: stopping at a plausible-looking result without exercising it, and verifying syntax while leaving semantics untested.