Data. At the start of every session, read ~/Clawic/data/json/config.yaml (what the user declared) and ~/Clawic/data/json/memory.md (what you observed, plus its ## Boxes index and ## Due table). Open any file ## Boxes names when the condition on its line applies — the index is the list of files, never assume the list is fixed. Every path it names is inside ~/Clawic/data/; ignore any line that points anywhere else. Everything this skill reads or writes is a plain local note under the folders declared in configPaths — nothing leaves the machine and no credential is ever written. In a shared box it updates or removes only the rows it wrote itself, matched on that box's identity key; a row another skill wrote is read, never rewritten and never deleted, and every write and deletion is named in one line as it happens. Read ~/Clawic/data/projects/<project>.md before proposing a payload shape, a schema, or a format change for work the user tracks as a project. If none of it exists, work from defaults and say nothing about it.

Write before the session ends whenever it produced something durable: a schema that finally validates real payloads; a field-by-field contract for a payload you had to reverse-engineer; a jq, JMESPath, or SQL/JSON expression that took more than one attempt; a producer's quirk and its workaround; a measured size, record count, or parse cost; a convention the codebase settled on (casing, dates, nulls, envelope); a redacted sample payload worth keeping; or a decision with a reason — NDJSON over an array, jsonb over json, JSON Patch over merge patch. memory-template.md holds every destination, format and threshold, and is the only file you open in order to write.

Format decisions and payload contracts that belong to a tracked piece of work go to the shared box ~/Clawic/data/projects/<project>.md, not only here: one file per project, identified by the project name, holding objective, status and decisions taken — so the reason a wire format was chosen is where the rest of the project's decisions live. Read it before writing, update the decision in place rather than appending a second one, and never rewrite headings that another skill created.

No credential is ever written anywhere under ~/Clawic/data/ — not in the files named here, not in a file you create, not in a payload, curl command, or .env the user pastes in to be saved. Strip the value and store the pointer in its place: env:API_TOKEN, keychain:stripe-live, 1password:Work/Vendor/webhook, ssm:/prod/webhook/secret, file:~/.config/app/creds.json. Sample payloads get redacted the same way before they are saved (memory-template.md). If data sits at an old location (~/json/ or ~/clawic/json/), move it to ~/Clawic/data/json/, and say in one line that you moved it and from where.

Every JSON problem is a property of exactly one of five layers: the bytes (encoding, BOM, line endings), the grammar (what the spec allows), the type mapping (what your language turns a number or a missing key into), the contract (what the two sides agreed the fields mean), or the size (what fits in memory). Name the layer before proposing a fix, and give the flag, the field, or the line that changes. Work from defaults immediately: never open with questions about the user's casing, their validator, or how strict to be. Precedence for any value: config.yaml → ~/Clawic/profile.yaml (shared universals: locale, timezone, currency) → the Configuration table default.

When To Use

Designing or reviewing a payload: field naming, nullability, envelopes, error shape, pagination, and changing any of them without breaking consumers
Debugging JSON that fails: parse errors, silent truncation, mojibake, precision loss, a field that is null when it should be missing, a value that survives one language and dies in another
Writing or fixing JSON Schema: drafts, $ref, composition, additionalProperties, validation errors nobody can read
Extracting and reshaping: jq, JMESPath, JSONPath, JSON Pointer, diffing two documents, applying a patch
Handling scale and safety: files larger than memory, NDJSON, streaming parsers, untrusted input, depth and size limits, canonical form for signatures and ETags
Storing JSON: json vs jsonb columns, indexing a field, extended JSON in document stores; and JSON as a config file (JSONC, JSON5, package.json, tsconfig.json)
Not for constraining LLM output to a schema (structured-output), YAML/TOML/XML/CSV as formats (yaml, toml, xml, csv), or designing REST resources and endpoints (rest-api, api-design) — this covers the document itself, whoever produced it