Post-Edit Verification

After editing a component file, the natural instinct is to re-read the full file to confirm the edit landed. Don't, by default. Component JSON files are minified single-line documents, often 20–100 KB, and re-reading them after every edit consumes parent-conversation context that the actual work needs. Several lighter-weight signals do the same job — apply them in this order.

Hook-replacement context. Mitch's repo carried a PostToolUse hook (hooks/validate-component.py) that auto-blocked any Edit/Write of a tracked component suffix when the description was null/empty/>100 chars or the JSON failed to parse. The Datex Skills repo has no PostToolUse mechanism — skills are not auto-invoked by tool events. This skill is the substitute: every component-creator skill ends with "after your edit, invoke post-edit-verification", so the same two platform invariants are enforced in one place (DRY) at the skill layer instead of the harness layer.

Platform invariants (the minimum checks)

These two rules are non-negotiable for every component file. They are the rules the former hook enforced and they remain the floor of this skill — every invocation must confirm both, regardless of how trivial the edit looked.

description is present and within the platform limit. The top-level description must be non-null, non-empty, and ≤ 100 characters. The Footprint platform stores description in a SQL column capped at 100 characters; imports fail with a SQL truncation error if exceeded. See ../datex-studio-conventions/defaults.md for the canonical "Descriptions Are Mandatory" rule and ../datex-studio-conventions/file-format.md for the 100-char SQL limit. If the field is missing or too long, fix it as part of the same edit cycle — do not ask whether to backfill, just author a ≤100-char description (the user can override the wording afterward like any authored value).
The JSON parses cleanly. After the edit, the file must still be valid JSON. Run python -c "import json; json.load(open(r'<path>')); print('OK')". A mismatched brace, stray quote, or bad escape sequence will surface here. Free, no parent-context cost. Run it once after a sequence of edits to the same file, not after each one.

If either invariant fails, the edit is not done. Fix the violation and re-verify before claiming completion or moving on.

Verification stack (cheapest first)

The Edit tool's success message. The tool reports "The file ... has been updated successfully." That message means old_string matched and was replaced verbatim. If you crafted a precise old_string and the tool reported success, the textual edit is in. The remaining question is whether the result is structurally and semantically valid — which the next layers cover.