ccf-common

CCF Common

Family File Contract

作業を始める前に、タスク／成果物ごとに正規の出力先と、安定した作業ディレクトリを1つずつ決定します。明示されている、または確立済みのタスクパスがあれば再利用します。それ以外の場合は、必要に応じて source/、assets/、cache/、build/ を使い、プロジェクトルートの ccfa-workfiles/<purpose>/<artifact-id>/ を使用します。現在のファイルはその場で更新し、中間ファイルを散在させたり、反復用のコピーを作成したりしないでください。入力と必要な証拠を保持し、このタスクで作成したことが確認済みの不要ファイルのみを削除します。テキストの入出力には UTF-8 を使用し、保存後またはレンダリング後に中国語のテキストがないか確認します。ファイルを扱う場合は artifact-contracts.md を適用し、スキル間の移行でも同じパスを再利用します。

Collaboration Contract

これらの共通制御を適用する前に、ベースラインがすでに有効になっている場合を除き、ccf-humanization を有効にします。このエントリは1回だけ適用してから、専門作業を続けます。どちらの事前確認も再帰的に行わないでください。適用可能なルールは、すべての担当者間で再利用します。

統合担当者を1名に定め、前提条件の不足を解消したり、重要な所見を確認したりするために、他のスキルを積極的に活用します。適用可能な証拠を再利用し、トークンを節約するために必要な下準備を省略しないでください。最終確定の前に、各担当者の成果を統合し、影響を受ける結果を検証します。条件に応じて cooperation routes に従い、無関係な段階や重複する報告は避けてください。

Core Rule

これは、ccf-humanization の後、すべての CCFA 専門スキルの前に有効化される共通制御モジュールです。タスクの範囲、統合担当者、関連する前提条件、証拠の境界、ファイルパスを設定し、専門スキルが調査成果物を作成できるようにします。これらの制御を適用しても、メンテナンスワークフローは実行されず、ガバナンス報告も必要ありません。

Invocation Controls

CCFA Handoff Mode: PARTIAL (Recommended). metadata.ccf_skill_controls.handoff_question_mode と references/handoff-modes.md に従います。直接呼び出す場合は、これらの制御を適用する前に Humanization のベースラインが読み込まれていることを確認します。どちらの事前確認も再帰的にやり直さないでください。適用可能なルールは担当者間で再利用し、現在の判断に必要な共通リファレンスのみを読みます。

ファミリーの事前確認

要求された成果、対象範囲と権限、統合を担当するオーナー、不足している前提条件や再利用可能な前提条件を確認します。共同作業には references/routing.md を、引き継ぎには references/handoff-modes.md を使用します。ソースや非公開の資料を扱う際は証拠・プライバシーのルールを、ファイル作業の前には成果物のルールを、評価の際にはレビュー基準を適用します。読み込み済みのルールと既知のパスを再利用し、このスキルを有効にするためだけに受付フォームや状態ファイルを作成しないでください。適用される制御を確立したら、専門タスクを続行します。以下のメンテナンスワークフローは、実際にファミリーのメンテナンスを依頼された場合に限り使用します。

検出メタデータや名前付きの事前確認が、その指示を読んだ証拠になるわけではありません。表示されているエントリー内容を適用し、関連セクションが欠落または途中で切れている場合は、対象を絞って読み直してください。報告されたトリガーの失敗を診断する際は、インストール済みバージョン、実際に読み取られたツール、選択されたモード、結果としての動作を区別してください。読み込みの受領記録を捏造してはいけません。通常のタスクでは、開始時の報告や永続的なトレースは不要です。

このスキルの scripts/preferences.py resolve を使って設定を一度だけ確認し、プロジェクトが判明している場合は --project <established-root> を追加します。引き継ぎ時には簡潔な結果を再利用してください。ファイルがなければ、書き込みも質問もせず、デフォルトを適用します。現在の明示的な指示は、プロジェクト、ユーザー、組み込みのデフォルトより優先されます。これらの選択が適用されるのは、任意の追加作業のみです。必要なチェックと事前確認は引き続き有効です。機能強化のトリガー、初回の選択、設定変更、またはリゾルバーの欠落・エラーに該当する場合に限り、preferences.md の関連セクションだけを読みます。ガイド全体を読み込んだり、タスクのたびにウェブページを開いたりしないでください。

現在のユーザーの目標、妥当な進め方、次のアクションをそれぞれ明確に区別してください。タスクで探索が必要な場合は、異なる仕組みを調べます。実行中は、重要な理由がない限り、選択した進め方を維持してください。提案された作業、実行済みの作業、検証済みの作業を区別します。コンテキストを失った後や、同じ方向への逸脱を繰り返した後は、実際の成果物を照合し、成果物の基準を下げずに範囲を限定した次の一歩を取ります。作業を繰り返す場合は、新たな観察、変更された仮説、または具体的な修正が必要です。長期にわたるタスク、進捗の停滞、または重大な復旧作業では、continuity.md を読み込みます。短いタスクでは、追加ファイルやレビューの呼び出しは不要です。

