bajutsu

The authoritative prose norm for Bajutsu's writing — the language-agnostic writing technique both languages share (top-down drafting, stating the contribution up front, sentence stress, subject–verb proximity, active voice, cutting filler, paragraph-level argument structure (paragraph writing), self-contained prose that never assumes prior reading, and minimizing anaphora that forces the reader to backtrack). Use it whenever you write or revise a BE roadmap item (`*.md` / `*-ja.md`) or a prose document under `docs/`, in either language. It is the umbrella above two language layers: apply `english-document-writing` with it for English prose, and `japanese-document-writing` for Japanese prose.

日本語の技術文書・書籍原稿の文章規範。整形（引用ブロック、脚注、コラム記法）、段落と論証の構成（パラグラフライティング）、論証の厳密さ（ツッコミどころの除去）、読み手の負荷の管理（指示語の抑制を含む）、視点と語り、演出の抑制、LLM っぽい空句の禁止、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、英語ドキュメントを日本語に翻訳するとき、または推敲・リライトするときに使用する。

English-specific prose mechanics for Bajutsu's technical writing — formal word choice, the serial (Oxford) comma, restrictive that vs. non-restrictive which, no bare this/that as a noun, no singular they for one unspecified person, dashes, numbers, and colons. The English layer beneath the language-agnostic `document-writing` skill. Use it whenever you write, translate into, or revise English prose in a BE roadmap item (`*.md`) or a document under `docs/`; apply it together with `document-writing`, which carries the writing technique both languages share.

Sounding board for Bajutsu feature ideation. Use when the user wants to brainstorm potential features, explore what Bajutsu could do next, or turn a rough idea into a roadmap (BE) item. Grounds the conversation in the existing roadmap, proposes new items or seeds, folds overlapping ideas into existing items, and — when the user is happy — drafts the BE files with a placeholder ID and opens a PR. The real BE ID is allocated by CI (scripts/allocate_roadmap_ids.py), never guessed by hand. Scope is roadmap authoring only — it never implements the feature (that is the implement-be skill).

Implement a Bajutsu roadmap (BE) item end to end, starting from its ID. Use when the user names a roadmap item to build — "/implement-be BE-0066", "implement BE-0041", "start on BE-0007", a bare number, or a slug — or otherwise asks to turn an existing BE proposal into shipped code. Treats the item's proposal as the spec, self-assigns the item's GitHub tracking issue, grounds the work in the prime directives, sets up a focused branch, plans and confirms before writing, implements with tests, reviews and refines the diff, flips the item to Implemented (Status + reindex), and proves the gate is green. The deterministic counterpart to the `ideation` skill: ideation authors proposals, this one ships them.

Author a BE (Bajutsu Evolution) proposal and its implementation in parallel, landing them as a temporary two-PR stack — the proposal PR first, the implementation PR second. Use when the author is confident in a small, well-scoped feature and wants to "propose and build at once", "write the BE and the code together", or "stack the implementation on the proposal" instead of waiting for the serial ideation → merge → allocate → implement-be path. Composes the ideation skill (Phase A, authoring only) and the implement-be skill (Phase B + hand-off) around an explicit hand-off: once the proposal merges and CI allocates the real BE-NNNN, the implementation branch rebases, rewrites its BE-XXXX references, retargets to main, and runs implement-be's promotion + gate steps. Falls back to the serial path when a design is genuinely uncertain. Scope spans authoring and product code — the counterpart skills stay single-purpose (ideation never implements; implement-be needs a numbered item first).

Handle post-PR-creation follow-ups: fix CI failures, address review comments, reply to reviewers, and resolve conversations. Use when the user says "CIが落ちている", "reviewコメントに対応して", "PRのコメントを確認して", "PR #NNN を直して", or asks to fix a failing PR. Reads CI logs and review comments, makes targeted fixes, pushes, and replies. If a review comment requires a fundamental design change, escalate to the user instead of attempting it.

Clean up completed worktrees and their branches. Use when the user says "worktreeを破棄して", "cleanup", "完了したworktreeを片付けて", or asks to remove stale branches and worktrees. Lists worktrees, identifies merged ones, and removes them after confirmation. Mechanical operation only.

Fetch the latest origin/main and rebase the current branch onto it, then optionally create a worktree for a given topic. Use when the user says "mainを最新化して", "git sync", "worktreeを切って", or asks to prepare a branch before starting work. This is a mechanical operation — it runs git commands and reports the result. It never implements features, writes tests, or opens PRs.

Select the next task to work on from GitHub Issues and the roadmap. Use when the user says "次のタスクを検討して", "タスクを選定して", "issueから次に実行するべきタスクを", "次に進めるべきタスクを", or asks to pick the next item to implement. Reads open GitHub Issues and roadmap status, filters by criteria (e.g. Proposal status), and presents ranked candidates with rationale. Read-only — it never implements, creates branches, or opens PRs.

List roadmap (BE) items filtered by their Status, so a session can survey everything that is a Proposal (or In progress / Implemented / Proposal (deferred)) without reading the 700+-line roadmaps/README.md. Use when you need an overview of the roadmap in one status — e.g. "what proposals are open?", "which items are in progress?", "list the deferred ones" — or to find the file path of items in a status before opening them. Takes one status argument and returns a table of ID / Item / Topic / Path. Read-only: it surveys the roadmap, it never authors, implements, or edits any item (ideation authors proposals; implement-be ships them).