arquiteto-de-empresa
작성자 alirezarezvaniarquiteto-de-empresa는 창업자의 비즈니스 아이디어를 frontmatter, cross-links, index.md, log.md가 포함된 version-controlled OKF Markdown bundle로 바꿔 줍니다. 전략, 시장, 재무, 제품, 운영, 법무, 거버넌스를 다루는 12단계 인터뷰도 포함합니다. templates와 함께 Python scaffold, linter, index scripts를 제공합니다.
이 skill은 84/100점으로, 창업자 인터뷰를 버전 관리 가능한 회사 지식 기반으로 전환하는 agent-led workflow를 원하는 디렉터리 사용자에게 충분히 추천할 만한 항목입니다. trigger guidance, phase structure, templates, references, scripts가 잘 갖춰져 있어 일반적인 사업계획 prompt보다 실질적인 활용도가 높습니다. 다만 설치 방식과 언어/명명 규칙에 대한 기대치는 더 명확하게 패키징될 필요가 있습니다.
- 트리거 가능성이 높습니다. frontmatter에 회사를 처음부터 설계하기, company-as-code, OKF bundles, AI-readable company wikis 같은 사용 사례가 명시되어 있습니다.
- 실무 활용도가 높습니다. 참조된 12단계 playbook은 모호한 business-advisor prompt에 기대지 않고, 각 단계별 목표, 질문, 생성 산출물, 업데이트 절차를 정의합니다.
- 에이전트 활용성이 좋습니다. OKF conformance rules, 통제된 type vocabulary, templates, example bundle, scaffolding·linting·index generation용 Python tools 덕분에 결과물을 더 구조화하고 재사용하기 쉽습니다.
- skill 디렉터리 안에 README나 install command가 없어, 사용자가 설치 방법을 더 넓은 repository/tooling 맥락에서 추론해야 합니다.
- 번들 구조는 포르투갈어 folder/file names를 사용하지만 skill 설명은 영어로 작동한다고 되어 있어, 도입 전에 naming-language 기대치를 명확히 할 필요가 있습니다.
arquiteto-de-empresa skill 개요
arquiteto-de-empresa의 용도
arquiteto-de-empresa는 창업자의 거친 비즈니스 아이디어를 OKF 번들로 전환하는 Company Architect skill입니다. OKF 번들은 YAML frontmatter, 타입이 지정된 개념, 상호 링크, index.md 대시보드, append-only 방식의 log.md를 갖춘, 버전 관리 가능한 Markdown 파일 트리입니다. 이 skill은 일회성 사업계획서를 만드는 대신 단계별 인터뷰를 진행하고, 사람과 AI 에이전트가 함께 읽을 수 있는 구조화된 지식으로 회사를 구체화합니다.
가장 잘 맞는 사용자와 의사결정
이 skill은 단순한 피치 내러티브가 아니라 살아 있는 회사 지식 베이스가 필요한 창업자, chief-of-staff 역할의 운영 담당자, venture studio, 컨설턴트, 전략기획팀에 잘 맞습니다. 초기 단계의 회사 설계, 비즈니스 모델 문서화, 운영체계 구축, “company as code” 워크플로에 적합합니다. arquiteto-de-empresa for Strategic Planning은 전략, 시장, 재무, 영업, 마케팅, 제품, 운영, 기술, 인사, 법무, 거버넌스 의사결정을 하나의 저장소 안에서 연결하고 싶을 때 특히 유용합니다.
이 skill이 다른 점
가장 큰 차별점은 구조입니다. 이 skill은 12단계 플레이북을 따르고, 한 번에 몇 가지 질문만 던지며, 통제된 type 어휘를 사용해 하나의 개념을 하나의 .md 파일로 작성합니다. 그 결과물을 Git에서 diff하기 쉽고, 검증·색인·재사용하기도 쉬워집니다. 포함된 reference와 Python 스크립트는 스캐폴딩, OKF 준수 여부 linting, index table 재생성을 지원합니다.
과도할 수 있는 경우
빠른 SWOT, 랜딩페이지용 브리프, 짧은 투자자 메모만 필요하다면 arquiteto-de-empresa skill을 설치하지 않는 편이 낫습니다. 이 방식은 의도적으로 체계적입니다. 단계별 질문에 답하고, 파일을 유지관리하며, 가정을 최종 진실이 아니라 초안 지식으로 다룰 준비가 되어 있을 때 가장 잘 작동합니다.
arquiteto-de-empresa skill 사용 방법
먼저 저장소를 설치하고 살펴보기
Claude skills 워크플로에서는 다음 명령으로 저장소에서 설치합니다.
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도 미리 살펴보는 것이 좋습니다.
완성도 있는 discovery prompt로 시작하기
좋은 arquiteto-de-empresa usage는 막연한 요청이 아니라 충분한 맥락에서 시작됩니다. “내 회사를 만들어줘”라고 하기보다 Phase 0 discovery에 필요한 초기 사실을 제공하세요.
- 회사 아이디어와 고객 문제
- 단계: idea, MVP, operating, scaling
- 비즈니스 모델: service, SaaS, marketplace, product, hybrid
- 산업, 국가, 법적 관할권
- 기존 이름, 자산, 제약 조건, 이미 알고 있는 가정
- 원하는 출력 위치, 예:
./my-company-okf
더 좋은 프롬프트 예시는 다음과 같습니다. “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 순서로 인터뷰하도록 설계되어 있습니다. 다음 단계로 넘어가기 전에 에이전트에게 한 단계를 완료하게 하고, 생성된 개념을 확인한 뒤, 루트 index.md를 업데이트하고 log.md에 내용을 추가하도록 요청하세요. 이렇게 해야 얕고 일관성 없는 결과를 줄이고, 전략적 의사결정의 추적 가능성을 유지할 수 있습니다.
품질 관리를 위해 helper script 사용하기
저장소에는 scripts/scaffold_bundle.py, scripts/okf_linter.py, scripts/index_generator.py가 포함되어 있습니다. 에이전트가 초안을 작성한 뒤 구현 보조 도구로 활용하세요. OKF 품질은 세부 사항에 크게 좌우되므로 linter가 중요합니다. 모든 개념은 별도의 Markdown 파일이어야 하고, frontmatter에는 유효한 type이 있어야 하며, 링크는 고립된 문서 묶음이 아니라 실제로 사용할 수 있는 그래프를 이뤄야 합니다.
arquiteto-de-empresa skill FAQ
arquiteto-de-empresa는 새 회사에만 쓰나요?
아닙니다. 처음부터 비즈니스를 만들 때 가장 강력하지만, 현재 전략, 프로세스, 도구, 재무, 조직 정보를 제공한다면 기존 회사도 문서화할 수 있습니다. 운영 중인 회사라면 번들이 현실을 목표처럼 다시 쓰지 않도록 “current state”, “target state”, [ASSUMPTION] 항목을 구분하라고 skill에 요청하세요.
일반적인 사업계획서 프롬프트보다 나은 점은 무엇인가요?
일반 프롬프트는 보기 좋지만 평면적인 문서를 반환하는 경우가 많습니다. arquiteto-de-empresa는 탐색 가능한 지식 시스템을 만듭니다. 타입이 지정된 Markdown 개념, 예약된 index, 의사결정 log, 상호 링크가 포함됩니다. 이후 에이전트가 회사 지식을 검색하거나, 전체를 다시 쓰지 않고 하나의 개념만 업데이트하거나, 시간이 지나며 의사결정이 어떻게 바뀌었는지 추적해야 한다면 이 차이가 중요합니다.
사용하기 전에 OKF를 알아야 하나요?
아니요. 다만 결과물을 신뢰하기 전에 OKF conformance reference는 읽어야 합니다. 핵심 규칙은 단순합니다. 파일 하나에 개념 하나, 유효한 type이 포함된 YAML frontmatter, 예약된 index.md와 log.md, 개념 간 상대 링크, 명확히 표시된 가정이 필요합니다. 초보자도 모든 파일을 한 번에 요구하지 않고 단계별 인터뷰를 따르면 이 skill을 잘 활용할 수 있습니다.
언제 이 skill을 쓰지 말아야 하나요?
구조보다 속도가 더 중요할 때, 비즈니스 정보가 너무 민감해 AI 환경에 공유하기 어렵거나, 법적 구속력이 있는 조언이 필요할 때는 이 skill을 건너뛰세요. 이 skill은 법무와 거버넌스 개념을 정리할 수는 있지만, 변호사, 회계사, 관할권별 컴플라이언스 검토를 대체하지는 않습니다.
arquiteto-de-empresa skill 개선 방법
파일 생성 전 arquiteto-de-empresa 입력 품질 높이기
품질을 가장 크게 좌우하는 요소는 입력의 구체성입니다. 예산 범위, 목표 고객, 지역, 창업자 역량, 현재 traction, 가격 가설, 영업 방식, 규제 리스크, 기술 선호도처럼 실제 제약 조건을 제공하세요. 모르는 것이 있다면 모른다고 말해야 합니다. skill의 [ASSUMPTION] 관례는 에이전트가 어떤 사실이 빠져 있는지 알아야 제대로 유용해집니다.
흔한 OKF 실패 유형 방지하기
여러 개념을 한 파일에 합친 경우, 누락된 type 값, 지나치게 일반적인 설명, 깨진 상대 링크, 시장 또는 재무 가정과 연결되지 않은 전략 주장을 주의하세요. 각 단계가 끝날 때마다 에이전트에게 conformance 점검을 요청하세요. “Check every generated concept against references/okf_conformance.md and references/type_vocabulary.md; list fixes before rewriting.”
의사결정 기준으로 단계별 결과 반복 개선하기
각 단계가 끝난 뒤 의사결정에 실제로 도움이 되는지 검토하세요. 좋은 foundation 단계는 목적, 문제, 가치, 가정을 명확히 해야 합니다. 좋은 finance 단계는 수익 모델, 비용 구조, unit economics, 가격, 전망을 드러내야 합니다. 좋은 operations 단계는 누군가 실제로 실행할 수 있는 프로세스와 runbook을 만들어야 합니다. 결과물이 마케팅 문구처럼 읽힌다면 더 분명한 tradeoff, 의존성, 채택하지 않은 대안을 요구하세요.
운영 모델에 맞게 skill 확장하기
조직에 맞게 arquiteto-de-empresa를 개선하려면 OKF의 기본 원칙을 깨지 않는 선에서 회사별 template, type vocabulary 확장, review checklist를 추가하세요. 예를 들어 규제 대상 헬스케어 스타트업은 컴플라이언스 증거 필드를 추가할 수 있고, venture studio는 investment committee status를 넣을 수 있으며, SaaS 팀은 PRD를 roadmap 및 architecture 파일과 연결할 수 있습니다. 확장은 명시적으로 유지해야 향후 에이전트가 숨은 관례 없이도 번들을 이해할 수 있습니다.
