تشغيل أي مهارة في Manus بنقرة واحدة

aidlc-brainstorming

النجوم٢

التفرعات٠

آخر تحديث١٣ مايو ٢٠٢٦ في ٠٥:١٤

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

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

bluejayA

bluejayA/aidlc-devflow

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

name	aidlc-brainstorming
description	아이디어를 설계로 전환하거나, 새로운 기능을 만들거나, 구현 전 구조화된 설계가 필요한 창의적/탐색적 작업에 사용. Use when turning an idea into a design, creating a new feature, or when any creative/exploratory work needs structured design before implementation.
metadata	{"version":"0.1.0","author":"Jay","category":"ai-dlc-workflow","invoke_mode":"user-invocable","return_behavior":"stop-with-gate","skill_nature":"amplification","lifecycle":"active"}

Brainstorming

아이디어를 설계 문서로 전환한다.

HARD-GATE: _shared/devflow-conventions.md Brainstorming HARD-GATE 참조. 설계 승인 전 코드 작성 금지.

시작 시 선언: "aidlc-brainstorming 스킬을 사용하여 설계를 진행합니다."

프로세스

Step 1: 프로젝트 컨텍스트 탐색

파일, 문서, 최근 커밋 확인
브라운필드인 경우: _shared/patterns/brownfield-exploration.md 참조
범위 판단: 여러 독립 서브시스템이면 먼저 분해 제안

Step 2: 명확화 질문

한 번에 하나만 질문
객관식 선호 (가능한 경우)
각 답변에 Ambiguity Resolution Loop 적용 (아래 참조)

Step 3: 복잡도 선언 + 접근법 제안

복잡도 선언 (접근법 제안 전 필수):

이 작업의 복잡도를 **[Minimal/Standard/Comprehensive]**로 판단했습니다.
이유: [한 줄]

다르게 조정하시겠습니까?

단계	기준	설계 분량	접근법
Minimal	단일 파일/함수, 명확한 경로	2-5문장	1-2개
Standard	새 컴포넌트, 복수 고려사항	표준 섹션	2-3개
Comprehensive	시스템 설계, 아키텍처 결정	전체 섹션 + 다이어그램	2-3개

사용자 승인 후 2-3개 접근법 제안. 추천안 + 이유 먼저 제시.

Step 4: 설계 제시

섹션별 제시, 각 섹션 승인 후 다음
섹션: architecture, components, data flow, error handling, testing
각 섹션 분량은 복잡도에 비례

설계 원칙:

단일 책임 단위로 분해
잘 정의된 인터페이스로 소통
독립적으로 이해/테스트 가능
YAGNI — 불필요한 기능 제거

Step 5: 설계 문서 작성

저장 경로: docs/plans/YYYY-MM-DD-<topic>-design.md
가정이 있으면 ## Assumptions 섹션 포함
문서 상단에 **Complexity:** [Minimal|Standard|Comprehensive] 기록
커밋

Step 5.5: Self-Review Checklist

저장된 설계 문서를 아래 4항목으로 셀프리뷰한다. 이슈 발견 시 즉시 인라인 수정 후 재저장. re-review 없이 다음 단계로 진행.

Placeholder scan — TBD, TODO, "추후 결정", 불완전 섹션, 모호한 요구사항이 남아있는가?
Internal consistency — 섹션 간 모순이 없는가? 아키텍처 설명과 기능 요구사항이 일치하는가?
Scope check — 이 설계가 단일 구현 계획(writing-plans)으로 분해 가능한가? 아니면 추가 분해가 필요한가?
Ambiguity check — 두 가지 이상 해석이 가능한 요구사항이 있는가?

수정 사항이 있으면 파일 업데이트 후 Step 6으로 진행.

Step 6: Spec Review + 사용자 리뷰 + 전환

Spec Review Loop (conventions 리뷰 루프 규약 참조):

Minimal / Standard / Comprehensive depth:
- _shared/reviewers/spec-document-reviewer-prompt.md를 서브에이전트로 dispatch
- ❌ Issues Found → 수정 후 re-dispatch (최대 3회)
- Recommendations만 → 루프 종료 (수정 권장)
- 3회 초과 → 사용자 escalate

