/audit-knowledge — Knowledge Repository Audit

Scan the current Antigravity conversation transcript and artifact directory, compare against what's already in the knowledge folder and project-level docs, and surface anything worth extracting.

Step 0: Resolve Config

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

• knowledge_folder — required base path
• audit_cadence_knowledge — cadence in days (default 7); safety-net trigger for low-activity periods
• audit_trigger_threshold — backlog-entry count (default 20); primary activity-driven trigger. Tier boundaries derived via fixed offsets: threshold (suggested), threshold + 15 (recommended), threshold + 30 (overdue)
• projects_enabled — default false; controls whether project tier is audited (Step 5e)
• projects_list — default empty; comma-separated tag:path pairs; only relevant if projects_enabled: true
• projects_promotion_threshold — default 2; minimum projects sharing a similar pattern before Step 5e suggests cross-project promotion

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.

Step 1: Read the Audit Log and Determine Mode

Read {knowledge_folder}/logs/knowledge-audit-log.md.

Note the "Last Audit" date and calculate days since.

Compute the current trigger state by counting ^### entries across the four action-eligible backlogs (insights, decisions, extraction, rules — exclude intake/ideas/, which routes out via the Accept submenu rather than promoting directly). Count only entries below the first --- separator per file, matching the convention used by /stats and /backlog:

for f in {knowledge_folder}/intake/insights-backlog.md \
         {knowledge_folder}/intake/decisions-backlog.md \
         {knowledge_folder}/intake/extraction-backlog.md \
         {knowledge_folder}/intake/rules-backlog.md; do
  [ -f "$f" ] && awk '/^---$/{sep++; next} sep>=1 && /^### /{c++} END{print c+0}' "$f"
done | awk '{s+=$1} END{print s+0}'

Record the count — it feeds both the prompt message and Step 8's Trigger: audit-log subfield.

Determine how this skill was invoked:

• User-requested (user said /audit-knowledge, "audit knowledge", "scan transcript", etc.): Always run the full audit, regardless of how recently the last audit was. Skip directly to Step 2.
• Session-start check (triggered by the session-start ephemeralMessage): Check whether either trigger fired.
  • Entry-count trigger (primary): if backlog_count >= audit_trigger_threshold, prompt per tier:
    • count ≥ threshold + 30 → "Knowledge audit overdue — N entries, plan for multi-pass. Run /audit-knowledge?"
    • count ≥ threshold + 15 → "Knowledge audit recommended — N entries, near one-pass ceiling. Run /audit-knowledge?"
    • count ≥ threshold → "Knowledge audit suggested — N entries ready for review. Run /audit-knowledge?"
  • Elapsed-days trigger (safety net): if no entry-count tier fired AND days_since >= audit_cadence_knowledge, prompt: "Knowledge audit due — N days since last audit. Run /audit-knowledge?"
  • Neither fired: report the last audit date + current backlog count + days-since, then stop. "Last knowledge audit was N day(s) ago (YYYY-MM-DD). Backlog at M entries (threshold T). Next trigger at M=T entries or N=C days."

Step 1b: Check Index Freshness

Read {knowledge_folder}/index.md if it exists.

Several audit steps depend on index data (Step 5b entity refs + skill-knowledge drift, Step 5c tag matching, Step 6 stale files). Running against a stale or missing index produces incomplete results.

Check:

1. If index.md doesn't exist → note: "No index found. Steps 5b (entity/skill checks), 5c (tag matching), and stale file detection will be limited. Consider running /index after this audit."
2. If index.md exists → read the Last rebuilt: date from the header. Compare against today.
   • If older than 7 days AND there are pending backlog entries (from a quick line count of the 3 backlog files) → prompt: "Index was last rebuilt N days ago and there are pending backlog items. Run /index first for more accurate integrity checks? (y/n)"
   • If user says yes → run the full /index logic (Steps 0-10 from the /index skill), then continue with Step 2
   • If user says no → continue with degraded checks (note in Step 6 output which checks were limited)
   • If 7 days or fewer → continue normally, index is fresh enough

This is a lightweight check — it reads one file header and counts backlog lines. The expensive work (full index rebuild) only happens if the user opts in.

Step 2: Review Insights Backlog

Read {knowledge_folder}/intake/insights-backlog.md. If the file is missing, report it in Step 6 and suggest running /setup to repair the structure. Do not create it.

If there are entries below the --- separator, these are insights captured during work sessions that need review.

For each insight entry, note it for presentation in Step 6 alongside Category C items. Insights are reviewed with the same approve/reject flow — promoted ones go to the appropriate knowledge file, rejected ones get cleared from the backlog.

Step 2b: Review Decisions Backlog

Read {knowledge_folder}/intake/decisions-backlog.md. If the file is missing, report it in Step 6 and suggest running /setup to repair the structure. Do not create it.

If there are entries below the --- separator, these are cross-project architectural decisions captured during work sessions that need review.

For each decision entry, note it for presentation in Step 6. Decisions are reviewed with the same approve/reject flow — promoted ones become full ADRs in {knowledge_folder}/decisions/ (using ADR format), rejected ones get cleared from the backlog.

Step 2c: Review Extraction Backlog

Read {knowledge_folder}/intake/extraction-backlog.md. If the file is missing, report it in Step 6 and suggest running /setup to repair the structure. Do not create it.

If there are entries below the --- separator, these are feedback, project context, and reference items captured via /extract during work sessions.

For each entry, note it for presentation in Step 6. Feedback items are promoted to ~/.gemini/antigravity/transcripts/ memory as feedback memories. Project context items become project memories. Reference items become reference memories or go to {knowledge_folder}/references/. Rejected items get cleared from the backlog.

Reclassification check: If any entry reads as a feature proposal, bug report, or design idea (rather than an observation about what IS), flag it for re-routing to intake/ideas/ (as a new per-file idea) during Step 7. Common signals: "should", "could be better if", "missing handling for", "UX gap", "would help if". Misclassified proposals will otherwise get promoted into knowledge files where they sit as documentation of things that don't exist — a known drift mode.

Step 2c2: Review Ideas Directory

Glob {knowledge_folder}/intake/ideas/*.md. If the directory is missing, report it in Step 6 and suggest running /setup to repair the structure. Do not create it.

Counting note: When reporting an idea count (Step 6's Pending Ideas (N) header and Step 8's Plus N ideas audit-log subfield), filter out README.md and .gitkeep from the glob result — they're directory-purpose files, not ideas, and inflate counts by 1-2 if included. The reads-and-categorize step below is unaffected since non-idea files lack the required date:/project:/type:/title: frontmatter and are skipped during per-file review. Concrete primitive: ls intake/ideas/*.md 2>/dev/null | grep -v 'README\|\.gitkeep' | wc -l.

Legacy-file detection (one-time): Also check for {knowledge_folder}/intake/ideas-backlog.md. If it exists alongside