jumibot/문서_창립

창립 문서

창립 문서는 프로젝트 또는 제품군을 공식적이고 간결하게 소개합니다: 어떤 필요를 충족하는지, 왜 개발할 가치가 있는지, 무엇인지, 어떤 상황에서 가치를 제공하는지, 무엇이 이를 뒷받침하며, 무엇을 입증해야 하는지를 설명합니다. 이것이 프로젝트의 참조 설명서입니다.

비전 문서(documento_vision 스킬)와 세 가지 차이점이 있습니다:

• 서사 없음. 사례, 장면 또는 프롤로그가 없습니다. 서류철처럼 정리된 설명입니다.
• 더 공식적. 도메인의 모든 진술에는 참조가 있으며, 게시된 내용, 설계 목표, 계산 가정이 항상 분리됩니다.
• 작성자와 공유를 위한 것. 작성자(및 향후 세션의 Claude)에게 방해 요소 없이 간결한 설명을 제공하며, 협력자, 파트너 또는 자금 제공자에게 그대로 전달할 수 있습니다.

둘은 공존합니다. 비전은 프로젝트를 이야기로 설명하고, 창립 문서는 설명합니다. 하나가 변경되면 다른 하나도 검토됩니다.

이 스킬은 창립 문서에 포함되어야 할 내용과 작성 방법을 설명합니다. 생성기, 리소스 및 구문, 테마, 도구 및 검증은 crear_documentos의 공통 사항이며, 이를 함께 읽어야 합니다.

위치

프로젝트의 창립 문서는 docs/specs/vision/(SF 방법론, "공통 문서 구조")에 함께 위치합니다: 비전, 창립 문서, 기술 인포그래픽은 infografias/에 있습니다.

• 프로젝트: docs/specs/vision/fundacional-<프로젝트>.md 및 .html.
• 제품군의 각 제품(있는 경우): fundacional-<제품>.md.

.md가 원본입니다. .html은 생성되며 수동으로 편집하지 않습니다. PDF 또는 기존 HTML에서 시작하는 경우 .md로 변환하고 원본은 그 옆이나 _respaldo/에 보관합니다.

모델. 프로젝트에 이미 이러한 규칙을 잘 적용하는 창립 문서가 있다면, 다른 문서를 작성하거나 검토할 때 예시로 읽습니다. 해당 도메인의 내용은 복사하지 않습니다.

섹션

모든 창립 문서에 포함되는 핵심 섹션과 프로젝트에 필요할 때 포함되는 선택적 섹션이 있습니다. 나타나는 순서대로 번호가 매겨집니다. 부록은 마지막에 "부록 A · …" 형식으로 추가됩니다.

순서: 먼저 설명하고, 그 다음에 정당화. 독자는 주장을 평가하기 전에 제품이 무엇인지 알아야 합니다. 시작(목적, 있다면 개발 이유를 설명하는 산문(아이디어, 차별점, 테제)) 다음에는 시스템 또는 제품군, 제품 및 작동 방식, 시나리오 및 대안을 설명하는 섹션이 옵니다. 그 다음에는 문서화된 필요성과 문제 비용, 영향, 규모, 위험 및 "입증해야 할 사항"을 정당화하는 섹션이 옵니다. 문서화된 필요성 카드는 시작 부분에서 이미 테제를 요약하는 경우 제품 설명 다음에 자체 섹션으로 배치될 수 있습니다.

깔끔한 표지. 일반 글꼴로 브랜드, 이름 및 슬로건(한 줄 또는 두 줄). 그 외에는 아무것도 없어 헤더를 낮춥니다: 아이디어와 목적이 첫 번째 섹션의 도입부 역할을 하고, 버전과 상태는 하단에 있으며, 숫자 행(카드 또는 증거 수 세기)은 없습니다(숫자가 주장하는 데 사용된다면 본문에 포함).

전역 범위 알림(문서의 어떤 부분이 설계 목표이고 어떤 부분이 검증되었는지, 또는 전체 텍스트에 적용되는 기준): 모든 섹션 외부, 처음에 위치합니다. # 이름과 첫 번째 ## 사이에 인용문 >으로 작성됩니다. 생성기는 이를 섹션 앞에 상자로 배치합니다.

