一键在 Manus 中运行任何 Skill

开始使用

bs-rules

星标0

分支0

更新时间2026年5月12日 15:12

브레인스토밍 에이전트들이 공유하는 토론 규칙과 출력 형식. 모든 에이전트가 이 규칙을 따른다.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

dc-choi

dc-choi/school-manage

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

브레인스토밍 공통 규칙

프로젝트 컨텍스트

이 프로젝트는 가톨릭 모임 운영 도구(출석부 프로그램)다. 토론 시 반드시 아래 사업 문서를 읽고 현재 상황을 파악한 뒤 발언해라:

문서	용도
`docs/business/STATUS.md`	현재 목표, 파일럿 현황, 오픈 이슈
`docs/business/README.md`	비전, 핵심 문제, 문서 인덱스
`docs/business/1_market/market.md`	시장/경쟁 분석
`docs/business/2_bm/bm.md`	가치 제안, 수익 모델
`docs/business/4_risk/risks.md`	리스크/가정
`docs/business/1_market/competitive-analysis.md`	경쟁사 상세 분석

토론 규칙

모든 발언은 근거를 포함해라. "좋다/나쁘다"만 쓰지 마라
상대 의견을 먼저 요약한 뒤 자신의 의견을 말해라
동의할 점은 명확히 인정해라
반박 시 대안을 함께 제시해라
감정적 표현을 배제하고 논리적으로 서술해라
1인 개발 프로젝트임을 항상 고려해라 (리소스 제약)
모든 문서는 한글로 작성해라

할루시네이션 가드 (HIGH 우선)

기획자/비판자 모두 주장형 발화를 만들어야 한다는 압박을 받는다. 그래서 false positive(없는 데이터로 우기기, 추측한 리스크 단정) 위험이 크다. 다음을 반드시 지킨다 — 위반 발언은 라운드 요약에서 폐기 대상.

근거 형식 강제. "근거 포함"만으론 부족. 셋 중 하나 형태로 인용:
- 사업 문서 인용: STATUS.md L42 또는 > 인용구
- 파일럿 데이터: 본당명/규모/기간 명시 (예: "정자동 60명, 2개월 운영")
- 외부 레퍼런스: 출처 + 링크 (없으면 사용 X)
"가능성 있음"·"리스크일 수 있음" 단독 발언 금지. 추정 리스크는 구체 시나리오 + 발생 조건까지 명시. 둘 다 못 대면 발언 X.
사업 문서에 없는 수치/타겟/경쟁사 만들지 마라. 토론 전 위 사업 문서 목록을 실제로 읽고 발언. 안 읽었으면 "확인 필요"로 보류.
자신 없으면 "근거 부족 — 검증 필요"라고 말해라. 억지로 ✅/❌ 판정 채우지 마라. false 데이터는 다음 라운드를 오염시킨다.
비판자는 없는 문제를 만들지 마라. 비판은 기획자 발언의 실제 약점에만. "이런 가정도 있을 수 있다"는 비판 X.

아이디어 평가 축

모든 아이디어는 다음 4가지 축으로 평가한다:

축	질문
사용자 가치	교리교사/모임 운영자의 실제 페인포인트를 해결하는가?
기술 실현성	1인 개발로 3개월 내 MVP를 만들 수 있는가?
시장 차별성	가톨릭 전용 도구로서 기존 범용 앱과 무엇이 다른가?
비즈니스 모델	수익 모델 또는 성장에 어떻게 기여하는가?

라운드 출력 형식

각 라운드는 다음 구조로 기록해라:

## Round N

### 기획자 발언
(planner의 아이디어 또는 반론)

### 비판자 발언
(critic의 비판 및 질문)

### 라운드 요약
- 합의된 사항: ...
- 미합의 사항: ...
- 다음 라운드에서 다룰 것: ...

파일 저장 규칙

디렉토리: docs/brainstorm/YYYY-MM-DD/ (날짜별 폴더)
파일명: <주제-slug>.md (예: revenue-model.md, acquisition-retention.md)
같은 날 여러 주제를 다룬 경우 같은 폴더에 주제별 파일 생성

docs/brainstorm/
├── 2026-02-23/
│   └── event-management.md
├── 2026-03-16/
│   ├── acquisition-retention.md
│   ├── catholic-news-tracker.md
│   └── revenue-model.md

