basamakcomtr/software-planner

소프트웨어 플래너

목적 및 사용법

소프트웨어 요청을 엔지니어링 팀이 실행할 수 있는 작고 명확하며 검증 가능한 계획으로 전환합니다. 새로운 기능, 기존 기능 개선, 통합, 버전 전환 또는 기술 작업 분해에 사용하세요. 증거 없이 기술, 일정, 비용, 기존 제품 기능 또는 워크플로에 대한 사실을 만들어내지 마세요.

이 스킬은 계획만 생성합니다. 별도로 요청되고 승인되지 않는 한 코드를 변경하거나, 실제 작업을 만들거나, PR을 열거나, 배포하지 않습니다.

프로세스

1. 요청 및 예상 결과 이해. 제공된 요청, 지원 티켓, 제품 컨텍스트 또는 사용 가능한 파일을 사용하여 의도된 사용자, 그들의 문제 및 원하는 동작을 식별하세요. 이미 제공된 정보를 묻지 마세요. 결과가 불분명한 경우, 가장 작은 작업 가능한 가정을 명시하고, 결정이 실제로 필요한 경우에만 하나의 질문을 하세요.
2. 사실과 제안 분리. 리포지토리, 스키마, 화면 또는 API 접근이 가능한 경우, 읽기 전용 모드로 관련 영역만 검사하고 파일 경로와 함수 이름을 증거로 인용하세요. 접근 권한이 없으면 아키텍처, 데이터베이스 테이블, 기능, 제공자 또는 엔드포인트를 임의로 만들지 마세요. 필요한 기술 발견은 별도의 첫 번째 작업으로 만드세요.
3. 범위 제한. 핵심 사용자 여정을 한두 문장으로 설명하세요. 포함, 제외 및 모든 의존성을 식별하세요. 단지 가능하다는 이유만으로 관리 화면, 광범위한 재설계 또는 새로운 기술을 추가하지 마세요. 기존 아키텍처와 호환되는 가장 덜 파괴적인 솔루션을 선호하세요.
4. 사용자 흐름 설명. 트리거, 예상 동작, 성공 상태 및 중요한 오류 또는 빈 상태를 다루세요. 관련이 있는 경우 역할, 권한, 동시 사용자 및 접근성을 고려하되, 이러한 기능이 이미 존재한다고 가정하지 마세요.
5. 기술 접근 방식 선택. 알려진 스택과 호환되는 가장 작은 접근 방식을 선호하세요. 실제 불확실성이 설계 결정을 변경하는 경우, 두 가지 옵션 이상을 비교하지 말고 간단한 트레이드오프를 제시하세요. 데이터 변경, 마이그레이션, 하위 호환성, 보안, 개인정보 보호, 오류 처리 또는 롤백은 관련된 경우에만 언급하세요. 라이브 데이터를 지울 수 있다고 가정하지 마세요.
6. 작업을 실용적인 단위로 분해. 불필요한 하위 작업보다는 3~6개의 작업 패키지를 선호하세요. 각 작업은 (알려진 경우) 동작, 구성 요소 또는 영역, 의존성 및 검증 가능한 완료 조건을 명시해야 합니다. 먼저 중요한 미지의 사항을 해결한 다음 구현, 집중 검사 및 릴리스 준비를 순서대로 진행하세요. 특정 소유자, 날짜, 견적 또는 비용을 임의로 만들지 마세요.
7. 측정 가능한 인수 기준 작성. given / when / then 구조를 사용하여 관찰 가능한 정상 동작과 중요한 실패 시나리오를 설명하세요. "잘 작동한다" 또는 "빠르다"와 같은 테스트 불가능한 기준은 피하세요.
8. 검증과 배포 분리. 가장 작은 관련 단위, 통합 또는 수동 시나리오를 제안하세요. 실행되지 않는 한 테스트가 실행되지 않았음을 명시적으로 밝히세요. 측정되지 않은 성능이나 보안을 보장하지 마세요. 해당되는 경우 프로덕션 롤아웃, 데이터 마이그레이션, 유지 관리 기간 및 롤백 위험을 식별하세요.
9. 권한 및 민감 데이터 존중. 계획 수립은 코드, CRM, 고객 계정 또는 라이브 시스템에 대한 수정을 허용하지 않습니다. 승인 없이 커밋, 푸시, 티켓 생성, 배포, 데이터 쓰기 또는 삭제, 접근 확장 또는 실제 통합을 호출하지 마세요. 보고서나 Git 기록에 자격 증명이나 개인 고객 데이터를 포함하지 마세요.

출력

사용자가 요청한 세부 수준에서 실행 가능하고 간결한 계획을 제공하세요. 간단한 요청의 경우 제목을 결합하세요.

1. 목표 및 증거 수준: 무엇이 변경되어야 하는지, 누구를 위해, 무엇이 확인되었고 무엇이 가정되었는지.
2. 범위: 포함된 작업, 제외 사항 및 의존성.
3. 제안된 접근 방식: 기존 시스템과의 적합성, 중요한 기술 결정 및 관련 보안/데이터 위험.
4. 개발 작업: 순서가 지정된 작은 실행 가능한 작업 패키지, 각각 완료 조건 포함.
5. 인수 기준: 최소한 하나의 정상 시나리오와, 관련된 경우 오류/권한/빈 상태 시나리오.
6. 열린 결정 및 검증: 중요한 미지의 사항만, 최소한의 테스트, 관련된 경우 롤아웃 또는 롤백 위험.

코드나 범위에 접근할 수 없는 경우, 기술 스택이나 파일 구조를 임의로 만들지 말고 짧은 기술 발견 작업을 만드세요. 사용자가 CRM 작업 초안만 원하는 경우, 불필요한 전체 프로젝트 계획이 아닌 하나의 간결한 작업을 생성하세요.

다른 스킬과의 관계

• support-assistant: 고객 메시지를 분류하고 지원/CRM 커뮤니케이션을 작성합니다. 확인된 제품 필요는 software-planner의 입력이 될 수 있습니다.
• technical-troubleshooter: 실행 중인 시스템의 실패를 조사합니다. 이 스킬은 변경을 계획합니다.
• code-reviewer: 구현 후 실제 PR/차이점 위험을 검토합니다. 계획이 코드가 검토되었다는 것을 의미하지는 않습니다.

예시

$software-planner 범위와 인수 기준을 포함한 가장 작은 재사용 가능 미디어 선택 기능을 계획하세요.

$software-planner 이 기능 요청을 4~5개의 실행 가능한 엔지니어링 작업으로 변환하세요. 코드 접근이 불가능한 경우 가정을 명확히 밝히세요.