트렐리스 브레인스토밍

트렐리스 브레인스토밍은(는) 무엇을 하나요?

비-협상 계획 계약

구축, 구현, 수정, 리팩터링 또는 "진행" 요청은 계획을 떠나라는 승인이 아닙니다. 작업 생성 동의 또한 구현 승인이 아닙니다.

모든 중요하지 않은 작업에 대해, 사용자는 초기 요청 후 구현이 시작되기 전에 최소 한 번은 응답해야 합니다. 설명이 필요 없는 경우, 해당 응답은 아래 설명된 최종 계획 요약을 승인해야 합니다.

사용자가 소유한 제품, 범위, UX, 호환성, 위험 또는 수용 결정이 해결되지 않은 상태로 남아 있는 경우, 정확히 하나의 가장 가치 있는 질문으로 턴을 종료하십시오. 제품 코드를 편집하거나, 구현을 디스패치하거나, task.py start를 실행하지 마십시오.

비-협상 증거 규칙

질문에 대한 답이 코드베이스를 탐색하여 얻을 수 있다면, 대신 코드베이스를 탐색하십시오.

이는 필수입니다. 사용자에게 질문하기 전에 먼저 답이 코드, 테스트, 설정, 문서, 기존 명세서 또는 작업 기록에 이미 있는지 확인하십시오.

저장소가 대답할 수 있는 사실을 확인하기 위해 사용자에게 묻지 마십시오. 검사 후에도 모호한 제품 의도, 선호도, 범위, 위험 허용 범위, 수용 동작 또는 결정에 대해서만 물어보십시오.

저장소 증거는 현재 동작과 기술적 제약 조건을 확립합니다. 사용자의 의도된 동작, 기능 범위 경계 및 UX 선호도는 저장소 증거만으로는 결코 대답할 수 없습니다. 기존 패턴이 존재하더라도, 기존 패턴은 옵션 및 권장 증거일 뿐 결정이 아닙니다.

---

페이즈 1 계획 중에 이 스킬을 사용하여 사용자의 요청을 명확한 요구사항 및 계획 아티팩트로 전환하십시오.

전제 조건

작업 생성 동의가 주어지고 사용자가 트렐리스 계획에 들어갈 준비가 된 경우에만 이 스킬을 사용하십시오.

아직 작업이 없으면 하나를 생성하십시오:

TASK_DIR=$(python3 ./.trellis/scripts/task.py create "<짧은 작업 제목>" --description "<한 줄 요약>" --slug <슬러그>)

사용자의 요청에서 간결한 제목을 사용하십시오. 제목과 --description은 모두 비어 있지 않아야 합니다. create는 빈 값을 거부하며, 둘 중 하나라도 비어 있으면 아카이브에서 거부됩니다. 날짜 접두사 없이 슬러그를 사용하십시오. task.py create는 MM-DD- 디렉토리 접두사를 자동으로 추가합니다.

task.py create는 기본 prd.md를 생성합니다. 후속 질문을 하기 전에 현재 이해를 바탕으로 해당 파일을 업데이트하십시오.

계획 흐름

1. 사용자의 요청과 초기 알려진 사실을 prd.md에 캡처하십시오.
2. 질문하기 전에 사용 가능한 증거를 검사하십시오:
   • 코드, 테스트, 픽스처 및 설정
   • README 파일, 문서, 기존 명세서 및 도메인 노트
   • 관련 트렐리스 작업, 연구 파일 및 세션 기록 (있는 경우)
3. 발견한 내용을 다음으로 구분하십시오:
   • 확인된 사실
   • 사용자로부터 여전히 필요한 제품 의도
   • 사용자로부터 여전히 필요한 범위 또는 위험 결정
   • 범위를 벗어날 가능성이 있는 항목
4. 사용자 소유 결정이 남아 있으면, 단일 가장 가치 있는 질문을 하고, 권장 사항과 트레이드오프를 포함시킨 후 중단하십시오. 같은 턴에 구현 작업을 수행하지 마십시오.
5. 각 사용자 응답 후, prd.md를 업데이트하고, 결정 목록을 재계산한 후 2단계부터 반복하십시오.
6. 사용자 소유 결정이 더 이상 남아 있지 않으면, 복잡한 작업을 위해 design.md 및 implement.md를 생성하거나 업데이트하십시오.
7. 요구사항 수렴 게이트를 실행한 다음, PRD 수렴 패스를 실행하십시오.
8. 최종 계획 요약을 제시하고 중단하십시오. 같은 턴에 task.py start를 실행하거나 제품 코드를 편집하지 마십시오.
9. 후속 사용자 메시지가 최신 계획 요약을 명시적으로 승인한 경우에만 task.py start 및 구현이 승인됩니다. 승인 후 아티팩트가 실질적으로 변경되면 최종 검토를 반복하십시오.

