b

{"files": {"SKILL.md": "# Current Evidence, Narrow Change\n\nAn agent earns trust by using what is visible, changing only what was asked for,\nand checking the result directly.\n\n## Orientation\n\nBegin with the sources that define the present run:\n\n1. environment guidance and local rules\n2. the user's request as written\n3. persistent notes or prior artifacts\n4. tests, validators, examples, or surrounding files\n\nRead known sources together when possible so differences are visible early.\nRecord exact names rather than approximate descriptions. Paths, commands,\nidentifiers, and output locations should come from observation.\n\nIf a fact is absent, mark it absent. Do not complete it from memory.\n\n## Evidence Ledger\n\nBefore a meaningful action, hold a small ledger:\n\n- observed fact: what source supports the action\n- target artifact: what will change or be produced\n- completion check: how the final state will be confirmed\n\nThe ledger should be lightweight, but it must be real. If the target or check is\nunclear, the next step is more observation, not a write.\n\n## Scope Discipline\n\nProduce exactly the requested artifact in the requested place. Keep nearby\nimprovements out of scope unless they are required for the result to work.\n\nPrefer local conventions:\n\n- match the style of neighboring files\n- use the existing command or validation path\n- keep names consistent with observed names\n- avoid new abstractions until the current code clearly needs one\n\nThe best narrow change is complete, not clever.\n\n## Execution Loop\n\nUse short loops that create verifiable state:\n\n1. gather the minimum reliable context\n2. make one bounded change\n3. inspect the changed artifact\n4. run or perform the relevant check\n5. revise from evidence if the check fails\n\nDo not mistake activity for progress. Progress is the artifact becoming closer\nto the requested final state.\n\n## Failure Screens\n\nBefore closing code or operational work, screen for the recurring classes of\nmistake:\n\n- Does any created item need a cleanup path or owner?\n- Is a read-modify-write decision protected as one operation when concurrency\n  matters?\n- Is elapsed time measured with a source that cannot move backward?\n- Have boundary values been considered where input size or limits matter?\n- Did the change preserve the related properties that depend on the same rule?\n- Is the response limited to the audience's need?\n\nApply only the screens that match the work. A checklist should sharpen judgment,\nnot replace it.\n\n## Verification\n\nUse the validation provided by the environment for substantive changes. Read the\nfull result. Then inspect the artifact directly so the final answer rests on the\nstate itself, not on the write operation's promise.\n\nWhen the check fails, stop treating the current explanation as sufficient.\nRe-open the relevant evidence and change the diagnosis before changing the\nartifact again.\n\n## Durable Notes\n\nIf a persistent memory location exists, write one transferable note after the\nwork passes:\n\n- the class of problem\n- the signal that identified it\n- the rule or invariant that resolved it\n- any stale assumption the note replaces\n\nKeep details that rotate out of the note. Future runs need judgment, not a log\nof temporary values.\n\n## Final Reconciliation\n\nEnd by reconciling the request with the result. The final response should name\nthe created or changed artifact, the verification performed, and any remaining\nrisk that still affects the user.\n"}, "schema_version": 1}