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.

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 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 to Step 3.

Why sweep all, not just this session's: a skill does not receive the runtime session_id, so /extract cannot reliably match captures to "the current session" by their {parent-session-8} filename prefix (save-transcript.sh documents this same limitation). The prefix stays useful for provenance/audit, but it is not a skill-side filter. Sweeping all pending captures is safe — they are sticky and governed regardless of origin, and each is ledger-cleared once folded in, so nothing is double-processed.

For each capture, digest it for cheap review:

bash ${CLAUDE_PLUGIN_ROOT}/bin/digest-transcript.sh "{capture_path}" "/tmp/aria-digest-{filename}"

Fold any findings from the digest into the SAME six buckets from Step 2 (insights, decisions, feedback, project context, references, ideas). They then flow through Step 3 (dedup) and Step 4 (append) with the conversation's own findings.

Ledger-clear after Step 4: once a capture's findings have been appended to a backlog, create {knowledge_folder}/archive/extract-{date}/subagent-captures/ if needed, append an entry to its REMOVED.md (filename + parent-session-id + agent_type + agent_id), then rm the capture .md. Leave any captures you did not process (no extractable content, or skipped) for /audit-knowledge.

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 (glob the directory; read frontmatter + body of each to compare)
5. CLAUDE.md files in the current working directory (root and project-level)
6. Memory files in ~/.gemini/antigravity/transcripts/ for the current project
7. Knowledge files in {knowledge_folder}/

Skip anything already captured. Be conservative — if the content is substantively the same even with different wording, skip it.

If any deduplication source cannot be read (mis