スキル writing-skills
📝

writing-skills

安全

TDD手法でAIスキルを作成してテストする

こちらからも入手できます: Cycleaddict,Cygnusfear,davila7,Dimon94,DYAI2025,CodingCossack,obra

テストなしでAIスキルを作成すると、エージェントが压力下で無視するドキュメントになってしまいます。このスキルではテスト駆動開発をスキル作成に適用します。まず失敗するシナリオを実行し、失敗を記録し、その具体的なギャップに対処するスキルを作成し、最後にコンプライアンスを確認します。

対応: Claude Codex Code(CC)
🥉 73 ブロンズ
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「writing-skills」を使用しています。 エージェントは時間壓力下でスキルのチェックをスキップし、'ドキュメントを読まずに速く修正できる'と言いました

期待される結果:

特定された合理化:スピードバイアス。追加するカウンター:デバッグ前にスキルチェックを要求する明示的な'STOP'チェックポイント。レッドフラグ:'既知の内容は承知'=むしろスキルを読む

「writing-skills」を使用しています。 スキル説明:'テストが不安定な場合の非同期テストに使用'

期待される結果:

改善版:'テストにレーシングコンディション、タイミング依存性、または実行ごとに一貫して合格/失敗しない場合に使用。'検索可能な症状と技術に依存しないトリガーを追加。

セキュリティ監査

安全
v1 • 2/24/2026

This is a documentation skill teaching test-driven development for AI skill creation. All 513 static findings are false positives: markdown code examples flagged as shell commands, documentation URLs flagged as network calls, and normal English text matching security keywords. The render-graphs.js utility safely calls graphviz for diagram rendering with hardcoded arguments.

7
スキャンされたファイル
2,911
解析された行数
0
検出結果
1
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
50
コミュニティ
100
セキュリティ
87
仕様準拠

作れるもの

新しいドキュメントを作成するスキル著者

RED-GREEN-REFACTORサイクルに従って、エージェントが压力下で従う強力なスキルを作成します

エージェント行動を調整するチーム

明示的な合理化カウンターとレッドフラグを持つ規律強制スキルを作成します

明確さを向上させるドキュメント作成者

トークン効率と相互参照技術を適用して、簡潔で発見可能なドキュメントを作成します

これらのプロンプトを試す

初心者: スキル作成チェックリストを開始
[トピック]のための新しいスキルを作成したいですか。REDフェーズを 안내してください:スキルを書く前に実行する压力シナリオの書き方を助けてください。
中級者: ベースライン失敗を分析する
スキルなしで压力シナリオを実行したら、エージェントが[行動の説明]ました。合理化パターンを特定し、スキルのカウンターを書くのを手伝ってください。
上級者: 合理化に対して強固にする
私のスキルは[規律]を強制します。草案をレビューして、エージェントが压力下で不遵守を合理化する可能性のある潜在的な抜け穴を特定してください。
エキスパート: フルTDDスキル作成セッション
完全なスキル作成をガイドしてください:1) 3つ以上の複合压力シナリオを設計する 2) ベースライン失敗を記録する 3) ギャップに対処する最小限のスキルを書く 4) 残りの抜け穴を特定する 5) コンプライアンスを確認する

ベストプラクティス

  • スキルコンテンツの下書きを作成する前に、压力シナリオを書いてベースライン失敗を記録する
  • 説明はワークフローの要約ではなく、'使用条件...'で始めてトリガー条件を列表する
  • 禁止される回避策と合理化カウンターを列表して、抜け穴を明示的に閉じる

回避

  • エージェントがそれなしで失敗する様子を見る前にスキルドキュメントを書く
  • 説明フィールドにトリガー条件ではなくスキルワークフローを要約する
  • 1つの優れた実行可能な例ではなく、多言語の例を作成する

よくある質問

なぜスキルを書く前にテストしなければならないですか?
エージェントが実際にどのように失敗するかを見なければ、スキルが何を教えられる必要があるかわかりません。まずテストすることで、あなたのスキルが対処すべき具体的な合理化とギャップが明らかになります。
私のスキルが単なる参照ガイドの場合はどうなりますか?
参考資料であってもテストが必要です。取得と適用のシナリオで、エージェントが情報を見つけて正しく適用できることを確認してください。
私のスキル説明が良いかどうかどうわかりますか?
テストしてください:説明は'使用条件...'で始まり、トリガー条件を列表していますか?ワークフローの要約を避けていますか?別のエージェントは関連する検索用語で見つけられますか?
'压力シナリオ'とは何ですか?
複数の压力を組み合わせたシナリオ:時間壓力(締め切り)、サンクコスト(すでに投資した努力)、権威壓力(人間のパートナーがスピードを望む)、および疲労(長いセッション)。
再テストせずにスキルを編集できますか?
いいえ。任何の変更は、同じシナリオで再テストして、変更が新しい抜け穴を導入したり既存のコンプライアンスを壊したりしていないことを確認する必要があります。
テストのサブエージェントサポートを得られない場合はどうなりますか?
学術的レビューのアプローチを使用してください:压力シナリオをシミュレートし、可能性のある合理化を特定し、明示的なカウンターを追加します。サブエージェントが利用可能になったらテストしてください。