rpikit
[!WARNING]
사용 중단(Deprecated). 대신 bostonaholic/team을 사용하세요.
지대한 소프트웨어 엔지니어링을 위해 연구-계획-구현 (Research-Plan-Implement, RPI) 프레임워크를 구현하는 플러그인입니다.
철학 (Philosophy)
행동하기 전에 이해하고. 코딩하기 전에 계획하며. 규율을 가지고 구현하라.
이 플러그인은 성급한 구현을 방지하고 중요한 의사 결정 지점에서 인간의 감독(human oversight)을 보장하는 구조화된 워크플로우를 강제합니다.
설치 (Installation)
1단계: 마켓플레이스 추가
/plugin marketplace add bostonaholic/rpikit
2단계: 플러그인 설치
빠른 시작 (Quick Start)
| 슬래시 명령어 | 목적 |
|---|
/rpikit:research-plan-implement | 종단 간(End-to-end) 연구, 계획 및 구현 파이프라인 실행 |
| ... | |
워크플로우 (Workflow)
전체 파이프라인 (Full Pipeline)
flowchart LR
rpi["/rpikit:research-plan-implement"] -->|자동화됨(automated)| research[연구(Research)]
research -->|승인(approval)| plan[계획(Plan)]
...
/rpikit:research-plan-implement 스킬은 병렬 서브 에이전트(parallel subagents)를 사용하여 단일 세션에서 전체 파이프라인을 실행하며, 각 단계 사이에 승인 게이트(approval gates)가 존재합니다. 구현은 메인 브랜치를 보호하기 위해 격리된 작업 트리(isolated worktree)에서 실행됩니다.
개별 스킬 (Individual Skills)
flowchart LR
brainstorm["/rpikit:brainstorming"] -.->|선택적(optional)| research["/rpikit:researching-codebase"]
research -->|승인(approval)| plan["/rpikit:writing-plans"]
...
더 많은 제어를 원한다면, 각 단계를 개별 스킬로 실행하세요. 각 단계는 docs/plans/에 아티팩트(artifacts)를 생성하며, 다음 단계로 전환하기 전에 인간의 승인을 필요로 합니다.
브레인스토밍 대 연구 (Brainstorming vs. Research)
두 명령어 모두 행동하기 전에 명확화 질문을 하는 것으로 시작합니다. 핵심적인 차이점은 그 목적입니다:
| 브레인스토밍 | 연구 |
|---|
| 무엇을 구축해야 할까요? | 어떻게 작동하나요? |
| ... | |
| 브레인스토밍 사용 시: | |
- 요구사항이 모호함: "사용자 인증 추가" → 어떤 종류? OAuth? JWT? 세션?
- 여러 접근 방식이 존재함: "성능 개선" → 어느 영역? 어떤 트레이드오프(trade-offs)?
- 리서치하기 전에 필요한 설계 결정
Research를 사용해야 할 때:
- 무엇을 만들지 알지만 코드베이스에 대한 이해가 필요할 때
- "인증은 어디에 구현되어 있나요?" → 파일을 찾고 흐름(flow)을 추적함
- "기존 캐싱 방식은 어떻게 작동하나요?" → 패턴을 문서화함
일반적인 흐름: 먼저 브레인스토밍(Brainstorm) (불분명할 경우) → Research → Plan → Implement
출력 구조
docs/plans/
├── YYYY-MM-DD-<topic>-research.md # 파일:라인 참조와 함께 리서치 결과
└── YYYY-MM-DD-<topic>-plan.md # 작업 및 기준이 포함된 구현 계획
...
사용 예시
전체 파이프라인 (권장)
단일 세션에서 전체 research-plan-implement 워크플로우를 실행합니다:
/rpikit:research-plan-implement Add OAuth login with Google and GitHub providers
이는 병렬 리서치 서브에이전트(subagents)를 생성하고, 발견된 내용을 종합하며, 계획을 만들고, 구현까지 수행합니다. 각 단계 사이에는 승인 게이트(approval gates)가 있습니다.
단계별 워크플로우
더 많은 제어를 위해 각 단계를 개별적으로 실행합니다:
/rpikit:researching-codebase I want to add OAuth login - what auth patterns exist?
docs/plans/에서 리서치 결과를 검토한 후, 이를 바탕으로 계획을 작성합니다:
/rpikit:writing-plans @docs/plans/2025-01-07-oauth-login-research.md
계획을 검토하고 승인한 다음, 이를 기반으로 구현합니다:
/rpikit:implementing-plans @docs/plans/2025-01-07-oauth-login-plan.md
임시 코드 리뷰 (Ad-hoc Code Review)
품질 문제를 위해 현재 변경 사항을 검토합니다:
보안 취약점을 위해 검토합니다:
결정 기록 (Recording Decisions)
계획 수립 또는 설계 작업 후, ADR(Architecture Decision Record)로 결정을 기록합니다:
/rpikit:documenting-decisions @docs/plans/2025-01-07-oauth-login-design.md
이해관계 기반 계획 수립 (Stakes-Based Planning)
이 프레임워크는 변화하는 복잡도에 적응합니다:
- 낮은 위험도 (문서화, 형식 지정): 최소한의 계획, 빠른 실행
- 중간 위험도 (새로운 기능, 리팩토링): 전체 RPI 워크플로우 적용
- 높은 위험도 (아키텍처, 보안): 철저한 연구와 상세한 계획
스킬(Skills)
이 플러그인은 체계적인 개발을 안내하는 방법론적 스킬들을 포함합니다:
핵심 RPI 워크플로우 (Core RPI Workflow)
- research-plan-implement: 모든 RPI 단계를 병렬 서브 에이전트로 오케스트레이션하는 엔드투엔드 파이프라인
- researching-codebase: 질의응답을 통한 철저한 코드베이스 연구
- synthesizing-research: 병렬 연구 결과를 통합된 보고서로 정리
- writing-plans: 세분화되고 검증 가능한 구현 계획 작성
- implementing-plans: 체크포인트 검증을 통한 체계적인 실행
- reviewing-code: 컨벤셔널 커멘트(Conventional Comments)를 사용한 품질 검토
- security-review: 취약점을 위한 보안 중심의 검토
개발 규율 (Development Discipline)
- test-driven-development: RED-GREEN-REFACTOR 사이클 강제 적용
- systematic-debugging: 수정 전에 근본 원인 조사(Root cause investigation)
- verification-before-completion: 주장보다 증거를 우선시함
워크플로우 지원 (Workflow Support)
- brainstorming: 연구/계획에 앞선 협업적 디자인
- documenting-decisions: 아키텍처 결정(ADRs)으로 기록
- finishing-work: 구조화된 완료 (병합, PR, 정리)
- receiving-code-review: 피드백에 대한 검증 우선 응답
고급 패턴 (Advanced Patterns)
- git-worktrees: 병렬 작업을 위한 격리된 작업 공간
- parallel-agents: 독립적인 작업을 위한 동시 디스패치(Concurrent dispatch)
아키텍처 (Architecture)
스킬, 에이전트, 후크가 어떻게 연결되는지에 대한 자세한 개요는 Architecture를 참조하세요.
참고 자료 (Inspired By)
라이선스
MIT