mcpField
S
stewardship

stewardship

github.com/athola開発34382 回インストール1 日前に更新
リポジトリ

stewardship について

stewardship は、night-market エコシステムのプラグイン開発に向けたエンジニアリング実践スキルです。5つの原則と美徳を通じて、設計判断、コードレビュー、ワークフローの振り返りでコミュニティと後続の貢献者を重視します。

主な機能

  1. 015つのコード保守原則
  2. 025つのエンジニアリングの美徳
  3. 03プラグイン層別の指針
  4. 04ワークフロー境界での振り返り

活用シーン

  1. 01プラグインをレビューし貢献者体験を改善
  2. 02コミット前に設計とコード品質を確認
  3. 03基盤プラグインの互換性を保つ変更を計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/athola/claude-night-market --skill stewardship

インストール後、Claude Code で/stewardshipを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

modules/
care.md
curiosity.md
diligence.md
foresight.md
humility.md
reflection.md

詳細

スチュワードシップ

使用するタイミング

  • プラグインに取り組み、設計上の判断を行うとき
  • コードの品質と貢献者の体験を確認するとき
  • ワークフローの区切り(コミット前、PR 後)に振り返るとき

使用しないタイミング

  • 設計に影響しない、すぐに済む一行の修正
  • night-market エコシステム外の外部プロジェクト

プラグインに触れるときは、常にこれらの原則を適用してください。研究の背景を含むマニフェスト全文は、プロジェクトルートの STEWARDSHIP.md にあります。

5 つの原則

  1. あなたは所有者ではなく、スチュワードです:コードベースはコミュニティのものです。自分のためではなく、読者のために書きましょう。
  2. ただ維持するのではなく、より良くしましょう:触れた部分を改善してください。足りないテストを追加し、わかりにくい名前を明確にし、古くなった例を更新しましょう。
  3. 小さなことにも誠実に取り組みましょう:誤字を直し、不要なインポートを削除し、型ヒントを追加しましょう。小さな行動は積み重なります。
  4. 後から来る人のために尽くしましょう:何の背景知識もない状態で参加する貢献者のために書きましょう。その人の体験を優先してください。
  5. 7 回先の変更まで考えましょう:シンプルで透明性の高いパターンを選びましょう。この設計は、7 回の大きな変更を経ても通用するでしょうか?

5 つの美徳

このフレームワークのエンジニアリング手法と、Claude が訓練を通じて身につけた特性を結び付ける、行動につながる心構えです。 各美徳には、認識パターン、実践用プロンプト、アンチパターンを含む専用モジュールがあります。

  1. 思いやり:自分の成果を引き継ぐ人々に積極的に配慮すること
  2. 好奇心:行動する前に深く理解すること
  3. 謙虚さ:自分が知っていることと知らないことを正直に見極めること
  4. 勤勉さ:小さなことでも、質を高めるための実践を怠らないこと
  5. 先見性:後から来る人々の選択を考慮して設計すること

美徳の定義と美徳とワークフローの対応表については、STEWARDSHIP.md の「Soul of Stewardship」セクションを参照してください。

これはスチュワードシップが求められる場面でしょうか?

プラグインで作業するときは、次の質問を自分に投げかけてください。

質問はいの場合原則
わかりにくいコードを読んだところですか?説明を補うコメントを残す4
この README は古くなっていますか?状況を把握しているうちに更新する2
誤字や不要なコードに気付きましたか?今すぐ直す。10 秒で済みます3
気の利いた抽象化を追加しようとしていますか?考え直しましょう。7 回目の変更でも感謝されるでしょうか?5
自分のために書いていますか、それともコミュニティのためですか?読者のために書き直す1

どの質問にも当てはまらない場合:問題のない領域です。その状態を保ちましょう。

どれか 1 つでも当てはまる場合:小さな改善を行いましょう。ほんの数秒で済み、将来の読者全員に大きな価値をもたらします。

レイヤーごとの指針

Meta(抽象)

他のすべてを支えるツールを保守します。スチュワードシップで優先すべきことは、スキル作成パターンの安定性と明確さです。評価フレームワークが変わると、下流のプラグインにも影響します。慎重に変更し、十分に文書化し、厳密にテストしてください。

Foundation(leyline、sanctum、imbue)

他のすべてのプラグインが依存するインフラストラクチャを保守します。スチュワードシップで優先すべきことは、後方互換性と明確な移行手順です。leyline のパターンを変更すると、15 個のプラグインで対応が必要になる場合があります。追加的な変更を優先してください。破壊的変更を避けられない場合は、移行ガイドを作成しましょう。

Utility(conserve、conjure、hookify)

貢献者が日常的に使うツールを保守します。スチュワードシップで優先すべきことは、ユーザー体験と手間の少なさです。フックがわかりにくければ、貢献者は無効にします。ルールが煩雑なら、貢献者は無視します。量ではなく、有用なシグナルを重視して調整しましょう。

Domain(その他すべて)

専門知識を保守します。スチュワードシップで優先すべきことは、正確さと利用しやすさです。ドメイン知識は、他の人が利用できて初めて価値を持ちます。参照情報だけでなく、例も書きましょう。基盤となるドメインの進化に合わせて、ドメインスキルを最新の状態に保ってください。

振り返り

タスクの完了、コミットの準備、セッションの終了など、ワークフローの自然な区切りで、振り返りモジュールを使い、5 つの美徳に基づいて簡単に自己評価してください。テンプレート全文は modules/reflection.md を参照してください。

完了条件

  • いずれかのプラグインの作業を完了する前に、「これはスチュワードシップを発揮すべき場面か?」という5つの質問すべてを確認します。該当する質問があれば、それに応じた小さなアクション(コメント、README の更新、誤字の修正、抽象化の再検討)を実施します
  • レイヤー固有のガイダンスを適用します。基盤プラグイン(leyline、sanctum、imbue)では、破壊的変更に移行ガイドを添えて追加的な変更を行います。ドメインプラグインには、リファレンスだけでなく例を含めます
  • コミット前の段階で、modules/reflection.md の振り返りチェックリストを完了します。成果物は、5つの美徳(思いやり、好奇心、謙虚さ、勤勉さ、先見性)に照らした簡潔な自己評価です
  • 「7回の反復」テストを経ていない巧妙な抽象化は採用しません。設計は、7回の大きな変更を経ても成り立つ必要があります

コメント