tumeda-dev

Plugin tumeda-dev from marketplace tumeda-dev-plugins in tumeda1992/ai_agent_dev_skill_plugin. Commands read from the repo's manifest — 5 days ago.

Skills (17)

• doc-enricher

  コードリーディング/タスク遂行後に、永続性が高く高レバレッジな知識だけをディレクトリREADMEに提案する。デフォルトは提案のみ。ユーザー承認後にのみREADME/docsを更新。新規docs/作成は禁止。

• document-review

  md ファイルを作成・更新したら emit 前に通すレビューゲート。 「作成時観点」「更新時観点」を必ず当て、必要なら「ケース別観点」を足す。 doc を書く／直すフロー（tasklist-executor・task-design 等）が emit 前のゲートとして呼ぶ。 「ドキュメントをレビューして」「md を出す前にチェック」等でも起動する。

• escalate-plugin-skill-fix

  このpluginのskill、docs、template、scriptに対する修正提案が生じた時に使う。利用先repositoryで作業中でもplugin repositoryで作業中でも、提案が生じた瞬間、または元担当が同じ作業の保留条件を再確認・再開する時に起動する。plugin repositoryかどうかの判定はこのskillの内部で行うため、起動条件には含めない。通常の設計議論や、利用先repository自身のcodeに対する修正では起動しない。

• exhaustive-review

  高知能モデルで、リポジトリ全体・指定範囲・差分を複数の観点から繰り返し精査し、問題を徹底的に洗い出す。 指摘と改善案を指定ディレクトリへ独立して記録する。 修正はユーザーと合意した範囲だけを適用する。

• facilitate-discussion

  明示された議論を論点単位で進行し、委託されたテーマ内の提案、feedback、決定、親子関係を指定directoryのMarkdownへ継続記録する。合意済みの議論も再合意なしで記録し、記録漏れへ後から気づいた場合は結論だけでなく議論の変遷を再構成するが、会話から確認できない提案や合意は補完しない。ユーザーが `$facilitate-discussion`、議論のMarkdown保存・追記を明示した時、またはconsumer skillが保存を伴う議論workflowとして明示適用した時だけ使う。通常の質問、説明、短い相談には使わない。

• maintenance-plugin-context

  tumeda-dev pluginのrepository context、作業限定の暫定指示、配布version規約を管理する。plugin skillがリポジトリ固有の文書、command、規約を必要とする時、`.agents/skills/tumeda-dev-plugin-context.md`を新規作成・更新する時、またはplugin versionを変更・検証する時に使う。暫定指示の登録・改訂・取得・終了にも使う。文脈・暫定指示・versionが不要な通常作業には使わない。

• name-work-directory

  作業成果物を格納するディレクトリの安定した basename を決める。実装、調査、計画などの作業用ディレクトリに再利用可能な日付付きの名前が必要なときに使う。

• plan-commits

  コミット計画、変更の分割、レビューする単位と順番、コミットメッセージを決める時に使う。 意味のある一つの仕事を最優先に、実差分・依存・revert時の効果から境界を決める。 計画だけを求められた時はstage・commit・pushしない。

• share-work-in-progress

  作業中のbranchの内容を、依頼者がGitHub上で読める状態にする。「出来上がったものをちょっと見たい」など、動作確認の完了を待たずに今のbranchの中身を共有したい時に使う。tasklist-executorの「ユーザー動作確認が完了するまでcommit・push・PRを行わない」契約とは前提が逆であり、動作確認の後に呼ぶものではない。

• skill-update-review

  汎用skillの新設・更新で、SKILL.mdと内部指示が、独立した判断・状態・完了条件・改訂理由を持つ工程を抱え込んでいないかを見て、 切り出せる工程（同じskillの内部指示へ分けるもの、別skillにするもの）を候補として知らせる。構造案の採用前と編集後に使う。単独でも使う。

• steering

  task-designのready resultを受け、plan resultをdispatchし、planless resultを安全gate後に完了する。roadmap treeの子steering bindingとruntime orchestrationはsteeringが所有する。明示指定時、および軽度でない複数file・複数stepの変更時に起動する

• task-design

  変更タスクが与えられたとき、変更前の不確実性をゼロにするための設計プロセス。 「設計書を書く」のではなく、後続作業では合意済みの内容を手を動かして反映するだけの状態を作ることが目的。 以下のいずれかに該当する場面で積極的に使う: - 機能追加・変更の要件が渡されたとき - 「どう実装すればいいか」を問われたとき - 複数ファイル・レイヤーにまたがる変更が含まれるとき - ドメイン命名・DB設計・API 設計が絡むとき - 実装方針が決まっていない状態で「作って」と言われたとき - docs、skill、prompt、規範、調査結果等の完成後の姿を設計するとき デフォルトモデル: Opus（設計

• tasklist-executor

  指定されたtasklist.md を上から順に実行し、未完了タスクがなくなるまで実装・テスト・更新を繰り返す

• test-runner

  テストの実行と失敗の分析を行う専門エージェント。テスト実行後に自動的に使用されます。

• think-through

  議論・思考プロセスの作法を矯正するスキル。毎ターン適用する想定の常時注入型。 ユーザー発言を唯々諾々で受け取らず、事象から原因へ降り、提案を検証まで通す構造で考え抜く。 ロジックツリー上位から再帰的に問いを解き、TBD 暫定全体で構造合意を先取りし、 複数事項や作業中の状態変化では、未決事項に依存しない確定事項を先に完了してから残る未決事項を決める。 広くvariationのある対象では、具体caseと方針群を往復し、全caseを扱えるまで帰納する。 抽象と具体の往復で意味を曲解されない原則を立てる。 「議論する」「論点を整理する」「どう設計？」「どう実装？」「修正したい」「エラーが出た」 「

• unattended-execution

  利用者が不在または応答できない間の自走を明示した時、既承認scopeの作業を進め、新たな承認が必要な操作を保留する。

• visual-inspector

  フロントエンドのUIをPlaywrightでスクリーンショット撮影して目視確認する。UI変更後の見た目チェックに使う。

Similar plugins