toyin-software-factory/develop

출력 스타일 (일반 언어, 대시 없음, 하이픈 없음)

이 스킬이 생성하는 모든 것(파일과 메시지 모두)을 간단한 일반 언어로 작성하세요. 독자를 '당신'이라고 부르며 동료처럼 따뜻하고 직접적으로 말하고, 각 단계를 실행하거나 건너뛸 수 있는 권장 사항으로 제시하며 절대 명령으로 제시하지 마세요. 실제 의미를 지닌 기술 용어는 유지하고 각 용어를 일반 언어로 설명하세요. 구두점으로 대시나 하이픈을 절대 사용하지 마세요: em 대시, en 대시, 하이픈으로 연결된 복합어도 금지입니다. read-only가 아닌 read only로 작성하세요. 간단한 단어로 말하거나 문장을 다시 표현하세요. 코드, 파일 경로, 명령 플래그, 다른 스킬이 일치시키는 값은 하이픈을 유지합니다. 짧은 문장, 쉼표, 또는 괄호를 사용하세요. 명확함이 기발함보다 낫습니다.

이 스킬이 하는 일

빌더: 명세와 프로젝트 컨벤션을 동작하는 코드로 변환합니다. 추적 대상: UI(컴포넌트, 페이지, 레이아웃; ui-guide.md), 논리(API, 서비스, 데이터 계층, 비즈니스 로직, 통합; logical-guide.md), 또는 둘 다(예: "auth" = 로그인 페이지 + 세션 로직 → 둘 다 실행). 0단계는 명세에 게이트를 걸어 중요한 선택(인증 방식, 결제 제공자)이 /architect에서 결정되고 빌드 도중 묵시적으로 발명되지 않도록 합니다.

질문 vs 실행

게이트를 걸고 실행합니다: /architect와 같은 사전 질문 라운드는 없습니다. 결정을 읽고, 구축하고, 디자인이 열어둔 것만 질문합니다(참조가 주어지지 않은 경우 시각적 방향; 명세가 결정하지 않은 비즈니스 규칙). 명세, AGENTS.md, 코드베이스에서 추론하고 로컬 구현 선택을 권장합니다.

아티팩트 소유권

• 앱 코드(UI의 경우 CSS/토큰 포함)를 작성합니다.
• 범위(docs/scope/): 4단계만 영향을 줍니다(기능 상태 → in-progress, 마일스톤 하위 상자, Build it 상자, 코드 포인터). Prototype 워크플로우 계층에서만 기능을 done으로 표시합니다(빌드 + 자체 확인; 엔지니어가 별도 검증을 선택하지 않음). Assumed 명세는 이를 차단하지 않으며, 비준이 필요함을 표시한 상태로 유지됩니다. Alpha/Beta/GA에서는 기능을 in-progress로 두어 /check verify와 /test가 종료하도록 하고, Verify it 또는 Test it을 절대 체크하지 않습니다. docs/scope/에 파일을 절대 생성하지 않습니다(범위 전용; 분석/연구는 /architect의 작업이며 명세의 rationale.md에 있습니다).
• 명세 내용을 절대 작성하지 않거나 결정을 심의하지 않습니다(필요를 표시하고 /architect로 넘깁니다). 루트 AGENTS.md를 절대 재구성하지 않습니다(그것은 /audit의 작업입니다). 새로운 영역 컨벤션은 이후 /sync를 통해 전달됩니다. 한 가지 좁은 예외: Build now, record it as an assumed spec(0단계)에서 /develop은 명세를 생성할 수 있지만, 오직 Status: Assumed 상태로만, 그리고 가정 기록 필드(결정 필요, 기반 가정, 권한자, 코드 영역, 요구사항 시드)만 작성합니다. 근거를 절대 작성하지 않으며 Assumed 명세를 그 상태 이상으로 진행시키지 않습니다. /architect가 이를 해제하는 것을 소유합니다. 이것이 /develop이 생성하는 유일한 명세입니다.
• 기존 명세에 대한 한 가지 터치: **Status**: 라인(우산 결정 → index.md의 것이며 자식의 것이 아님)과 기능의 명세 포인터 라인 채우기. 빌드 시작: Proposed → In Progress; 빌드 완료(기능 → done): In Progress → Accepted(명세는 기능이 출시될 때까지 Accepted가 아닙니다). 명세 내용을 절대 편집하지 말고, 해당 라인만 외과적으로 편집하세요: 쓰기 직전에 다시 읽으세요. 예상치 못한 상태(이미 Accepted, Superseded) → 플래그를 지정하고 덮어쓰지 마세요. Assumed 명세를 절대 상태에서 이동시키지 마세요(그것은 비준이며 /architect의 작업입니다): Assumed 명세는 기능이 in-progress인 동안에도 빌드 전체에 걸쳐 Assumed로 유지되므로, /architect가 비준할 때까지 Accepted에 도달할 수 없습니다. 기능 자체는 여전히 done으로 표시될 수 있습니다(엔지니어의 결정). Assumed 명세는 비준이 필요함을 표시한 상태로 유지되며 done을 차단하지 않습니다.
• 아티팩트 기준: 기본적으로 docs/, docs/가 게시된 문서 사이트인 경우 .workflow/. 존재하는 쪽에서 읽습니다(여기서 경로는 docs/를 가정).
• 공유 범위: 체크하기 직전에 다시 읽고, 특정 체크박스, 상태 또는 포인터 라인만 편집합니다(파일을 절대 다시 쓰지 않음). 예상과 다른 기능(이미 done, 재작업) → 플래그를 지정하고 덮어쓰지 마세요.

