mcpField
V
vibe-writing

vibe-writing

github.com/adhi-jp開発1135 回インストール3 日前に更新
リポジトリ

vibe-writing について

vibe-writingは、Agent支援型コーディングでLLMが扱う文書など、長期的に使える開発テキストを書くためのスキルです。編集範囲と副作用を制限し、明示的な根拠、安定した参照、意味の保持を重視します。

主な機能

  1. 01影響区分に応じた執筆境界
  2. 02成果物とコード範囲の規則
  3. 03根拠に基づく表現
  4. 04長期記録と参照の要件
  5. 05言語と形式のガイド

活用シーン

  1. 01LLM向けの明確な開発指示の作成
  2. 02定められた範囲での決定記録の作成
  3. 03義務を変えずに行う文章編集

インストール

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

$npx skills add https://github.com/adhi-jp/agent-skills --skill vibe-writing

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

同梱ファイル

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

references/
artifact-guidance.md
changelog.md
commit-messages.md
durable-records.md

詳細

Vibe Writing

概要

次に使う読者のために、長く役立つ開発文書を書きます。 エージェント支援によるコーディング作業では、標準の読者は、正確な契約、安定したアンカー、明示的な根拠を必要とする LLM です。

効果と書き込みの境界

フェーズで宣言された効果クラスと境界が許可する範囲を超えて、何も書き込まないでください。

  • フェーズが自身のテキストで宣言する効果クラスを適用します。このパッケージでより狭い制限が定められている場合は、その制限を優先します。
  • 読み取り専用:チャットで報告し、ファイルを編集せず、状態を変更するコマンドを実行しないでください。また、ステージング、コミット、タグ付け、プッシュ、バージョン変更、データ削除、サービスの起動は決して行わないでください。保存する成果物をユーザーが明示的に求めた場合に限り、ファイルを書き込みます。
  • 成果物のみ:フェーズが担当する成果物と、テキストで宣言された補助パス(確定した計画の振り返りや決定記録など)のみを作成または更新し、作業ツリーに残します。
  • 成果物のみのフェーズでは、実行可能な動作を実装したり、実装としてコードやテストを編集したり、別のフェーズの成果物を作成したり、リリース作業を行ったり、成果物を同じターンで実装する権限として扱ったりしないでください。
  • 状態変更可能:宣言された範囲内でのみ、最小の検証済み単位で編集とコマンド実行を行います。ユーザーが選択しない限り、その他のパス、既存の変更、実行時または外部の状態には触れないでください。
  • これらの制限はファイルツールだけでなく、シェルコマンド(リダイレクト、sed -i、tee、mv、cp、rm、git checkout --)にも適用されます。書き込みを拒否した場合は、境界による停止として報告し、別のツールを使って再試行しないでください。
  • 取り消し不能な操作や外部に影響する操作は、それぞれ個別の同意を得てから行ってください。

このフェーズが担当する成果物は、書き換え、推敲、ローカライズを含め、依頼で指定されたテキストの納品物です。決定記録と調査結果レポートについては、パスを定める Durable Records に従います。

長期保存する記録

確定した決定を記録する、調査結果を保留にする、または既存の記録を適用・更新する前に、references/durable-records.md を読んでください。このフェーズでは、補助パスとして宣言されている docs/decisions/ と docs/reports/findings/、またはリポジトリに既存の記録用ディレクトリに書き込みます。

コミットの選択

文書のみのフェーズで、コミットを選択しないでください。

  • 検証済みの成果物の変更は作業ツリーに残します。呼び出し、パスへの配置、追跡状態、レビューや監査の合格、振り返りへの同意、成果物の完成のいずれも、コミットを選択する理由にはなりません。
  • 明示的な現在のユーザー依頼がある場合に限り、そのフェーズが担当する成果物に範囲を限定してコミットを選択できます。コミットワークフロー、または見当たらない場合はフェーズ自体が、ファイルセットのレビュー、メッセージの受け渡し、保存されたメッセージの検証、プッシュと履歴の境界に従ってコミットします。
  • 草稿作成中は、ステージング、コミット、プッシュ、リリース、バージョン変更、履歴の書き換えを決して行わないでください。また、成果物を実装、プッシュ、リリース、バージョン変更、履歴の書き換えの許可として扱わないでください。
補助的な文言モード

別のワークフローが進行中の場合、ユーザーが独立した文書の作成を求めない限り、このスキルは文言の調整にのみ使用します。範囲、検証、リリース、コミットに関する判断権は、進行中のワークフローにあります。

範囲の境界

正確さが重要なテキスト、すなわちツールやログの逐語的な出力、プロトコルの断片、引用されたソース、または短い相づちは書き換えないでください。そのまま伝えるか、それに触れずに回答してください。一時的な進捗テキストは簡潔に保ち、依頼がない限り、生のログを要約して整えないでください。

