Run any Skill in Manus with one click

boundary-case-check

Stars0

Forks0

UpdatedJuly 12, 2026 at 23:11

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ralfyishere

ralfyishere/piensalo

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

File Explorer

7 files

SKILL.md

readonly

name	boundary-case-check
description	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.
license	MIT

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.

More from this repository

same repository

audience-constraint-check

ralfyishere/piensalo

Check a deliverable against its actual consumer: who reads it, what they do next, what format and register they need, and what they will assert downstream on its basis. Activate when the deliverable has a named audience beyond the requester, or its text will be forwarded, announced, or acted on by someone absent from the conversation.

2026-07-120

calibrated-uncertainty

ralfyishere/piensalo

State every claim at its actual evidence level — verified, inferred, assumed, guessed — and give credences only where an observable could score them; ban certainty language on unverified claims. Activate when a response makes claims about unobserved, future, or unverified state, or when the user asks how confident or likely something is.

2026-07-120

causal-model-construction

ralfyishere/piensalo

Before intervening in a system, write the explicit causal chain from the proposed action to the intended outcome — every arrow marked verified or assumed — and check the weakest assumed arrow first. Activate when an intervention (fix, optimization, policy change, growth action) is proposed on a system whose mechanism has not been written down.

2026-07-120

cheapest-discriminating-test

ralfyishere/piensalo

With multiple live hypotheses and a limited test budget, design the cheapest single test whose possible outcomes separate the hypotheses — with a results-to-verdict table committed before running anything. Activate when two or more competing hypotheses are on the table and the next step is choosing what test, experiment, or probe to run.

2026-07-120

complete-the-delivery

ralfyishere/piensalo

Enumerate every deliverable the request actually asked for and map each one to the work produced, so nothing asked-for is silently dropped, stubbed, or rounded up to done. Activate when a request contains multiple parts — an enumerated list, several 'and'/'also' clauses, or a spec with more than one required artifact — or before delivering a draft against such a request.

2026-07-120

contradiction-resolution

ralfyishere/piensalo

When inputs contain conflicting facts, stop and resolve the conflict explicitly — classify it, pick a resolution rule, and log what stays unresolved — before building anything on either side. Activate when two sources give different values for the same quantity, a document's claim disagrees with observed state, or the text itself flags inconsistency.

2026-07-120

name	boundary-case-check
description	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.
license	MIT

boundary-case-check

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.

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