extract

Extract workflow

Extract structured knowledge from the wiki for downstream use. Use $ARGUMENTS as the intent description and optional destination (e.g., /extract a checklist for editing LinkedIn posts, /extract all prompt templates as JSON to ./prompts.json, /extract a compact summary of synthetic voice tells).

Prerequisites

• Verify wiki/index.md exists and the wiki has content. If the wiki is empty, suggest running /ingest on a source first — it will bootstrap the wiki automatically.

Phase 1: Parse intent

From $ARGUMENTS, determine three things:

1. What knowledge the user wants (definitions, procedures, taxonomies, frameworks, templates, examples, rules/heuristics, named patterns, or a combination)
2. What output format they want, if stated — otherwise ask in Phase 4
3. Where to write the output, if stated — otherwise ask in Phase 5

Fast path: If $ARGUMENTS specifies all three (what, format, destination), skip Phase 4 and Phase 5 — proceed directly from Phase 3 to Phase 6. Present a brief confirmation of what you understood before producing output.

If $ARGUMENTS is empty or too vague to determine what knowledge is needed, use the AskUserQuestion tool to clarify the output type. Options: "Structured data (JSON/YAML)" (description: "Machine-readable for apps and APIs"), "Derivative document (checklist, guide)" (description: "Human-readable reference docs"), "Compact knowledge pack" (description: "Dense summary for LLM prompts or handoff"), "Visual format (diagram/slides)" (description: "Mermaid, Marp, or matplotlib output"). If the user picks an option, follow up with a separate AskUserQuestion call to narrow scope (what topic or pages to extract from) — ask one question at a time.

Phase 2: Find relevant pages

Read wiki/index.md. Match the user's intent against the page titles and one-line summaries to identify which wiki pages contain the knowledge needed.

Lens scoping (optional): If the user specifies a lens or domain (e.g., "extract all techniques from the ML lens"), filter candidates to pages with the matching lens frontmatter field. If no lens is specified, include pages from all lenses (default).

Selection principles:

• Cast wide first — include any page that might contribute, even partially.
• For cross-cutting requests, follow the wiki's concept-technique linkage: concept pages define frameworks, technique pages contain the actionable moves.
• Read wiki/overview.md if the intent spans multiple topics — it maps how concepts relate.

List the pages you plan to read and briefly state what each contributes. Note which lens each page belongs to if the extraction spans multiple lenses.

Phase 3: Read and catalog

Read the identified wiki pages. As you read, catalog the extractable knowledge units — do not summarize or transform yet, just identify what's there.

Knowledge units to look for:

• Definitions — precise formulations of concepts, terms, or distinctions
• Procedures — sequenced steps for accomplishing a task (e.g., pipeline stages, methods, workflows)
• Taxonomies — categorized lists with attributes (e.g., platforms, audiences, genres, component types)
• Frameworks — multi-dimensional models, rubrics, or level-by-level scales with names and descriptions
• Templates — reusable patterns with fill-in-the-blank structure (e.g., prompt templates, boilerplate)
• Examples — concrete instances, before/after pairs, case studies
• Rules and heuristics — diagnostic rules, decision criteria, symptom-to-cause mappings, failure modes
• Named patterns — recognized recurring patterns organized by category (e.g., anti-patterns, tells, idioms)

Phase 4: Propose the extraction

Present a proposal to the user covering:

A. Knowledge to extract — list each knowledge unit with a count (e.g., "15 templates across 4 categories", "20+ named patterns across 5 groups"). Note which lenses the source pages belong to if the extraction spans multiple lenses.

B. Output format — if the user already specified a format, confirm it. If not, use the AskUserQuestion tool to ask (one question only). Options: "Structured data (JSON/YAML)", "Derivative document (Markdown)", "Compact knowledge pack", "Visual format (diagram/slides)". Include descriptions stating what each is best for.

1. Structured data (JSON or YAML) — machine-readable schemas with typed fields. Best for: feeding into applications, APIs, or automated pipelines.

2. Derivative document (Markdown) — a new document restructured for a specific use. Types include: checklists, quick-reference guides, decision trees, scoring sheets, one-pagers. Best for: human reference, printing, sharing with collaborators.

3. Compact knowledge pack (plain text or Markdown) — dense, self-contained summary optimized for injection into LLM prompts or handoff documents. Minimal formatting, maximum information density. Best for: system prompts, context windows, handoff to another AI session.

4. Visual formats — diagrams and presentations derived from wiki knowledge:

   • Mermaid diagrams — flowcharts, mind maps, timelines, entity-relationship diagrams, sequence diagrams. Rendered natively in Obsidian. Best for: concept maps, process flows, relationship visualization.
   • Marp slide decks — markdown with marp: true frontmatter and --- slide separators. Best for: presenting wiki knowledge to others, training materials, summaries for stakeholders.
   • matplotlib/Python scripts — for quantitative or complex visualizations that exceed mermaid's capabilities. Produce a .py script that generates .png output. Best for: data distributions, multi-axis charts, scatter plots.
   • Prefer mermaid when the visualization is structural (relationships, flows, hierarchies). Use matplotlib when it's quantitative (data plots, distributions).

5. Multiple formats — combine any of the above (e.g., "JSON of the rubrics plus a mermaid concept map").

C. Proposed structure — outline the specific shape of the output: what sections, fields, or hierarchy it will have. Be concrete enough that the user can say "yes, that's what I need" or "actually, restructure it like this."

Use the AskUserQuestion tool to confirm the proposal. Options: "Approve extraction plan (Recommended)", "Adjust scope or structure". If the user adjusts, incorporate feedback and re-present with another AskUserQuestion. Do not proceed until the user confirms.

Phase 5: Confirm destination

If the user already specified a destination path, verify the parent directory exists. If not, use the AskUserQuestion tool to confirm where to write.

Destination rules:

• For structured data files: require a file path. Use AskUserQuestion with the suggested default path as "(Recommended)" option, plus "Choose a different path".
• For derivative documents: require a file path. Do not place output inside wiki/ — extracted derivatives are not wiki pages. Use AskUserQuestion with the suggested default as "(Recommended)" option, plus "Choose a different path".
• For compact knowledge packs: use AskUserQuestion to ask delivery method. Options: "Print in conversation" (recommend for <200 lines), "Write to file" (recommend for larger output). Adjust which option is "(Recommended)" based on expected size.
• If the destination directory does not exist, use AskUserQuestion to confirm. Options: "Create directory (Recommended)", "Choose a different path".

Phase 6: Produce the output

Generate the output according to the confirmed proposal.

Format-specific instructions:

Structured data (JSON/YAML):

• Use consistent key naming (snake_case for JSON, kebab-case for YAML).
• Include a top-level metadata object with source (wiki page names that contributed), lens (lens name if extraction was scoped to a lens, or omit if cross-lens), extracted (today's date), and description (what this file contains).
• Preserve the wiki's categorization hierarchy.
• For frameworks/rubrics: include level (number), name, and description for each entry.
• For templates: include category, name, template_text, and optionally when_to_use. Adapt field names to the domain.

Derivative documents (Markdown):

• Open with a title and one-line description of what the document is for.
• Add a "Source" note stating which wiki pages the content was derived from.
• Structure for the specific document type:
  • Checklist — checkbox items (- [ ]) grouped by category, ordered by workflow sequence.
  • Quick-reference guide — tables and concise descriptions, no prose paragraphs, fits on 1-2 screens.
  • Decision tree — nested conditions using indentation or a flow format (If X -> do Y).
  • Scoring sheet — tables with dimensions, levels, space for evaluation.
• Do not include wikilinks ([[...]]) — the output must be self-contained.

Compact knowledge packs:

• Maximize information density. Use terse descriptions, abbreviations where unambiguous, and compressed formatting.
• No preamble or explanation of the format — start with the content.
• No wikilinks, no "See also" sections, no source citations within the body.
• Organize hierarchically: category -> item -> detail.
• End with a brief provenance line: [Extracted from wiki: page1, page2, ...].
• Target: someone (human or LLM) who receives this pack should be able to use the knowledge without needing the wiki.

All formats:

• Extract faithfully — do not paraphrase rubric levels, prompt text, or tell names. These are precise formulations.
• When the wiki provides examples (before/after pairs), include them if the output format supports it and the user's intent benefits from them.
• If knowledge units from different wiki pages need to be combined, merge them coherently.

Phase 7: Report

After writing the output, report:

• What was produced (format, size, location)
• What knowledge was extracted (counts: N templates, N named patterns, N framework levels, etc.)
• Which wiki pages were drawn from
• Any knowledge the user's intent implied but that the wiki does not yet contain (flag as a gap)

Guidelines

• This skill is read-only on the wiki. Never modify wiki pages, index.md, log.md, or overview.md.
• Extract faithfully. Rubric levels, prompt text, tell names, and taxonomy entries are precise formulations — do not paraphrase them.
• The user's intent may not map cleanly to wiki page boundaries. A single extraction may draw from many pages. This is expected.
• If the wiki does not contain the knowledge the user is looking for, say so clearly. Suggest which raw sources or topics might fill the gap, and whether /ingest could help.
• For very large extractions, warn the user about output size and suggest splitting into multiple files or a multi-section document.
• Do not place extracted output inside wiki/. The wiki is for wiki pages; extractions are derivatives that live elsewhere.
• When in doubt about format or scope, ask. A quick clarification saves a wasted extraction.