読者の優先順位

標準として、LLM 向けに最適化された開発文書を作成します。事実、契約、制約、根拠を直接述べ、有用で安定したアンカーを維持し、冗長な表現を削り、存在しないことも明示してください。成果物が主に人向けのものである場合(エンドユーザー向けドキュメント、UI 文言、サポート文面、公開リリースノートなど)は、人向けに最適化された文章を使用してください。

証拠と意味

理由、目標、結果、影響、テスト、安全性やパフォーマンスに関する主張、ロールアウト、リスク低減に関する主張を捏造しないでください。提示された機能は、その原因、目的、効果、証明、利点を示す証拠ではありません。

現在のプロンプトに示されたワークフローの状態は、提示された証拠として扱ってください。回答のみを求めるタスクで、変更がステージ済みであること、編集が完了していること、チェックに合格したこと、またはその他のワークフロー上の事実がすでに確立されている場合は、その状態に基づいて記述してください。プロンプトが対象として明示的に指定していない限り、評価用サンドボックス、ランナー、または現在のチェックアウトの状態に置き換えないでください。タスクがメッセージ、コマンド列、または完了記録のみを求めている場合、ツールを利用できるという理由だけで、示された変更を実行しないでください。現在のリクエストでコミットが選択されている場合、または変更を含むワークフローのチェックポイントである場合に限り、コミットの手順を記述してください。

事実、範囲、条件、例外、警告、必須の対応、意味のある順序、法性を保ってください。検索の手掛かり、ワークフローのラベル、契約、またはドメイン用語として役立つ用語や識別子は、そのまま維持してください。義務、適用範囲、許可、または失敗時の動作を変えるような、より洗練された文への書き換えは誤りです。

言語と形式

チャットの言語

ユーザー向けチャット文の言語は、成果物の言語とは別に、次の順序で決定してください:

  1. チャット、応答、または出力の言語に関する、現在のユーザーからの明示的な指示。
  2. VIBE_CHAT_LANGUAGE。読み取り可能な、またはユーザーがこのリクエスト用に設定した言語名や、ja、pt-BR などの BCP47 タグ。空または無効な値は未設定として扱います。
  3. ユーザーが現在使用している会話言語。それがない場合は、このワークフローで直近に明確に使われた言語。
  4. 英語。

ユーザーが言語の指定として明示していない限り、成果物、ファイルの内容、パス、コマンド、コード、スキルの呼び出し、ホストラッパーの文面からチャットの言語を推測しないでください。 翻訳を求められていない限り、パス、コマンド、識別子、環境変数、ロケールタグ、メッセージキー、製品名、コードはそのまま維持してください。

成果物の言語

成果物の言語は、次の優先順位で選択してください:

  1. 翻訳やローカライズの依頼を含む、ユーザーからの明示的な指示。
  2. 対象となる成果物についてすでに選択されている、アクティブなワークフローまたは成果物固有の言語契約。設定による文書言語の指定も含みます。
  3. 既存の成果物の言語。
  4. README.ja.md や docs/de_de/guide.md など、ファイル名のロケール表記。
  5. プロジェクトの慣例。
  6. 英語。

成果物の言語は、チャットの言語には従いません。「チャットの言語」でそのまま維持すると定められたものに、翻訳または改名が求められていない限り、正規表現も加えてそのまま維持してください。新たに生成する文章は選択された言語で記述しますが、引用、用語、識別子、証拠の手掛かりとして役立つ原文の表現は保持してください。

形式と厳密性

説明を求められていない限り、Markdown のコードフェンス、プロンプトだけのラッパー文、出典情報を付けず、成果物を直接返してください。必要な改行、コマンド、機械可読構造を維持してください。厳密な形式では、余分な文章や、指定されていないフィールドを追加してはいけません。裏付けのない主張は意味の上で取り除き、許可されている場合は、必須のスキーマを裏付けのある中立的な値または空の値で維持してください。

成果物固有のガイダンス

成果物固有のルールについては references/artifact-guidance.md を読んでください。コミットメッセージの草案作成、転送、または保存済みメッセージの修正の前には references/commit-messages.md を、変更履歴の作業の前には references/changelog.md を読んでください。このフェーズで本文のコミットまたは修正を行う場合は、完了を報告する前に保存済みメッセージを確認し、不正なバイト列があれば修正してください。意思決定記録と調査結果レポートには「永続的な記録」の規則を適用してください。

永続的な参照情報

成果物は、プロンプトがなくても意味が通じるものにしてください。プロンプト内だけで通用する参照や、ローカルマシン固有の文脈は、永続的な事実または有用で解決可能な参照情報に置き換えてください。

コメント