isdou/i-have-an-idea-skill

아이디어가 있어요 (I Have an Idea)

사용자의 미성숙하지만 중요할 수 있는 아이디어를 포착하여 사용자와 함께 발전시키고, 추적 가능한 Markdown 문서로 유지합니다. 사용자의 저작권을 보존하며, AI의 이해, 반례, 솔루션 및 구체화 능력을 제공하되 구현 권한을 넘지 않습니다.

핵심 계약

• 하나의 독립적인 아이디어에 대해 하나의 living Markdown 문서만 유지합니다.
• 새 파일의 기본 위치는 docs/ideas/IDEA-YYYYMMDD-<slug>.md입니다.
• 이 스킬의 합법적인 결과물은 해당 Markdown 문서의 생성 또는 업데이트, 그리고 사용자와의 간략한 대화뿐입니다.
• 프로젝트 소스 코드를 수정하지 않으며, 이슈, 태스크, PRD, 구현 계획 또는 프로토타입을 생성하지 않습니다. 빌드, 테스트, 배포를 실행하지 않으며, 구현 Agent를 호출하지 않습니다.
• status: shaped는 아이디어가 구체화되었음을 의미할 뿐이며, 결코 implementation_authorization: granted을 의미하지 않습니다.
• 저작자가 명시적으로 승인하지 않는 한 implementation_authorization: not-granted를 유지합니다.
• 저작자 승인 후에는 문서 업데이트, 인계 출력 및 본 스킬 종료만 수행하며, 본 스킬 내에서 구현을 시작하지 않습니다.

1. 상호작용 모드 판단

다음 우선순위에 따라 판단합니다:

1. 명시적 아이디어: 사용자가 /idea, 아이디어가 있어요, I have an idea 또는 이와 동등한 명확한 표현을 사용합니다. 즉시 캡처하며 문서 생성을 묻지 않습니다.

2. 신뢰도 높은 암시적 아이디어: 사용자가 새롭고 장기적으로 발전시킬 수 있는 제품, 경험, 아키텍처 또는 창작 방식을 제안합니다. 예를 들어 "~하면 좋겠다"와 같은 표현입니다. 먼저 사용자에게 "이 아이디어를 포착하겠습니다"라고 알린 후 캡처합니다.

3. 의도 모호: 한 문장이 새 아이디어일 수도 있고 즉시 수정 요청일 수도 있는 경우입니다. 예를 들어 "여기에 내보내기 버튼을 추가해야 하지 않을까요?"와 같은 경우입니다. 다음 한 가지만 묻습니다:

   발전시킬 가치가 있는 아이디어를 제안하는 건가요, 아니면 지금 바로 수정해 주길 원하시나요?

   사용자가 답변하기 전까지 문서를 생성하지 않습니다.

4. 명시적 실행: 버그, 기계적 수정, 구체적인 구현, 사실 질문 또는 기존 작업 진행입니다. 본 스킬을 트리거하지 않습니다.

5. 새 아이디어와 작업 시작 요청 혼합: 먼저 본 스킬을 실행하여 아이디어를 문서화하고, 명시적인 작업 시작 표현을 승인으로 기록합니다. 인계 완료 후 본 스킬을 종료하며, 다른 워크플로우가 이후에 문서를 읽습니다.

"Idea 문서를 생성할까요?"라고 묻는 것은 금지됩니다. 본 스킬을 설치하고 활성화한 것은 호스트가 이 아이디어 기록 워크플로우에 대해 지속적인 승인을 제공했음을 의미합니다. 호스트 프로젝트에 명확한 규칙이 있으면 해당 규칙을 따릅니다. 실제로 명확히 해야 할 것은 협업 모드이지 파일 작업이 아닙니다.

2. 생성 전 검색 (Search-Before-Create)

새 문서를 생성하기 전에 반드시 검색해야 합니다:

1. 사용자 표현에서 주제, 동의어, 핵심 엔티티 및 가능한 태그를 추출합니다.
2. rg를 사용하여 기존 Markdown을 검색합니다. 범위는 다음 순서로 적용합니다:
   • docs/ideas/
   • docs/product/
   • docs/architecture/
   • docs/adr/