핵심

1. 개발 이유. 카드 앞과 부제목 없이 시작 산문으로 시작:

   • 아이디어와 목적, 도입부 역할;
   • 기존 대안과의 차별점, 하나의 단락으로, 참조 및 대안별 문장 포함;
   • 개발 테제: 지금 무엇에 자금을 지원하거나 구축할 가치가 있으며, 어떤 조건에서 가치를 가질 것인지. 산문 형식(상자 아님)으로 작성되며 정당화됩니다: 문서의 어떤 사실에 기반하는지(수치 및 참조 포함), 그리고 파일럿이 측정해야 하는 아직 알려지지 않은 것은 무엇인지.

   그 후, 문서화된 필요성(측정된 문제, 개입 능력, 결과)에 대한 두세 개의 카드, 각각 참조 포함. 주장하는 산문 다음에 정당화된 카드가 오는 이 형식은 모든 섹션의 모델입니다("작성 규칙" 참조).

2. 제품. 몇 가지 수치(용량, 자율성, 범위…)로 무엇인지, 하위 시스템별 작동 방식, 아키텍처, 주요 기능, 진화 방식(제품군, 플랫폼, 확인/재구성/재설계) 및 하지 않는 일.

3. 사용 시나리오. 제품이 가치를 제공할 수 있는 상황, 각각 코드(S1, S2…)가 있어 문서의 나머지 부분에서 참조합니다. 각 시나리오: 가치를 제공하는 시기, 주장의 한계, 측정할 사항 및 문서 기반. 시나리오는 서로 호환됩니다. 독립적인 모집단으로 합산되지 않습니다.

4. 증거. 먼저 검색 방법과 범위. 그 후, 증거당 하나의 카드: 유형(측정, 파일럿, 가이드, 연구…), 내용(수치 포함), 영향을 받는 시나리오 및 프로젝트를 위한 해석(무엇을 뒷받침하는지 그리고 무엇을 뒷받침하지 않는지).

5. 입증해야 할 사항. 문서에서 파일럿으로의 단계: 우선순위가 지정된 단계, 각각 회로, 이유 및 진행 조건 포함; 필요한 검증(기술, 운영, 경제); 진행 결정(게이트); 제안된 결정 및 측정 방법.

6. 출처 및 참조. 유형별 코드가 있는 모든 출처(예: E 증거, F 기술 데이터, P 가격, D 경제, C 임상, M 프로젝트 자체 문서), 출처, 링크 및 검토 날짜.

선택 사항

• 목적 및 가치(사명, 비전 및 가치), 처음에, 자체 섹션으로 또는 첫 번째 섹션 내 카드로. 팀 또는 협력자의 참여를 유도하는 프로젝트용.
• 문제 비용, 경제적 차원이 있는 경우: 수치 및 "의미와 범위"가 포함된 문서화된 사례, 방지할 수 있는 사항 및 경제 모델(공식). 개발 이유 다음에 위치.
• 시장 또는 영역 규모: 출처가 확인할 수 있는 것과 그렇지 않은 것, 필요한 데이터(분모, 노출, 경제), 투명한 시나리오(자체 계산기를 포함할 수 있음) 및 방어 가능한 추정치로 전환하는 방법. "입증해야 할 사항" 앞에 위치.
• 기존 참조와의 비교 부록: 차원당 하나의 카드, 두 개의 열("참조 · 게시됨" 및 "프로젝트 · 설계") 및 각 접근 방식의 기여. 마지막에 비교가 유지해야 하는 가치와 부가 가치를 확인하는 방법.
• 요소별 시트 부록(의약품, 재료, 구성 요소, 고객 유형…): 요소당 하나의 시트(데이터 및 시나리오 포함). 생성기가 시나리오별 검색 및 필터를 추가합니다.
• 영향: 제품이 작동할 경우 무엇이 바뀔지, 항상 파일럿이 입증하는 것에 조건부. 차원당 하나의 카드(경제적, 인간, 영토 또는 환경) 및 측정 가능한 지표(사전 및 사후). 시작 산문은 이미 존재하는 기준선과 측정해야 할 것을 명시합니다. 이 대조 없이는 프로젝트에 절감액이 귀속되지 않습니다. SDGs(인용 시)는 공식 명칭과 출처와 함께.
• 위험: 실패할 수 있는 것과 완화 방법. 위험당 하나의 카드, 유형 레이블(기술, 운영, 경제, 규제), "완화" 및 "확인 위치"("입증해야 할 사항"의 단계 또는 게이트 참조). 시작 산문은 주요 위험과 계획이 이를 조기에 감지하는 방법을 설명합니다. 아직 분석되지 않은 것(예: 규제 적합성)은 공개된 위험으로 선언되며, 가능한 경우 출처를 포함합니다. "입증해야 할 사항" 바로 앞에 위치.
• 협력 초대: 찾고 있는 프로필, 제공하는 것 및 기대하는 것. 공유되는 문서용.