최종 보고서 형식

# 브레인스토밍 결과 보고서

## 주제
(브레인스토밍 주제)

## 토론 요약
(3라운드 핵심 내용 요약)

## 아이디어 목록

### [아이디어명]
- 한 줄 요약
- 사용자 가치
- 실현 방법
- 차별점

(아이디어별 반복)

## Decision Tree 결과
| 아이디어 | 사용자 가치 | 기술 실현성 | 시장 차별성 | 비즈니스 모델 | 판정 |
|----------|------------|------------|------------|-------------|------|
| ... | ✅ `<근거 1줄>` / ❌ `<이유 1줄>` / ⚠️ 검증 필요 | (동일) | (동일) | (동일) | 승인/조건부/기각 |

> ✅/❌만 적지 마라. 근거 한 줄 또는 "⚠️ 검증 필요"를 함께 적는다 (할루시네이션 가드 §1·§4 강제).

## 착수 조건 (해당 시)
| 아이디어 | 선행 조건 | 착수 시점 |
|---------|---------|---------|
| ... | ... | ... |

## 실행 계획 (해당 시)
(단계별 실행 항목, 우선순위, 예상 일정)

## 인터뷰 항목 (해당 시)
(검증을 위한 인터뷰 질문, 대상, 확인 사항)

## 누락된 관점 (해당 시)
(토론에서 다루지 못한 관점, 후속 브레인스토밍 주제)

## 사용자 결정 대기
(사용자에게 최종 판단을 요청하는 질문)

同仓库更多 Skills

同仓库

biz-pulse

dc-choi/school-manage

매일 21:00 DB 운영 메일 본문 paste + GA4/Clarity MCP 자동 조회로 정량 스냅샷을 만들어 STATUS 갱신 근거를 제공한다. /biz-pulse 로 호출.

2026-06-040

biz-audit

dc-choi/school-manage

사업 문서 7개 + STATUS 간 용어·수치·가정 충돌 자동 감지. /biz-audit [문서1] [문서2] 형식으로 호출.

2026-05-240

biz

dc-choi/school-manage

2026-05-240

design-draft

dc-choi/school-manage

Claude Design(claude.ai/design)으로 시안 제작 → 2단 컨펌 → Claude Code 구현 플로우를 5단계로 진행한다. /design-draft [기능명]으로 호출. 새 페이지·주요 컴포넌트·출력물 비주얼이 필요할 때.

2026-05-120

pre-pr

dc-choi/school-manage

PR 생성 전 변경 파일 영역을 분석해 관련 reviewer 에이전트를 병렬 호출하고 심각도별 결과를 집계한다. /pre-pr 로 호출.

2026-05-120

save-session

dc-choi/school-manage

현재 세션 상태를 docs/sessions/에 저장해서 다음 세션이 완전한 컨텍스트로 이어갈 수 있게 한다. /save로 호출. 컨덕터 워크스페이스 컨텍스트 리셋이나 문맥 한계 직전에 필수.

2026-05-120

name	bs-rules
description	브레인스토밍 에이전트들이 공유하는 토론 규칙과 출력 형식. 모든 에이전트가 이 규칙을 따른다.
user-invocable	false

브레인스토밍 공통 규칙

프로젝트 컨텍스트

이 프로젝트는 가톨릭 모임 운영 도구(출석부 프로그램)다. 토론 시 반드시 아래 사업 문서를 읽고 현재 상황을 파악한 뒤 발언해라:

문서	용도
`docs/business/STATUS.md`	현재 목표, 파일럿 현황, 오픈 이슈
`docs/business/README.md`	비전, 핵심 문제, 문서 인덱스
`docs/business/1_market/market.md`	시장/경쟁 분석
`docs/business/2_bm/bm.md`	가치 제안, 수익 모델
`docs/business/4_risk/risks.md`	리스크/가정
`docs/business/1_market/competitive-analysis.md`	경쟁사 상세 분석

토론 규칙