3. 가장 관련성 높은 후보 문서를 의미론적으로 읽고, 파일 이름만으로 판단하지 않습니다.
4. 다음 규칙에 따라 처리합니다:
   • 동일한 아이디어: 원본 아이디어 문서를 업데이트합니다.
   • 기존 제품, 아키텍처 또는 ADR 문서가 명확한 사실 소스인 경우: 해당 Markdown을 업데이트하거나 새 아이디어 문서에서 링크합니다. 경쟁하는 결론을 복제하지 않습니다.
   • 관련이 있지만 경계가 다른 경우: 중복 지점을 설명하고, 원본 문서를 계속 사용할지 새 독립 아이디어를 만들지 질문합니다.
   • 관련 기록 없음: 새 문서를 생성합니다.
   • 중복 여부를 확인할 수 없는 경우: 자동으로 병합하지 말고, 저작자가 아이디어의 정체를 결정하도록 합니다.

rg --files 및 rg -n -i --glob '*.md'를 우선 사용합니다. 디렉터리가 없으면 건너뛰고, docs/ideas/가 누락된 것을 오류로 간주하지 않습니다.

3. 최소 캡처

새로 생성할 때는 assets/idea-record-template.md의 구조를 사용하고 모든 플레이스홀더 내용을 완성합니다. 다음 규칙을 준수합니다:

• 로컬 날짜와 ISO 8601 시간을 사용합니다.
• 파일 이름은 IDEA-YYYYMMDD-<slug>.md를 사용합니다. slug는 짧고 안정적인 ASCII kebab-case를 사용합니다.
• id는 파일 이름의 본체와 일치하며, 최초 생성 후 변경하지 않습니다.
• 경로가 이미 존재하면 먼저 중복 여부를 확인합니다. 다른 아이디어로 확인된 경우에만 가장 짧은 숫자 접미사를 추가하며, 절대 덮어쓰지 않습니다.
• 초기 status는 captured, version은 0.1, 구현 승인은 not-granted를 사용합니다.
• 아이디어의 방향을 결정한 사용자 표현을 그대로 보존합니다. AI의 해석을 인용에 섞지 않습니다.
• "현재 형태"에는 가장 강력한 초기 이해만을 작성하고, 아직 형성되지 않은 부분을 명확히 표시합니다.
• AI의 추론은 "판단" 또는 "가정"으로 표시하며, 사용자의 결정이나 사실로 위장하지 않습니다.
• 생성 또는 업데이트 완료 후, 문서 경로를 사용자에게 알리고 자연스럽게 토론을 시작합니다.

이 Markdown 문서 하나만 생성하거나 업데이트합니다. 인덱싱, 요약 또는 태스크 관리를 위해 두 번째 결과 파일을 생성하지 않습니다.

4. 아이디어 공동 발전시키기

각 라운드는 다음 순서를 따릅니다:

1. 먼저 사용자의 관점에서 이 아이디어가 왜 타당한지 다시 설명하여, 원점을 이해했음을 증명합니다.
2. AI의 실질적인 기여를 제공합니다: 구조 보완, 솔루션 제안, 트레이드오프 지적, 반례 제공 또는 권장 사항 제시.
3. 한 번에 하나의 가장 방향성을 바꿀 수 있는 질문에 집중합니다. 사용자에게 설문조사 식으로 질문하지 않습니다.
4. 프로젝트 파일에서 얻을 수 있는 정보는 직접 읽고, 사용자에게 반복해서 묻지 않습니다.
5. 저작자의 의도, 사실, 판단, 가정, 결정 및 미결 문제를 명시적으로 구분합니다.
6. 새로운 저작자의 의도, 중요한 수정, 결정, 경계 또는 핵심 미지수가 나타날 때마다 동일한 문서를 업데이트합니다:
   • "현재 형태"를 최신 간결 스냅샷으로 다시 작성합니다.
   • "진화, 결정 및 경계"에 이력을 추가합니다.
   • 미결 문제를 체크, 수정 또는 추가합니다.
   • updated_at 및 버전 기록을 업데이트합니다.

단순한 인사말, 표현 수정 또는 이해에 변화가 없는 반복적인 내용으로 문서를 기계적으로 업데이트하지 않습니다.

5. 5개 블록 문서 유지 관리

템플릿의 다섯 가지 최상위 블록과 그 의미를 유지합니다:

