Markdown

Data. At the start of every session, read ~/Clawic/data/markdown/config.yaml (what the user declared) and ~/Clawic/data/markdown/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 the recorded render targets before writing or fixing any document: the same bytes are correct in one parser and broken in another. If none of it exists, work from defaults and say nothing about it.

Write before the session ends whenever the session produced something durable: a render target and the quirk it imposes; a doc set and the generator that builds it; a lint, formatter, or CI config that finally passed; a conversion recipe that produced the right output; a house-style rule observed in their files; a link or lint sweep and what it found; or something the user will re-read — a page or README template, a style guide, a decision about the docs stack. memory-template.md holds every destination, format and threshold, and is the only file you open in order to write.

Doc sets that belong to a tracked project or a client point at the shared boxes: the project goes in ~/Clawic/data/projects/<project>.md and the person in ~/Clawic/data/contacts/contacts.md — read each before writing, update the existing entry in place, and here keep only the name. Duplicating a project or a person is how two skills start contradicting each other.

No credential is ever written anywhere under ~/Clawic/data/ — not in the files named here, not in a file you create, not in a document the user pastes in to be saved. Documentation is unusually dense in secrets: a curl example carries a token, a config snippet carries a connection string, a CI YAML carries a publish key. Strip the value and leave the pointer: env:NPM_TOKEN, keychain:docs-deploy, 1password:Work/Docs/confluence, file:~/.netrc. If data sits at an old location (~/markdown/ or ~/clawic/markdown/), move it to ~/Clawic/data/markdown/, and say in one line that you moved it and from where.

Correct Markdown is not a property of the text. It is a property of the text plus the parser that will render it, and every bug in this domain is one of five things: a missing block boundary, an indentation column, an unescaped character, an extension the target does not have, or raw HTML the target strips. Name which one, name the target, and hand back the exact bytes that change. Work from defaults immediately: never open with questions about their flavor, their linter, or how proactive to be. Precedence for any value: config.yaml → ~/Clawic/profile.yaml (shared universals: locale) → the Configuration table default.

When To Use

• Writing or generating Markdown that must render correctly somewhere specific: a README, a docs page, a changelog, an issue, a chat message, a generated report
• Debugging a render: broken lists, tables, fences, emphasis, links, anchors, images, frontmatter, footnotes, math, diagrams
• Porting a document between targets — GitHub to a docs site, docs site to MDX, HTML to Markdown, Markdown to PDF or DOCX
• Setting up or fixing the toolchain around Markdown files: markdownlint, Prettier, remark, link checking, CI gates
• Editing existing Markdown without exploding the diff, and keeping anchors alive through a heading rename
• Rendering Markdown that someone else wrote, where raw HTML and link schemes are an attack surface
• Not for LaTeX documents (latex), .docx production (word-docx), templated PDF deliverables where the layout is the point — reports, invoices, contracts (pdf-generator) — or deciding what documentation should exist and how it is maintained (documentation); this is the syntax and rendering layer under all four. Markdown → PDF stays here when the question is the conversion itself: engine choice, fonts, filters, what the export silently drops (conversion.md)