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.

---

Step 5 — Extract key reviewers (DO NOT equate “participants” with reviewers)

Key reviewers must be evidence-based contributors, not simply attendees.

Use this priority order:

Tier 1 (best): explicit reviewer fields

• Document fields:

  reviewers

  ,

  key_reviewers

  ,

  approvers

  ,

  requested_reviewers

• PR fields:

  reviewers

  ,

  approvers

  ,

  requested_reviewers

Tier 2: explicit feedback authors

• Document

  feedback

  sections that attribute feedback to specific people/IDs
• Meeting transcripts where turns are attributable to people AND those people provide concrete suggestions/edits

Tier 3: slack thread replies to the report-share message

• Only include users who reply with substantive feedback/suggestions/questions tied to the report.
• Exclude:
  • the author (unless question explicitly wants them included as reviewer too)
  • pure acknowledgements (“looks good”, “thanks”) unless no other reviewers exist

Critical rule:

• Meeting

  participants

  list alone is NOT sufficient.
  • Only count someone as a key reviewer if the transcript shows they contributed feedback
  • OR they appear in explicit reviewer fields.

If the benchmark expects “key reviewers” to be “the people who reviewed in the review meeting”, then your evidence must cite the transcript lines/turns that contain their suggestions.

---

Step 6 — Validate IDs & de-duplicate

• All outputs must be valid employee IDs (pattern

  eid_...

  ) and exist in the employee directory if provided.
• Remove duplicates while preserving order:
  1. authors first
  2. key reviewers next

---

Output Format (Strict, JSON-ready)

Return:

1) Final Answer Object

{
  "target_product": "<ProductName>",
  "report_doc_id": "<doc_id>",
  "author_employee_ids": ["eid_..."],
  "key_reviewer_employee_ids": ["eid_..."],
  "all_employee_ids_union": ["eid_..."]
}

2) Evidence Map (pointers + minimal snippets)

For each extracted ID, include:

• artifact type + artifact id (doc_id / meeting_id / slack_message_id / pr_id)
• a short snippet that directly supports the mapping

Example evidence record:

{
  "employee_id": "eid_xxx",
  "role": "key_reviewer",
  "evidence": [
    {
      "artifact_type": "meeting_transcript",
      "artifact_id": "CoachForce_planning_2",
      "snippet": "…Alex: We should add a section comparing CoachForce to competitor X…"
    }
  ]
}

---

Recommendation Types

Return one of:

• USE_EVIDENCE — evidence sufficient and product-grounded
• NEED_MORE_SEARCH — missing reviewer signals; must expand search (PRs, slack replies, other meetings)
• AMBIGUOUS — conflicting product signals or multiple equally valid reports

---

Common Failure Modes (This skill prevents them)

1. Cross-product leakage
   Picking “Market Research Report” for another product (e.g., CoFoAIX) because it appears first.
   → Fixed by Step 2 (2-signal product grounding).

2. Over-inclusive reviewers
   Treating all meeting participants as reviewers.
   → Fixed by Step 5 (evidence-based reviewer definition).

3. Wrong version
   Choosing draft over final/latest.
   → Fixed by Step 3.

4. Schema mismatch
   Returning a flat list when evaluator expects split fields.
   → Fixed by Output Format.

---

Mini Example (Your case)

Question:
“Find employee IDs of the authors and key reviewers of the Market Research Report for the CoachForce product?”

Correct behavior:

• Reject any report whose content/links are clearly about CoFoAIX unless it also passes 2+ CoachForce grounding signals.
• Select CoachForce’s final/latest report.
• Author from doc field

  author

  .
• Key reviewers from explicit

  reviewers/key_reviewers

  if present; else from transcript turns or slack replies showing concrete feedback.

---

Do NOT Invoke When

• The answer is in a single small known file and location with no cross-references.
• The task is a trivial one-hop lookup and product scope is unambiguous.