/extract

description: "Extract uncaptured knowledge from the current conversation before it's lost to compaction. Use after completing a task, before switching context, before large exploratory work (multi-file reads, codebase scans), or when the user signals session end. Trigger: '/extract', 'extract knowledge', 'capture session knowledge'. Also prompt mid-session: 'Task complete — want me to run /extract?' and 'Switching context — want me to run /extract first?'. (Code port — ADR-094.)"

/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.

Step 0: Resolve Config and Detect Project Context

Read `~/.gemini/antigravity/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 bucke