arquiteto-de-empresa
作者 alirezarezvaniarquiteto-de-empresa 可将创始人的商业想法转化为可版本控制的 OKF Markdown bundle，包含 frontmatter、交叉链接、index.md、log.md，以及覆盖战略、市场、财务、产品、运营、法律和治理的 12 阶段访谈流程。还提供模板，以及用于 scaffold、linter 和 index 的 Python 脚本。
该技能评分为 84/100。对于希望通过 agent 引导式流程，把创始人访谈转化为可版本管理的公司知识库的目录用户来说，这是一个扎实的候选条目。它提供了足够的触发指引、阶段结构、模板、参考资料和脚本，相比通用商业规划提示词能带来明显更多杠杆；不过安装方式以及语言/命名预期还需要更清晰的打包说明。
- 触发意图清晰：frontmatter 明确列出从零创建公司、company-as-code、OKF bundles、AI-readable company wikis 等使用场景。
- 执行层面扎实：引用的 12 阶段 playbook 为每个阶段定义了目标、问题、生成产物和更新步骤，而不是停留在笼统的商业顾问式提示词。
- 对 agent 友好：OKF 合规规则、受控类型词汇表、模板、示例 bundle，以及用于 scaffolding、linting 和 index 生成的 Python 工具，让输出更结构化，也更便于复用。
- 技能目录中没有 README 或安装命令，用户需要根据更大的仓库/工具链自行推断安装方式。
- bundle 结构使用葡萄牙语文件夹/文件名，而技能描述称其以英语运行；采用前应先明确命名语言方面的预期。
arquiteto-de-empresa skill 概览
arquiteto-de-empresa 适合用来做什么
arquiteto-de-empresa 是一个 Company Architect skill，用于把创始人尚未成型的商业想法转化为 OKF bundle：一棵可版本控制的 Markdown 文件树，包含 YAML frontmatter、类型化概念、交叉链接、index.md 仪表盘，以及只追加不改写的 log.md。它不是一次性生成一份商业计划书，而是通过分阶段访谈，把公司建模为人类和 AI agent 都能读取的结构化知识。
最适合的用户与决策场景
这个 skill 最适合创始人、chief-of-staff 类型的运营负责人、venture studio、咨询顾问和战略规划团队使用——尤其是当你需要的是一个持续演进的公司知识库，而不只是融资叙事或 pitch 文案。它适用于早期公司设计、商业模式文档化、运营系统搭建，以及 “company as code” 工作流。arquiteto-de-empresa for Strategic Planning 尤其适合把战略、市场、财务、销售、营销、产品、运营、技术、人才、法律和治理等决策连接到同一个 repository 中。
这个 skill 的差异点
核心差异在于结构化程度。该 skill 遵循 12 个阶段的 playbook，每次只提出少量问题，并使用受控的 type 词表，将每个概念写入单独的 .md 文件。这样生成的内容更容易在 Git 中 diff、校验、索引，并被其他 agent 复用。随附的 reference 和 Python scripts 也支持脚手架生成、OKF 合规检查，以及重新生成索引表。
什么时候可能过于复杂
如果你只需要一个快速 SWOT、landing page brief，或一份简短的投资人 memo，就不建议安装 arquiteto-de-empresa skill。它的方法有意设计得比较系统化。只有当你愿意按阶段回答问题、维护文件，并把假设视为仍在迭代的草稿知识，而不是最终真相时，它才能发挥最大价值。
如何使用 arquiteto-de-empresa skill
先安装并检查 repository
在 Claude skills 工作流中，可以用以下命令从 repository 安装：
npx skills add alirezarezvani/claude-skills --skill arquiteto-de-empresa
如果你的工具不支持这个命令，可以从 c-level-advisor/arquiteto-de-empresa/skills/arquiteto-de-empresa 复制或引用该 skill 文件夹。正式使用前，先阅读 SKILL.md，再看 references/phase_playbook.md、references/okf_conformance.md 和 references/type_vocabulary.md。同时预览 assets/frontmatter_template.md、assets/index_template.md 和 assets/log_template.md，以便理解 agent 需要遵守的文件契约。
从完整的 discovery prompt 开始
好的 arquiteto-de-empresa usage 应该从上下文开始，而不是只给一个含糊请求。不要只说“帮我搭建公司”，而是提供 Phase 0 discovery 所需的初始事实：
- 公司想法与客户问题
- 阶段：idea、MVP、operating 或 scaling
- 商业模式：service、SaaS、marketplace、product、hybrid
- 行业、国家和法律管辖区
- 现有名称、资产、限制条件和已知假设
- 期望输出位置，例如
./my-company-okf
更好的 prompt 示例是：“Use arquiteto-de-empresa to create an OKF bundle for a B2B SaaS in Brazil that helps clinics reduce no-shows. We are at MVP stage, have no legal entity yet, and want files suitable for Git. Run Phase 0 first, ask only the necessary questions, mark unknowns as [ASSUMPTION], then scaffold the bundle.”
按 12 个阶段推进，而不是一次性倾倒内容
这个 skill 设计为按顺序访谈：discovery、foundation、strategy、market、finance、sales、marketing、product、operations、tech、people、legal 和 governance。建议要求 agent 完成一个阶段后，先确认生成的概念，更新根目录 index.md，并追加 log.md，再进入下一阶段。这样可以避免输出浅薄、前后不一致，也能让战略决策保持可追踪。
用辅助 scripts 做质量控制
repository 中包含 scripts/scaffold_bundle.py、scripts/okf_linter.py 和 scripts/index_generator.py。在 agent 起草内容后，可以把它们作为实现辅助工具使用。linter 很重要，因为 OKF 质量取决于细节：每个概念都应是单独的 Markdown 文件，frontmatter 应包含有效的 type，链接也应形成可用的知识图谱，而不是一堆彼此孤立的文档。
arquiteto-de-empresa skill 常见问题
arquiteto-de-empresa 只适合新公司吗？
不是。它最擅长从零创建一家公司，但如果你提供现有战略、流程、工具、财务和组织信息，它也可以用来文档化一家已经在运营的公司。对于运营中的公司，应要求该 skill 区分 “current state”、“target state” 和 [ASSUMPTION] 项，避免 bundle 把愿景写成现实。
它和普通商业计划 prompt 相比好在哪里？
普通 prompt 往往会返回一份打磨得不错但结构扁平的文档。arquiteto-de-empresa 生成的是一个可导航的知识系统：类型化的 Markdown 概念、保留索引、决策日志和交叉链接。如果你希望未来的 agent 能检索公司知识、只更新某个概念而不重写全部内容，或者跟踪决策如何随时间变化，这一点就很关键。
使用前需要了解 OKF 吗？
不需要，但在信任输出之前，你应该阅读 OKF conformance reference。核心规则并不复杂：每个文件一个概念，YAML frontmatter 中包含有效的 type，保留 index.md 和 log.md，概念之间使用相对链接，并且清楚标记假设。即使是初学者，只要按阶段访谈推进，而不是一次性要求生成所有文件，也能很好地使用这个 skill。
什么时候不应该使用这个 skill？
当速度比结构更重要、业务信息过于机密不适合放入 AI 环境，或你需要具有法律效力的建议时，应跳过这个 skill。它可以组织法律和治理相关概念，但不能替代律师、会计师或针对具体司法辖区的合规审查。
如何改进 arquiteto-de-empresa skill
在生成文件前先改进 arquiteto-de-empresa 输入
影响质量最大的杠杆是输入的具体程度。请提供真实限制条件：预算范围、目标客户、地域、创始人能力、当前 traction、定价假设、销售方式、监管风险和技术偏好。如果某些信息未知，就明确说明。只有当 agent 知道哪些事实缺失时，skill 的 [ASSUMPTION] 约定才真正有用。
避免常见 OKF 失败模式
留意这些问题：一个文件混合多个概念、缺少 type 值、描述过于泛泛、相对链接失效，以及战略判断没有连接到市场或财务假设。可以要求 agent 在每个阶段后做一次合规检查：“Check every generated concept against references/okf_conformance.md and references/type_vocabulary.md; list fixes before rewriting.”
用决策标准迭代各阶段输出
每个阶段结束后，都要从“是否有助于决策”的角度审查输出。好的 foundation 阶段应澄清目标、问题、价值观和假设。好的 finance 阶段应展开收入模型、成本结构、unit economics、定价和预测。好的 operations 阶段应产出他人可以实际执行的流程和 runbook。如果输出读起来像营销文案，就要求它给出更清晰的取舍、依赖关系和被否决的备选方案。
按你的运营模型扩展 skill
要让 arquiteto-de-empresa 更适合你的组织，可以添加公司专属模板、扩展 type vocabulary，或加入 review checklist，但不要破坏 OKF 的基础规则。比如，受监管的医疗健康创业公司可以增加合规证据字段；venture studio 可以加入 investment committee status；SaaS 团队可以把 PRD 链接到 roadmap 和 architecture files。扩展应保持显式，方便未来的 agent 在没有隐藏约定的情况下理解整个 bundle。