arquiteto-de-empresa
作者 alirezarezvaniarquiteto-de-empresa 是一個 Company Architect skill，可將創辦人的輸入轉成 OKF 公司知識庫：包含帶有 YAML frontmatter 的互相關聯 Markdown files、indexes、logs，以及受控類型。適合用於 Strategic Planning、company-as-code 工作流程，以及分階段訪談，涵蓋策略、市場、財務、產品、營運、人才、法務與治理。
此 skill 評分為 82/100，對於想用 agent 引導公司建立與文件化、並產出結構化 markdown 知識包的目錄使用者來說，是相當穩健的上架候選。這個 repository 提供足夠的觸發指引、分階段工作流程、範本、一致性規則與輔助 scripts；相較一般商業規劃 prompt，更能降低摸索成本。不過，如果能補上更清楚的安裝與快速開始文件，採用門檻會更低。
- 觸發條件很明確：frontmatter 清楚說明適用於建立、架構化或記錄整間公司，並包含「company as code」、「company knowledge base for AI」、「OKF」與「knowledge bundle」等語句。
- 流程具備可操作性：skill 定義了連續 12 階段訪談，phase playbook 也列出目標、問題區塊、產出檔案，以及 index.md 和 log.md 的更新步驟。
- 不只是一段提示詞，對 agent 的支援更完整：references 定義 OKF 一致性規則與受控類型詞彙，scripts 則支援 scaffolding、linting 與索引產生，方便建立可版本控管的 markdown bundle。
- skill 路徑中沒有安裝指令或 README，因此使用者必須從較大的 repository 或 Agent Skills 慣例推斷安裝方式。
- 這套流程企圖心強、涵蓋整個企業；如果使用者只需要聚焦財務、法務或 GTM 的顧問，12 階段 OKF bundle 的做法可能比必要的更重。
arquiteto-de-empresa skill 概覽
arquiteto-de-empresa 的用途
arquiteto-de-empresa 是一個 Company Architect skill，能把創辦人還很粗略的商業想法，轉成一組 OKF bundle：這是一棵可版本控管的 Markdown 檔案樹，包含 YAML frontmatter、具型別的概念、交叉連結、index.md 儀表板，以及只能追加內容的 log.md。arquiteto-de-empresa skill 特別適合創辦人、營運負責人、顧問，以及策略規劃團隊；他們需要一套公司知識庫，讓人類與 AI agents 都能不經轉譯直接讀懂。
最適合的使用情境與使用者
當你需要把一家公司「as code」建立或重整時，就適合使用 arquiteto-de-empresa skill：策略、市場、財務、銷售、行銷、產品、營運、技術、人才、法務與治理，都放在同一個相互連結的結構中。它適合早期創業設計、商業模式文件化、公司內部 wiki、AI 可讀的營運系統，以及用於 Strategic Planning 的 arquiteto-de-empresa；尤其是那些決策必須能隨時間追溯的情境。
它和一般 prompt 有什麼不同
一般 prompt 可能會產出一份很長的商業計畫書。這個 skill 則會引導分階段訪談，並把答案具體生成為檔案：每個 .md 對應一個概念、受控的 type 值、相對連結、保留用途的 index.md 與 log.md，以及可預期執行結果的 helper scripts。它的關鍵差異不只是提供商業建議，而是一套可重複使用的文件格式；這套格式可以被 lint、建立索引、提交到 Git，並由其他 agents 繼續擴充。
採用前需要考量的事
當你願意逐階段回答問題時，這個 skill 的效果最好。若你要的是一頁式 pitch deck、法律意見、財務保證，或是不需要創辦人輸入就完成的公司策略，它就不太適合。部分資料夾與檔名帶有葡萄牙語風格，而 skill 語言是英文，因此團隊應及早決定要保留原始結構，還是將命名慣例在地化。
如何使用 arquiteto-de-empresa skill
arquiteto-de-empresa 安裝與 repository 檢查
使用以下指令安裝：
npx skills add alirezarezvani/claude-skills --skill arquiteto-de-empresa
接著檢視原始路徑：
c-level-advisor/skills/arquiteto-de-empresa
先閱讀 SKILL.md，了解 persona、觸發條件、操作規則與 12 階段流程。接著查看 references/phase_playbook.md、references/okf_conformance.md 與 references/type_vocabulary.md；這些檔案定義 agent 應該問什麼、Markdown bundle 必須長成什麼樣子，以及哪些 frontmatter type 值是有效的。在正式產生公司檔案之前，先預覽 assets/frontmatter_template.md、assets/index_template.md 與 assets/log_template.md。
能產出更好結果的輸入內容
arquiteto-de-empresa 的使用模式，在第一個請求就提供足夠商業脈絡以啟動 Phase 0 時效果最好。請包含公司階段、商業模式、產業、司法管轄區、客戶、目前資產，以及期望輸出位置。
較弱的 prompt：
「Help me structure my startup.」
較好的 prompt：
「Use arquiteto-de-empresa to create an OKF bundle for a B2B SaaS in Brazil that helps small clinics reduce missed appointments. Stage: MVP with 5 pilot customers. Model: monthly subscription. Need the first phases only: discovery, foundation, strategy, and market. Ask me questions in small blocks, mark unknowns as [ASSUMPTION], and generate conformant Markdown files with relative links.」
這樣能改善結果，因為 skill 可以選擇正確階段、避免過早展開細節，並建立符合 OKF 規則的檔案。
建立完整 OKF bundle 的建議工作流程
從 Phase 0 discovery 開始，然後依序走完整個 12 階段 playbook。每個階段都先問 3–5 個問題、確認創辦人的回答、產生概念檔、更新資料夾中的 index.md，並在 log.md 新增一筆決策紀錄。除非你只需要粗略原型，否則不要要求 agent 一次傾倒所有階段；這個 skill 的設計目標，是透過先訪談再寫作來降低策略幻覺。
用於策略規劃時，請依決策順序推進各階段：foundation、strategy、market、financial model、sales、marketing、product、operations、tech、people、legal 與 governance。尚未解決的主張要用 [ASSUMPTION] 保持可見，讓 bundle 成為一套規劃系統，而不是製造虛假確定性的工具。
使用 helper scripts
這個 repository 內含 Python 工具，可讓輸出更可靠。使用 scripts/scaffold_bundle.py 建立骨架、使用 scripts/okf_linter.py 檢查一致性，並用 scripts/index_generator.py 重新產生 index.md 中的概念表格。這些 scripts 以 standard-library 為導向，支援 Git 工作流程：generate、review diffs、lint，然後 commit。即使你的 agent 是手動建立檔案，在把 bundle 視為正式版本之前，仍應先執行 linter。
arquiteto-de-empresa skill 常見問題
arquiteto-de-empresa 只適用於新公司嗎？
不是。它的框架是從零開始建立公司，但也能用來文件化既有公司，特別是當公司知識分散在文件、試算表、聊天紀錄與創辦人記憶之中時。對已營運的公司來說，請先告訴 agent 目前已經存在什麼，並要求它分別標記既有事實、假設與缺少證據的部分。
這和 business plan generator 有什麼不同？
business plan generator 通常會產出一份敘事型文件。arquiteto-de-empresa skill 產出的是 OKF knowledge graph：大量小型 Markdown 概念檔，並具備一致的 metadata 與連結。因此它更適合長期維護、AI retrieval、Git diffs，以及跨職能規劃。如果你只需要一份修飾精美、面向投資人的 PDF，它就沒那麼方便。
初學者需要先理解 OKF 嗎？
不需要，但應該先理解它的運作概念：每個概念一個檔案、具型別的 frontmatter、相關檔案之間的連結，以及一份決策紀錄。在大量使用之前先閱讀 references/okf_conformance.md，可以避免常見錯誤，例如把多個概念合併到同一個檔案，或使用不一致的 type 標籤。
什麼時候不該使用這個 skill？
不要把它當成法律、稅務、會計，或受監管產業專業審查的替代品。若團隊無法回答基本 discovery 問題、目標只是品牌文案，或你需要在沒有安全執行環境的情況下處理機密財務模型，也應避免使用。這個 skill 會結構化決策；它本身不會驗證市場真相。
如何改善 arquiteto-de-empresa skill
用更完整的脈絡改善 arquiteto-de-empresa 結果
最有槓桿效果的改善方式，是提升輸入品質。提供真實限制條件：預算、runway、地理範圍、目標客戶、銷售動作、定價假設、團隊產能、技術堆疊、法規曝險，以及既有文件。要求 agent 在每個概念檔中區分「known」、「assumed」與「to validate」區塊。這會讓 OKF bundle 更適合策略規劃，而不只是描述性文件。
常見失敗模式與檢查重點
請留意檔案過度壓縮、缺少 frontmatter、無效的 type 值、相對連結薄弱，以及 index.md 頁面沒有反映實際資料夾內容。另一個常見問題，是在創辦人尚未提供證據時，產生過度自信的商業語氣。請要求使用 [ASSUMPTION] 標記，並在重大決策變更時更新 log.md。
第一版 bundle 產生後要持續迭代
第一版完成後，請像檢視產品 backlog 一樣審閱這組 bundle。問自己：哪些概念太大？哪些主張缺少證據？哪些決策需要替代方案與理由？哪些連結能幫助未來的 agent 從策略一路導覽到財務、產品或營運？接著要求 skill 拆分過大的檔案、補上缺少的概念連結、重新產生 indexes，並把變更記錄到 decision log。
依組織需求擴充這個 skill
團隊可以透過加入公司專用 templates、司法管轄區 checklists、產業詞彙與 validation gates，來改善 arquiteto-de-empresa。請維持核心 OKF 規則穩定：每個檔案一個概念、必填 type、相對連結、保留用途的 index.md 與 log.md，以及以 script 為基礎的檢查。如果你將資料夾名稱在地化，或新增概念型別，請更新 references/type_vocabulary.md，讓未來的 agents 能保持一致。