요구사항에서 배포까지
먼저 사용자가 무엇을 바꾸려는지, 완료가 무엇을 의미하는지 명확히 한 후 실행하세요. 승인된 작업을 지속적으로 완료하고, 결정이 필요한 경우 해당 결정에 의존하지 않는 부분을 먼저 완료하세요. "계획을 작성했다", "코드가 컴파일된다", "자동 병합이 활성화되었다"를 최종 인도로 간주하지 마십시오.
작업 규칙
- 목표, 위험 및 피드백 비용에 따라 개발 방법을 선택하세요. 사양을 먼저 작성하거나, 명확한 공용 인터페이스에서 테스트 주도 개발을 하거나, 직접 구현 후 검증할 수 있습니다. 방법은 조합 가능합니다. 항상 관찰 가능한 완료 조건을 명확히 하고 실제 동작 증거를 확보하며, 특정 프로세스를 모든 작업에 강요하지 마십시오.
- 현재 코드, 실행 결과 및 실제 릴리스 아티팩트를 사용하여 "현재 무엇인지"를 설명하고, 사용자가 확인한 목표를 사용하여 "무엇이 되어야 하는지"를 설명하세요. 차이점을 발견하면 구현 또는 오래된 기록을 수정하고, 사용자 목표를 오래된 문서로 덮어쓰지 마십시오.
- 규모에 따라 프로세스를 선택하세요. 작은 수정은 사양을 몇 문장으로 작성할 수 있습니다. 여러 모듈에 걸친 요구사항만 슬라이스로 나누고 설계 및 기록하세요. 모든 편집에 모든 지식을 로드하거나, 고정된 승인 체인을 설정하거나, 빈 템플릿을 채우지 마십시오.
- 사용자가 이미 승인한 범위는 계속 유효합니다. 연구, 구현, 가역적 검증에 대해 반복 확인하지 마십시오. 외부 릴리스는 사용자의 명시적 목표에 따라 실행하세요. 프로덕션 목표나 권한이 아직 부족한 경우, 먼저 아티팩트, 차이점, 롤백 및 검사를 준비한 후 무엇이 부족한지 설명하세요.
- 이 스킬은 독립적으로 사용할 수 있습니다. 아래 표에 있는 스킬이 설치된 경우 필요에 따라 호출하고, 설치되지 않은 경우 해당 단계의 결과를 직접 완료하며 사용자가 전체 스킬 세트를 갖추도록 요구하지 마십시오.
- 하나의 작업은 현재 담당자가 지속적으로 추진합니다. 전문화된 방법은 현재 단계의 증거와 산출물을 보완하며, 이미 확인된 결정과 동일한 기록을 사용하고 경쟁적인 프로세스를 추가하지 마십시오.
다음 단계 선택
| 현재 상황 | 진행 방식 | 호출 가능 스킬 |
|---|---|---|
| 어떤 능력을 사용해야 할지 모르거나 사용 방법만 알고 싶음 | 작업에 따라 최소 진입점 선택; 먼저 사용 방법을 설명하고, 상담을 구현 권한으로 오해하지 마십시오 | dev-help |
| 환경, 역할 모델 또는 추론 예산을 처음 구성함 | 실제 사용 가능한 도구와 모델을 확인하고 간결한 선호도를 저장하십시오. 특정 공급업체 또는 백엔드 기능을 가정하지 마십시오 | dev-setup |
| 반복 작업을 점진적으로 자신의 습관에 맞추고 싶음 | 읽기가 허용된 기록에서 안정적인 패턴을 추출하여 간결하고 유지보수 가능한 프로젝트 스킬을 형성하십시오 | dev-personalize |
| 사용자가 작업 진행 상황을 묻거나 인계 브리핑이 필요함 | 완료된 사항, 현재 증거 및 미결 사항을 요약하십시오. 답변 후 명시적 일시 중지 요청이 없는 한 원래 작업을 계속하십시오 | dev-status |
| 입력이 채팅, Issue, 스크린샷, 로그 또는 여러 피드백에서 옴 | 원본 증거, 실제 동작, 목표 및 범위를 찾고 중복 요청을 병합하십시오 | dev-intake |
| 보고서 통합을 구성하거나 소스별로 요구사항을 모니터링해야 함 | 소스, 추적기, 리포지토리 라우팅, 제어 방식 및 실제 트리거를 별도로 선택하고 승인된 범위 내에서 초기화를 완료하십시오 | dev-issue-setup |
| 구성된 소스 어댑터의 보고서를 분류, 중복 제거 또는 라우팅해야 함 | 기본 보고서, ID 및 추적기 계약에 따라 증거를 처리하십시오. 소스는 채팅, 티켓, 이메일, 알림 또는 수동 입력일 수 있습니다. 이 단계에서는 재현하거나 수정하지 마십시오 | dev-issue-triage |
| 구성된 보고서 파이프라인, 신뢰할 수 있는 트라이지 및 실제 UI 제어 조건이 모두 갖춰짐 | 소유권을 확인하고 전체 프로토콜에 따라 기존 패치를 재현하거나 검증하십시오. 필요하고 승인된 경우 수정하고 초안 PR을 전달하십시오 | dev-issue-fix |
| 제품 규칙에 중요한 모호함이 있음 | 먼저 코드에서 사실을 답변하고, 계획을 변경할 문제에 대해 라운드별로 명확히 하십시오 | dev-grill |
| 요구사항이 명확하지만 아직 직접 검증할 수 없음 | 사용자 행동, 경계, 비목표 및 성공 조건을 작성하십시오 | dev-spec |
| 사용자가 실행할 요청을 심화하거나 다시 작성하려고 함 | 네 가지 질문을 사용하여 전문적인 누락, 원본 자료, 구체적인 방법 및 독립적 증거를 확인하고 사용 가능한 프롬프트를 전달하십시오 | dev-sharpen |
| 익숙하지 않은 모듈 인수 | 실제 사용 사례 하나를 따라 진입점, 비즈니스 로직, 저장소, 피드백 및 실패 경로를 통과하십시오 | dev-learn |
| 과거 설계가 왜 존재하는지 이해하지 못함 | 현재 동작, 당시 근거 및 추측을 구분하고 코드와 획득 가능한 결정 증거를 추적하십시오 | dev-why |
| 경계 또는 인터페이스에 실질적인 트레이드오프가 있음 | 다른 구조를 비교하십시오. 호출자 경험, 상태 소유권 및 도메인 용어로 판단하십시오 | dev-architecture |
| TLA+ 모델이 있거나 명확히 구축해야 하며 검사 결과가 포함된 상태 차트가 필요함 | TLC를 실행하고, 규칙 마커와 최단 반례를 생성하며, 실제 코드를 단계별로 확인하십시오 | dev-statechart |
| 주요 속성을 확인하거나, 형식 도구를 선택하거나, 모델을 유지해야 함 | 속성, 가정 및 경계를 명확히 하고, 검사를 실행하며, 모델 드리프트를 식별하십시오. 일반 설명 다이어그램은 자동으로 이 프로세스에 들어가지 않습니다 | dev-formal-verify |
| 페이지, 상호 작용, 디자인 시스템 또는 시각적 승인과 관련됨 | 실제 코드의 컴포넌트와 토큰을 사용하고, 제품 또는 마케팅 시나리오에 따라 디자인 사양을 읽으십시오. 디자인 도구 계정이 필요하지 않습니다 | dev-ui-design |
| 요구사항을 한 번에 안정적으로 전달할 수 없음 | 승인 가능한 수직 기능 슬라이스로 분할하고, 명시적 종속성을 설정하며, 최소한의 완전한 경로를 먼저 실행하십시오 | dev-plan |
| 서로 충돌하지 않는 작업 또는 비교할 가치가 있는 다른 계획이 있음 | 할당 범위와 승인 규칙을 작성한 다음 통합하고 최종 결과를 검증하십시오 | dev-parallel |
| 사양 또는 슬라이스가 구현 준비가 됨 | 기존 엔지니어링 규칙에 따라 구현하고, 실제 동작에 연결하고, 현재 아티팩트를 검증하십시오 | dev-build |
| 일반적인 Issue, CLI/API/UI 기능 오류 또는 승인 실패 | 실제 진입점을 따라 재현하고 근본 원인을 찾으십시오. 성능 메트릭만 목표로 하는 경우 측정 프로세스로 이동하십시오 | dev-debug |
| 사용자가 테스트 주도 개발을 지정했거나 현재 구현이 TDD를 선택함 | 공용 인터페이스별로 실패 테스트와 최소 구현을 완료하십시오. 올바른 동작에 대한 보충 테스트는 자동으로 적녹 구현으로 들어가지 않습니다 | dev-tdd |
| 유사한 오류가 반복되거나 주요 제약 조건이 우회되기 쉬움 | 유형, 인터페이스 및 상태 소유권을 개선하는 것을 우선시하고, 실제 가치가 있는 경우 실행 가능한 규칙을 추가하십시오 | dev-guardrails |
| 구현 완료 | 사양 준수와 엔지니어링 품질을 별도로 확인하고, 실제 문제를 수정하십시오 | dev-review |
| 실제 사용자 경로가 작동함을 입증해야 함 | 실제 애플리케이션을 구동하고, 결과와 부작용을 확인하며, 반복 가능한 검증 방법을 유지하십시오 | dev-verify |
| 목표가 지연 시간, 처리량, 리소스 또는 기타 측정 메트릭 개선임 | 고정된 작업 부하와 측정 기준을 설정하고, 증거 수집, 최적화 또는 공정한 비교를 완료하며, 동일한 기준선을 재사용하십시오 | dev-benchmark |
| 목표에 출시가 포함됨 | 환경과 버전을 확인하고, 승인된 배포를 실행하며, 실제 서비스를 검증하고 기록하십시오 | dev-deploy |
| 명확한 문서, 커밋 메시지 또는 PR 브리핑이 필요함 | 독자의 질문에 따라 정보를 구성하고, 구체적인 동작, 증거 및 필요한 트레이드오프를 제공하십시오 | dev-writing |
| 요구사항이 전달되었거나 명시적으로 중단됨 | 새로운 지식을 정리하고, 충돌을 수정하며, 가치 있는 근거를 보존하고 프로세스를 아카이브하십시오 | dev-archive |
기존 사양이 있으면 직접 구현하고, 설계만 요청하면 설계를 전달하며, 설명만 요청하면 설명에서 멈추십시오. 병렬 처리 및 중단을 처리하려면 진행 및 복구를 읽으십시오. 요구사항을 개선해야 하는 경우 요구사항에서 구현 단계 연결을 읽고, 선택한 작업을 실행할 때 엔지니어링 실행 방법을 읽으십시오. 이들은 현재 단계를 보완하며 이미 완료된 단계를 다시 선택하지 않습니다.
복잡한 작업에 적합한 기존 프로세스가 없는 경우 사용자 정의 실행 방법을 사용하여 검증 가능한 단위를 형성하고 승인된 작업을 계속하십시오. 장기 작업의 기록 및 사후 검토는 결정 증거 방법을 사용하여 결정, 대안 및 실제 증거가 일치하는지 확인하십시오. 검토만 요청하는 경우 감사 결과를 전달하고 자동으로 마이그레이션이나 구현을 계속하지 마십시오. 특정 설계가 당시에 왜 채택되었는지 추적하는 것은 dev-why가 담당합니다. 사용자가 명시적으로 실행 가능한 상태 패널을 구축하려는 경우 구현 작업으로 처리하고, 진행 상황만 조회하려면 dev-status를 사용하십시오.
작업을 계속 가능하게
이 스킬 세트로 새로 추가되는 프로젝트 자료는 .agents/wtadev/를 루트로 하여 필요에 따라 다음 파티션을 사용하십시오. 기존 자료는 실제 위치에서 참조하고 필요한 참조를 보존하십시오. 명시적 마이그레이션 요청이 있을 때만 이동하고 내용, 식별자 및 유효한 링크를 보존하십시오. 사용자가 이번에 다른 위치를 명시적으로 지정한 경우 해당 지시에 따라 실행하십시오.
.agents/wtadev/changes/<날짜-주제>/: 현재 요구사항의 brief, spec, plan, progress, evidence. 필요 시 생성..agents/wtadev/notes/: 검증된 용어, 배경, 결정, 오류 경험 및 모듈 이해.index.md는 경로만 안내..agents/wtadev/deploy/<환경>/: 배포 매뉴얼 및releases/아래의 과거 릴리스 기록..agents/wtadev/archive/changes/,.agents/wtadev/archive/notes/: 종료된 작업 및 이전 지식. 현재 동작을 나타내지 않음을 명시.
이는 대상 프로젝트의 자료이며 설치 패키지 .agents/skills/에 기록할 수 없습니다. 복구가 필요한 경우 인계 템플릿을 사용하여 현재 결과, 증거, 미결 문제 및 다음 단계만 남기십시오.
마무리
초기 전달 목표와 대조하여 실제 변경 사항, 현재 버전의 검증 증거, 전달 주소 또는 커밋, 및 실제로 완료되지 않은 부분을 제공하십시오. 출시가 필요하지만 아직 배포되지 않은 경우 "구현 완료, 배포 미완료"라고 명시적으로 작성하십시오. 배포가 성공한 후 재사용 가능한 지식과 최신 코드 참조를 프로젝트에 통합하고 채팅 기록 전체를 AGENTS.md에 채워 넣지 마십시오.
전체 로컬 자료
자료 인덱스에 따라 이 스킬 내의 전체 프로세스, 검사 규칙, 예제 및 템플릿을 선택하십시오. 모든 실행에 필요한 리소스는 이 패키지 내에 있으며 다른 스킬 설치에 의존하지 않습니다. 현재 작업 브랜치에 필요한 내용만 읽으십시오.