---

이식성 (모든 OS, 모든 에이전트)

모든 Agent Skills 클라이언트, macOS/Linux/Windows. 감지 스니펫은 POSIX 참조입니다. 에이전트 자체의 크로스 플랫폼 파일 도구를 사용하세요. 메인 스레드에서 인라인으로 빌드합니다(3단계). 유일한 하위 에이전트는 코드를 탐색하는 읽기 전용 scout(2.5단계)와 문서 확인을 위한 읽기 전용 researcher(2.6단계, 웹 기능 없이 지식에서 빌드로 저하됨)이며, 둘 다 가장 저렴한 모델을 사용합니다. 번들 가이드(ui-guide.md, logical-guide.md, checklist.md)와 게이트 이후의 빌드 흐름(flow/build.md)은 이 스킬의 폴더를 기준으로 한 상대 경로입니다. 메인 스레드가 이를 읽습니다. 대화형 질문 선택기 없음 → 동일한 옵션으로 일반 텍스트 프롬프트를 질문하세요.

실행

빌드 전: 프로젝트가 이미 존재해야 합니다(스캐폴드 작업 제외)

예외: 이것이 스택 및 아키텍처 기반 기능의 스캐폴드 하위 작업인 경우(프롬프트가 scaffold라고 말하거나 단계가 스택 명세에서 프로젝트를 초기화하는 경우), 프로젝트를 생성하는 것이 작업입니다. ARCHITECTURE 명세의 ## Proposed stack를 읽으십시오. 명세가 지정한 스택에 대해 프레임워크 자체의 프로젝트 이니셜라이저를 실행하십시오. 기본 종속성(프레임워크, 코어 런타임, 첫 번째 슬라이스에 필요한 것만)을 설치하십시오. 디렉토리를 배치하십시오. 개발 서버 또는 빌드가 실행되는지 확인하십시오. 이니셜라이저가 생성한 저장소를 유지하십시오(프로젝트를 재배치할 때 절대 폐기하지 마십시오). 이니셜라이저가 저장소를 만들지 않았고 git 통합이 켜져 있으면 git init을 실행하십시오. 스캐폴드 단계는 스택 결정에서 파생됩니다(결정 명세에는 빌드 계획이 없습니다). 적시에만 설치하십시오: 명세가 지정한 모든 라이브러리(이메일, 모니터링 등)가 아닙니다. 각 후속 기능은 빌드될 때 자체 라이브러리를 설치합니다. 교차 절단 도구(린트, 포맷, 타입 엄격성)만 /audit + 도구 작업을 통해 초기에 제공됩니다. 그런 다음 진행하십시오.

그렇지 않으면 /develop은 기존 프로젝트에 빌드됩니다. 스켈레톤이 없고(package.json/pyproject.toml/go.mod/매니페스트, 소스 트리 없음) 스캐폴드 작업이 아닌 경우 → 중지:

빌드할 프로젝트를 찾을 수 없습니다. 먼저 스캐폴드 단계(아키텍처 명세에 따른 스택 및 아키텍처 기능의 스캐폴드 하위 작업)를 실행한 다음 /develop을 다시 실행하십시오.

프로젝트가 존재하는 경우(빈 스캐폴드라도) → 진행하십시오.

빌드 전: 최신 상태 및 협업 (오래된 상태나 동료 위에 빌드하지 마십시오)

무언가를 변경하기 전에(단독, 오프라인 또는 git을 사용하지 않는 경우 자동으로 건너뜁니다): git fetch를 자동으로 실행하십시오. 기준 = main, 그렇지 않으면 master; 뒤처진 커밋 수(git rev-list --count HEAD..origin/<base>); 커밋되지 않은 작업(git status --short).

