---
name: estate-search
description: Search the Jinemi estate — Discord, the Taiga board, OneDev repositories, the estate's Drive corpus (kylene call summaries), and the docs repo — with the right tool, and bring back actionable IDs. Use for any search-shaped ask: "find the message about X", "who said Y", "which story covers Z", "what did the call decide", "where is this in the code", "grep for W", "message ID", "search Discord/Taiga/OneDev/Drive".
---

# Searching the estate

## Purpose

Every surface in this estate is searchable through Centralis, and each surface
answers a different class of question. Reaching for the wrong one wastes a
round trip or silently misses the answer; this skill is the routing table and
the ID discipline that makes a hit actionable.

## Where a question lives

| The question | The tool |
|---|---|
| "who said X", "find the message about Y" — Discord, one shot | `discord_search` |
| Discord by pattern, repeatedly, or deep in history | `discord_grep` |
| "which story/epic/task covers X" — the Taiga board | `taiga_search` |
| "where is this in the code/config" — any of the nine repos | `onedev_grep` |
| docs, notes and summaries in `Jinemi/docs` | `docs_search` / `notes_search` (fuller semantics than onedev_grep for that one repo) |
| "what did the call say" — kylene call summaries, estate Drive corpus | `drive_grep`; `voice_calls` to list calls structurally first |
| The user's own Google Drive (personal, not estate) | the `google-drive` MCP `search` — NOT `drive_grep` |

These compose. "What did we decide about X" is usually `taiga_search` +
`discord_search` + `drive_grep` + `docs_search` — run the pair that fits the
question's shape first, widen only if the answer is thin.

## Procedure

1. **Pick the surface from the table**, not from whichever tool is nearest.
   Discord search and grep overlap deliberately: search is one server-side
   call over every readable channel including archived forum posts; grep
   serves an incremental cache and never misses on pattern shapes.
2. **Discord**: try `discord_search` first for keyword/author/date questions.
   If it replies that the endpoint is rate-limited or unavailable, run the
   same question through `discord_grep` — that fallback is the designed
   path, not an error to retry around. Use `discord_grep` directly when the
   ask is regex-shaped (`license.*expired`), when you will search more than
   once in a session (its cache makes repeats free), or when `deep` history
   is needed.
3. **Taiga**: `taiga_search` returns per-project refs — the numbers the UI
   shows and `story_get`/`story_update`/`epic_update`/`epic_link` take.
   Scope with `project` when the question names one.
4. **OneDev**: `onedev_grep` takes a hierarchical project path
   (`Jinemi/thermograph`, never a bare name). Narrow with `path=` and
   `suffix=` before raising `limit`; the coverage footer names anything it
   could not read or skipped as oversized — never assume an empty result
   means "not in the repo" until that footer is clean.
5. **Drive**: `drive_grep` sees only the estate's service-account corpus
   (kylene call summaries + whatever `CENTRALIS_DRIVE_GREP_FOLDERS` adds).
   A personal My Drive question goes to the per-user `google-drive` MCP
   `search` with a `fullText contains` query, then download + local grep if
   an exact match is needed.
6. **Chat history specifically** = kylene summaries (`drive_grep`) + Discord
   (`discord_search`/`discord_grep`) + the voice-transcript digests in
   `summaries/` (`docs_search`). A "what was said in the meeting" answer
   that checked only one of the three is incomplete — say which you
   searched.

## ID discipline

Every one of these tools returns the IDs the follow-up calls take. Capture
them the moment you see a hit you will act on:

- Discord rows carry **message ID** and a `discord.com/channels/...` link;
  every `discord_*` verb (react, reply, edit, read in context via
  `discord_get_messages`) takes that ID. Channel IDs are in the link.
- Taiga rows carry **per-project ref** — pass it with the project slug, never
  as a bare global id.
- `onedev_grep` rows carry **file:line** — cite them that way.
- `drive_grep` rows carry the document's `webViewLink` — open from there,
  and line numbers refer to the exported text, which can differ from the
  rendered Doc.

## Rules

- **Author identity is not resolved by one lookup.** "Was it member X?" needs
  more than a current roster read — see the
  `discord-bot-roster-check-false-negative` lesson before concluding someone
  never said something.
- **`discord_grep` matches raw markup.** Mentions appear as `<@1234567890>`,
  not as names — grep for the ID when hunting mentions, and use
  `discord_search`'s author filter when hunting by person.
- **Grep coverage footers are part of the answer.** "Not read" and
  "skipped" lines mean the corpus was partial; report the gap or fix the
  scope, never quote a clean-looking result over a dirty footer.
- **The tools are read-only.** Acting on a hit (reacting, replying, filing a
  story, posting) is a separate, deliberate step under its own rules.
- **Respect the Drive boundary.** `drive_grep` never reaches a person's own
  My Drive; do not try to work around that — route to the per-user tools.

## Sources

- Tools: `Jinemi/centralis` — `internal/tools/discordsearchtools`,
  `taigatools`, `onedevtools`, `drivetools` (2026-09-06).
- The Discord search/grep split and its degradation path are documented in
  the tool descriptions themselves; when this skill and a description
  disagree, the description (i.e. the code) is newer.