Turn the current conversation's conclusions into a well-formed context document filed in the project's context system. Use for /to-ctx, "file this into contexts", "turn this conclusion into a context doc". Finds the placement rules (e.g. CONTEXT_MAP.md), writes in the project's house style, and reports the path.
Installs into .claude/skills of the current project.
Are you the author of To Ctx?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/keli-wen-to-ctx-dev-skills)
---
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, "file this into contexts", "turn this conclusion into a context doc". 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
1. **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.
2. **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.
3. **Match the house style**: read one or two neighboring context files first, then mirror their structure, headings, naming and dating conventions.
4. **Place and write** the file per the rules; run the map file's placement check before writing, not after.
5. **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.