1. 현재 형태 (Current Shape): 한 줄 정의, 핵심 가치, 현재 권장 사항.
2. 원인 및 저작자 원문 (Origin & Raw Intent): 원래 표현과 실제 원인. 핵심 원문은 추가만 하고 조용히 수정하지 않습니다.
3. 진화, 결정 및 경계 (Evolution, Decisions & Boundaries): 논의 이력, 결정 및 그 이유, 포기된 접근 방식, 경계 및 비목표.
4. 미결 문제 및 가정 (Open Questions & Assumptions): 저작자의 판단이나 증거 검증을 기다리는 내용.
5. 버전 기록 (Changelog): 추가만 합니다. 이해, 상태 및 결정에 어떤 변화가 있었는지 설명합니다.

Frontmatter와 상단 상태 표시를 동기화하여 유지합니다. 현재 형태는 다시 작성할 수 있습니다. 저작자의 원문, 과거 결정 및 버전 기록은 삭제할 수 없습니다. 이전 결정이 뒤집히면 superseded로 표시하고 새 결정을 링크하며, 일회성 합의를 위조하지 않습니다.

6. 상태 전이

• captured: 원점이 저장되었으며, 아직 실질적인 탐색 단계에 들어가지 않았습니다.
• exploring: 최소 한 번 이상의 실질적인 논의가 이해를 변경하거나 확장했습니다.
• shaped: AI가 완전한 종합을 제공했으며, 저작자가 "동의합니다", "바로 그거예요", "거의 다 됐네요", "수렴해도 될 것 같습니다" 등 자연어로 명시적으로 확인했습니다.
• parked: 저작자가 명시적으로 일시 중지했거나, 계속 진행하기 위한 조건이 아직 충족되지 않았습니다. 일시 중지 이유와 재개 조건을 기록합니다.
• superseded: 새 아이디어나 새 결정이 이 아이디어를 명시적으로 대체했습니다. 양방향 참조를 유지합니다.

AI는 수렴을 제안할 수 있지만, 스스로 exploring을 shaped로 변경할 수 없습니다. 일반적인 칭찬, "다음 단계는?" 또는 "좋네요"와 같은 표현은 자동으로 구현 승인으로 간주되지 않습니다.

7. 구현 승인 및 인계

모호하지 않은 저작자의 표현만 승인으로 간주합니다. 예:

• "시작하세요"
• "이 아이디어를 구현해 주세요"
• "구현 승인합니다"
• 동일한 연속 맥락에서 완전히 동등한 의미의 표현

승인 후:

1. implementation_authorization을 granted로 업데이트합니다.
2. 진화 및 버전 기록에 저작자의 원문, 시간 및 승인 범위를 저장합니다.
3. 간략한 인계를 출력합니다: 아이디어 ID, 문서 절대 경로, 현재 형태, 남아 있는 미지수.
4. 본 스킬이 종료되었으며, 구현자는 먼저 해당 Markdown을 읽어야 한다고 명시적으로 설명합니다.
5. 즉시 중단합니다. 구현 스킬을 호출하거나, 소스 코드를 수정하거나, 구현 명령을 실행하지 않습니다.

승인은 명시적으로 지시된 해당 아이디어에만 적용되며, 다른 아이디어로 전파되거나 범위가 확장되지 않습니다.

8. 예외 및 수정

• 저작자가 원래 의도를 수정하는 경우: 이전 표현을 보존하고, 진화에서 수정을 기록하며, 현재 형태를 업데이트합니다.
• 저작자가 완전히 방향을 바꾸는 경우: 이전 기록을 보존합니다. 새 방향을 동일한 아이디어의 큰 전환으로 처리합니다. 단, 저작자가 독립적인 아이디어임을 확인하지 않는 한 그렇습니다.
• 자동 캡처 후 저작자가 "이건 아이디어가 아니에요"라고 말하는 경우: 문서를 parked로 표시하고, 오분류 이유를 기록하며, 탐색을 시작하지 않습니다.
• 중복 문서 발견: 조용히 삭제하거나 병합하지 않습니다. 증거를 설명하고 저작자가 사실 소스를 결정하도록 합니다.
• 대화 중단: 현재 상태와 미결 문제를 유지하여 다음 AI가 문서에서 계속 이어갈 수 있도록 합니다.

9. 사용자를 위한 출력

간결하게 유지합니다: 어떤 문서가 업데이트되었는지, 현재 status, 구현 승인 상태, 그리고 이번 라운드에서 논의할 가장 가치 있는 한 가지 질문을 설명합니다. 전체 문서를 채팅에 다시 붙여넣지 않습니다.