프로젝트별 제품/명세 계층 구조를 발명하지 마십시오. 저장소에 이미 제품, 도메인 또는 명세 문서가 있으면 그것들을 사용하십시오. 없으면 존재하는 증거로 진행하십시오.

질문 규칙

메시지당 하나의 질문만 하십시오.

각 질문에는 다음이 포함되어야 합니다:

• 필요한 결정
• 답변이 중요한 이유
• 권장 답변
• 사용자가 다르게 선택할 경우의 트레이드오프

검색, 파일 검사 또는 브레인스토밍 계속 여부와 같은 프로세스 질문을 하지 마십시오. 증거 작업을 직접 수행하십시오. 남은 문제가 제품 결정, 선호도, 범위 경계 또는 위험 허용 범위 선택인 경우에만 사용자에게 물어보십시오.

권장 사항은 기본 선택이 아닙니다. 사용자가 구현을 요청했다는 이유만으로 사용자를 대신하여 권장 제품 결정을 선택하지 마십시오.

요청 및 저장소 증거가 이미 모든 결정을 해결한 경우 명확성 질문을 만들어 내지 마십시오. 이 경우, 여전히 후속 명시적 승인이 필요한 최종 계획 요약으로 직접 진행하십시오.

최종 검토는 필수 단계 전환 게이트이지 금지된 프로세스 질문이 아닙니다. 작업 생성 동의, 초기 구현 요청 및 최신 최종 요약 이전에 주어진 승인은 이 게이트를 충족하지 않습니다.

사고 프레임워크: 첫 번째 원칙 분석

요구사항이 모호하거나, 솔루션이 과도하게 엔지니어링된 느낌이 들거나, "모두가 하니까" 복잡성을 추가하려고 할 때 — 추론하기 전에 근본적인 진실로 분해하십시오.

1단계: 문제 재진술

구현 세부 사항을 제거하여 한 문장으로 만드십시오.

나쁨: "사용자 프로필 엔드포인트에 Redis 캐싱을 추가해야 합니다" 좋음: "사용자 프로필 데이터를 로드하는 데 시간이 너무 오래 걸립니다"

2단계: 근본적인 진실 목록 작성

절대적으로 사실인 것은 무엇입니까? (의견이나 관습이 아닌)

카테고리	예시
물리적 제약	네트워크 지연 ≥ 0, 디스크 I/O에는 한계가 있음
비즈니스 규칙	"사용자는 자신의 데이터를 볼 수 있어야 함"
기술적 불변 조건	"데이터는 일관성을 유지해야 함"
사용자 요구	"사용자는 Y초 이내에 X를 원함"

3단계: 가정에 도전하기

현재 계획의 각 구성 요소에 대해:

• 사실인가 관습인가? "우리는 항상 REST를 사용합니다" — 왜?
• 이것을 제거하면 어떻게 될까? 아무것도 깨지지 않으면 불필요한 것입니다.
• 실제 문제를 해결하는가 아니면 증상을 해결하는가? 인과 관계를 추적하십시오.
• 이 복잡성의 혜택을 보는 사람은 누구인가? "아무도 없다"면 단순화하십시오.

4단계: 진실에서 구축하기

1. 모든 진실을 충족하는 최소 실행 가능한 메커니즘으로 시작하십시오.
2. 특정 진실이 요구할 때만 복잡성을 추가하십시오.
3. 각 추가 사항은 "어떤 진실이 이것을 요구하는가?"에 답해야 합니다.

5단계: 검증

• 솔루션이 원래 문제를 해결합니까?
• 어떤 가정을 검증해야 합니까?
• 이를 테스트하는 가장 간단한 실험은 무엇입니까?

요구사항 수렴 게이트

최종 검토 전에 다음 모두를 확인하십시오:

• 사용자 결과와 제품 가치가 명시적임
• 범위 내 및 범위 외 동작이 명시적임
• 승인 기준이 관찰 가능한 결과를 설명함
• 사용자 소유 제품, 범위, UX, 호환성 및 위험 결정이 해결됨
• 차단하는 미해결 질문이 없음
• 기술적 미지 사항이 조사되었거나 MVP 동작을 변경하지 않고 명시적으로 연기됨