계층별 읽기. 가장 중요한 것을 먼저 전달하고, 각 다음 계층은 심층 분석을 제공합니다. 첫 번째 부분만 읽는 사람은 핵심을 얻고, 더 원하는 사람은 계속 읽습니다. 순서는 중요도 순이며, 결론에 도달한 방법 순서가 아닙니다. 이는 전체 문서와 각 섹션에 적용되며, 결론으로 시작하고("작성 규칙" 참조) 세부 사항은 카드, 접힌 #### 및 부록에 남깁니다.

프로젝트에 여기에 없는 섹션이 필요한 경우, 작성 전에 작성자에게 제안합니다. 다른 프로젝트에 유용하다면 SF의 이 스킬을 개선하는 것입니다. 프로젝트에 기록하지 않고 한 줄로 말합니다. SF 자체에서는 프로젝트의 일부입니다.

작성 규칙

• 최종 결정만. 문서는 기록 없이 현재 상태를 설명합니다.
• 세 가지 유형의 진술, 항상 분리: 게시된 사실(참조 포함), 프로젝트의 설계 목표(원하는 기능), 계산 가정(예시로 표시). 시작 부분의 범위 상자가 이를 설명하고, "게시됨" 및 "설계" 레이블이 비교되는 곳에서 상기시킵니다.
• 도메인의 모든 수치 또는 진술은 작성 전에 출처와 대조하며, 기억에 의존하지 않고, 동일한 문장에 참조를 포함합니다. 웹 검색 시 작성자의 허가를 받지 않았다면 요청합니다.
• 각 증거는 입증하지 않는 것도 명시합니다. "프로젝트를 위한 해석", "주장의 한계", "의미와 범위": 문서는 자체 한계를 표시할 때 신뢰성을 얻습니다.
• 간결. 두세 문장의 단락, 20단어 이하의 문장, 첫 번째 사용 시 약어 설명. 핵심은 한 번에 읽히고, 광범위한 세부 사항은 부록에 포함됩니다.
• 군더더기 없음. 문서 자체에 대한 언급("이 문서를 업데이트해야 합니다…", "이 문서는 다음을 포함하지 않습니다…") 또는 자명한 내용은 없습니다. 각 문장은 프로젝트에 대한 무언가를 제공합니다.
• 각 섹션은 주장하는 산문으로 시작하며, 첫 번째 섹션과 같습니다. 카드 앞, 부제목 없이, 약 두세 단락으로 섹션의 결론, 이를 뒷받침하는 사실(수치 및 참조 포함), 그리고 아직 알려지지 않은 것을 포함합니다. 소개 문장("6가지 경험이 가능하게 합니다…")만으로는 충분하지 않습니다. 테제 또는 전체 해석은 상자 안이 아닌 이 산문에 포함됩니다. 카드는 그 후에 오며, 주장을 반복하지 않고 참조할 수 있는 세부 사항을 제공합니다.
• 완전한 문장, 카탈로그 아님. 각 하위 섹션(###) 내에서는 동사가 있는 문장으로 작성하여 무언가가 어떻게 작동하고 왜 그런지 설명하며, 동사 없는 열거("식별, 인벤토리, 추적성…")는 사용하지 않습니다. 하위 섹션 제목은 "냉기를 유지하는 방법"과 같이 답변하는 질문을 따르며, "주제: 하위 주제" 패턴을 사용하지 않으며, 단락의 일부를 ####로 나누지 않습니다. ####는 접힐 세부 사항을 위해 남겨둡니다.
• 가시적 구조, 읽기 흐름 유지: 카드, 산문, 하위 섹션, 상자, 표 또는 목록, 굵은 글씨, 반복 필드 및 타이포그래피 사용 시기는 crear_documentos("각 리소스 사용 시기")에 명시되어 있습니다. 창립 문서에서 일반적인 카드는 경험, 시나리오, 증거, 단계, 게이트, 비교 차원, 시트 및 제품의 핵심 수치입니다. 평가에서는 작동한 것을 산문으로 설명하고 결함은 상황과 상태를 포함한 표에 표시합니다.
• 아직 독자가 모르는 코드 사용 금지. 내부 코드(S1, S2…)는 이를 정의하는 섹션 이후, 그리고 참조 연결에 도움이 되는 경우에만 사용됩니다. 그 전과 주장하는 산문에서는 단어로 설명합니다("택배 배송 및 가정 보관").
• 모든 핵심 진술은 동일한 위치에서 정당화. 중요한 테제 또는 결론은 근거(문서의 사실, 수치 및 참조 포함)와 아직 입증되지 않은 것을 명시합니다.
• 제안, 강요 금지. "제안합니다", "검토할 사항", "해당자가 결정".
• 도메인의 민감성 존중. 프로젝트 도메인 규칙은 ID reglas에 있습니다(documento_vision이 읽는 것과 동일).

작업 방법

1. 제안하기 전에 읽기: 프로젝트의 비전, ID 및 규칙, 사양(있는 경우), 수치를 제공하는 코드 또는 디지털 트윈, 작성자가 가져온 자료. 프로젝트의 모든 주장 인벤토리 작성. 제품 창립 문서는 프로젝트가 가진 모든 주장을 수집하며, 다른 제품과 비교할 때 더욱 그렇습니다: 다른 창립 문서, 비전, 사양 및 이미 구축된 것(디지털 트윈, 프로토타입, 테스트)의 주장. 작성 또는 검토 전에, 누락된 사항(출처 및 유형(게시된 사실, 설계 목표, 가정 또는 시뮬레이션에서만 검증된 진행 상황))과 문서 간 모순을 인벤토리화하고, 영향을 받는 수치를 전달하기 전에 작성자에게 문의합니다. 구축된 것은 선언된 한계와 함께 설명됩니다.
2. 색인 및 도구 제안: 문서가 프로젝트용 아티팩트인지 사용자용인지, 어떤 도구(검색, 메모, "읽기", 접기, 범례, 편집…)가 필요한지, 해당 목적에 대한 권장 사항을 포함하여 하나의 질문에 옵션으로 질문합니다. 응답을 헤더에 기록합니다. 색인 제안: 핵심, 적용되는 선택적 섹션 및 이유, 코드가 있는 후보 시나리오, 표지 수치. 작성자가 세부 조정할 수 있도록 합니다.
3. 누락된 증거 조사(검색 허가 필요), 정확한 출처 포함.
4. 아래 리소스를 사용하여 .md 작성 및 .html 생성. 버전을 교체하기 전에 _respaldo/에 백업합니다(crear_documentos, "백업").
5. 검증("확인" 참조) 및 요약과 함께 전달: 내용, 예시 표시, 누락된 증거, 전문가 검증 권장 사항.
6. 작성자와 함께 세부 조정. 각 일반 수정 사항은 crear_documentos의 "문서 정리"(적용되는 경우)에 추가되고, 그렇지 않으면 이 스킬의 새 버전을 제안합니다.

확인

crear_documentos("확인")에서 공통 확인을 참조하세요. 이 문서에만 해당하는 추가 확인 사항:

• 각 증거에는 "프로젝트를 위한 해석" 및 "주장의 한계" 필드가 있습니까?
• 각 주요 진술에는 참조가 포함됩니까?
• 실제 수치와 가정이 명확히 구분됩니까?
• 시나리오는 독립적으로 합산되지 않고 서로 호환 가능합니까?
• 인벤토리에는 문서 간 모순이 없습니까? (있는 경우 해결됩니까?)
• 문서에는 서사가 없으며, 제품 설명과 정당화라는 핵심 목적에 충실합니까?