Grilling: does Skill Usage need to attach to the specific nested Agent, not just the flat Session?

[antejavor]

Part of #275

Question

Skill usage detection is already grounded in real harness data (tool-name matching, local SKILL.md reads via SkillGraphConnector) -- that part doesn't need re-litigating. What's open: today USED_SKILL links (:Session)-[:USED_SKILL]->(:Skill) flatly. If a subagent (not the main session) is what actually used a skill, should that usage attach to the specific Agent node (if #3 introduces one) instead of the flat Session, so "which agent used this skill" is answerable? Blocked on #3, since there's nothing to attach to otherwise. Resolve with the driving user via /grilling + /domain-modeling.

[antejavor]

Resolution

Resolved via /grilling + /domain-modeling with the driving user:

USED_SKILL attaches to the specific Agent when the usage happened inside a subagent, not just the flat Session. Same relationship type either way -- (:Session)-[:USED_SKILL]->(:Skill) or (:Agent)-[:USED_SKILL]->(:Skill) -- mirroring exactly how (:Session|:Agent)-[:HAS_ACTION]->(:Action) already works generically from either container per #278. No new relationship name needed; Skill Surfacing gets the same treatment for consistency.

Gap surfaced, not a new open question: for SkillGraphConnector to know which Agent (if any) a given skill-usage event belongs to, the event needs to carry that information -- but ToolStartEvent/ToolEndEvent/MessageEvent (the Event Protocol) have no agent_id field at all today, even though Claude Code/Codex's real hook payloads carry agent_id on events fired inside a subagent. This is the exact same missing piece actions-graph's own (:Agent)-[:HAS_ACTION]->(:Action) mechanism from #278 needs -- it wasn't made fully explicit when #278 resolved. Recorded on the map's Notes as a shared Event Protocol prerequisite both actions-graph and skills-graph depend on, rather than re-litigated as new fog here.

[antejavor]

Correction (2026-08-14): the gap described above ("no agent_id field at all") was slightly off. ToolStartEvent/ToolEndEvent already had an agent_name field in events.py — it just wasn't populated by claude_code.py's adapter for tool events. Fixed as part of implementing this map: the existing field is now populated from payload.get("agent_id"), and MessageEvent (which genuinely had no field) got one added. See map #275's Notes for the full correction.