genshijin-crew

genshijin-crew = a 3-subagent preset that outputs in genshijin form. Roles are the same as the Anthropic defaults (Explore, editing agents, reviewer). The difference is that the returned tool-result is already compressed → main context consumption shrinks with each delegation.

genshijin-crew vs alternatives: when to use which

Task	Use
"Where is X defined / where is Y called / all usages of Z"	genshijin-investigator
Same as above + want architecture explanation/proposals too	Explore (vanilla)
Surgical edits, ≤2 files, clear scope	genshijin-builder
New feature / 3+ files / cross-cutting refactor	Main thread or feature-dev:code-architect
Bug review of Diff/branch/file	genshijin-reviewer
Deep code review with rationale + alternatives	Code Reviewer (vanilla)
Certain content already answered in one line	Main thread, no subagent needed

Decision criterion: if you want subagent output in 1/3 the tokens, use genshijin-crew; if you want prose, use vanilla。

Why it exists (practical benefit)

Subagent tool-results are injected verbatim into the main context. When vanilla Explore returns 2k tokens of prose, it consumes 2k of main context every time. The same findings in genshijin-investigator are about 700 tokens. With 20 delegations per session, that is the difference between context exhaustion vs task completion.

Output contract

A format the main thread can rely on per agent:

genshijin-investigator

<Header>:
- path:line — `symbol` — short note
集計: <counts>。

or No match. Always file path first, with line numbers, symbols in backticks.path:\d+ is grep-able.

genshijin-builder

<path:line-range> — <change ≤10語>。
verified: <re-read OK | mismatch @ path:line>。

or one of the following: too-big. / needs-confirm. / ambiguous. / regressed. (terminal first token)。

genshijin-reviewer

path:line: <emoji> <severity>: <問題>. <修正>.
totals: N🔴 N🟡 N🔵 N❓

or No issues. files → ascending line order.

Chaining pattern

Locate → fix → verify (most frequent):

1. genshijin-investigator get the site list
2. Main thread picks 1-2 sites and genshijin-builder pass the path to
3. genshijin-reviewer audits the diff

Parallel scouting (when investigation is broad): in one message, genshijin-investigator launch 2-3 in parallel (different angles: defs vs callers vs tests). Aggregate in the main thread.

Single edit (when the site is already known): Skip the investigator.genshijin-builder pass path:line directly to

Prohibitions

• Do not use genshijin-builder when the file is not yet identified. Launch the investigator first → otherwise the main thread consumes tokens passing context.
• In a 5-file refactor, genshijin-investigator → genshijin-builder chains are prohibited. The Builder returns too-big. → wasted turn.
• genshijin-reviewer Do not request "general feedback" from → it returns findings only, no architecture opinions. For that, use Code Reviewer。
• Do not expect prose. genshijin-crew output is structured, sometimes cryptic. If a human will read it directly, the main thread rephrases it.

Automatic release (inherited)

Subagents switch from genshijin to normal Japanese for security warnings, confirmation of irreversible operations, and output where fragment ambiguity risks misreading. They return to genshijin afterward for the relevant portion.