aria-knowledge

/audit-config — Configuration & Documentation Health Check

Scan all GEMINI.md files, hooks.json configs, plugin manifests, and knowledge files for drift, broken references, and staleness.

Step 0: Resolve Config

Read ~/.gemini/antigravity/aria-knowledge.local.md and extract knowledge_folder and audit_cadence_config. If the file doesn't exist, stop: "aria-knowledge is not configured. Run /setup to get started."

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

Step 1: Read the Audit Log and Determine Mode

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

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

Determine how this skill was invoked:

• User-requested (user said /audit-config, "audit configs", "check setup", 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 if the configured cadence has been exceeded.
• If cadence exceeded: Prompt the user — "It's been N days since the last config & docs audit. Want me to check for drift?" If they agree, proceed to Step 2. If not, stop.
• If within cadence: Report the last audit date and stop. "Last config & docs audit was N day(s) ago (YYYY-MM-DD). Next check due in M days."

Step 2: Scan Configuration Files

Use agents in parallel to scan these areas:

2a: Hooks Configuration

Find hooks.json files at workspace .agents/hooks.json (if present), global ~/.gemini/config/hooks.json (if present), and plugin-bundled ~/.gemini/config/plugins/*/hooks.json. For each:

• Validate JSON structure (run jq . <file> and check exit code)
• Verify every referenced script command path resolves (e.g., bash ./bin/antigravity/post-plan-prospect-aria.sh, bash ./bin/antigravity/post-push-retrospect-aria.sh → do the files exist?)
• Check matchers against the documented Antigravity tool vocabulary (write_to_file, replace_file_content, multi_replace_file_content, grep_search, find_by_name, run_command, view_file, etc.). Flag any matchers using Claude Code tool names (Edit, Write, Glob, Grep, Bash, Read) — those are non-functional in Antigravity.
• Verify timeouts are reasonable (default per docs is 30s; flag any 5s or lower as overly tight).

2b: MCP Configuration

Find mcp_config.json files at user level (~/.gemini/antigravity/mcp_config.json), workspace level (.agents/mcp_config.json if present), and plugin-bundled (~/.gemini/config/plugins/*/mcp_config.json). For each:

• Validate JSON
• For HTTP servers: verify serverUrl is a well-formed URL
• For stdio servers: verify command path exists
• Check oauth_tokens.json (at ~/.gemini/antigravity/mcp_oauth_tokens.json) — list servers with expired tokens

2c: Plugin Manifests

For each plugin under ~/.gemini/config/plugins/ and .agents/plugins/:

• Verify plugin.json exists at the flat root (Antigravity expects flat, not .claude-plugin/plugin.json)
• Validate it parses as JSON
• If the plugin ships version.txt as a sidecar (the aria-knowledge port convention), validate it's a single semver line
• Check that hooks.json / mcp_config.json / skills/ / rules/ subdirs are well-formed if present

2d: Rules and Workflows

Scan workspace .agents/rules/*.md and global ~/.gemini/GEMINI.md:

• Verify each rules file is under the documented 12,000-character limit
• Resolve @filename cross-references inside rules — flag broken links
• Scan workspace .agents/workflows/.md and global ~/.gemini/workflows/.md:
• Each workflow file should be under 12,000 characters
• Each workflow filename maps to a slash-command (/workflow-name); flag if filename contains spaces or unusual characters that would break invocation

2e: ARIA Configuration

Check ~/.gemini/antigravity/aria-knowledge.local.md:

• Validate frontmatter parses (delimiters at column 1, no quoted values, no blank lines between keys)
• Verify referenced knowledge_folder exists on disk
• Check every field from canonical bin/config.sh is present (cross-check against the field list at the top of config.sh)

Step 3: Scan GEMINI.md and CLAUDE.md Files

Find all GEMINI.md and CLAUDE.md files recursively in the current working directory.

Expand via Glob first, then issue Read calls for all found files in a single parallel tool-use block. Validation checks run in the main thread after reads complete.

For each file, check:

• File references — do referenced files/paths actually exist?
• Cross-references — do pointers to other GEMINI.md / CLAUDE.md files resolve?
• Version claims — do stated versions match actual manifests/package.json?
• Version-stamp ripple — when a version appears in one GEMINI.md, does the same version appear consistently across sibling files and memory files that reference the same project? Mismatched versions across surfaces signal a post-release update that didn't propagate. See Step 3a for the detection pattern.
• Adoption-state phrases — does language like "NOT YET BUILT", "(placeholder)", "spec drafted, not yet built", "currently disabled", "still has older prototype", "pipeline built but not yet adopted" contradict the actual state of a referenced artifact (plugin.json exists with non-zero version, config flag is enabled, build output is present)? See Step 3a.
• Team roster — is it consistent across files?
• Stale content — are there line numbers, dates, or status claims that look outdated?
• Missing references — are there significant docs/files in the project that aren't referenced?

Step 3a: Release-State Cascade Patterns

Two specific cascade shapes are common enough to warrant dedicated detection. Both follow the same structural pattern: one source-of-truth surface changes (a version bump, an enabled flag), and N downstream surfaces fail to update.

3a.1: Version-stamp ripple

After a plugin/package release, version references typically touch 5+ surfaces: the manifest itself, the project's GEMINI.md status header, any parent container GEMINI.md table row, the project memory file's description + body + version-row, and the memory index entry. Each is small; skipping any creates documentation drift.

Detection:

1. For each plugin manifest (plugin.json) or package.json found, extract the canonical version string (e.g., v2.14.4). For the aria-knowledge Antigravity port, also check version.txt sidecar.
2. Glob GEMINI.md and CLAUDE.md files in the project + ancestor directories + ~/.gemini/antigravity/transcripts/.../memory/project_*.md files referencing the project's slug.
3. For each surface, grep for version strings matching the pattern v?\d+\.\d+\.\d+ near a mention of the project name.
4. Flag any surface where the stated version is older than the manifest version. Treat "older" by semver comparison, not string comparison.
5. Do NOT flag surfaces where the version is absent entirely — those are not drift, just under-documentation (out of scope for this check).

Report shape:

Version-stamp drift for {project-slug}:
  Canonical: v{manifest-version} (from {manifest-path})
  Stale surfaces:
    - {surface-path} — stated v{stale-version}
    - {surface-path} — stated v{stale-version}

3a.2: Adoption-state cascade

When a binary config value flips (e.g., enabled=0 → enabled=1 in a deploy script, or a placeholder folder becomes a built artifact), N referenced docs may still describe the prior state.

Detection patterns to grep against GEMINI.md / README.md / memory files:

| Phrase pattern (case-insensitive) | Inverse-state check | |-----------------------------------|---------------------| | "currently disabled in {flag-name}" | Read the named flag/script; flag drift if value is now enabled | | "NOT YET BUILT" / "(placeholder)" / "spec drafted, not yet built" | Check for plugin.json / package.json with n