• 뒤처진 경우(커밋 수 > 0) → 중지하고 경고: "당신은 origin/$BASE보다 N 커밋 뒤쳐져 있습니다. 팀원이 이미 이것을 변경했거나 출시했을 수 있습니다. 먼저 풀(pull)한 다음 다시 실행하십시오."
• 변경할 영역에 커밋되지 않은 작업이 있는 경우 → 경고: "여기에 커밋되지 않은 변경 사항이 있습니다. 먼저 커밋하거나 스태시(stash)하여 이 빌드가 그들과 얽히지 않도록 하십시오." 사용자가 계속 요청하면 진행하도록 하십시오.
• 범위에서 기능이 in-progress이고 해당 코드 영역(포인터 라인의 경로)에 다른 작성자의 최근 커밋이 있는 경우(git log --format='%an' -- <area>) → 경고: "**은(는) 다른 사람이 빌드 도중인 것으로 보입니다. 계속하기 전에 조정하십시오." 진행 전에 확인하십시오.

경고이지만 하드 블록은 아니며, 표면화하십시오.

Git 통합: 가장 가까운 AGENTS.md ## Git이 integration: on이라고 말하면 flow/git.md를 읽고 따르십시오(빌드 전에 브랜치 생성, 마일스톤이 완료되면 커밋). 없거나 off인 경우 활성 git을 수행하지 마십시오.

0단계: 명세 게이트 (항상 먼저)

결정이 필요하지만 기록되지 않았습니까? 이것을 내성(introspection)("내가 무언가를 발명하고 있다고 느끼는가?")으로 판단하지 마십시오. 빌드 모델은 실제 결정을 "단지 배선"으로 합리화하고 통과시킵니다. 기계적이고 스스로를 합리화하기 어려운 긍정적인 입력 범위 테스트를 사용하십시오:

이 빌드가 생성, 계산 또는 표시해야 하는 모든 값(허용 기준 및 명세의 디자인에서)을 열거하십시오. 각 값에 대해 명세가 값의 출처(입력, DB 열, 명명된 값의 파생, 이전 결정)를 지정합니까? 출처가 명명되지 않은 필수 값은 결정이 필요한 것입니다.

출처가 명명되지 않은 경우 중지하고 게이트로 라우팅하십시오(/architect 또는 Assumed 명세 기록; /develop은 결정을 구현할 뿐 결정을 내리지 않습니다). 다음과 같은 경우에도 결정이 필요합니다:

• 제공자, 라이브러리, 통합, 데이터 모델 또는 교차 절단 패턴(예: 인증 제공자, DB/ORM, 캐싱 전략).
• 전체 UI 페이지 또는 화면: 해당 디자인 시스템(design.md가 있습니까? 없으면 어떤 방향?), 섹션/구성, 컴포넌트 인벤토리, 자산 전략(스크린샷 없음, 저장소 이미지 없음 → 예: 온라인 소스). design.md와 페이지 수준 명세가 이를 명확히 하지 않는 한 필요합니다.
• 기능의 동작(검색, 마법사: "정확히 무엇을 해야 합니까?"가 열려 있음; /architect가 이러한 질문을 합니다). 명세가 정의하지 않는 한 필요합니다.

"로컬 구현 세부 사항"이 실제로 의미하는 것(좁은 예외): 명세의 명명된 출처가 이미 허용하는 옵션 중에서 선택, 루프 스타일, 변수 이름, 호출할 헬퍼만 해당됩니다. 선택이 값의 출처 또는 허용 기준이 제한하는 동작을 결정하는 순간, 아무리 작아 보여도 정의상 중요합니다. "사용자의 오늘을 마지막으로 읽은 행의 시간대에서 파생"하는 것은 로컬 세부 사항이 아닙니다: 허용 기준이 제한하는 값의 출처를 선택하므로 필요합니다. 진정한 순수 구현에는 필요하지 않습니다: 작은 버그 수정, 기존 design.md와 일치하는 컴포넌트, 명세가 이미 출처를 지정하는 조각 배선, 복사 조정, 기존 명세/design.md/AGENTS.md가 완전히 관리하는 모든 것.

페이지 이름이나 단일 예제(시간대는 패턴의 예시일 뿐 규칙이 아님)에 하드코딩하지 마십시오. 요청된 모든 것에 입력 범위 테스트를 적용하십시오. 거짓 음성(false negative)이 실패 모드입니다: 실제 결정을 인지하지 못한 상태로 구축하는 것입니다. 필수 값의 출처가 명명되지 않았거나 확실하지 않은 경우 필요로 처리하고 질문하십시오(아래 패널).

이 기능에 필요한 것만 읽고, 전체 docs/ 트리를 절대 읽지 마십시오: 하나의 범위 파일과 하나의 관리 명세(단일 파일 또는 우산 index.md + 이 하위 작업을 명세하는 하나의 자식 명세)만 읽으십시오. 다른 기능의 행, 범위 파일, 워크스페이스 또는 관련 없는 명세는 읽지 마십시오.

순서대로 확인하십시오:

1. 이 기능의 범위 파일(해당 하나만)을 찾으십시오. 모노레포 → 작업 패키지에 대해 docs/scope/<workspace>/. 한눈에 보기 표에서만 파일(scope.md 또는 분할된 경우 일치하는 <epic>.md)을 선택하십시오. 이 기능의 섹션만 읽으십시오. needs a decision에 아직 명세 포인터가 없으면 → 결정이 필요하고 누락되었습니다. 잘못된 형식 → 플래그를 지정하고 질문하십시오. 추측하지 마십시오.
2. 기능의 spec 포인터를 통해 관리 명세를 여십시오. 빌드 흐름(flow/build.md)의 2단계 항목 1에 정의된 대로 빌드 명세 섹션만 읽으십시오. 발견됨 → 명세입니다. 진행하십시오. 포인터가 없고 연결된 명세도 없으면 → docs/specs/<workspace>/에서 이 기능의 범위와 일치하는 대상을 집중적으로 찾으십시오. 절대 전체를 읽지 마십시오.
3. 가장 가까운 AGENTS.md(워크스페이스/영역)가 이미 결정을 캡처했을 수 있습니다(이전 기능에서 동기화됨, 예: "인증 제공자가 이미 선택됨") → 새 명세 없이 진행하십시오.

결정이 필요하지만 기록되지 않음 → 추측하지 말고 자동으로 중지하지 마십시오. 질문하십시오(단일 선택; Claude Code에서 AskUserQuestion):

• question: "이것은 먼저 아키텍처 결정이 필요한 것으로 보입니다: <특정 중요 결정 이름 지정, 예: '어떤 인증 제공자 + 세션 모델'>. 어떻게 처리하시겠습니까?"
• header: "spec first?"
• options:
  1. Architect it first: "권장됩니다. 빌드 전에 명세에 결정을 캡처하여 빌드에 명세가 있도록 하십시오." → 아래 핸드오프와 함께 여기서 종료하십시오. 빌드하지 마십시오.
  2. No, not needed: "여기에는 실제 결정이 없다고 판단했습니다. 직접 빌드하십시오." → 빌드 흐름(flow/build.md)으로 진행하십시오.
  3. Build now, record it as an assumed spec: "빌드하되, 먼저 가정을 기록하여 결정이 이 채팅뿐만 아니라 저장소에 남도록 하십시오. Assumed 명세는 비준이 필요함을 표시한 상태로 유지되지만(/architect), 기능을 done으로 표시하는 것을 차단하지 않습니다." → 아래 Assumed 명제를 작성한 다음 빌드 흐름(flow/build.md)으로 진행하여 범위(docs/scope/)에 assumed decision (spec NNNN) 메모와 함께 기능을 in-progress로 남겨 두십시오.

도구는 자동으로 "기타"를 자유 텍스트 옵션으로 추가합니다.

Build now, record it as an assumed spec에서 빌드 전에 최소한의 Assumed 명세를 작성하십시오(이것은 /develop이 소유하는 유일한 좁은 명세 작성입니다. 아티팩트 소유권 참조). /architect가 하는 방식으로 $SPEC_DIR을 결정하십시오(단일 저장소 → docs/specs/; 모노레포 워크스페이스 → docs/specs/<workspace>/), 다음 사용 가능한 NNNN을 가져와 $SPEC_DIR/NNNN-<slug>.md에 작성하십시오:

# NNNN · <feature>

**Status**: Assumed
**Date**: <today>
**Authorized by**: <engineer>, during /develop

## Owed decision
<the specific load bearing choice that was not made>

## Assumption built on
<the concrete assumption this build will use>

## Code area
<the paths this build will touch>

## Requirements
<acceptance criteria seeds carried from the scope Done when, if any>

## Ratify
This decision was recorded by /develop, not deliberated. Run `/architect <feature>`
to deliberate and ratify it. Until then it stays flagged as an owed decision; it does not block marking the feature `done`.

기능의 범위 spec 라인을 이 파일로 지정하십시오. 가정은 이제 지속됩니다: /clear에서도 유지되고 팀원이 읽을 수 있으며 이후 /develop이 다시 추측하는 대신 이를 기준으로 빌드합니다. Assumed 명세는 비준이 필요함을 표시한 상태로 유지되며 기능을 done으로 표시하는 것을 차단하지 않습니다(flow/build.md, 4단계 참조).

Architect it first에서 다음으로 종료하십시오:

다음을 실행한 다음 /develop으로 돌아오십시오:

/architect <feature>: <the specific decision to settle>

명세가 존재하면 /develop <task>를 다시 실행하면 빌드하겠습니다.

결정이 필요하지 않음(순수 구현) → 질문을 건너뛰고 진행하십시오.

빌드 흐름 (1-4단계)

한 번...

[번역을 위해 잘림]