iroha924
UserLocal memory of past decisions for Claude Code and Codex. Records sessions and decisions in a local SQLite file and recalls them over MCP.
Categories
Indexed Skills (22)
design
承認済みの要件定義（.gleanery/changes 配下の requirements.md）を唯一の入力に、現在のコードと gleanery の過去の判断を根拠にして設計書（design.md）を作り、利用者の明示承認まで進める。要件の変更が要るときは requirements へ戻す。実装は始めない。
requirements
生の要求から、コードと gleanery の過去の判断を根拠に一問ずつ壁打ちし、要件定義（.gleanery/changes 配下の requirements.md）を作って利用者の明示承認まで進める。設計書・タスク・実装は作らない。
trace
いまの session で下した判断（決定と捨てた案、制約、やらないこと、行き止まり、分かったこと、意図して残した負債、検証、問い）と作業の現在地を DB に残す。会話そのものは自動で残るので、次の判断を誤らないための要素だけを選ぶ。ユーザーが明示的に頼んだときだけ使う。
winnow
依頼を、実装に入る前に詰めて、利用者が Go を判断できる方針にする。決めるべき問いの木を描き、事実は調べて確かめ、技術判断は別のモデルと突き合わせ、人にしか決められない問いだけを利用者へ出す。設計に分岐がある変更（仕様の解釈・公開インターフェース・データ・依存の選択が割れるもの）を受けたときに、実装より先に使う。**文書は作らない** —— 要件定義や設計書を残すなら requirements と design を使う。分岐の無い小さな変更、調べて答えるだけの質問、Go の後の実装、レビューには使わない。
knowledge-schema
gleaneryのDB schema（db/schema.sqlとdb/migrations、SQLite）、接続の役割とauthorizer、全文検索の索引（FTS5）、知識の種類と状態、取り込み元の書き方を変更する。table、列、CHECK、view、trigger、権限、新しいimport経路を触るときと、既存のDBへmigrationを当てるときに使う。端末の画面だけの変更には使わない。
plugin-release
gleaneryのMCP、CLI（端末の画面を含む）、自動記録のhook、plugin SkillまたはAgentを変更してnpmへ届ける。bundleのエントリポイントとその依存module、versionの一致、Claude/Codex両方への到達確認が対象。DB schemaやroleだけの変更には使わない。
ui-hono
gleaneryの画面（Vite + React + TanStack Router）またはHono HTTP APIを変更する。画面、route、URLの状態、API入力、ローカルの境界を触るときに使う。MCP・CLIだけの変更やDB schemaの変更には使わない。
review
変更をレビューする。コミット済みと未コミットの差分を自分でレビューするとき、他人の PR をレビューするとき、マージやリリースの前に見落としを洗うときに使う。独立したレビュアーを観点ごとに立て、Codex が入っていれば同じ観点を別モデルでも走らせて、片方のモデルにしか見えない欠陥を拾う。指摘は再現で裁定してから返す。書式や命名の揺れ、設計の好み、将来の拡張性は扱わない。
tui
gleaneryの端末の画面（`gleanery dashboard`、server/src/tui/ の Ink）とCLIの出力の見た目（server/src/tui/view.ts）を変更する。画面・キー操作・一覧と詳細の表示・CLIの出力の形・記号とアイコン・Markdownの描画・CLIのbundleを触るときに使う。セッションや作業の読み出し（server/src/sessions.ts）を画面のために変えるときも使う。MCP・CLIの他のcommandだけの変更やDB schemaの変更には使わない。
plugin-agent-authoring
gleanery pluginが配るreviewの観点（plugin/skills/review/reviewers/）とその起動方法を変更する。観点の本文を足す・直す、レビュアーへ渡すtoolsや立て方を変えるときに使う。通常の実装や組み込みsubagentの利用には使わない。
codex-review
gleanery の差分のレビューや調査を Codex（codex exec）に頼む。PR を merge する前、一次情報で決まらない判断を別のモデルと突き合わせるとき、入った変更を振り返るときに使う。Codex の指摘を受け取って直すところまでを扱う。Claude Code 側の reviewer（review-shipping・review-ui）を立てるときには使わない。
init
このリポジトリに、要件定義と設計書の置き場所（.gleanery/）を gleanery init で作る。作った場所が想定したリポジトリの根かを利用者に確かめさせる。要件の整理は始めない。
iroha-review
The self-review pipeline for this repository — the only one. Targets committed changes (default: everything since the merge-base with main), reviewing them through a multi-stage pipeline: deterministic checks (lint/typecheck/test/build/secret grep) → launch fresh-context reviewers (security-reviewer / spec-compliance-reviewer / adversarial-reviewer, plus security-diff-reviewer when the diff touches packages/git, packages/forge*, or packages/adapter-*) in parallel → reproduce-and-verify HIGH/CRITICAL findings with finding-validator. Can be invoked at any time, with or without a PR, and is what to run before pushing a fix to a security-sensitive package. If the working tree has uncommitted changes, use AskUserQuestion to confirm whether to include them. No commit, push, or PR creation — its only write is the PR-comment draft inside `.git/`, which is never committed. fail-open (this skill itself does not block the merge; it only reports findings). Invoked by "self-review this", "review this", or "/iroha-review".
pr-review-status
Find out what the AI reviewer said about a pull request, and respond to it. The hosted OpenAI Codex reviewer is invisible to CI — it appears in no status check — so `gh pr checks` being green says nothing about whether a review ran, is still running, or left findings. Use after pushing to a PR and before reporting the work as done, when deciding whether a re-review is worth its rate limit, and when replying to or resolving a review thread. Not for reviewing a diff yourself — that is `iroha-review`.
release
Cut an iroha npm release — bump the version, verify locally, dispatch the human-gated Release workflow, and confirm the publish. iroha ships to npm as `@irohalabs/iroha` via OIDC trusted publishing (no npm token). Use when preparing or cutting a release (a new `@irohalabs/iroha` version), or when asked "how do we release / publish iroha". Not for day-to-day development.
init
Initialize iroha in the current Git repository so agents share approved engineering memory. Use when the user asks to set up, install, or initialize iroha in a repo. Do not use for unrelated project scaffolding or for repositories that are already initialized (rerunning is safe but unnecessary).
digest
Compose the editorial prose for the current iroha Digest period — the dashboard's front page. Use when the user asks to write, refresh, or regenerate the Digest (weekly or monthly). Do not use to look up knowledge or to report on a person; the Digest is aggregate and agent-and-rule-focused.
checkpoint
Save a structured Checkpoint of the current work as a local iroha candidate for later human approval. Use after a meaningful unit of work — a decision reached, a bug fixed, a reusable rule or pattern discovered. Do not use for trivial edits, and never treat a Checkpoint as approved knowledge (a human approves candidates in the dashboard).
dashboard
Open the local iroha review dashboard, where a human approves or rejects candidate knowledge and browses the memory graph. Use when the user wants to review the iroha queue, approve or reject candidates, or open the dashboard. Do not use for unrelated local web servers or UIs.
doctor
Diagnose the iroha installation — platform integration, hook trust, MCP connectivity, database capabilities, and Git access. Use when iroha behaves unexpectedly, a hook or the MCP server seems inactive, or the user asks to check or verify the iroha setup. Do not use for unrelated environment diagnostics.
search
Search approved iroha engineering memory — decisions, rules, incidents, patterns, and session summaries — across Japanese, English, and code. Use when the user asks what iroha knows, why a past decision was made, or which rules apply here. Do not use for general web search or for searching source files directly.
sync
Rebuild the local iroha index from the Git-tracked .iroha/ canonical files. Use when the user asks to sync, refresh, or rebuild iroha memory — typically after pulling teammate changes or resolving a merge. Do not use for unrelated file synchronization or version control operations.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.