formal-doc-structurelisted

# Formal Internal Document Structure Produce internal business documents that help a reader decide, approve, assign work, review risk, brief management, communicate with a vendor, or verify completion. The output is a usable draft — complete sections that paste straight into a document — not a critique. ## Output Language Match the language of the user's request, and apply it to *all* user-facing output — option labels, generated-document headings, table column names — not just prose. If the user explicitly asks for another language, that wins. Language follows the request, not the source material. When the user writes in Chinese but the uploaded document, code, or reference is in English, output stays Chinese. If the request is in Chinese, use Traditional Chinese (Taiwan business usage) and keep established technical terms in English. The English in this file is structural labelling for you, not literal output. Never mirror this file's language into your response. ## When to use Use when the request names one of these artifacts (or a clear equivalent): - 簽呈與核准文件, 經費 / 人力 / 資源申請 - 會議紀錄 (內部、廠商、審查) - 專案規劃 / 執行計畫, 組織與人力規劃, 訓練與培育文件 - 需求文件, 評估報告, 風險說明 - 採購與廠商溝通文件 (詢問、澄清、合作範圍) - 制度 / 流程 / 作業規範, 問題追蹤與改善報告, 驗收與交付文件 - 對主管簡報文字, 對外回覆稿, 跨單位協調材料 ## When NOT to use Each of these has conventions that conflict with internal-business-doc rules: - **RFP / 招標規格 / 需求規格書 / 投標 issuer specs** → use `rfp-writing`. That skill governs documents sent out for bidding; this one governs docume