개발계획서 작성 (STEP 4)
npx skills add https://github.com/unicorn-plugins/abra --skill dev-plan이 명령을 Claude Code에 복사하여 붙여넣어 스킬을 설치하세요
AI Agent 개발 및 배포 (STEP 5)
Dify DSL 자동생성 (STEP 2)
Dify 프로토타이핑 자동화 (STEP 3)
요구사항 시나리오 생성 및 선택 (STEP 1)
Dify 환경 구축 및 Abra 플러그인 초기 설정
Abra 플러그인 사용 안내
| name | dev-plan |
| description | 개발계획서 작성 (STEP 4) |
| user-invocable | true |
| type | orchestrator |
[dev-plan 활성화]
검증된 DSL과 시나리오를 기반으로 개발계획서를 작성함. 기술스택, 아키텍처, 모듈 설계, 테스트 전략, 배포 계획을 포함하는 포괄적 계획서를 산출함. 특히 DSL에 없는 시나리오 요구사항까지 식별하여, 개발 착수 전에 누락 범위와 추가 설계를 명확히 드러냄.
/abra:dev-plan 호출 시AGENTS.md 파일에서 ## 환경변수 섹션의 환경변수 로딩.
로딩 실패 시 사용자에게 /abra:setup을 먼저 수행하라고 안내하고 종료.
AI_RUNTIME 자동 감지 및 업데이트:
{ABRA_PLUGIN_DIR}/resources/guides/call-subagent.md의 "0. AI_RUNTIME 자동 감지" 규칙에 따라 현재 런타임을 감지하고 AGENTS.md의 AI_RUNTIME 값을 업데이트.
| 에이전트 | FQN |
|---|---|
| plan-writer | abra:plan-writer:plan-writer |
{ABRA_PLUGIN_DIR}/resources/guides/combine-prompt.md에 따라
AGENT.md + agentcard.yaml + tools.yaml 합치기Agent(subagent_type=FQN, model=tier_mapping 결과, prompt=조립된 프롬프트) 호출{ABRA_PLUGIN_DIR}/gateway/runtime-mapping.yaml 참조워크플로우 단계에 Agent: {agent-name}이 명시된 경우,
메인 에이전트는 해당 단계를 직접 수행하지 않고, {ABRA_PLUGIN_DIR}/resources/guides/call-subagent.md에 따라 서브 에이젼트 호출
{PROJECT_DIR}/AGENTS.md에 각 Phase 완료 시 저장. 최종 완료 시 Done으로 표기.
## 워크플로우 진행상황
- {skill-name}: Phase3
진행상황 정보가 있는 경우 마지막 완료 단계 이후부터 자동 재개.
검증된 DSL 파일과 scenario.md 파일의 존재 여부를 확인함.
검증 항목
{PROJECT_DIR}/output/<app>_v<MAX>.dsl.yaml 존재 확인
<app>_v*.dsl.yaml 중 버전 정수 최대값 파일을 로드{PROJECT_DIR}/output/scenario.md 존재 확인미존재 시
dsl-generate 스킬로 위임scenario 스킬로 위임DSL과 scenario.md를 함께 읽고 아래 4개 분류로 요구사항을 정리함.
분류 항목
dsl_covered: DSL에 이미 포함된 요구사항scenario_only: 시나리오에는 있으나 DSL에는 없는 요구사항custom_required: 커스텀 개발이 필요한 요구사항excluded_this_sprint: 이번 스프린트 제외 범위와 제외 사유필수 점검 대상
산출 형식
gap_analysis:
dsl_covered:
- <요구사항>
scenario_only:
- <요구사항>
custom_required:
- <요구사항>
excluded_this_sprint:
- feature: <요구사항>
reason: <제외 사유>
impact: <실패하거나 제한되는 시나리오>
scenario_only 또는 custom_required 항목이 있으면,
Phase 2 개발계획서에 구현 전략 또는 제외 영향도를 반드시 반영함.
또한 이 분석 결과를 바탕으로 Phase 1B의 특화질문 후보를 생성함.
모든 프로젝트에 공통으로 적용되는 질문만 수집함.
질문 항목
기술스택 선호
배포 환경
성능 요구사항
보안 요구사항
기타 제약 사항
Phase 0.5의 gap_analysis, scenario.md, DSL 구조를 분석하여
프로젝트마다 다른 특화질문을 동적으로 생성함.
원칙
주요 생성 대상 예시
산출 형식
special_questions:
- key: <snake_case_key>
source: "scenario" | "dsl" | "gap_analysis"
reason: <왜 이 질문이 필요한가>
question: <사용자에게 물을 질문>
options:
- <옵션 1>
- <옵션 2>
- <옵션 3>
default: <기본값>
응답 정규화 형식
nfr:
common:
stack: "Option A" | "Option B"
deployment: "로컬" | "Docker" | "Kubernetes" | "서버리스"
performance: "빠름(1s)" | "보통(3s)" | "느림(5s+)"
security: "높음" | "보통" | "낮음"
misc: <자유 텍스트>
special:
- key: <snake_case_key>
source: "scenario" | "dsl" | "gap_analysis"
reason: <질문 생성 근거>
answer: <선택 또는 자유 입력 결과>
impact: <설계에 주는 영향 요약>
{PROJECT_DIR}/output/dev-plan.md)nodes/ 파일 수)DSL 파일: {PROJECT_DIR}/output/<app>_v<MAX>.dsl.yaml
시나리오: {PROJECT_DIR}/output/scenario.md
갭 분석 결과: Phase 0.5의 gap_analysis YAML
공통 비기능요구사항:
nfr:
common:
stack: "Option A" | "Option B"
deployment: "로컬" | "Docker" | "Kubernetes" | "서버리스"
performance: "빠름(1s)" | "보통(3s)" | "느림(5s+)"
security: "높음" | "보통" | "낮음"
misc: <자유 텍스트>
special:
- key: <snake_case_key>
source: "scenario" | "dsl" | "gap_analysis"
reason: <질문 생성 근거>
answer: <선택 또는 자유 입력 결과>
impact: <설계에 주는 영향 요약>
출력 파일: {PROJECT_DIR}/output/dev-plan.md
개발계획서를 사용자에게 보고하고, 다음 리뷰 포인트를 확인함.
리뷰 포인트
DSL-계획 일관성
app/ 루트를 사용하고 app/main.py·app/api/routes.py를 포함하는가?
(develop 스킬 Phase 4/5 연결 전제)시나리오 충족성
비기능요구사항 반영
시간 기반 후속 작업 구현성
파일/이미지 입력 구현성
프로덕션 전환 전략
배포 실현 가능성
지속 저장·보안 설계
결과 보고 형식
# dev-plan 완료 보고
## 산출물
- 개발계획서: `{PROJECT_DIR}/output/dev-plan.md`
## 리뷰 포인트
- [✓/✗] DSL-계획 일관성
- [✓/✗] 시나리오 충족성
- [✓/✗] 비기능요구사항 반영
- [✓/✗] 시간 기반 후속 작업 구현성
- [✓/✗] 파일/이미지 입력 구현성
- [✓/✗] 프로덕션 전환 전략
- [✓/✗] 배포 실현 가능성
- [✓/✗] 지속 저장·보안 설계
## 다음 단계
- 개발계획서 검토 후 `/abra:develop` 호출하여 구현 시작
dev-plan.md)완료 시 임시 파일 없음 (상태 파일 미사용).
| # | 규칙 |
|---|---|
| 1 | 개발계획서에 9개 섹션(개요, 기술스택, 아키텍처, 모듈 설계, 프롬프트 최적화, API 설계서, 데이터 모델, 테스트 전략, 배포 계획)을 모두 포함한다 |
| 2 | Phase 0.5의 시나리오-DSL 갭 분석 결과를 반드시 반영한다 |
| 3 | Phase 1A 공통질문과 Phase 1B 특화질문 결과를 반드시 반영한다 |
| 4 | DSL 구조와 개발계획서의 모듈 설계 일관성을 확보한다 |
| 5 | 아키텍처 패턴에 Streaming HTTP MCP 서버를 포함하고 SSE는 사용하지 않는다 |
| 6 | §2(기술스택)의 LLM 래퍼는 DSL model.provider 값에서 도출한다 (OpenAI 하드코딩 금지) |
| 7 | 시나리오에 시간 기반 후속 작업이 있으면 스케줄러/워커/저장소 설계를 포함한다 |
| 8 | 시나리오에 파일·이미지 입력이 있으면 처리 전략 또는 제외 사유를 명시한다 |
| 9 | 보안 요구가 높음 또는 외부 API가 있으면 인증/권한/비밀관리/감사로그 설계를 포함한다 |
| 10 | 배포 스니펫과 CI 단계는 실제 실행 가능성 기준으로 점검한다 |
| 11 | 디렉토리 컨트랙트는 app/ 루트를 사용하며(app/main.py, app/api/routes.py 포함) develop 스킬과 일관성을 유지한다 |
| # | 금지 사항 |
|---|---|
| 1 | 코드를 작성하지 않는다 (개발은 별도 STEP) |
| 2 | DSL 파일을 수정하지 않는다 |
| 3 | 시나리오 파일을 수정하지 않는다 |
{PROJECT_DIR}/output/에 존재하는가app/ 루트이며 app/main.py·app/api/routes.py가 포함되었는가