모든 발언은 근거를 포함해라. "좋다/나쁘다"만 쓰지 마라
상대 의견을 먼저 요약한 뒤 자신의 의견을 말해라
동의할 점은 명확히 인정해라
반박 시 대안을 함께 제시해라
감정적 표현을 배제하고 논리적으로 서술해라
1인 개발 프로젝트임을 항상 고려해라 (리소스 제약)
모든 문서는 한글로 작성해라

할루시네이션 가드 (HIGH 우선)

근거 형식 강제. "근거 포함"만으론 부족. 셋 중 하나 형태로 인용:
- 사업 문서 인용: STATUS.md L42 또는 > 인용구
- 파일럿 데이터: 본당명/규모/기간 명시 (예: "정자동 60명, 2개월 운영")
- 외부 레퍼런스: 출처 + 링크 (없으면 사용 X)
"가능성 있음"·"리스크일 수 있음" 단독 발언 금지. 추정 리스크는 구체 시나리오 + 발생 조건까지 명시. 둘 다 못 대면 발언 X.
사업 문서에 없는 수치/타겟/경쟁사 만들지 마라. 토론 전 위 사업 문서 목록을 실제로 읽고 발언. 안 읽었으면 "확인 필요"로 보류.
자신 없으면 "근거 부족 — 검증 필요"라고 말해라. 억지로 ✅/❌ 판정 채우지 마라. false 데이터는 다음 라운드를 오염시킨다.
비판자는 없는 문제를 만들지 마라. 비판은 기획자 발언의 실제 약점에만. "이런 가정도 있을 수 있다"는 비판 X.

아이디어 평가 축

모든 아이디어는 다음 4가지 축으로 평가한다:

축	질문
사용자 가치	교리교사/모임 운영자의 실제 페인포인트를 해결하는가?
기술 실현성	1인 개발로 3개월 내 MVP를 만들 수 있는가?
시장 차별성	가톨릭 전용 도구로서 기존 범용 앱과 무엇이 다른가?
비즈니스 모델	수익 모델 또는 성장에 어떻게 기여하는가?

라운드 출력 형식

각 라운드는 다음 구조로 기록해라:

## Round N

### 기획자 발언
(planner의 아이디어 또는 반론)

### 비판자 발언
(critic의 비판 및 질문)

### 라운드 요약
- 합의된 사항: ...
- 미합의 사항: ...
- 다음 라운드에서 다룰 것: ...

파일 저장 규칙

디렉토리: docs/brainstorm/YYYY-MM-DD/ (날짜별 폴더)
파일명: <주제-slug>.md (예: revenue-model.md, acquisition-retention.md)
같은 날 여러 주제를 다룬 경우 같은 폴더에 주제별 파일 생성

docs/brainstorm/
├── 2026-02-23/
│   └── event-management.md
├── 2026-03-16/
│   ├── acquisition-retention.md
│   ├── catholic-news-tracker.md
│   └── revenue-model.md

최종 보고서 형식

# 브레인스토밍 결과 보고서

## 주제
(브레인스토밍 주제)

## 토론 요약
(3라운드 핵심 내용 요약)

## 아이디어 목록

### [아이디어명]
- 한 줄 요약
- 사용자 가치
- 실현 방법
- 차별점

(아이디어별 반복)

## Decision Tree 결과
| 아이디어 | 사용자 가치 | 기술 실현성 | 시장 차별성 | 비즈니스 모델 | 판정 |
|----------|------------|------------|------------|-------------|------|
| ... | ✅ `<근거 1줄>` / ❌ `<이유 1줄>` / ⚠️ 검증 필요 | (동일) | (동일) | (동일) | 승인/조건부/기각 |

> ✅/❌만 적지 마라. 근거 한 줄 또는 "⚠️ 검증 필요"를 함께 적는다 (할루시네이션 가드 §1·§4 강제).

## 착수 조건 (해당 시)
| 아이디어 | 선행 조건 | 착수 시점 |
|---------|---------|---------|
| ... | ... | ... |

## 실행 계획 (해당 시)
(단계별 실행 항목, 우선순위, 예상 일정)

## 인터뷰 항목 (해당 시)
(검증을 위한 인터뷰 질문, 대상, 확인 사항)

## 누락된 관점 (해당 시)
(토론에서 다루지 못한 관점, 후속 브레인스토밍 주제)

## 사용자 결정 대기
(사용자에게 최종 판단을 요청하는 질문)