/audit-share

description: "Internal facet of the audit family — invoke via '/audit share'. Batch-reviews personal knowledge for promotion to the team-shared _project-knowledge/ tier; per-item opt-in, requires the shared-knowledge config."

/audit share — Batch-Review Personal Knowledge for Team Sharing

Canonical invocation: **`/audit share`**. The direct `/audit-share` form is retained for compatibility and is not advertised.

Walk personal knowledge files and IDEAS-BACKLOG.md entries; recommend a target `_project-knowledge/` destination per item; present a batch summary; let the user approve, modify, or skip.

Step 0: Resolve Config

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

• `knowledge_folder` — required
• `projects_enabled` — required (must be `true`)
• `projects_list` — required (parsed into tag→path map)
• `projects_shared_knowledge` — required (comma-separated tag list; non-empty list of tags from `projects_list`); each tag in the list is a project enabled for shared knowledge
• `author_tag` — required (non-empty); fall back to deriving from `git config user.name` (first 2 chars of first + first 2 chars of last) if missing

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

If `projects_shared_knowledge` is empty/missing (or the legacy literal `true`): *"Shared knowledge has no projects enabled. Run /setup and pick which projects to enable in the 'Which projects do you want to enable shared knowledge for?' prompt."*

If `projects_enabled: false` or `projects_list` empty: *"Shared knowledge requires the project tier. Run /setup to enable projects and configure your project list."*

If `author_tag` is missing AND no derivable git user.name: *"Author tag is required. Set `author_tag` in `~/.gemini/antigravity/aria-knowledge.local.md` (e.g., `init`) or configure `git config user.name`."*

Step 1: Scan Candidates

Walk these directories under `{knowledge_folder}/`:

• `insights/`
• `decisions/`
• `approaches/`
• `rules/`
• `projects/<tag>/` for each tag in `projects_shared_knowledge` (the per-project opt-in list — projects not in this list stay personal-tier and are skipped here)

Plus IDEAS-BACKLOG.md entries from each project root:

• For each tag in `projects_shared_knowledge`, resolve to project root via `~/Projects/<path>` (where `<path>` is the corresponding `projects_list` value).
• Probe `<project-root>/_project-knowledge/IDEAS-BACKLOG.md` first (post-feature location).
• Fall back to `<project-root>/IDEAS-BACKLOG.md` (pre-feature location, will trigger Step 7 migration on first execute).
• Parse the file by `### YYYY-MM-DD — {title}` headers; treat each section as a candidate "entry."

**Skip candidates** when:

• File frontmatter contains a `shared:` array with an entry whose `path` matches the proposed target. (Already shared; no action needed.)
• File type is `feedback` or `references` (out of scope per design Q10 — feedback memories tend to be personal preferences; references are pointers to external systems that may not apply uniformly to teammates).

Step 2: Suggest Action Per Candidate

For each candidate, determine:

1. **Project tag(s)** — derived from any of three sources, unioned (matches `/index` Phase 4 Decision #9 path-derived convention so audit-share and /index see the same tag set):

• **Path-derived:** if file path is under `{knowledge_folder}/projects/<tag>/`, that `<tag>` is implicit (even if not in YAML frontmatter).
• **Frontmatter `project:` field** if present (split on `,` for multi-value).
• **Frontmatter `tags:` array:** any tag matching a project in `projects_shared_knowledge` is treated as a share signal. A file tagged `[architecture, cs, ss]` with `cs,ss` in `projects_shared_knowledge` produces TWO share recommendations (one to cs, one to ss) — multi-tag files generate one recommendation per matching project, with independent destinations.
• The literal value `cross` (in any source) marks the file as cross-cutting within its product group, not as cross-PROJECT-GROUP. Cross-PROJECT-GROUP relevance is naturally expressed by multi-tag (e.g., `[cs, ss]` = relevant to both cs and ss product groups) and is handled by the multi-tag fan-out above, not by `cross`.

2. **Recommended action** (per recommendation produced in step 1):

• Tag is `cross` → recommend **share-to-cross** (will need user to pick destination repo at execute time, since cross items can land in any repo's `cross/` subfolder; cross destinations may be any tag from `projects_shared_knowledge`).
• Tag matches a tag in `projects_shared_knowledge` → recommend **share-to-{project}**.
• Tag exists in `projects_list` but is NOT in `projects_shared_knowledge` → recommend **skip** with reason "project not enabled for shared knowledge (use `/setup` to enable)".
• Otherwise (no tag detected, or tag not in projects_list) → recommend **skip**.

3. **Target path** — compute as follows. Multi-repo projects (those with a `projects_groups` entry) require sub-repo selection because the projects_list path resolves to a container, not a git repo:

• **Single-repo project** (no `projects_groups[tag]` entry):
• Repo-scoped: `<project-root>/_project-knowledge/<YYYY-MM-DD>-<author_tag>-<slug>.md`
• Cross-stack: `<destination-repo-root>/_project-knowledge/cross/<YYYY-MM-DD>-<author_tag>-<slug>.md`
• **Multi-repo project** (`projects_groups[tag]` is set, listing role:sub-repo pairs like `backend: foo-backend`, `web: foo-web`, `mobile: foo-mobile`):
• Run **role-detection heuristic** on file content + frontmatter tags:
• **backend keywords:** django, flask, fastapi, server-side, api, endpoint, jwt, oauth, auth, idor, impersonation, sql, database, migration, model, view, serializer, drf, rest, graphql resolver
• **web keywords:** nextjs, next.js, react, frontend, client-side, app router, spa, redux, rtk, rtk-query, css, tailwind, ui component, hook, page, route component
• **