自律的な調査や実験の反復を明示的に依頼された場合は、オーケストレーターのリサーチループに進みます。このループでは、タスクの実験範囲と予算を使用し、任意のメンテナンス候補の上限は使用しません。通常の文章作成、コンセプトのレビュー、計画立案では、実験を開始しません。

共有コントロール

現在の事前確認の判断またはメンテナンスタスクに必要な参照のみを読み込みます。

• references/routing.md：リクエストを担当する CCFA スキルを特定し、トリガーの重複を避けるために使用します。
• references/task-modes.md：探索的／クイック／標準の深度、認可を考慮した継続、コンテキストの選択、ホストがサポートする並列作業、GPT-6 への適応に使用します。
• references/review-output-standards.md：数値スコアリング、複数レビューアーのパネル、スコア変更の条件、目に見える出力品質の一貫性を保つために使用します。
• references/handoff-modes.md：metadata.ccf_skill_controls.handoff_question_mode の解釈に使用します。
• references/preferences.md：記憶された任意の拡張機能、優先順位、3 言語対応のローカル設定ページを確認します。必須の事前確認と必要なチェックは引き続き有効です。
• references/continuity.md：ルーティング変更や復旧時にタスクの意図を保つために使用します。コンパクトな状態を維持し、必要な場合にのみ任意の記録検証を行います。
• references/privacy-and-evidence.md：原稿、査読、反論、非公開ドラフト、文献検索、根拠に関する主張を扱う際に使用します。
• references/source-registry.yaml：会場の規定、査読方法、模範記録、研究ワークフローの参照先に関する共有ソース一覧として使用します。
• references/ccf-a-venue-map.md：非執筆スキルが ccf-paper-writer に依存せずに会場ファミリーのマッピングを行う際に使用します。
• references/skill-trigger-registry.yaml：正規のトリガー登録簿として使用します。説明とエージェントプロンプトを同じ担当範囲に照らして比較します。
• references/artifact-contracts.md：スキルがファイルを作成または改訂する際に使用します。担当範囲、正規のパス、中間ファイルの生成を最小限に抑えること、既定の上書き動作、タスク単位のクリーンアップ、保持が必要な履歴を定めています。
• references/ccfa-yaml-contract.md：共有 ccfa.yaml プロジェクト状態スキーマに使用します。

メンテナンスのワークフロー

1. デフォルトよりも、現在のユーザーのスコープと既存の認可を優先してください。新しいファイルを作成しないメンテナンスでは、既存の箇所のみを編集してください。CCFA ファミリーのスキルを編集する場合は、metadata.ccf_skill_controls ブロックを保持し、そのキーを references/handoff-modes.md と一致させてください。
2. トリガーとなる表現を新たに追加する前に references/routing.md を確認し、担当範囲の重複を防いでください。
3. チェックリストの厳格さ、簡易的な仕上げ、標準レビュー、または出力契約を変更する前に references/task-modes.md を確認してください。
4. スコアカード、レビューパネル、スコアリスクに関する表現、または最終出力のセルフチェック規則を変更する前に references/review-output-standards.md を確認してください。
5. ブラウジング、引用、新規性、スコアリング、実験結果、圧縮、または反論に関する指示を追加する前に references/privacy-and-evidence.md を確認してください。
6. 生成ファイル名、改訂の扱い、レポートフォルダー、キャッシュ、試行アーカイブ、または台帳を変更する前に references/artifact-contracts.md を確認してください。成果物ごとに正規の成果物を1つ、タスク／成果物ごとに安定した作業ディレクトリを1つとし、納品前にタスクで作成した破棄可能なファイルを削除することを基本としてください。必要な証拠と他のタスクのファイルは保持してください。
7. 個人の絶対パス、ユーザー名、展開されたホームディレクトリ、非公開のローカルスキルのルート、またはマシン固有のコマンド例は決してコミットしないでください。$CODEX_HOME、$HOME、リポジトリ相対パス、または個人を特定しないプレースホルダーを使用してください。
8. 新しい公開ソースは references/source-registry.yaml に追加してください。兄弟関係にある source-notes.md ファイルに長い URL の一覧を重複して記載しないでください。ローカル参照には、マシンのパスではなく、リポジトリ相対または個人を特定しない local:／repo: 識別子を使用してください。
9. ソースレジストリを編集した後は scripts/check_sources.py を実行してください。このスクリプトは問題を報告するだけで、レジストリファイルを書き換えてはいけません。
10. ファミリーメタデータ、レジストリ、スクリプト構文、参照リソース、および回帰チェックには scripts/check_v04.py を実行してください。その後、ドキュメント、例、ソース記録、スクリプト、図、またはリリースファイルに変更を加える CCFA ファミリーの変更を確定する前に、scripts/check_path_privacy.py を実行してください。

出力契約

通常の事前確認では、別途レポートを出さずにスペシャリストへ制御を戻してください。CCFA スキルを監査または更新する場合は、次のように報告してください。

Routing impact:
Handoff mode impact:
Private-material safety:
Source-registry changes:
Score-risk language changes:
Validation result: