aidlc-devflow

아이디어를 설계로 전환하거나, 새로운 기능을 만들거나, 구현 전 구조화된 설계가 필요한 창의적/탐색적 작업에 사용. Use when turning an idea into a design, creating a new feature, or when any creative/exploratory work needs structured design before implementation.

태스크나 unit 구현이 완료되어 머지 전 코드 리뷰가 필요할 때, 또는 사용자가 명시적으로 코드 리뷰를 요청할 때 사용. Use when a task or unit implementation is complete and needs code review before merging, or when the user explicitly requests a code review on their changes.

설계 문서를 상세 구현 계획으로 변환하거나, "구현 계획 작성", "plan 만들어줘" 요청 시 사용. INCEPTION 워크플로우 계획은 aidlc-workflow-planning 사용. Use when a design document needs to be converted into a detailed implementation plan with task breakdown, or when "구현 계획 작성", "plan 만들어줘" is requested. Not for INCEPTION workflow planning — use aidlc-workflow-planning instead.

Use when user explicitly requests "auto 모드", "자동 모드", "auto mode", or "알아서 만들어줘". 초보자를 위한 완전 자동 devflow. greenfield 전용. 요구사항 입력 → inception → construction → build-test를 자동 진행하며 각 flow 종료 시 멀티에이전트 리뷰 필수.

현재 세션에서 구현 계획을 실행할 때 사용. 독립 태스크별 신규 서브에이전트 컨텍스트 활용. Use when executing an implementation plan in the current session with independent tasks that benefit from fresh subagent context per task.

프로덕션 코드 작성, 버그 수정, 리팩토링 시 사용 — 예외 없이 RED-GREEN-REFACTOR 사이클을 강제. Use when writing any production code, fixing bugs, or refactoring — enforces RED-GREEN-REFACTOR cycle with no exceptions.

AIDLC 워크플로우로 새 프로젝트를 시작하거나, 기존 devflow 세션을 재개하거나, "devflow 시작" 또는 "devflow 재개" 요청 시 사용. Use when starting a new project with AIDLC workflow, resuming an existing devflow session, or when "devflow 시작" or "devflow 재개" is requested.

버그 신고, 테스트 실패, 예상 밖 동작, 에러 발생, 수정 시도 실패 등 코드 변경 전 진단이 필요한 모든 증상에 사용. Use when a bug is reported, a test is failing, behavior is unexpected, an error is thrown, a fix attempt is not working, or any symptom requires diagnosis before a code change is made.

Use when CONSTRUCTION phase begins, to manage the full build cycle for each unit from implementation through verification.

Use when INCEPTION phase begins, to orchestrate workspace detection, requirements, planning, and design stages.

구현이 완료되고 모든 테스트가 통과한 후, 개발 브랜치를 머지, PR, 유지, 폐기 중 어떻게 처리할지 결정할 때 사용. Use when implementation is done and all tests pass, and a decision is needed on what to do with the development branch — merge, PR, keep, or discard.

Use when component and service structure needs to be designed before implementation, as a conditional INCEPTION stage after workflow-planning.

Use when code implementation is complete and needs to be built, tested, and verified before completion.

Use when a defined unit or feature needs code implementation with TDD, or when "코드 생성", "구현해줘", "code generation" is requested.

2개 이상 독립 태스크를 동시에 실행하거나, 다른 도메인을 별도로 조사하거나, 순차 대기가 시간 낭비일 때 사용. Use when two or more independent tasks can be executed simultaneously, when different domains need separate investigation, or when waiting for one task to complete before starting another would waste time.

Use when a unit needs detailed functional design including domain entities, business rules, and API contracts before code generation.

Use when non-functional requirements need to be defined based on domain context and project profile, or when importing existing NFR documents.

코드 리뷰 피드백, PR 코멘트, 인라인 제안, 또는 작성한 코드에 대한 비평을 받아 응답이나 조치가 필요할 때 사용. Use when receiving code review feedback, PR comments, inline suggestions, or any critique of written code that requires a response or action.

Use when user requirements need to be analyzed, structured into a requirements document, or when open questions from a previous analysis need resolution.

aidlc 스킬과 패턴을 superpowers 업데이트와 비교하거나, 격차를 추적하거나, superpowers 릴리스의 기능 도입을 계획할 때 사용. Use when comparing aidlc skills and patterns against superpowers updates, tracking gaps, or planning feature adoption from superpowers releases.

Use when the system needs to be decomposed into independently developable and testable units with dependency ordering.

Use when requirements need to be converted into INVEST-compliant user stories with acceptance criteria.

Use when an isolated workspace is needed for feature development, creating a git worktree with a new branch.

태스크 완료를 주장하거나, "될 것 같다", 수정 완료를 선언하거나, "테스트 통과"라고 말하기 전에 실제 검증 명령을 실행해야 할 때 사용. Use when about to claim a task is complete, say "it should work", declare a fix is done, say "tests pass", or make any success assertion before running the actual verification commands.

Use when INCEPTION needs to determine which stages to execute, their depths, and the overall development approach.

Use when starting INCEPTION to detect whether the workspace is greenfield or brownfield and analyze existing code structure.

Use when recording an interaction or decision to the devflow audit log during orchestrator execution.

디버깅 완료 후 해결 지식을 구조화하여 devflow-docs/solutions/{category}/에 저장한다. systematic-debugging이 근본 원인을 확정한 직후 orchestrator가 호출. STORE 인터페이스로 5개 필드를 받아 Solution-Writer로 개인정보를 제거한 뒤 Knowledge-Librarian이 중복 검사 후 YAML+Markdown 솔루션 파일로 저장한다.

Use when reading or writing devflow state during orchestrator execution, including phase tracking and stage completion.