Enterprise Artifact Search

Enterprise Artifact Search Skill (Robust)

This skill delegates multi-hop artifact retrieval + structured entity extraction to a lightweight subagent, keeping the main agent’s context lean.

It is designed for datasets where a workspace contains many interlinked artifacts (documents, chat logs, meeting transcripts, PRs, URLs) plus reference metadata (employee/customer directories).

This version adds two critical upgrades:

1. Product grounding & anti-distractor filtering (prevents mixing CoFoAIX/other products when asked about CoachForce).
2. Key reviewer extraction rules (prevents “meeting participants == reviewers” mistake; prefers explicit reviewers, then evidence-based contributors).

When to Invoke This Skill

Invoke when ANY of the following is true:

1. The question requires multi-hop evidence gathering (artifact → references → other artifacts).
2. The answer must be retrieved from artifacts (IDs/names/dates/roles), not inferred.
3. Evidence is scattered across multiple artifact types (docs + slack + meetings + PRs + URLs).
4. You need precise pointers (doc_id/message_id/meeting_id/pr_id) to justify outputs.
5. You must keep context lean and avoid loading large files into context.

Why Use This Skill?

Without this skill: you manually grep many files, risk missing cross-links, and often accept the first “looks right” report (common failure: wrong product).

With this skill: a subagent:

• locates candidate artifacts fast
• follows references across channels/meetings/docs/PRs
• extracts structured entities (employee IDs, doc IDs)
• verifies product scope to reject distractors
• returns a compact evidence map with artifact pointers

Typical context savings: 70–95%.

Invocation

Use this format:

Task(subagent_type="enterprise-artifact-search", prompt="""
Dataset root: /root/DATA
Question: <paste the question verbatim>

Output requirements:
- Return JSON-ready extracted entities (employee IDs, doc IDs, etc.).
- Provide evidence pointers: artifact_id(s) + short supporting snippets.

Constraints:
- Avoid oracle/label fields (ground_truth, gold answers).
- Prefer primary artifacts (docs/chat/meetings/PRs/URLs) over metadata-only shortcuts.
- MUST enforce product grounding: only accept artifacts proven to be about the target product.
""")

Core Procedure (Must Follow)

Step 0 — Parse intent + target product

• Extract:
  • target product name (e.g., “CoachForce”)
  • entity types needed (e.g., author employee IDs, key reviewer employee IDs)
  • artifact types likely relevant (“Market Research Report”, docs, review threads)

If product name is missing in question, infer cautiously from nearby context ONLY if explicitly supported by artifacts; otherwise mark AMBIGUOUS.

Step 1 — Build candidate set (wide recall, then filter)

Search in this order:

1. Product artifact file(s): /root/DATA/products/<Product>.json if exists.
2. Global sweep (if needed): other product files and docs that mention the product name.
3. Within found channels/meetings: follow doc links (e.g., /archives/docs/<doc_id>), referenced meeting chats, PR mentions.

Collect all candidates matching:

• type/document_type/title contains “Market Research Report” (case-insensitive)
• OR doc links/slack text contains “Market Research Report”
• OR meeting transcripts tagged document_type “Market Research Report”

Step 2 — HARD Product Grounding (Anti-distractor gate)

A candidate report is VALID only if it passes at least 2 independent grounding signals:

Grounding signals (choose any 2+): A) Located under the correct product artifact container (e.g., inside products/CoachForce.json and associated with that product’s planning channels/meetings). B) Document content/title explicitly mentions the target product name (“CoachForce”) or a canonical alias list you derive from artifacts. C) Shared in a channel whose name is clearly for the target product (e.g., planning-CoachForce, #coachforce-*) OR a product-specific meeting series (e.g., CoachForce_planning_*). D) The document id/link path contains a product-specific identifier consistent with the target product (not another product). E) A meeting transcript discussing the report includes the target product context in the meeting title/series/channel reference.

Reject rule (very important):

• If the report content repeatedly names a different product (e.g., “CoFoAIX”) and lacks CoachForce grounding → mark as DISTRACTOR and discard, even if it is found in the same file or near similar wording.

Why: Benchmarks intentionally insert same doc type across products; “first hit wins” is a common failure.

Step 3 — Select the correct report version

If multiple VALID reports exist, choose the “final/latest” by this precedence:

1. Explicit “latest” marker (id/title/link contains latest, or most recent date field)
2. Explicit “final” marker
3. Otherwise, pick the most recent by date field
4. If dates missing, choose the one most frequently referenced in follow-up discussions (slack replies/meeting chats)

Keep the selected report’s doc_id and link as the anchor.

Step 4 — Extract author(s)

Extract authors in this priority order:

1. Document fields: author, authors, created_by, owner
2. PR fields if the report is introduced via PR: author, created_by
3. Slack: the user who posted “Here is the report…” message (only if it clearly links to the report doc_id and is product-grounded)

Normalize into employee IDs:

• If already an eid_*, keep it.
• If only a name appears, resolve via employee directory metadata (name → employee_id) but only after you have product-grounded evidence.