--- name: capture-context description: Extract reusable knowledge from any input — conversations, pasted documents, links, MCP content, teammate messages, meeting notes, casual mentions — and route it into the right workspace files so future conversations start smarter. Use this skill whenever the user says "capture", "save what we learned", "update context", "feed this back", "remember this for next time", "capture context", or at the end of any substantive conversation. Also trigger proactively — when a conversation is wrapping up and the user shared information that would save time in future chats (corrections, clarifications, process explanations, cost figures, stakeholder preferences, constraints), suggest running this skill before closing out. Even partial triggers count: if the user provided new domain knowledge while using another skill, this skill captures the knowledge that made that skill work better. Trigger phrases include "done", "thanks", "that's it", "wrap up" when the conversation contained new reusable information. Also trigger when the user pastes a Teams/Slack message, shares a link, or says things like "someone told me", "I just learned", "turns out", "FYI", "heads up", or relays information from a meeting, stakeholder, or document. --- # Capture Context People share valuable information during every conversation — constraints, processes, cost figures, how things actually work internally, what a stakeholder said, what they learned in a meeting. That knowledge dies when the chat ends. This skill extracts it and feeds it back into the workspace so every future conversation (and every skill) benefits automatically. The goal: say something once, and it sticks. This is not a note-taking tool. It captures **reusable knowledge** — the kind of information that, had it been in the workspace from the start, would have saved time or avoided mistakes. --- ## Step 0: Understand the Input Information arrives in many forms. Before extracting learnings, understand what you're working with: - **Conversation context** — things said during this chat that contain reusable knowledge - **Pasted text** — a Teams/Slack message, an email, a document excerpt, meeting notes - **A link** — a URL to a document, dashboard, wiki page, or resource (fetch and read it) - **MCP-accessed content** — a Confluence page, Jira ticket, or other tool content already pulled in - **Casual relay** — "my manager just told me X", "turns out the process actually works like Y" For links: fetch the content first (using WebFetch or the appropriate MCP tool), then extract learnings from what you find. For pasted documents: read the full text and extract what's new and reusable. For casual mentions: the fact that it was mentioned casually doesn't make it less important — often the most valuable context comes from offhand remarks. --- ## Step 1: Scan the Workspace Structure Every workspace is different — the onboarding skill creates folders and files based on each person's specific product, tools, and role. Before routing any information, discover what actually exists. ``` # Run this to understand the workspace layout find context/ -name "*.md" -type f 2>/dev/null find initiatives/ -name "*.md" -type f 2>/dev/null find discovery/ -name "*.md" -type f 2>/dev/null ls templates/ 2>/dev/null cat BACKLOG.md 2>/dev/null | head -20 ``` Build a mental map: - **What context files exist?** (strategy docs, KPI files, operations docs, team context, etc.) - **What initiatives are active?** (each folder in `initiatives/`) - **What discovery artifacts exist?** (research questions, OSTs, campaigns) - **What's the general shape?** (sparse template vs. rich workspace) This scan takes seconds and prevents routing mistakes. Skip it and you risk creating duplicates or putting information in the wrong place. --- ## Step 2: Extract Learnings Review the conversation (or the provided input) and identify information that would be valuable in future chats. The best signal: moments where something had to be corrected, clarified, or explained — those are context gaps. ### What to capture - **Business rules & constraints** — "we can't do X because legal requires Y", "our auth system doesn't support Z" - **Internal processes** — "the ops team reviews candidates weekly", "Sales handles stage transitions, not the product" - **Cost & metric inputs** — "cost per hour is X€", "average session duration is 30 minutes" - **Stakeholder preferences** — "Sales wants the report in format X", "the CEO cares about metric Y" - **Terminology & definitions** — "when we say 'qualified' we mean X", "'self-service' means the user does it, not the support team" - **Solution constraints** — "we can't touch system X without involving Team Y", "the two portals don't share the same auth tenant" - **Process exceptions & edge cases** — "for enterprise customers, the review takes 2 extra weeks" - **Domain knowledge** — how the business, product, market, or users actually work beyond what's documented - **Corrections to existing docs** — if the conversation revealed something documented is wrong or outdated - **Calculation logic** — formulas, assumptions, or business rules behind metrics and business cases - **Tool & system knowledge** — "we use Calendly for booking", "the data lives in Salesforce, not our DB" - **Reference links** — dashboards, wiki pages, external docs that were mentioned and would be useful later For each piece, capture the **fact** and the **why** behind it. "Reviews are weekly" is useful. "Reviews are weekly (Tuesdays) because the team batches to reduce context-switching across 200+ items" is much better — the reasoning helps future conversations judge when the rule applies. ### What NOT to capture - **Task outputs** — what tickets were created, what was shipped. That's ephemeral. - **Current status or in-progress work** — belongs in `status.md`, not context files. - **Claude behavior preferences** — how the user wants responses formatted belongs in CLAUDE.md or memory, not context files. - **Vague or speculative claims** — only capture things stated with confidence or from a credible source. If uncertain, flag it. - **One-time facts** — "we need this by Friday" is ephemeral. "Sprint cadence is 2 weeks, starting Tuesdays" is reusable. - **Information already in the workspace** — always check first. ### How to spot learnings The richest captures come from **friction moments**: - A correction was made → the correct version is a learning - A skill needed extra input → that input is a context gap - A process was explained to make something work → that process knowledge is reusable - A requirement changed because of a constraint that wasn't known → that constraint is a learning Also watch for **implicit knowledge** — things mentioned casually that aren't documented anywhere. --- ## Step 3: Check Against Current State For each candidate learning, read the target file(s) to verify: 1. **Already documented?** → Skip it. No value in duplicating. 2. **Partially documented but incomplete?** → Propose adding the missing detail. 3. **Contradicts existing documentation?** → Propose a correction. Flag clearly and explain which source is more recent/reliable. 4. **Entirely new?** → Propose an addition to an existing file, or a new file if no good home exists. This prevents noise. The goal is genuine delta — information the workspace doesn't already have. --- ## Step 4: Route Each Learning to the Right File Information goes where it **belongs**, not where the conversation happened to be about. A constraint about operations that came up during a feature discussion belongs in the operations context file, not in the initiative folder. ### How to route (dynamic — based on your Step 1 scan) **Initiative-specific information** (only if it's truly specific to one initiative): | Content type | Target | |---|---| | Stable facts, constraints, scope decisions | `initiatives//README.md` | | Requirements, acceptance criteria details | `initiatives//prd.md` | | Tracking details | `initiatives//tracking-plan.md` | **Cross-cutting knowledge** (applies beyond a single initiative): Match each learning to the most relevant existing file in `context/`. Use the filenames and content from your Step 1 scan to find the best fit. Common patterns: | Learning about... | Likely home | |---|---| | KPIs, costs, ROI, business case inputs | A KPI or business case file in `context/` | | Funnel stages, conversion mechanics | A funnel or pipeline file in `context/` | | Operations, internal processes | An operations file in `context/` | | Team structure, stakeholder info | A team or org context file in `context/` | | Strategy, direction, priorities | A strategy file in `context/` | | Tools, systems, tech stack | A tools or tech reference file in `context/` | | External links, dashboards | A reference links file or README | If no existing file is a good match, create a new one in the most logical subfolder of `context/`. Follow the workspace's frontmatter convention — include `title`, `type`, and `last_updated` at minimum. **Research insights or user evidence:** Route to `discovery/` — research questions, OST opportunities, or campaign findings. **Random ideas or feature requests mentioned in passing:** Route to `BACKLOG.md` as inbox items. ### Routing test For each learning, ask: "If someone started a brand new conversation about [topic], where would they look for this information?" That's where it belongs. --- ## Step 5: Present All Proposed Changes as a Batch Show all changes in one overview so the user can approve, modify, or reject them efficiently. Group by file for readability. ### Format for updates to existing files ``` ### 1. Update: context/[subfolder]/[filename].md **What:** Add batch review cadence and volume context **Section:** After "[relevant heading]" **Add:** > The ops team processes reviews in weekly batches (Tuesdays). Volume is ~200 items per cycle, > which means new items submitted mid-week wait up to 6 days for their first review. ``` ### Format for new files ``` ### 2. New file: context/[subfolder]/[filename].md **What:** Document booking scheduling constraints (came up during conversation — incorrect assumptions were made about flexible scheduling but booking windows are actually fixed) **Preview:** > --- > title: Booking Rules > type: reference > last_updated: [today's date] > --- > [first ~10 lines of content] ``` ### Format for corrections ``` ### 3. Correction: context/[subfolder]/[filename].md **What:** Fix team-to-customer ratio (currently says 1:50, actually 1:80 since restructuring) **Current:** "Each team member manages approximately 50 active cases" **Updated:** "Each team member manages approximately 80 active cases (ratio changed after the team restructuring in [date])" ``` After the list, ask: > **Apply all updates?** You can ask me to skip, modify, or split any of these before I apply them. --- ## Step 6: Apply Approved Changes For each approved change: 1. Read the target file 2. Apply the edit (or create the new file with proper frontmatter) 3. Move to the next After all changes: one-line summary of what was captured and where. --- ## Proactive Triggering When a conversation is naturally ending — the user says thanks, a deliverable is done, or the chat is winding down — and you identified reusable knowledge shared during the conversation, suggest it specifically: > "We covered some new ground on [specific topic] — you explained [concrete example]. Want me to run /capture-context to save that for future conversations?" Be concrete about what you'd capture. If you can't name at least one specific learning, don't suggest it. Generic "should I update the docs?" adds no value. The strongest signal for proactive triggering: something had to be explained or corrected that a well-informed workspace would have already known. That's a context gap worth closing. --- ## Edge Cases **Multiple topics discussed:** Group proposed changes by file, not by topic. Easier to review. **Conflicting information:** If a learning contradicts existing docs, present both versions and explain which is more likely current. Let the user decide. **Large input (pasted document or fetched page):** Prioritize. Better to capture 3 high-impact learnings than 10 trivial ones. Focus on information with the most leverage across future conversations. **Skill-produced conversations:** When another skill was used and corrections or extra context were needed to get the right output, those corrections are the highest-value captures. They represent gaps that will cause the same friction next time. **Uncertain attribution:** If a number or fact came up but it's unclear whether it's current or approximate, capture it with a caveat: "~X (estimate, [date] — verify against [likely source])". **Nearly empty workspace:** If Step 1 reveals a sparse workspace (just the template defaults), you may need to create new files rather than updating existing ones. Follow the conventions from `context/README.md` and use the frontmatter rule from CLAUDE.md. **Nothing worth capturing:** Sometimes a conversation has no new reusable knowledge. That's fine — say so. "Reviewed the conversation — no new reusable context to capture. Everything discussed was either already documented or task-specific."