Crowi の security 依存(GitHub Dependabot alerts)を本質的に対応する skill。 「最近 dependency 見てないな」というとき単発 (`/crowi-deps`) で手起動する。 alert 取得 → direct/transitive 分類 → 根本対応(direct は version bump、 transitive は親 bump、親が上げられないときだけ per-major override、major upgrade 待ちは報告のみ)→ pnpm…
設計アイデアを RFC か spec に落とすワークフロー。新機能 / 記法 / アーキの設計を 「調査 → 設計 → 敵対的レビュー → ドキュメント化」で詰めたいとき。重い調査・設計・ レビュー・執筆を subagent (Workflow) に散らして main を軽く保ち、ユーザーとの収束だけ 対話ゲートに残す。crowi-feature (実装) の設計版。 キーワード: 設計, design, rfc, spec, 設計レビュー, 調査, ドキュメント化, brainstorm, 設計判断, 壁打ち
worktree での実装 + QA + 修正が全部終わったと自分で判断したときに worktree セッションで起動する。客観ゲート (clean / commit あり / type-check / test / lint / openapi) を走らせ、全部 green のときだけ tasks/{id}.json を READY_TO_INTEGRATE にする (spec を切らず gw start から直接 fix した等で task ファイルが無ければ synthesize して作る)。これが…
完了した並行 worktree の作業を main に取り込み、worktree を close、その後 simplify で 統合後のコードを整える一連のワークフロー。複数エージェントが gw worktree で並行作業して いる時に、ひとつ終わったブランチを main に合流させる時に使う。 キーワード: worktree, merge, integrate, gw end, 統合, 取り込み
changeset を追加するかどうかの判断基準・bump level (patch/minor/major) の選び方・ 対象パッケージの選び方・コマンド。feature や fix を commit する直前、 「これ changeset いる?」と迷ったとき、リリースノートに載る文面を書くときに読む。 キーワード: changeset, リリースノート, changelog, bump, patch, minor, major, pnpm changeset add, リリース準備
直近の main の変更(integrate 済み feature・fix)を踏まえて apps/crowi-site/ の ドキュメント(content/docs/{ja,en})を更新し、既存ページに陳腐化した記述が ないかを実コード照合で調査・修正する定期メンテ skill。integrate が数本たまった とき・release pre-flight の前・「ドキュメント古くない?」と言われたときに回す。 キーワード: docs, ドキュメント, 陳腐化, stale, 古い, site,…
Crowi 2.0 の新機能開発ワークフロー。設計合意 (implementation-ready spec または legacy spec) を起点に、 spec 承認 → Workflow (plan → implement → simplify → review-loop → commit) を決定的に駆動。 制御フローは pipeline.workflow.js (コード)、各 phase は feature-* エージェント。 キーワード: feature, 新機能, 開発, build, 設計,…
バグ報告・小修正のための軽量ワークフロー。spec 不要。再現(失敗するテスト)を先に作り、 systematic-debugging で根本原因を特定してから直す。ゲート(type-check / test / lint)→ codex 1 パスレビュー → commit。設計判断が要る規模なら crowi-design / crowi-feature へ誘導。 キーワード: fix, バグ, 修正, bug, 不具合, repro, 直して, 壊れてる