| name | to-ctx |
| description | Turn the current conversation's conclusions into a well-formed context document filed in the project's context system. Use for /to-ctx, "写进 contexts", "落个 context", "把这个结论归档", "file this into contexts". Finds the placement rules (e.g. CONTEXT_MAP.md), writes in the project's house style, and reports the path. |
| metadata | {"short-description":"File conclusions into the context system"} |
to-ctx
Take what this session has settled — a decision, a research result, a design, an investigation log — and turn it into a durable context file in the right place, so no future session has to rediscover it.
Language: context files are written in the project's documentation language (check neighboring files), which is not necessarily the conversation's language. Chat replies mirror the user.
Steps
- Locate the context system: find the project's durable layer and its placement rules — a map file (e.g.
contexts/CONTEXT_MAP.md), a docs/ADR convention, or directory READMEs. If the project has its own context-management skill, defer to its rules and use this skill only as the entry point. If no context system exists, propose ONE location to the user before creating anything.
- Select what is durable: keep decisions and their reasons, verified facts with sources, discovered constraints, and open questions. Drop process noise — exploration dead ends, tool logs, interim misunderstandings. If part of the content is already persisted (an issue, PR, or another context doc), reference it; never duplicate it.
- Match the house style: read one or two neighboring context files first, then mirror their structure, headings, naming and dating conventions.
- Place and write the file per the rules; run the map file's placement check before writing, not after.
- Report: the chat gets a one-line summary, the file path, and where it sits in the map. If the map file itself must register the new doc, update it in the same change.
Rules
- One fact, one home: never create a second source of truth for something already documented — update or reference the existing doc instead.
- The repo's own placement rules always win over this skill's defaults.
- Do not commit or push; filing the doc is the deliverable, version control stays with the user's workflow.
