Entity Resolution

Entity Resolution

Use this skill before acting when the user's request contains ambiguous or underspecified references, including:

• Entity references: “the task”, “that workflow”, “the resolver”, “the extension”, “the issue”, “the branch”.
• Anaphora: “it”, “this”, “that”, “those”, “the former/latter”, “same thing”, “there”.
• Project-specific terms or aliases: skill names, workflow names, Munera task ids/slugs, extension ids, namespaces, vars, commands, docs, or vocabulary symbols.
• Project paths: incomplete paths, informal names, renamed files, directory nicknames, or references implied by nearby context.

Goal

Convert the user's surface language into a concrete, evidence-backed mapping:

surface reference → canonical project entity/path/term → evidence → confidence

Then proceed only when the mapping is sufficiently unambiguous.

Method

1. Collect local context

   • Current user turn and immediately relevant conversation history.
   • Active worktree path and current git status when path or task references matter.
   • mementum/state.md for project orientation when needed.
   • munera/plan.md and relevant munera/open/* when the user says “task”, “plan”, “design”, “steps”, or similar.

2. Identify referring expressions

   • Pronouns and deixis: it, this, that, these, there, same, former, latter.
   • Definite descriptions: the resolver, the lifecycle workflow, the current task.
   • Aliases and shorthand: partial names, old names, symbols, command names, workflow labels.
   • Path-like references: filenames without directories, directory names, namespace-like strings.

3. Generate candidates

   • Prefer already-mentioned entities in recency order.
   • Search authoritative project surfaces when not obvious:
     • git ls-files / find for paths.
     • git grep for terms, vars, namespaces, workflow ids, commands, and docs.
     • Psi graph introspection for runtime/session entities when applicable.
   • Include candidate type: path, namespace, var, task, workflow, skill, extension, command, issue, branch, doc, concept.

4. Score candidates

   • Evidence strength: exact id/path match > exact symbol/name > nearby conversation mention > fuzzy match.
   • Context fit: active worktree/task/request domain > unrelated project area.
   • Recency: latest explicit mention > older mention.
   • Uniqueness: one strong candidate > many plausible candidates.

5. Normalize to project terms

   • Map informal language to canonical vocabulary:
     • “task” → munera/open/NNN-slug/ or munera/closed/NNN-slug/ when known.
     • “workflow” → .psi/workflows/<id>.edn or registered workflow id.
     • “skill” → .psi/skills/<name>/SKILL.md.
     • “extension” → extension manifest/path/id.
     • “docs” → README.md or doc/... as evidenced.
     • “state” → distinguish mementum/state.md, runtime atom state, task state, or git state.

6. Act or ask

   • If exactly one candidate is strongly supported, proceed and optionally state the mapping briefly.
   • If multiple candidates remain plausible, ask a focused clarification question listing the likely options.
   • If no candidate is evidenced, say what was searched and ask for the missing identifier.

Output Shape

For internal reasoning, keep a compact table:

In the final response, include only the mapping needed for clarity, e.g.:

Interpreting “that workflow” as .psi/workflows/task-lifecycle.edn because it was the last workflow mentioned.

Rules

• Do not silently guess project paths.
• Prefer runtime or filesystem evidence over memory and docs.
• Prefer current worktree over cwd if they differ.
• Preserve ambiguity instead of collapsing distinct concepts with the same name.
• When changing files, resolve path identity before editing.
• When operating on sessions, target by explicit session id if available; do not rely on implicit current-session assumptions when ambiguity matters.