SKILL.md 2.1 KB


name: problem-fix-verify

description: Answers by describing any problem with the pattern Problem / Proposed fix / Verification. Use when the user asks to explain a bug, a defect, or a change to make, on any topic.

Problem / Fix / Verification

What it's for

Produce an answer in a fixed, always-identical format when there is a problem to explain and fix. In plain terms: say what's broken, how you fix it, how you know it's fixed. Works for any topic, not just code.

How to answer

Open with one sentence saying where the problem is. Then three bullets, in this order. No intro, no closing, no repeats.

Pattern

.

  • Problem: .
  • Proposed fix: .
  • Verification: .
  • What to write in each item

    • Opening sentence: locate the problem. Where, in what, since when. One line.
    • Problem: what it does today and what the defect is. Describe the behavior, not the judgment.
    • Proposed fix: the concrete action to solve it. If there are future steps, add them as "when X arrives".
    • Verification: the cases to test, with expected result. Include at least one case that looks like it passes today but shouldn't.

    Rules

    • Short sentences. One item = one line.
    • Plain language: no jargon unless needed.
    • Verification must be observable: input → expected output.
    • Only the pattern block. No prose around it.

    Example (topic: Content-Type)

    The Content-Type problem sits inside RM-011: it's the first row of the known-defects table.

    • Problem: today the check only verifies that the header contains application/json somewhere. That's why a value like text/plain; x=application/json also passes.
    • Proposed fix: take only the part before the ;, strip spaces, and compare it to application/json case-insensitively. When RM-006 arrives, application/merge-patch+json will be accepted too.
    • Verification: text/plain; x=application/json must return 415, while application/json; charset=utf-8 must keep working.