사용자 리뷰 게이트 (리뷰 통과 후):

Codex CLI 감지(command -v codex) 시, 사용자 리뷰 게이트에 Codex 실행 가이드를 포함한다:

Spec이 `<경로>`에 저장되었습니다. 리뷰 후 변경사항이 있으면 알려주세요.

> **Codex 세컨드 오피니언**: 추가 검증이 필요하면:
> → /codex:adversarial-review
>   대상: <저장된 설계 문서 경로>
>   탐색 방향: 누락된 엣지케이스, 스케일 제약, 의존성 리스크

Codex 미감지 시 가이드 생략. 게이트 메시지만 표시:

사용자 승인 후 aidlc-writing-plans 스킬로 전환

Ambiguity Resolution Loop

명확화 질문의 답변을 받을 때마다 적용.

모호성 신호

"depends", "maybe", "not sure", "~하거나", "~일 수도", "상황에 따라"
키워드 없어도 설계 결정에 불충분하면 모호한 것으로 간주

후속 질문 방향

유형	예시 답변	후속 질문
선택 모호	"A나 B나 괜찮아요"	"어떤 기준으로 A를, 어떤 기준으로 B를?"
범위 모호	"적당히 빠르면 됩니다"	"구체적으로 어느 정도? (예: 1초 이내)"
우선순위 모호	"성능도 비용도 중요"	"둘이 상충할 때 어느 쪽 우선?"

탈출 조건

모든 모호함 해소 → 다음 단계
사용자가 "그냥 진행해" → 가정 목록 정리 → 승인 대기 → Assumptions에 기록

핵심 원칙

한 번에 하나만 질문
객관식 선호
YAGNI 엄격 적용
2-3개 대안 제시 후 선택
섹션별 점진적 검증

المزيد من هذا المستودع

نفس المستودع

aidlc-requesting-code-review

bluejayA/aidlc-devflow

태스크나 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.

2026-05-132

aidlc-writing-plans

bluejayA/aidlc-devflow

설계 문서를 상세 구현 계획으로 변환하거나, "구현 계획 작성", "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.

2026-05-132

aidlc-auto-mode

bluejayA/aidlc-devflow

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

2026-05-132

aidlc-subagent-driven-development

bluejayA/aidlc-devflow

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

2026-05-132

aidlc-test-driven-development

bluejayA/aidlc-devflow

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

2026-05-132

aidlc-using-devflow

bluejayA/aidlc-devflow

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.

2026-05-132

name	aidlc-brainstorming
description	아이디어를 설계로 전환하거나, 새로운 기능을 만들거나, 구현 전 구조화된 설계가 필요한 창의적/탐색적 작업에 사용. Use when turning an idea into a design, creating a new feature, or when any creative/exploratory work needs structured design before implementation.
metadata	{"version":"0.1.0","author":"Jay","category":"ai-dlc-workflow","invoke_mode":"user-invocable","return_behavior":"stop-with-gate","skill_nature":"amplification","lifecycle":"active"}

Brainstorming

아이디어를 설계 문서로 전환한다.

HARD-GATE: _shared/devflow-conventions.md Brainstorming HARD-GATE 참조. 설계 승인 전 코드 작성 금지.

시작 시 선언: "aidlc-brainstorming 스킬을 사용하여 설계를 진행합니다."

프로세스

Step 1: 프로젝트 컨텍스트 탐색

파일, 문서, 최근 커밋 확인
브라운필드인 경우: _shared/patterns/brownfield-exploration.md 참조
범위 판단: 여러 독립 서브시스템이면 먼저 분해 제안

Step 2: 명확화 질문

한 번에 하나만 질문
객관식 선호 (가능한 경우)
각 답변에 Ambiguity Resolution Loop 적용 (아래 참조)

Step 3: 복잡도 선언 + 접근법 제안

복잡도 선언 (접근법 제안 전 필수):

이 작업의 복잡도를 **[Minimal/Standard/Comprehensive]**로 판단했습니다.
이유: [한 줄]

