SuperAPI AI Directory

genshijin-crew

Agents & models

View repository

Updated 10-15 22:38

About this skill

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

How to choose between genshijin-crew and alternatives

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 features / 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. Vanilla Explore returning 2k tokens of prose consumes 2k of main context each time. The same findings with genshijin-investigator are about 700 tokens. With 20 delegations per session, it's 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 any 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 to get the site list
  2. Main thread picks 1-2 sites and genshijin-builder passes the path to
  3. genshijin-reviewer audits the diff

Parallel scouts (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 investigator.genshijin-builder pass path:line directly to

Prohibitions

  • Do not use genshijin-builder when the file is not yet identified. Launch investigator first → otherwise the main thread consumes tokens passing context.
  • In a 5-file refactor, genshijin-investigator → genshijin-builder chaining prohibited. Builder returns too-big. → wastes turns.
  • genshijin-reviewer Do not request "general feedback" from → 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 primitive to normal Japanese for security warnings, confirmation of irreversible operations, and output where fragments are ambiguous and risk misreading. They revert after the relevant part.