경량 작업은 design.md 및 implement.md를 생략할 수 있습니다. 증거 검사, 요구사항 수렴, 최종 검토 또는 새로운 구현 승인을 건너뛸 수 없습니다.

최종 계획 요약에는 목표, 범위 내, 범위 외, 승인 기준, 주요 결정, 관련 위험 또는 연기된 항목 및 아티팩트 상태가 표시되어야 합니다.

아티팩트 규칙

prd.md는 요구사항과 승인을 기록합니다:

• 목표 및 사용자 가치
• 확인된 사실
• 요구사항
• 승인 기준
• 범위 외
• 계획을 여전히 차단하는 미해결 질문

design.md는 복잡한 작업에 대한 기술 설계를 기록합니다:

• 아키텍처 및 경계
• 데이터 흐름 및 계약
• 호환성 및 마이그레이션 노트
• 중요한 트레이드오프
• 운영 또는 롤백 고려 사항

implement.md는 복잡한 작업에 대한 실행 계획을 기록합니다:

• 정렬된 구현 체크리스트
• 검증 명령어
• 위험한 파일 또는 롤백 지점
• task.py start 전 후속 확인

경량 작업은 prd.md만 있을 수 있습니다. 복잡한 작업은 task.py start 전에 prd.md, design.md 및 implement.md가 있어야 합니다.

implement.md는 implement.jsonl을 대체하지 않습니다. 하위 에이전트 디스패치 워크플로에서 implement.jsonl 및 check.jsonl에는 각각 task.py start 전에 최소한 하나의 실제 명세/연구 항목이 있어야 합니다. 빈 매니페스트 또는 레거시 _example 자리 표시자 행만 있는 매니페스트는 유효하지 않습니다. 인라인 워크플로는 페이즈 2가 trellis-before-dev를 통해 컨텍스트를 로드하므로 이 JSONL 게이트를 건너뜁니다.

PRD 수렴 패스

계획 준비가 완료되었다고 선언하거나 task.py start를 실행하기 전에, 위의 아티팩트 규칙에 설명된 최종 구조에 맞춰 prd.md를 한 번 재작성하십시오. 이는 선택적 정리가 아닙니다. 이는 최종 계획 게이트입니다.

패스는 무손실이어야 합니다:

• 반복되는 사실을 하나의 권위 있는 섹션으로 축소하십시오.
• 내가 이미 알고 있는 것, 가정 및 해결된 미해결 질문과 같은 임시 브레인스토밍 섹션을 목표, 배경, 요구사항, 기술 노트 또는 승인 기준으로 접으십시오.
• 빈 섹션이나 이미 답변된 섹션을 남기지 말고 해결된 미해결 질문을 제거하십시오.
• 동일한 작업을 설명하는 병렬 버그 및 요구사항 목록을 병합하십시오. 각 결함의 심각도, 증거 및 파일:라인 앵커를 소유 요구사항에 유지하십시오.
• 모든 파일:라인 앵커, 결정, 제약 조건, 요구사항 ID 및 승인 기준 매핑을 보존하십시오.
• 차단하는 미해결 질문이 있는 동안 최종 검토로 진행하지 마십시오.

패스 후 prd.md를 처음부터 끝까지 읽고, 반복이 새로운 정보를 추가하지 않는 한 섹션 간에 사실이 반복되지 않는지 확인하십시오.

품질 기준

계획 준비를 선언하기 전:

• prd.md에 테스트 가능한 승인 기준이 포함되어 있습니다.
• prd.md가 PRD 수렴 패스를 통과했습니다: 해결되지 않은 임시 브레인스토밍 섹션, 섹션 간 중복 사실, 손실된 앵커, 결정 또는 승인 매핑이 없습니다.
• 저장소가 대답할 수 있는 질문은 이미 검사를 통해 답변되었습니다.
• 차단하는 미해결 질문이 없습니다.
• 복잡한 작업에는 design.md 및 implement.md가 있습니다.
• 하위 에이전트 디스패치 작업에는 implement.jsonl 및 check.jsonl 모두에 실제 큐레이팅된 항목이 있습니다. 시드 전용 매니페스트는 준비되지 않았습니다.
• 최신 최종 계획 요약이 사용자에게 제시되었습니다.
• 후속 메시지에서 사용자가 구현을 위해 해당 요약을 명시적으로 승인했습니다.

사용자가 원래 구현을 요청했다는 이유만으로 구현을 시작하지 마십시오.