다르게 조정하시겠습니까?

단계	기준	설계 분량	접근법
Minimal	단일 파일/함수, 명확한 경로	2-5문장	1-2개
Standard	새 컴포넌트, 복수 고려사항	표준 섹션	2-3개
Comprehensive	시스템 설계, 아키텍처 결정	전체 섹션 + 다이어그램	2-3개

사용자 승인 후 2-3개 접근법 제안. 추천안 + 이유 먼저 제시.

Step 4: 설계 제시

섹션별 제시, 각 섹션 승인 후 다음
섹션: architecture, components, data flow, error handling, testing
각 섹션 분량은 복잡도에 비례

설계 원칙:

단일 책임 단위로 분해
잘 정의된 인터페이스로 소통
독립적으로 이해/테스트 가능
YAGNI — 불필요한 기능 제거

Step 5: 설계 문서 작성

저장 경로: docs/plans/YYYY-MM-DD-<topic>-design.md
가정이 있으면 ## Assumptions 섹션 포함
문서 상단에 **Complexity:** [Minimal|Standard|Comprehensive] 기록
커밋

Step 5.5: Self-Review Checklist

저장된 설계 문서를 아래 4항목으로 셀프리뷰한다. 이슈 발견 시 즉시 인라인 수정 후 재저장. re-review 없이 다음 단계로 진행.

Placeholder scan — TBD, TODO, "추후 결정", 불완전 섹션, 모호한 요구사항이 남아있는가?
Internal consistency — 섹션 간 모순이 없는가? 아키텍처 설명과 기능 요구사항이 일치하는가?
Scope check — 이 설계가 단일 구현 계획(writing-plans)으로 분해 가능한가? 아니면 추가 분해가 필요한가?
Ambiguity check — 두 가지 이상 해석이 가능한 요구사항이 있는가?

수정 사항이 있으면 파일 업데이트 후 Step 6으로 진행.

Step 6: Spec Review + 사용자 리뷰 + 전환

Spec Review Loop (conventions 리뷰 루프 규약 참조):

Minimal / Standard / Comprehensive depth:
- _shared/reviewers/spec-document-reviewer-prompt.md를 서브에이전트로 dispatch
- ❌ Issues Found → 수정 후 re-dispatch (최대 3회)
- Recommendations만 → 루프 종료 (수정 권장)
- 3회 초과 → 사용자 escalate

사용자 리뷰 게이트 (리뷰 통과 후):

Codex CLI 감지(command -v codex) 시, 사용자 리뷰 게이트에 Codex 실행 가이드를 포함한다:

Spec이 `<경로>`에 저장되었습니다. 리뷰 후 변경사항이 있으면 알려주세요.

> **Codex 세컨드 오피니언**: 추가 검증이 필요하면:
> → /codex:adversarial-review
>   대상: <저장된 설계 문서 경로>
>   탐색 방향: 누락된 엣지케이스, 스케일 제약, 의존성 리스크

Codex 미감지 시 가이드 생략. 게이트 메시지만 표시:

사용자 승인 후 aidlc-writing-plans 스킬로 전환

Ambiguity Resolution Loop

명확화 질문의 답변을 받을 때마다 적용.

모호성 신호

"depends", "maybe", "not sure", "~하거나", "~일 수도", "상황에 따라"
키워드 없어도 설계 결정에 불충분하면 모호한 것으로 간주

후속 질문 방향

유형	예시 답변	후속 질문
선택 모호	"A나 B나 괜찮아요"	"어떤 기준으로 A를, 어떤 기준으로 B를?"
범위 모호	"적당히 빠르면 됩니다"	"구체적으로 어느 정도? (예: 1초 이내)"
우선순위 모호	"성능도 비용도 중요"	"둘이 상충할 때 어느 쪽 우선?"

탈출 조건

모든 모호함 해소 → 다음 단계
사용자가 "그냥 진행해" → 가정 목록 정리 → 승인 대기 → Assumptions에 기록

핵심 원칙

한 번에 하나만 질문
객관식 선호
YAGNI 엄격 적용
2-3개 대안 제시 후 선택
섹션별 점진적 검증