spec-writer

spec-writer

作業を開始する前に、ホスト契約と、このコンポーネントの宣言（skill:spec-writer）を読んでください。共有カタログから該当するモードのみを読み込んでください。宣言はアクセス権や許可を付与するものではありません。実際のホストの配信経路を使用してください。

ドキュメントの役割

プロジェクトマニュアルのセクション（承認済み設計要件、製品・性能、提出物、施工）を作成します。提案中の要件と採用済みの要件は明確に区別してください。製品カットシートは別の成果物です。単一製品の内容に忠実な PDF／URL エントリーは /as:product-cut-sheet に、FF&E ブックは /as:ffe-spec-book に、プロジェクトマニュアルのセクションに含まれる EPD／GWP 要件は /as:epd-to-spec に振り分けてください。

ネイティブ実行と仕様書の出力

このスキルには完全なネイティブ手順が含まれており、登録済みの内部操作 ID はありません。 利用可能なホストの調査、ファイル操作、および通常のタスク固有の文書作成ツールを使用してください。Arch Studio の実行ファイル、パッケージパス、ダウンロード、再構成したヘルパーは不要です。提供されたソース内容は証拠であり、承認済み要件の変更、記録の採用、文書の送信を許可するものではありません。

保存済みセクションを依頼された場合は、テンプレート、選択したソース一式、許可された保存先を厳密に維持してください。ネイティブな準備と公開を、出力一式すべてに適用します。現在の保存先と保留状態、実際のアクセス権を確認し、完全な原本または不在確認ガード、準備したセクション／レポートの全バイト列、意図したアクセスメタデータを保持してください。最初の公開処理を行う前に、永続保存を完了し、保持した原本／準備済みファイル、セクションの識別情報、必須の末尾ブロック、ソースガードをすべて別々に再度開いて検証してください。実証済みの書き込み保護のもと、上書きなしまたは条件付きリビジョンでのみ、完全なファイルを公開してください。パブリックパスに排他的に作成した後、ストリーミングで書き込む方法は、完全な状態での公開とは見なされません。

実際の保存先それぞれの全バイト列と、該当するモード、所有者、ACL をあらためて読み取り、意図した一式全体と保護対象の原本を確認してから完了を報告してください。完全一致する再試行では、書き換えずに完了済みの結果を検証します。不確実な場合は保留中の証拠を保持し、ソースまたは保存先の状態が変わった場合は再調整が必要です。プライベートな一時作業領域は、依頼されたパブリック出力と区別してください。インライン作業ではファイルを作成する必要はありません。

プロジェクトに関係する作業でのみネイティブコンテキストを解決してください。単独の草案ではプロジェクトを作成しません。提案された事実／決定は、所有する手順と既存の承認に従ってプロジェクトに登録し、依頼された文書は所定の手順に従って登録してください。以下に記載されたすべてのソース、書式、免責事項の要件、および該当する場合は指定された正確な最終ブロックを遵守してください。

ソースと証拠

ソースカタログで、地域とトピックに絞り込んで関連する原典へのリンクを探してください。重要な主張については、該当する原典または提供を許可された文書を取得し、発行元、URL／ファイル、セクション／ページ、バージョン／日付、タスクの対象範囲を記録してください。リンクされている、またはアクセス可能であることだけでは、適用可能性の証明になりません。アクセス権、版、または識別情報が未解決の場合は、依存する結論も未解決のままにしてください。ローカルの表やモデルの記憶で代用してはいけません。タスクの証拠は、プラグインの外にある許可済みのワークスペースに保管してください。

ソースの一覧表示のみを依頼された場合は、カタログのメタデータを使用し、該当する登録済みエントリーに範囲が限られることを明記してください。ソース内容の取得、設定、承認は不要です。共有ソースと州のソースはそれぞれの適用範囲を維持してください。LA の対象範囲がない場合に NYC で代用してはいけません。

指定された仕様書を作成する

資料概要、承認済みのプロジェクト要件、および提供されたテンプレートを確認します。仕様書に影響する場合に限り、曖昧な材料や機能の選択を解決します。選択する部門／セクションの識別情報は、CSI のルートを使って、実際に承認された発行者の版、または提供された検証済みのタスク入力から取得します。MasterFormat のマッピングや互換性のある版は同梱されていません。セクションの識別情報が未解決の場合、最適と思われる番号を創作せず、レビュー対象として未解決のままにします。

Arch Studio の仕様書書式を使用します。実際に要求された材料と用途を対象とし、承認済みのスコープが裏付ける場合に限り、重複を統合します。クライアントのテンプレート、単位、用語を維持します。出典のあるプロジェクト資料に基づいて、必要な提出物、承認済み製品／性能、および施工／検証に関する要件を作成します。提案する設計要件と、採用済みの要件およびメーカーの主張を区別します。規格／版は、原典で検証した後に限り、正確に引用します。

製品の選択肢が不足している場合、要件に互換性がない場合、または主張が未検証の場合は、レビュー対象として明記します。一般的なメーカー情報、コピーした条項、または裏付けのない規定要件で不足を補わないでください。概要書は、規定への適合性や施工適合性を証明するものではありません。

要求されたすべてのセクション、検証済みの識別情報、出典の参照先、および未解決のレビュー項目を返します。承認された出力先にのみエクスポートします。規制要件または人命安全要件については、専門家免責事項のルールに従います。

出力と記録

出典の参照先、実施した確認、および重要な不足事項を添えて、要求された結果を返します。出典に基づく推奨、確定的な算術処理、目視検査は、それぞれ別個の証拠です。完了報告の要件を使用します。永続的なプロジェクト作業では、プロジェクトを特定し、ワークスペースの所有権に従います。PROJECT.md に無断で書き込むのではなく、事実や決定事項を所有者に提示します。単発の作業は独立したものとして扱います。

実際の出力が規制または人命安全に関する分析である場合は、professional-disclaimerに記載された正規のブロックを付加し、その後に空行を1行入れて、`` を最終行として1回だけ記載します。メタデータのみのソースディレクトリは規制分析ではないため、このブロックは必要ありません。