extract

/extract — Pre-Compaction Knowledge Extraction

Scan the current conversation since the last extraction for uncaptured insights, decisions, feedback, project context, and references. Dump everything to backlogs for review at the next knowledge audit. No confirmation dialog — just scan, deduplicate, and append.

Runtime Gate (per ADR-094)

Canonical resolution: This is the Claude Cowork variant — namespaced-only. When both plugin-claude-code and plugin-claude-cowork are loaded in the same session (most common in Claude Desktop), bare /extract resolves to aria-knowledge's variant — Code is the canonical owner of all 24 dual-port skills per ADR-094 §Part 1. To reach this skill, use the namespaced form: /aria-cowork:extract. Do NOT match bare /extract — that belongs to aria-knowledge.

Before Step 0: Check whether the Bash tool is available in this session. If Bash IS available (you are running in Claude Code or another runtime with shell access), surface the following notification and wait for explicit user confirmation:

⚠️ Runtime mismatch — you invoked aria-cowork's /extract from a runtime with shell access.

This variant only writes to the attached knowledge folder and skips ~/.claude/projects/.../memory/ + ~/.claude/plans/ — but you appear to be in Claude Code, where those memory + plans paths ARE reachable and the aria-knowledge canonical includes them. For the Code-native variant, use /extract (the aria-knowledge canonical).

Use /extract instead? (y / n)

Wait for an explicit reply:

• y / yes — Use the Skill tool to invoke extract (the bare-slash canonical, which routes to aria-knowledge when both ports are loaded) with the same arguments the user provided to this invocation. Do not proceed with this skill's steps; the aria-knowledge variant takes over and runs to completion. This is the default-yes path — auto-redirect is the helpful action.
• n / no — Proceed with this (aria-cowork) variant anyway despite the runtime mismatch. The user has explicitly opted in.
• No response / any other reply — Treat as "do not proceed" and exit cleanly without running either variant.

This gate applies even when mode = auto per ADR-094 §Part 3. Auto mode's "implicit-yes on all gates" rule is suspended for the runtime-mismatch check — auto trusts that the user invoked the correct variant, and this gate enforces that precondition. All other auto-mode gates remain bypassed. The friction cost is now low: on y, the auto-redirect runs the correct variant with the original args.

If Bash is NOT available (normal Cowork runtime), proceed to Step 0.

Step 0: Resolve config and detect project context

The default knowledge folder is ~/Projects/knowledge/ (expand ~ to your home directory's absolute path). Read <knowledge_folder>/aria-config.md and extract:

• knowledge_folder — required
• projects_enabled — default false
• projects_list — default empty (only relevant if projects_enabled: true)
• projects_remotes — default empty (parse-tolerated by cowork; consumed only when projects_enabled is true)

If aria-config.md doesn't exist, stop: "aria-cowork is not configured. Run /aria-setup to get started."

Use <knowledge_folder> for all file operations during this session.

Detect current project (only if projects_enabled: true)

Determine the current project context. Cowork has no automatic CWD detection (unlike aria-knowledge running in Code) — use these signals in order:

1. Explicit user attribution: if the conversation already mentions a project tag (e.g., "I'm working on proj-a today"), use that as current_project.
2. Conversation-thread context: if the conversation is anchored to docs, files, or topics that match a configured project, infer the project tag from projects_list.
3. No match: leave current_project unset — subsequent steps will skip auto-tagging and use explicit context labels.

Cowork's persistent-grant model means there's no single "current working directory" — multiple folders may be attached, and the active conversation context is the better signal than path inference. Aria-knowledge's bin/config.sh CWD-matching helper does not apply here.

Step 1: Determine extraction scope

Check if a previous extraction happened this session by looking for a timestamp marker. If this is the first extraction of the session, scan the entire conversation. If a previous extraction occurred, scan only from that point forward.

The timestamp is tracked as the last entry date in the backlogs from this session — check the most recent entry dates in:

• <knowledge_folder>/intake/insights-backlog.md
• <knowledge_folder>/intake/decisions-backlog.md
• <knowledge_folder>/intake/extraction-backlog.md
• <knowledge_folder>/intake/ideas/ — most recent *.md file by name (filenames are date-prefixed YYYY-MM-DD-...)

If no entries exist from today's date, treat the entire conversation as unscanned.

Step 2: Scan conversation for uncaptured knowledge

Review the conversation and categorize findings into six buckets. The first five (insights, decisions, feedback, project context, references) capture observations about what IS — they promote to knowledge during audit. The sixth bucket (ideas) captures proposals about what SHOULD BE different — these route via the audit's Accept submenu (tracker / roadmap / todo / adr / backlog / bundle / rule) rather than promoting directly into knowledge files.

Insights

• Non-obvious technical observations discussed in conversation
• Patterns discovered during research, exploration, or stakeholder discussion
• Behaviors that surprised either party
• Insight blocks that were output but NOT yet appended to insights-backlog.md

Decisions

• Architectural, process, or design choices made during the session
• Technology or approach selections with rationale
• Cross-project decisions that set precedents
• Scope decisions (what was included/excluded and why)
• Stakeholder decisions surfaced in conversation

Feedback

• Corrections from the user ("don't do X", "that's wrong", "not like that")
• Confirmed approaches ("yes exactly", "perfect", accepting an unusual choice)
• Workflow preferences expressed during the session
• Communication style preferences

Project Context

• Status updates about what's in-flight or blocked
• Who is working on what and by when
• Sprint, milestone, or release-cycle context
• Dependency or integration information

References

• External URLs, tools, dashboards, or services mentioned
• Linear projects, Slack channels, or other system pointers
• Documentation locations discovered during the session

Ideas (proposals, not observations)

• Feature proposals for any project ("this should support X", "X could be better if Y")
• Bug reports noticed in passing ("X silently fails when Y", "this UX is broken in case Z")
• Design ideas or refactoring proposals not yet scoped for implementation
• Workflow improvements ("it would help if the tool did X")
• Classification signal: phrases like "should", "could be", "missing handling for", "UX gap", "would help if", "this is broken" typically indicate an idea rather than an observation
• Soft routing: classification is a suggestion, not a hard rule. An item can legitimately be both observation and proposal — if so, put the observation in its appropriate bucket (insights/decisions/etc.) AND a separate file in intake/ideas/ covering just the proposal. The audit step can refine routing if needed.

Step 3: Deduplicate

For each finding, check against:

1. Existing entries in <knowledge_folder>/intake/insights-backlog.md
2. Existing entries in <knowledge_folder>/intake/decisions-backlog.md
3. Existing entries in <knowledge_folder>/intake/extraction-backlog.md
4. Existing files in <knowledge_folder>/intake/ideas/*.md (read frontmatter + body of each to