agentleFS
SprocketLabSprocketLab/slop-code-bench/.claude/skills/edge-cases/SKILL.md

edge-cases

Skill288 starsChanged 11 months agoMITView on GitHub

Analyze checkpoint tests and suggest missing edge cases. Use after writing tests or when reviewing test coverage. Invoke with /edge-cases <problem> <checkpoint>.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. morshed272/claude-build-workflow★ 1same name
    2. Leostruka/devin-bundle★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository8 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read these files for the specified problem/checkpoint:

    line 23
  2. Distinctive:

    If the spec is ambiguous or there are multiple valid interpretations:

    line 58
  3. Distinctive:

    Ask yourself: "Can I point to the spec line that defines this behavior?"

    line 66
  4. Distinctive:

    Run eval-snapshot to verify:

    line 138
  5. Very specific:

    Remove pytest.fail("Not implemented") as you implement each test

    line 144

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Edge Case Analyzer

Analyze a checkpoint's spec and existing tests to identify and add missing edge cases.

Usage: /edge-cases execution_server checkpoint_2

Workflow

  1. Read the spec - Understand all requirements, constraints, error conditions
  2. Read existing tests - See what's already covered
  3. Identify gaps - Find missing edge cases
  4. Add skeleton tests - Append to test file with TODOs

Step 1: Gather Context

Read these files for the specified problem/checkpoint:

problems/{problem}/checkpoint_N.md
problems/{problem}/tests/conftest.py
problems/{problem}/tests/test_checkpoint_N.py

Step 2: Analyze for Gaps

For each requirement in the spec, ask:

  1. What happens with empty/null input?
  2. What happens at boundary values (0, -1, max, min)?
  3. What happens with malformed input?
  4. What happens with missing required fields?
  5. What happens with unexpected types?
  6. Are there race conditions or state edge cases?
  7. Are there format edge cases (unicode, special chars)?

Cross-reference with existing tests:

  • Which spec requirements have tests?
  • Which error conditions are tested?
  • Which boundary conditions are tested?
  • What did the spec mention that tests don't cover?

Important: Avoid Ambiguous Cases

Only add edge cases where the spec is clear about expected behavior.

If the spec is ambiguous or there are multiple valid interpretations:

  • Don't add a test - it's not a valid edge case
  • The spec should define the expected behavior, not the tests
  • Tests should verify spec compliance, not invent requirements

Good edge case: Spec says "return error for negative values" → test with -1 Bad edge case: Spec doesn't mention negatives → we don't know what should happen

Ask yourself: "Can I point to the spec line that defines this behavior?"

  • Yes → Valid edge case
  • No → Skip it or note the spec ambiguity

Step 3: Generate Skeleton Tests

Append to test_checkpoint_N.py:

# === EDGE CASES (review and implement) ===

@pytest.mark.functionality
def test_empty_input(entrypoint_argv):
    """Edge case: Empty input should return appropriate error.

    Spec says: [quote relevant spec section]
    """
    # TODO: Implement - call with empty input, verify error handling
    pytest.fail("Not implemented")


@pytest.mark.functionality
def test_negative_value(entrypoint_argv):
    """Edge case: Negative values should be rejected.

    Spec says: [quote relevant spec section]
    """
    # TODO: Implement - test with negative input
    pytest.fail("Not implemented")


@pytest.mark.functionality
def test_unicode_input(entrypoint_argv):
    """Edge case: Unicode characters in input.

    Spec says: [quote relevant spec section]
    """
    # TODO: Implement - test with unicode characters
    pytest.fail("Not implemented")

Markers to Use

All edge cases use @pytest.mark.functionality.

Edge cases are additional coverage beyond the core tests - they should not block a passing submission. Core tests cover the main spec requirements; edge cases catch less common scenarios.


Common Edge Case Categories

See patterns.md for detailed patterns by problem type:

Always check:

  • Empty/null inputs
  • Boundary values (0, -1, MAX_INT, empty string)
  • Malformed data (invalid JSON, wrong types)
  • Missing required fields
  • Duplicate handling
  • Unicode and special characters
  • Very large inputs
  • Concurrent operations (if applicable)

After Adding Skeletons

  1. Review each TODO and implement the test
  2. Run eval-snapshot to verify:
    slop-code -v eval-snapshot problems/{problem}/solutions/checkpoint_N \
        -p {problem} -o /tmp/eval -c N \
        -e configs/environments/docker-python3.12-uv.yaml --json
  3. Remove pytest.fail("Not implemented") as you implement each test

Example Output

For execution_server checkpoint_1, might generate:

# === EDGE CASES (review and implement) ===

@pytest.mark.functionality
def test_execute_empty_command(client):
    """Edge case: Empty command string.

    Spec says: [quote relevant section about command validation]
    """
    response = client.post("/v1/execute", json={"command": ""})
    # TODO: Verify appropriate error response
    pytest.fail("Not implemented")


@pytest.mark.functionality
def test_execute_missing_command(client):
    """Edge case: Request body missing 'command' field.

    Spec says: [quote relevant section about required fields]
    """
    response = client.post("/v1/execute", json={})
    # TODO: Verify 400/422 response
    pytest.fail("Not implemented")


@pytest.mark.functionality
def test_execute_unicode_output(client):
    """Edge case: Command that outputs unicode characters.

    Spec says: [quote relevant section about output handling]
    """
    response = client.post("/v1/execute", json={"command": "echo '日本語'"})
    # TODO: Verify unicode is preserved in response
    pytest.fail("Not implemented")

Reference

  • patterns.md - Edge case patterns by problem type

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.