方針A(反復セルフレビュー)で 1 つの GitHub issue を 1 本の PR に実装する。 独立 Subagent(github-issue-implementer)で実装後、独立 Subagent(code-reviewer)による セルフレビューと修正を指摘点がなくなる(LGTM)まで繰り返し、PR をオープンのまま残す(マージしない)。 各マイルストーンを PR の行動記録(runlog)に残し、速度・反復回数はその記録から集計する。 `/pr-strategy-iterate <issue-number>` で起動する。
方針B(分割 PR)で 1 つの GitHub issue を、ある程度細かい単位の複数 PR に分割して実装する。 各 PR を独立 Subagent(github-issue-implementer)で実装し、独立 Subagent(code-reviewer)による セルフレビューと修正を「1 ターンのみ」行う(再レビューしない)。全 PR をオープンのまま残す。 各マイルストーンを PR の行動記録(runlog)に残し、速度・分割数はその記録から集計する。 `/pr-strategy-split <issue-number>` で起動する。
PR 戦略比較実験の「品質」を測るスキル。1 つの issue に対する最終的な差分(方針A は 1 本の PR、 方針B は複数 PR の和集合)を、横断文脈を持たない独立 Subagent に採点させる。 オーケストレーターは自分では採点せず、Subagent が返した構造化スコアをそのまま quality.json に記録する。 あわせて PR の行動記録(runlog)を辿って速度・反復回数を集計し metrics に反映する。 `/pr-quality-judge <issue-number> <pr-number>[,<pr-number>...]` で起動する。
Automatically consume open GitHub issues one by one. Fetches the oldest open issue, delegates implementation to the issue-implementer agent, runs code review via the code-reviewer agent, iterates on feedback, merges the PR, and moves on to the next issue. Invoke with `/auto-issue-worker`.
Run the auto-issue-worker flow against a single GitHub issue: implement it via the issue-implementer agent, review the PR once with the code-reviewer agent, apply one round of fixes for any findings, then stop with the PR left open (no merge). Use when you want a single issue taken from open to a ready-for-review PR without merging. Invoke with `/issue-worker <issue-number>`.
Run an authorized penetration test against the project after some implementation exists: combine static code analysis and dynamic testing against the running app to detect vulnerabilities, then register each confirmed finding as a GitHub issue. Use once enough of the project is implemented to be worth probing for security flaws. Invoke with `/pentest`. The created issues are consumed by `/auto-issue-worker`.
Interview the user to gather project requirements and consolidate them into a structured `spec.md` at the repository root. Use when starting a new project or feature and the requirements are not yet written down. Invoke with `/spec-builder`. Produces the input consumed by the `spec-to-issues` skill.
Read `spec.md`, break it down into discrete implementation tasks, and register them as GitHub issues in the project repository. Use after a spec exists (e.g. produced by the `spec-builder` skill) and the user wants to turn it into actionable issues. Invoke with `/spec-to-issues`. The created issues are consumed by `/auto-issue-worker`.