aria-knowledge

/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 Code variant. When both plugin-claude-code and plugin-claude-cowork are loaded in the same session (most common in Claude Desktop), bare /extract resolves to this skill — aria-knowledge (Code) is the canonical owner of all 24 dual-port skills per ADR-094 §Part 1. The Cowork variant is namespaced-only: /aria-cowork:extract.

Before Step 0: Check that the Bash tool is available in this session. If Bash is NOT available (you are running in Claude Cowork or another non-Code runtime), surface the following notification and wait for explicit user confirmation:

⚠️ Runtime mismatch — you invoked aria-knowledge's /extract from a non-Code runtime.

This variant writes captured items to ~/.claude/projects/.../memory/ and ~/.claude/aria-knowledge.local.md-scoped paths, which Cowork's persistent-grant model can't reach. For the Cowork-native variant (writes only to the attached knowledge folder), use /aria-cowork:extract.

Use /aria-cowork:extract instead? (y / n)

Wait for an explicit reply:

• y / yes — Use the Skill tool to invoke aria-cowork:extract with the same arguments the user provided to this invocation. Do not proceed with this skill's steps; the cowork 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-knowledge) 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 available, proceed to Step 0.

Step 0: Resolve Config and Detect Project Context

Read ~/.claude/aria-knowledge.local.md and extract:

• knowledge_folder — required
• projects_enabled — default false
• projects_list — default empty (only relevant if projects_enabled: true)

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

Use {knowledge_folder} as the base path for all file operations in subsequent steps.

Detect current project (only if projects_enabled: true)

Determine the current working directory and check if it matches a configured project path:

1. Get the current working directory (typically the user's primary working directory, e.g., ~/Projects/path/to/proj-a).
2. Parse projects_list into tag:path pairs.
3. For each pair, check if the CWD contains the configured path as a substring. If so, set current_project to that tag and stop iterating (first match wins).
4. If no path-based match is found AND projects_remotes is configured AND git is available, fall back to git-remote matching: run git config --get remote.origin.url from the CWD; for each tag:url-pattern pair in projects_remotes, check if the remote URL contains the pattern; if so, set current_project to that tag.
5. If still no match, leave current_project unset — subsequent steps will skip auto-tagging.

This logic mirrors the kt_project_for_path shell helper in bin/config.sh. Skills can either invoke that helper via Bash or replicate the matching logic in markdown-driven flow as above.

Examples:

• CWD = ~/Projects/myproject/sub-module/file.md, projects_list: myproject:myproject,other:other → current_project = myproject (substring match on myproject)
• CWD = ~/Projects/other, projects_list: myproject:myproject,other:other → current_project = other
• CWD = ~/Downloads/scratch-folder, projects_list: myproject:myproject,other:other → current_project unset (no configured path matches)

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/ — use the YYYY-MM-DD prefix of the most recent .md file (via ls -1 intake/ideas/.md | sort -r | head -1)

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

• Insight blocks that were output but NOT yet appended to insights-backlog.md (per-task capture may have already appended some — Step 3 dedup handles this)
• Non-obvious technical observations discussed in conversation
• Patterns discovered during debugging or exploration
• Codebase behaviors that surprised either party

Decisions

• Architectural 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)

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 or milestone 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 2.5: Sweep Subagent Captures

Scan {knowledge_folder}/intake/subagent-captures/ for all pending .md captures (transcripts archived by the SubagentStop hook from heavyweight subagents). If the directory is absent or empty, skip silently