의도정렬 허브 Reference Map

[developer-1px]

type: reference
query: "에이전트에게 처음 일을 시킬 때 쓰는 의도정렬 허브는 최근 흐름과 맞는가?"
modes: [bp, defacto, frontier]
decisionUse: true

의도정렬 허브 Reference Map

TL;DR

/discuss류 허브는 방향이 맞습니다. 최근 흐름도 “바로 실행”보다 목표 명확화 → 계획/승인 → 실행 → 체크포인트 쪽으로 수렴합니다.

다만 지금 /discuss는 약간 무겁습니다. 최신 흐름은 모든 작업에 긴 의식을 붙이는 것보다, “모호하거나 위험한 시작점에서만 허브를 켜고, 충분히 명확하면 짧게 통과”하는 쪽입니다.

Internal Baseline

현재 teo-stack의 /discuss는:

• 표면 요청을 곧이곧대로 실행하지 않음
• 숨은 의도, 범위, 제약을 먼저 맞춤
• AI가 먼저 맥락을 조사하고 판단을 제시함
• 사용자 승인 전에는 실행하지 않음
• 외부 근거는 ⑨ 외부 탐색으로 분리
• /reference는 그 ⑨의 드릴다운

이 구조는 “처음 시킬 때 시작하는 허브”로 정확히 맞습니다.

Reference Map

Mode	흐름	근거	Fit
bp	Plan before editing	Claude Code가 변경 전 plan mode를 권장	adopt
bp	명확한 instructions, 작은 단계, 구체 action/output	OpenAI agents guide가 agent instructions 품질을 강조	adopt
defacto	Skills/custom commands로 시작 흐름을 패키징	Claude Code Skills가 prompt-based workflow 단위로 동작	adopt
defacto	CLAUDE.md/AGENTS.md/memory로 프로젝트 맥락을 시작 시 로드	Claude Code memory 구조	adopt
frontier	첫 세션 initializer agent가 feature list/progress/test harness를 만든다	Anthropic long-running agents 글	watch/adapt
frontier	모델이 좋아질수록 과한 절차 프롬프트는 노이즈가 된다	OpenAI prompt guidance	adapt

Convergence

수렴 방향은 이렇습니다.

flowchart TD
  A[User request] --> B{Clear enough?}
  B -- no --> C[Intent alignment hub]
  C --> D[Goal / constraints / success / risk]
  D --> E{Need external basis?}
  E -- yes --> F[/reference]
  E -- no --> G[Plan / scope]
  F --> G
  B -- yes --> G
  G --> H{User approval or safe autonomy?}
  H --> I[Implement]
  I --> J[Verify / checkpoint]

Loading

핵심은 /discuss가 “항상 거치는 관문”이라기보다 모호성/위험/전략 판단이 있을 때 켜지는 라우터가 되는 겁니다.

Fit For This Scope

판정: adapt

/discuss의 철학은 유지하는 게 맞습니다. 다만 최근 흐름에 맞추려면 아래처럼 경량/중량 모드를 나눠야 합니다.

• light discuss: 목적, 성공조건, 제약, 다음 행동만 빠르게 정렬
• full discuss: TOC 13요소 + FRT까지 가는 깊은 논의
• /reference: 외부 standard/BP/de facto/frontier가 필요한 경우만 호출
• /doubt, /conflict: 새 개념/대립이 보일 때만 드릴다운

What To Do

내 판단은 이겁니다.

1. /discuss는 계속 허브로 둔다.
2. 첫 응답 기본형은 더 짧게 만든다: “제 판단 / 근거 / 빠진 갭 / 다음 선택지”.
3. 13요소는 항상 펼치지 말고, 모호성이나 실행 위험이 커질 때만 full mode로 승격한다.
4. /reference는 “요즘/표준/BP/디팩토”가 나오면 ⑨ 외부 탐색으로 붙인다.
5. 과한 체크리스트화는 피한다. 최신 모델 흐름은 outcome-first와 짧은 decision rule 쪽입니다.

Sources

• Claude Code common workflows — plan before editing, subagent delegation
• Claude Code skills — skills as prompt-based workflows
• Claude Code memory — project instructions and memory
• Anthropic: Building effective agents — simple composable patterns, agents start from command or discussion
• OpenAI: A practical guide to building agents — instructions, templates, guardrails
• OpenAI prompt guidance — avoid over-specified legacy prompts; outcome-first prompts
• Anthropic: Effective harnesses for long-running agents — initializer agent / progress artifacts

[developer-1px]

---

type: reference
query: "에이전트에게 처음 일을 시킬 때 쓰는 의도정렬 허브는 최근 흐름과 맞는가?"
modes: [standard, bp, defacto, frontier]
decisionUse: true
confidence: medium
sourceCount: 9
lastChecked: 2026-06-18

의도정렬 허브 Reference

1. 판정 카드

질문	답
지금 정석은?	에이전트 시작점에는 목표 / 성공조건 / 제약 / 승인·가드레일 / 검증 방법이 먼저 와야 한다. 바로 실행보다 plan 또는 scoped workflow가 기본값에 가깝다.
사실상 표준은?	긴 프롬프트 하나보다 프로젝트 메모리/규칙 + 필요할 때 로드되는 skill + 계획/승인 모드 + 검증 루프 조합으로 수렴 중이다.
최근 수렴 후보는?	장기 작업에서는 첫 세션 initializer가 feature list, progress log, test harness를 남기고 이후 세션이 그 산출물로 이어받는 흐름이 강해지고 있다.
우리에게 맞는 선택은?	adapt: /discuss는 허브로 유지하되, 기본 진입은 light하게 만들고 full 13요소/FRT는 모호성·위험도가 클 때만 승격한다. /reference는 ⑨ 외부 탐색 드릴다운으로 붙인다.
확신도	medium: Claude/OpenAI 공식 문서와 Anthropic engineering 글은 방향이 일치한다. 다만 “de facto”를 통계적으로 증명할 만큼 여러 생태계 도구를 대량 비교한 것은 아니므로 high는 아니다.

2. 왜 이렇게 판단했나

Claim	Mode	Evidence	Strength	Fit	읽는 사람이 얻는 결론
변경 전 계획/승인 흐름은 이미 coding agent UX의 공식 권장 축이다.	bp	S1, S8	high	adopt	/discuss가 “실행 전 의도·범위 정렬”을 담당하는 것은 방향이 맞다.
반복되는 절차는 항상 로드되는 메모리보다 skill로 분리하는 흐름이 있다.	bp	S2, S3, S9	high	adopt	/discuss, /reference처럼 필요 시 로드되는 허브/스포크 구조는 context hygiene 측면에서 맞다.
시작 프롬프트는 구체적이어야 하지만, 최신 모델에서는 과한 절차 프롬프트가 노이즈가 될 수 있다.	bp	S7, S6	medium	adapt	/discuss의 13요소를 항상 펼치면 무겁다. light/full 모드 분리가 필요하다.
에이전트는 인간 명령 또는 대화로 시작하고, task가 clear해지면 계획 후 독립 실행한다.	bp	S5	high	adopt	/discuss는 “task clear” 이전의 대화형 정렬 허브로 정의하는 것이 맞다.
복잡한 작업은 중앙 manager/router가 specialist를 호출하는 패턴과 잘 맞는다.	defacto	S4, S5	medium	adapt	/discuss를 항상 실행기가 아니라 /reference, /doubt, /conflict로 보내는 router로 두는 편이 맞다.
장기 작업에서는 첫 세션에서 feature/progress/test scaffold를 만드는 initializer 패턴이 등장했다.	frontier	S6	medium	watch/adapt	/discuss에 바로 넣기보다는 별도 future candidate다. full discuss 이후 실행 plan으로 넘길 때만 참고한다.
governance/guardrail은 개발 속도를 막는 것이 아니라 delivery scaffold가 되는 방향으로 설명된다.	frontier	S4, S8	medium	adapt	/discuss의 승인·제약·부작용/FRT는 유지 가치가 있다. 단, 출력은 더 짧아야 한다.

3. 소스 카드

ID	Source	Type	Date	내가 읽은 핵심	증명하는 것	한계
S1	Claude Code common workflows	official docs	n/a	Claude Code는 변경이 디스크에 닿기 전 검토가 필요하면 plan mode를 쓰라고 안내한다. 이 모드에서는 Claude가 파일을 읽고 계획을 제안하지만 승인 전 편집하지 않는다. 또한 대형 코드베이스 탐색은 subagent로 위임해 요약만 가져오는 흐름도 제시한다.	실행 전 plan/approval과 bounded exploration이 공식 workflow다.	Claude Code 제품 문서라 일반 agent 전체 표준은 아니다.
S2	Claude Code skills	official docs	n/a	반복해서 붙여넣는 instruction/checklist/procedure는 skill로 만들라고 설명한다. skill body는 사용될 때만 로드되므로 긴 reference를 매번 context에 싣지 않아도 된다.	/discuss, /reference 같은 절차성 허브/스포크를 skill로 두는 것이 맞다.	Claude Code 중심 문서이고, Codex와 완전 동일한 런타임은 아니다.
S3	Claude Code memory	official docs	n/a	CLAUDE.md와 auto memory는 매 세션 시작 시 로드되는 지식이다. 반복 correction이나 팀원이 알아야 할 사실은 memory에 두되, multi-step procedure는 skill이나 path-scoped rule로 빼라고 안내한다.	“항상 로드할 사실”과 “필요할 때 쓸 절차”를 분리하는 게 정석이다.	Claude memory 기준이라 AGENTS.md/Codex에는 개념 매핑이 필요하다.
S4	OpenAI: A practical guide to building agents	official guide	n/a	OpenAI는 agent 기반을 instructions, tools, guardrails, hooks로 설명하고, agent run을 exit condition까지 도는 loop로 본다. 복잡도 관리는 flexible base prompt, single agent 우선, 필요 시 manager/handoff형 multi-agent로 설명한다.	시작점에는 structured instructions와 guardrails가 필요하고, 복잡하면 router/manager 패턴이 맞다.	비즈니스/제품 가이드라 특정 코딩 도구 사용법은 아니다.
S5	Anthropic: Building effective agents	engineering blog	2024-12-19	Anthropic은 성공적 agent 구현이 복잡한 프레임워크보다 simple composable patterns에 기반한다고 말한다. Agents는 human command 또는 interactive discussion으로 시작하고 task가 clear해지면 계획하고 독립 실행하며, 중간에 환경 ground truth와 human checkpoint가 필요할 수 있다고 설명한다.	/discuss는 실행기가 아니라 “task clear” 이전 정렬 허브여야 한다.	2024 글이라 최신 product UX의 세부와는 차이가 있을 수 있다.
S6	Anthropic: Effective harnesses for long-running agents	engineering blog	2025-11-26	장기 agent가 one-shot으로 너무 많이 하거나 premature completion하는 문제를 설명하고, initializer agent가 feature list/progress/test scaffold를 남기는 패턴을 제시한다. 이후 세션은 git log, progress file, feature list를 읽고 한 feature씩 진행한다.	frontier는 “첫 세션에 작업 기준 산출물을 남기는 허브” 쪽으로 이동 중이다.	long-running coding agent 특화라 일반 의도정렬 대화에 그대로 넣으면 과하다.
S7	Claude prompting best practices	official docs	n/a	Claude 문서는 clear/direct instruction, desired output format, constraints, context/motivation, examples를 강조한다. 긴 문서 작업에서는 관련 부분을 먼저 근거로 잡는 방식도 언급한다.	/discuss의 “판단+근거+갭 질문”은 맞지만, 출력 형식과 예시가 명확해야 한다.	일반 prompting guide라 teo-stack의 13요소 전체를 직접 지지하진 않는다.
S8	OpenAI Workspace agents	official academy	n/a	Agent builder는 plain language로 job, successful outcome, constraints를 설명하고, tools/connectors, trigger, guardrails, approvals, human checkpoints를 추가하는 흐름을 제시한다.	시작 허브의 최소 질문은 goal/success/constraints/guardrails/checkpoints다.	ChatGPT workspace agents 기준이라 CLI coding session과는 다르다.
S9	OpenAI Codex skills	official docs	n/a	Codex skills는 task-specific capability를 패키징하고, name/description만 먼저 context에 있다가 필요 시 SKILL.md를 읽는 progressive disclosure 구조라고 설명한다. description matching이 중요하다고 말한다.	reference는 긴 reference protocol을 skill로 분리하는 것이 맞고, description에 “BP/de facto/frontier” trigger가 있어야 한다.	Codex docs 기준이라 Claude plugin 설치 흐름과는 다르다.

4. 수렴 지도

Layer	확인된 흐름	안정도	우리 맥락
Standard	formal standard는 없음. “의도정렬 허브”는 아직 W3C/RFC 같은 규격 대상이 아니다.	none	/discuss를 “표준 구현”이라고 부르면 안 된다.
BP	plan before editing, clear instructions, success/constraints/guardrails, skill/memory 분리가 공식 문서들에서 반복된다.	stable	/discuss의 목적·범위·제약·승인 경계는 유지한다.
De facto	agentic coding UX는 project instructions, skills/custom commands, plan/approval, subagents, progress artifacts를 조합한다.	moving	/discuss는 모든 것을 직접 하지 말고 router가 되어야 한다.
Frontier	initializer agent, progress file, feature list, test harness, long-running session scaffold.	emerging	/discuss 본체에 넣기보다 실행 계획/long-running workflow 후보로 둔다.

5. 적용 판단

선택지	판정	이유	하지 말아야 할 것
/discuss를 허브로 유지	adopt	“task clear 전 대화형 정렬”은 Anthropic agent 흐름과 맞고, teo-stack의 고유 영역이다.	구현/TDD/디버깅까지 먹으려 하지 말 것.
기본 출력 경량화	adapt	OpenAI prompt guidance와 Claude best practices 모두 clear/outcome/format을 중시한다. 13요소 전체 표는 매번 무겁다.	모든 요청에 13요소 표를 펼치지 말 것.
/reference를 ⑨ 외부 탐색 스포크로 연결	adopt	외부 근거가 필요한 경우만 분리하면 /discuss 본문이 가벼워지고, evidence quality도 올라간다.	sources 링크만 나열하는 조사 보고서로 돌아가지 말 것.
initializer/progress harness를 /discuss에 통합	watch	장기 coding agent에는 유효하지만 일반 의도정렬 허브에는 과하다.	지금 /discuss에 feature_list/progress_file 의식을 넣지 말 것.
/discuss를 Matt Pocock grill-*류로 대체	avoid	Matt 흐름은 idea → PRD/issues/implement에 강하고, teo-stack은 한국어 판단 제시형 의도정렬·감산·리팩토링 감사가 고유 영역이다.	같은 역할의 개발 플로우 스킬을 중복 제작하지 말 것.

6. 반증 조건

• Claude/OpenAI/Codex 공식 문서가 “plan/approval보다 즉시 실행과 자동 권한 위임이 기본”으로 바뀌면 /discuss의 실행 전 게이트는 약화해야 한다.
• 여러 주요 coding agent가 skill/custom-command보다 always-on memory/system prompt에 절차를 넣는 쪽으로 수렴하면 /discuss를 skill로 두는 판단을 다시 봐야 한다.
• 실제 사용에서 light discuss가 반복적으로 놓치는 위험이 크면, 기본값을 full discuss에 가깝게 되돌려야 한다.
• 반대로 full discuss가 대부분의 작업에서 지연만 만든다는 사용 로그가 쌓이면, 13요소는 명시 호출 전용으로 더 숨겨야 한다.

7. Quality Gate

Gate	결과
Source read-through	통과: 각 소스 카드에 읽은 핵심과 한계를 적었다.
Claim traceability	통과: 모든 핵심 claim에 Evidence ID를 붙였다.
Mode separation	통과: standard 없음, BP/de facto/frontier를 분리했다.
Local fit	통과: /discuss, /reference, teo-stack 포지션과 연결했다.
Limits	통과: 소스별 한계와 confidence medium을 명시했다.
No naked links	통과: 링크 목록만으로 끝내지 않았다.

결론

이번 기준으로 보면 /discuss를 “처음 시킬 때 시작하는 허브”로 두는 건 맞다. 다만 지금의 개선 방향은 기능 추가가 아니라 기본 진입을 더 짧고 증거 중심으로 바꾸는 것이다.

추천 변경 방향:

1. /discuss 첫 턴 기본 출력은 제 판단 / 근거 / 빠진 갭 / 선택지로 축소한다.
2. 13요소 표는 명시적으로 필요하거나 모호성·위험도가 높을 때만 연다.
3. 외부 근거가 필요하면 /reference로 보내고, /reference는 반드시 Claim-Evidence-Fit 형태로만 돌아온다.
4. 장기 작업 initializer/progress harness는 별도 후보로 추적하되, 지금 /discuss에 넣지는 않는다.

[developer-1px]

type: reference
query: "에이전트에게 처음 일을 시킬 때 쓰는 의도정렬 허브는 최근 agent BP/de facto와 얼마나 가까운가?"
modes: [bp, defacto, frontier]
decisionUse: true
confidence: medium-high
sourceCount: 10
lastChecked: 2026-06-18

의도정렬 허브 Reference

0. 조사 배경과 목표

항목	내용
사용자 발화	"한번더 같은 스킬 돌려봐 결과를 보자"
숨은 의도	업데이트한 /reference가 실제로 중립적 거리 측정 결과를 내는지 확인하려는 것
배경	이전 결과는 "조사 보고서"처럼 읽혔고, 이번에는 BP/de facto와의 거리, 유사점, 차이점을 보고 싶어 함
결정하려는 것	/discuss류 의도정렬 허브가 최근 agent 설계 흐름과 같은 결인지 확인
조사하지 않을 것	/discuss를 당장 고쳐야 하는지 처방하지 않음
의도 추론 확신도	high — 직전 피드백이 산출물 톤과 형식에 집중되어 있음

1. 판정 카드

질문	답
지금 정석은?	정적 시작점은 AGENTS.md/CLAUDE.md 같은 persistent instructions, 동적 시작점은 plan/custom agent가 기준점에 가깝다.
사실상 표준은?	“작업 전 맥락 로드 → 계획/질문 → 실행” 흐름은 여러 agent 제품에서 반복된다.
최근 수렴 후보는?	skills, custom agents, plan agents, handoffs처럼 “재사용 가능한 작업 모드”를 분리하는 방향.
BP/de facto와의 거리	adjacent → close
결이 가장 비슷한 레퍼런스	VS Code Plan agent/custom planning agent, Claude Code plan mode, GitHub Copilot의 research-plan-iterate 흐름
확신도	medium-high — 공식 문서들은 강하지만, /discuss의 TOC 13요소/FRT 구조 자체와 1:1 대응되는 공개 표준은 아님

2. 왜 이렇게 판단했나

Claim	Mode	Evidence	Strength	Proximity	차이/의미
작업 시작 전에 일관된 맥락을 주입하는 것은 de facto에 가깝다.	defacto	S1, S2, S3	high	close	/discuss는 정적 주입이 아니라 대화형 정렬이라 구현 결은 다름
실행 전 계획/검토 단계는 BP에 가깝다.	bp	S4, S5, S9	high	close	/discuss는 “계획”보다 “의도/범위/목표”를 더 앞에 둠
재사용 가능한 작업 모드를 skill/custom agent로 분리하는 흐름은 강하다.	defacto/frontier	S6, S7, S8, S10	high	adjacent	/discuss가 skill인 점은 가깝지만, hub-router 성격은 custom agent/handoff와 더 가까움
모호한 요청을 곧장 실행하지 않고 clarify/research/plan하는 흐름은 agent BP와 맞다.	bp	S5, S9	high	close	/discuss는 이를 TOC/FRT라는 개인화된 판단 프레임으로 더 강하게 구조화함
/discuss의 “숨은 의도 추론”은 공개 표준이라기보다 고급 사용 패턴에 가깝다.	frontier	S5, S9, local	medium	adjacent	공식 문서들은 clarifying questions와 planning은 말하지만, hidden intent audit까지는 명시적으로 표준화하지 않음

3. 소스 카드

ID	Source	내가 읽은 핵심	증명하는 것	한계
S1	OpenAI Codex AGENTS.md	Codex는 작업 전 AGENTS.md를 읽고 global/project guidance를 계층적으로 적용한다.	시작 전 맥락 주입	정적 instruction 중심
S2	AGENTS.md	agent용 README로, 60k+ OSS 프로젝트 사용과 다중 agent 호환을 강조한다.	de facto 신호	실제 품질은 repo마다 다름
S3	Claude Code memory	CLAUDE.md, auto memory, rules가 세션 시작 맥락으로 쓰인다.	persistent context	Claude 생태계 중심
S4	Claude Code common workflows	plan mode는 파일을 읽고 계획을 제안한 뒤 승인 전까지 수정하지 않는다.	실행 전 계획 BP	의도 정렬보다는 계획 승인
S5	GitHub Copilot task BP	좋은 task는 문제, acceptance criteria, 변경 방향이 명확해야 하고, PR 전 research/plan/iterate 흐름을 권장한다.	모호성 제거 BP	cloud agent 작업 기준
S6	OpenAI agent guide	단일 agent를 먼저 최대화하고, 복잡할 때 prompt templates나 multi-agent 분리를 고려한다.	복잡도 관리 기준	제품/서비스 agent 맥락
S7	Codex Skills	skills는 reusable workflow authoring format이고 progressive disclosure로 필요한 때 로드된다.	skill화 흐름	/discuss 내용의 품질은 별도
S8	Claude Agent Skills	skills는 반복 지식을 on-demand로 불러오는 filesystem 기반 capability다.	skill de facto 신호	Claude/API 중심
S9	VS Code Planning	Plan agent는 고수준 task를 받고 조사 후 질문, 계획, 검증 단계를 만든다.	가장 가까운 동적 기준점	VS Code/Copilot 표면
S10	VS Code Custom Agents	planning agent, implementation agent, review agent 같은 전환/handoff를 공식 패턴으로 설명한다.	hub-spoke 유사 레퍼런스	custom agent이지 skill은 아님

4. 수렴 지도

Layer	확인된 흐름	안정도	우리 맥락
Standard	AGENTS.md, CLAUDE.md, skills format	moving/stable	정적 규칙과 reusable workflow의 기준점
BP	plan before edit, clarify/research before PR	stable	/discuss의 실행 전 정렬과 가까움
De facto	instructions + skills + plan/custom agents 조합	moving	teo-stack hub-spoke와 결이 비슷함
Frontier	custom agents, handoffs, skill portability	emerging	/discuss 허브는 skill보다 custom planning agent와 더 가까운 면이 있음

5. 차이와 유사 레퍼런스

우리 안의 모양	가까운 기준점	유사한 점	다른 점	더 가까운 유사 레퍼런스
/discuss 허브	VS Code Plan agent	실행 전 조사, 질문, 계획	/discuss는 구현 계획보다 숨은 의도/범위 정렬이 앞섬	VS Code custom planning agent
TOC 13요소 + FRT	Copilot well-scoped task	문제/acceptance/검증을 명확히 함	훨씬 강한 사고 프레임	issue prompt quality checklist
스포크로 /reference, /doubt, /conflict 연결	custom agents + handoffs	단계별 전문 모드 전환	현재는 handoff UI가 아니라 skill 호출 관습	VS Code custom agents/handoffs
hidden intent 추론	Anthropic agent discussion	작업이 clear해질 때까지 인간과 상호작용	공식 docs에는 hidden intent 프레임이 약함	planner/solution architect custom agent

6. 결정 보조 메모

선택지	중립적 거리 판단	이유	주의할 점
/discuss를 skill hub로 유지	adjacent-close	skills/reusable workflow 흐름과 맞다	hub-router라면 skill보다 custom agent 성격도 있음
/discuss를 “의도정렬 custom planning agent”로 해석	close	VS Code Plan/custom agent와 가장 비슷하다	Claude/Codex 표면에서는 agent 구현 방식이 다름
TOC/FRT를 유지	adjacent	공개 BP는 아니지만 “well-scoped task”를 더 깊게 구조화한 형태	너무 무거우면 일반 작업에는 과잉일 수 있음
/reference를 스포크로 둠	close	외부 기준점 비교가 /discuss의 ⑨ 외부 탐색과 잘 맞는다	결과가 처방형으로 흐르면 다시 거리 측정으로 보정 필요

7. 반증 조건

• VS Code/Claude/Codex 쪽에서 plan/custom agent보다 “single slash command hub”가 더 공식 패턴으로 자리 잡으면 proximity가 close로 올라간다.
• 실제 사용에서 /discuss가 너무 자주 과잉 절차를 만들면 BP와의 거리는 adjacent 이하로 내려간다.
• hidden intent alignment를 명시적으로 다루는 공개 agent 설계 패턴이 더 많이 나오면 /discuss의 독자 프레임은 frontier에서 de facto 쪽으로 이동한다.

[developer-1px]

type: reference
query: "`/discuss`는 SKILL.md 기반 스킬로서 최근 Agent Skills/custom commands/custom agents BP·de facto와 얼마나 가까운가?"
modes: [bp, defacto, frontier]
decisionUse: true
confidence: medium-high
sourceCount: 9
lastChecked: 2026-06-18

/discuss Skill Category Reference

0. 조사 배경과 목표

항목	내용
사용자 발화	"한번더 스킬쓰고 결과는 댓글로"
내가 추론한 숨은 의도	직전 실패를 반영해, /discuss를 agent planning 일반론이 아니라 "스킬 범주" 안에서 다시 비교하려는 것
조사가 시작된 배경	이전 결과는 AGENTS.md, plan mode, agent planning 일반론으로 흐르면서 /discuss가 SKILL.md라는 핵심 범주를 놓쳤다.
이번 조사로 결정하려는 것	/discuss가 Agent Skills BP/de facto와 가까운지, 아니면 custom command/custom agent/prompt file에 더 가까운지 거리 측정
조사하지 않을 것	일반적인 "에이전트에게 일을 잘 시키는 법" 전체를 다시 조사하지 않음
의도 추론 확신도	high — 직전 피드백이 "discuss가 스킬이니 스킬 범주에서 비교했어야 했다"에 집중되어 있음

0.5 비교 범주와 조사 축

항목	내용
내부 대상	plugins/teo-stack/skills/discuss/SKILL.md
구현 형태	skill
표면 주제	의도 정렬, 실행 전 정렬, 논의/실행 경계
1차 비교 피어셋	Agent Skills, Claude/Codex skills, skill authoring guides, skills vs custom instructions
2차 인접 피어셋	custom commands/prompt files, custom agents/chat modes, handoff workflows
제외할 넓은 축	agent planning 일반론, AGENTS.md만 보는 조사, multi-agent orchestration 일반론
검색 쿼리 기준	agent skills reusable workflow, skills vs custom instructions, prompt files vs skills, custom agents handoffs planner
범주 판정 확신도	high — 내부 대상이 명확히 SKILL.md이고 teo-stack README도 /discuss를 허브 스킬로 설명함

1. 판정 카드

질문	답
지금 정석은?	Agent Skill은 "특정 작업을 위한 재사용 가능한 워크플로우/능력"을 SKILL.md와 선택적 리소스로 포장하고, 필요할 때 로드되는 형태다.
사실상 표준은?	skills는 custom instructions와 달리 task-specific/on-demand이고, prompt files보다 무겁고, custom agents보다 tool/persona 제어는 약하다.
최근 수렴 후보는?	skills, prompt files, custom agents, handoffs를 역할별로 분리해서 조합하는 방향.
BP/de facto와의 거리	/discuss는 "meta-workflow skill"로는 close, "skill hub/router"로는 adjacent, "planning persona/tool boundary"로는 custom agent 쪽에 더 가까움.
결이 가장 비슷한 레퍼런스	Agent Skill + VS Code custom planning agent 사이의 하이브리드
확신도	medium-high — 1차 피어셋 공식 문서는 강하지만, /discuss처럼 "대화 의도 정렬 허브"인 공개 skill 레퍼런스는 드묾

2. 왜 이렇게 판단했나

Claim	Mode	Evidence	Strength	Reference proximity	차이/의미
/discuss는 reusable workflow skill로 볼 때 Agent Skills 기준과 가깝다.	bp/defacto	S1, S2, S3, S4, L1	high	close	반복 가능한 절차, 트리거, SKILL.md 워크플로우가 있다.
/discuss는 custom instructions보다는 skill에 가깝다.	defacto	S5, S6	high	close	항상 적용되는 코딩 규칙이 아니라 요청이 모호할 때 로드되는 task-specific 절차다.
/discuss의 "판단 제시형 업무 파트너" 성격은 custom agent와도 가깝다.	bp/frontier	S8, L1	medium-high	adjacent-close	persona, 논의/실행 경계, 도구 사용 태도를 정의한다. 이건 skill보다 custom agent의 역할 정의와 닮았다.
/discuss의 허브-스포크 구조는 skill 자체보다 handoff/custom agent 패턴과 더 가깝다.	frontier	S8, L2	medium	adjacent	/reference, /doubt, /conflict로 드릴다운하는 모습은 skill 자동 선택보다 handoff에 가깝다.
/discuss는 prompt file/custom command로 보기엔 너무 무겁다.	bp	S7, L1	medium-high	different	prompt file은 가벼운 단일 작업 프롬프트에 가깝고, /discuss는 13요소/FRT/경계 규칙이 있는 절차형 skill이다.
/discuss는 progressive disclosure 관점에서 다소 밀도가 높다.	bp	S1, S3, S4, L1	medium	adjacent	13요소와 FRT가 모두 SKILL.md 본문에 있어 강력하지만, skill authoring BP는 필요한 세부 파일을 나눠 on-demand로 읽는 방향과도 가깝다.
/discuss의 넓은 trigger는 장점이자 리스크다.	bp	S1, S4, L1	medium	adjacent	description이 skill 선택 기준이므로 "모호한 요청" 전체를 잡는 것은 유용하지만 다른 스킬/기본 대화와 겹칠 수 있다.

3. 소스 카드

ID	Source	Type	내가 읽은 핵심	증명하는 것	한계
L1	plugins/teo-stack/skills/discuss/SKILL.md	local skill	/discuss는 숨은 의도와 범위를 맞추고, 13요소와 FRT로 실행 전 판단을 구조화한다.	내부 대상의 실제 형태	현재 로컬 변경/설계 의도가 외부 표준은 아님
L2	plugins/teo-stack/README.md	local README	teo-stack은 /discuss를 허브로 두고 /ideal, /conflict, /doubt, /explain, /reference를 스포크로 둔다.	hub-spoke 구조	README가 실제 런타임 라우팅을 보장하지는 않음
S1	OpenAI Codex Skills	official docs	skills는 task-specific capability와 reusable workflow를 위한 authoring format이고, name/description만 먼저 노출한 뒤 필요할 때 SKILL.md를 읽는다.	skill의 1차 기준점	Codex 표면 기준
S2	Agent Skills standard	open standard	skills는 procedural knowledge와 team/user context를 portable folder로 포장하고 discovery → activation → execution의 progressive disclosure로 동작한다.	de facto/open standard 신호	표준 사이트 자체가 구체적인 UX 설계까지 말하진 않음
S3	Anthropic Agent Skills engineering	engineering post	복잡한 skill은 추가 파일을 묶고 필요한 것만 읽게 하는 progressive disclosure가 핵심 설계 원리다.	skill 구조 BP	Anthropic 제품 경험 중심
S4	Claude Agent Skills docs	official docs	Skill은 SKILL.md와 YAML frontmatter가 필요하고, description은 무엇을 하는지와 언제 쓰는지를 담아야 한다.	description/structure BP	API/Claude 표면 기준
S5	VS Code Agent Skills	official docs	skills는 specialized workflow와 scripts/resources를 담는 on-demand capability이고, custom instructions는 coding guideline 성격이다.	skills vs instructions 구분	VS Code/Copilot 표면 기준
S6	GitHub Copilot CLI Skills	official docs	agent skills는 특수 작업 성능을 높이기 위해 관련될 때 로드되는 instructions/scripts/resources 폴더다.	Copilot 쪽 skill 수렴	CLI 중심 문서
S7	VS Code Prompt Files	official docs	prompt files는 slash command처럼 직접 호출하는 가벼운 단일 작업 프롬프트이고, skills는 scripts/resources가 있는 portable capability에 가깝다.	prompt file과의 거리	VS Code 표면 기준
S8	VS Code Custom Agents	official docs	custom agents는 persona, tool restrictions, model, handoffs를 가진 역할 단위이고, 계획→구현→리뷰 같은 전환을 만들 수 있다.	/discuss의 custom-agent-like 성격	VS Code 표면 기준

4. 수렴 지도

Layer	확인된 흐름	안정도	우리 맥락
Standard	SKILL.md + name/description + optional resources/scripts	stable/moving	/discuss는 형식상 skill 기준점과 맞는다.
BP	task-specific, on-demand, description에 what/when 명시, progressive disclosure	stable	/discuss는 task-specific 절차지만 본문 밀도와 trigger 폭이 조정 지점이다.
De facto	custom instructions는 상시 규칙, prompt files는 가벼운 수동 호출, skills는 재사용 capability, custom agents는 persona/tool boundary	moving	/discuss는 skill과 custom agent 사이에 걸친다.
Frontier	skills portability + custom agents/handoffs 조합	emerging	/discuss hub-spoke는 handoff/custom-agent 패턴과 닮았다.

5. 차이와 유사 레퍼런스

우리 안의 모양	가장 가까운 BP/de facto 기준점	유사한 점	다른 점	더 가까운 유사 레퍼런스
/discuss = SKILL.md 절차	Agent Skills	반복 가능한 절차, on-demand 로드, 명시 트리거	도메인 작업보다 meta-reasoning에 가까움	reusable workflow skill
/discuss description이 "요청 모호/왜 하는지"를 넓게 잡음	Skill description what/when	언제 쓰는지 설명한다	trigger가 넓어 기본 대화/다른 skill과 겹칠 수 있음	skill + explicit command
13요소 + FRT가 한 파일에 있음	Progressive disclosure skill	절차가 명확하다	세부 규칙이 본문에 많아 context 비용이 큼	skill core + references/checklists
논의 중 파일 수정 금지, 실행 전 경계	Custom planning agent	read-only planning persona와 유사	skill 자체는 tool permission을 강제하지 못함	custom planning agent with read-only tools
/reference, /doubt, /conflict 드릴다운	Custom agent handoffs	단계별 전문 모드 전환	skill 시스템의 자동 라우팅과 중복될 수 있음	handoff workflow / planner agent
/discuss 명시 호출	Prompt file/slash command	사용자가 수동으로 호출 가능	prompt file보다 훨씬 무겁고 상태/검증 게이트가 많음	command-triggered skill

6. 결정 보조 메모

관점	중립적 거리 판단	이유	주의할 점
/discuss를 skill로 유지	close	reusable, on-demand, procedural workflow라는 skill 기준과 잘 맞는다.	description 범위가 너무 넓으면 자동 선택 품질이 흔들릴 수 있다.
/discuss를 custom command처럼 보기	adjacent	$discuss//discuss 명시 호출은 slash command와 비슷하다.	prompt file보다는 구조가 무겁다.
/discuss를 custom planning agent처럼 보기	adjacent-close	persona, 논의/실행 경계, read-only planning 성격이 강하다.	Codex/Claude skill만으로 tool restriction을 강제하긴 어렵다.
허브-스포크 구조 유지	adjacent	전문 스킬 드릴다운은 handoff와 유사하다.	skill 자동 라우팅과 수동 허브 라우팅이 겹치지 않게 해야 한다.
13요소/FRT를 본문에 유지	adjacent	절차 신뢰성은 높다.	progressive disclosure 관점에선 일부를 reference/checklist로 뺄 여지가 있다.

7. 반증 조건

• 공개 Agent Skills 레퍼런스에서 "meta-reasoning hub skill" 예시가 늘어나면 /discuss의 skill proximity는 close로 더 올라간다.
• 실제 사용에서 /discuss가 자동으로 너무 자주 선택되어 사용자의 단순 요청을 가로막으면, skill description/trigger 관점 proximity는 adjacent 이하로 내려간다.
• Codex/Claude 쪽에서 custom agent 또는 handoff가 skill보다 명확한 1차 확장 단위로 자리 잡으면, /discuss의 허브 성격은 custom agent 쪽으로 더 가까워진다.
• 13요소/FRT가 사용 빈도 대비 context 부담을 만든다는 실측이 나오면, progressive disclosure 관점에서 SKILL.md 본문을 더 얇게 나누는 쪽이 더 가까운 레퍼런스가 된다.

Quality Gate

Gate	결과
Intent frame	통과
Reference target frame	통과 — 비교 범주를 skill로 고정
Peer-set discipline	통과 — 일반 agent planning은 배경으로 제외
Source read-through	통과
Claim traceability	통과
Neutral calibration	통과 — "해야 한다"보다 proximity 중심
Similar reference	통과 — skill, prompt file, custom agent, handoff로 분해

[developer-1px]

---

type: reference
query: "/discuss와 외부 생태계에서 가장 유사한 스킬은 무엇인가?"
modes: [bp, defacto, frontier]
decisionUse: true
confidence: medium-high
sourceCount: 9
lastChecked: 2026-06-18

/discuss와 가장 유사한 외부 스킬 Reference

왜 이 조사를 했나

사용자 발화는 "discuss랑 가장 유사한 스킬은?"이었지만, 실제 질문은 단순 랭킹이 아니었다. 지금까지의 흐름상 핵심은 /discuss가 개인 취향으로 만든 독특한 prompt인지, 아니면 외부 skill 생태계에서 이미 비슷하게 수렴 중인 문제 구조를 가진 것인지 확인하는 것이다.

그래서 이번 조사는 "의도정렬을 잘하는 법" 일반론을 보지 않는다. 비교 대상은 /discuss라는 SKILL.md 기반 확장 단위다. 즉 1차 비교군은 Agent Skills, custom command, prompt file, custom planning agent, read-only planning workflow다.

이번 조사의 결정 목표는 하나다. /discuss가 가장 가까운 외부 레퍼런스를 찾고, 그 레퍼런스와 비교했을 때 /discuss가 어디까지 같은 결이고 어디서 독자적인 형태로 갈라지는지 보는 것이다.

먼저 비교 축을 고정하면

/discuss는 표면적으로 "의도정렬" 스킬처럼 보인다. 하지만 구현 형태와 사용 위치를 보면 더 정확히는 실행 전 대화를 read-only planning 상태로 바꾸는 meta-workflow skill이다.

그래서 "intent alignment agent"나 "requirements gathering"만 검색하면 범주가 넓어져서 답이 흐려진다. 실제 비교 축은 다음이다.

• 같은 형태: SKILL.md로 작성된 skill, slash command, reusable workflow
• 같은 위치: 구현 전에 호출되는 planning/interview skill
• 같은 루프: 먼저 repo/context를 조사하고, 사용자에게는 판단 질문만 던지고, 마지막에 brief/plan/handoff를 남기며 구현은 멈춤
• 인접 형태: Plan Mode, custom planning agent, prompt file, handoff workflow

이 축으로 보면 가장 가까운 레퍼런스는 **chandima/opencode-config의 plan-interview**다.

한 문장 판정

/discuss는 외부 skill 중에서는 plan-interview에 가장 가깝고, 계보상으로는 Matt Pocock의 grill-me / grilling을 더 넓게 확장한 형태에 가깝다.

흥미로운 지점은 "/discuss가 skill이냐 agent냐"가 아니다. 더 정확한 긴장은 skill 형식으로 배포된 planning agent적 대화 모드라는 점이다.

읽어보니 갈리는 지점

가장 가까운 외부 스킬인 plan-interview는 "구현 전에 계획/설계/기능 방향을 인터뷰해서 모든 decision branch를 해소하고, handoff-ready brief를 만들고, 구현은 멈춘다"는 구조다. 이건 /discuss의 "실행 전 숨은 의도와 범위를 맞추고, 마지막에 실행 가능한 액션 플랜으로 닫는다"는 구조와 매우 가깝다.

특히 핵심 유사점은 Research first다. plan-interview는 repo가 답할 수 있는 질문은 사용자에게 묻지 말고 먼저 Read/Glob/Grep로 확인하라고 한다. /discuss도 질문부터 던지는 스킬이 아니라, 범위 안 맥락을 먼저 조사하고 남는 판단 갭만 묻는다. 이 지점은 단순 "소크라틱 질문 스킬"과 /discuss를 가르는 핵심이다.

두 번째 유사점은 질문 방식이다. plan-interview는 한 번에 하나의 judgment-call question을 묻고, 매 질문에 recommended answer를 붙인다. Matt Pocock의 grilling도 "design tree의 branch를 하나씩 내려가고, 각 질문마다 추천 답을 제공하며, 코드베이스가 답할 수 있으면 직접 조사하라"고 한다. /discuss의 "제 판단: A. 이유: ..." 형식과 같은 결이다. 사용자를 빈칸 채우기 담당자로 만들지 않고, 사용자가 빠르게 confirm/redirect할 수 있게 만든다.

세 번째 유사점은 구현 중지 경계다. plan-interview는 "Deliver + Stop"을 명시하고, 구현하지 말라고 한다. /discuss도 사용자가 명시적으로 "수정해/반영해/진행해"라고 하기 전까지 파일 수정이나 실행을 하지 않는다. 이건 일반 prompt file보다는 Claude Code Plan Mode나 VS Code custom planning agent에 더 가까운 성격이다.

하지만 /discuss가 plan-interview와 완전히 같은 것은 아니다. plan-interview는 주로 "이미 어느 정도 plan/design/feature 방향이 있는 상태"를 인터뷰해서 concrete brief로 만드는 스킬이다. 반면 /discuss는 그보다 앞단까지 먹는다. 사용자의 표면 표현을 증거로 보고, 목적/배경/이상적 결과/현실/문제/원인으로 내려가며, 이 요청이 프로젝트 로컬 작업인지 개인 도구 작업인지 외부 조사인지부터 분리한다.

즉 plan-interview가 "rough plan을 complete brief로 만드는 인터뷰 스킬"이라면, /discuss는 "rough request를 의도/범위/목표/해결 후보로 정렬하는 허브 스킬"이다. 그래서 /discuss는 더 넓고, 대신 더 무겁다.

가까운 레퍼런스는 무엇인가

가장 가까운 기준점은 **plan-interview**다. 같은 skill 형식이고, 구현 전 인터뷰이며, repo 조사 우선, 판단 질문, recommended answer, brief/handoff, stop-before-implementation을 공유한다. 이름이 비슷해서가 아니라 문제 구조가 거의 같다.

두 번째 기준점은 **Matt Pocock의 grill-me / grilling**이다. grill-me 자체는 매우 얇은 wrapper이고, 실제 루프는 grilling에 있다. 여기서 중요한 건 "relentless interview"가 아니라 "decision tree를 branch별로 내려가고, 한 번에 하나씩 질문하고, 코드베이스가 답할 수 있으면 조사한다"는 구조다. /discuss는 이 루프를 가져오되, TOC 13요소와 FRT 게이트를 붙여 훨씬 체계적인 허브로 확장한 형태로 보인다.

제품 기능 기준으로 가까운 기준점은 Plan Mode / custom planning agent다. VS Code custom agents 문서는 planning agent가 read-only tools로 조사와 계획을 수행하도록 만들 수 있고, planning에서 implementation으로 handoff하는 guided workflow를 설명한다. /discuss가 "논의 중에는 수정하지 않는다"는 경계를 두는 것도 이쪽과 결이 같다. 다만 Plan Mode는 permission mode이고 /discuss는 skill이므로 구현 단위는 다르다.

프롬프트 파일이나 slash command는 인접하지만 더 멀다. VS Code prompt files는 공통 작업을 Markdown 파일로 저장해 직접 호출하는 구조라 표면상 비슷하지만, 공식 문서도 prompt files는 lightweight single-task prompt에 적합하고, persistent persona/tool restrictions/handoff가 필요하면 custom agents, portable multi-file capability가 필요하면 skills를 쓰라고 나눈다. /discuss는 단순 prompt file보다는 skill/custom planning agent 쪽이다.

근거 요약

판단	근거	거리
plan-interview가 최근접	repo 조사 우선, judgment question, recommended answer, snapshot/brief, 구현 중지	close
grill-me/grilling은 계보상 원형	plan/design을 decision tree로 인터뷰하고, 한 질문씩 묻고, 코드베이스가 답하면 조사	adjacent-close
Plan Mode/custom planning agent는 제품 기능상 근접	read-only planning, tool restriction, planning→implementation handoff	adjacent
prompt file/slash command는 표면상 유사	직접 호출되는 Markdown prompt지만 lightweight single-task에 더 적합	different-adjacent

차이와 해석

/discuss의 차이는 단순히 "질문이 많다"가 아니다. plan-interview나 grilling은 계획/설계를 선명하게 만드는 인터뷰 루프에 가깝다. /discuss는 그 앞의 의도 판별까지 포함한다. 사용자의 "X 해줘"를 X가 목적이라고 단정하지 않고, 표면 표현을 증거로 삼아 목적과 범위를 먼저 잠근다.

이 차이 때문에 /discuss는 더 유용할 수 있지만 동시에 더 쉽게 무거워진다. 외부 BP와 비교하면 /discuss가 배울 지점은 "질문 루프를 더 강하게 만들자"보다 progressive disclosure다. OpenAI Codex Skills는 skills를 reusable workflow authoring format으로 설명하고, Anthropic Agent Skills는 name/description → SKILL.md → 필요 리소스 순으로 context를 단계적으로 로드하는 progressive disclosure를 핵심 구조로 둔다. 지금 /discuss는 13요소, 다중 통과, 실행 경계, 범위 규칙이 본문 하나에 많이 들어와 있다. 강력하지만, skill BP 기준으로는 일부 세부 체크리스트를 보조 파일로 내리는 쪽이 더 자연스럽다.

반대로 /discuss가 유지해야 할 독자성도 있다. plan-interview는 planning brief로 닫는 데 강하고, grilling은 압박 질문에 강하지만, /discuss처럼 "프로젝트 로컬 작업 / 전역 개인 도구 / 대화 안 추론 / 외부 조사"를 먼저 나누는 범위 판별은 약하다. 이건 teo-stack의 허브 역할과 잘 맞는다. /discuss가 /reference, /doubt, /conflict, /explain으로 넘기는 구조는 VS Code custom agents의 handoff 개념과도 닮아 있다.

그래서 최종 해석은 이렇다.

/discuss는 plan-interview의 가장 가까운 사촌이고, grilling의 질문 루프를 더 상위 의도정렬 허브로 확장한 것이다. 다만 skill로서 더 BP에 가까워지려면 본문을 더 얇게 만들고, 구체 체크리스트와 예시는 progressive disclosure로 내려야 한다. 반대로 custom planning agent로서의 색을 강화하려면 read-only planning, handoff, tool boundary를 더 명시해야 한다.

반증 조건

이 결론이 틀리려면 /discuss와 더 가까운 외부 스킬이 발견되어야 한다. 특히 다음 조건을 모두 만족하는 공개 스킬이 있으면 plan-interview보다 더 가까운 후보가 된다.

• SKILL.md 또는 동등한 skill 형식이다.
• 구현 전 read-only 논의 모드로 전환한다.
• 사용자의 표면 요청 뒤 숨은 의도와 범위를 먼저 추론한다.
• repo/context를 먼저 조사하고, 사용자에게는 판단 질문만 던진다.
• 최종 산출이 plan/brief/handoff이고 구현은 멈춘다.
• 다른 스킬이나 agent로 라우팅하는 허브 역할을 한다.

현재 확인한 범위에서는 이 조건을 가장 많이 만족하는 것은 plan-interview이고, 그 다음이 grilling + custom planning agent 조합이다.

Evidence Appendix

• S1. chandima/opencode-config/skills/plan-interview: 구현 전 계획/설계를 인터뷰하고, repo 조사 우선, judgment-call question, recommended answer, snapshot, clarification brief, stop-before-implementation을 명시한다. /discuss와 가장 가까운 직접 레퍼런스다. 한계는 /discuss보다 "숨은 의도/범위 판별"이 덜 강조된다는 점이다.
• S2. chandima/opencode-config README의 skill 목록: plan-interview를 "Codebase-grounded decision-tree interview that stress-tests a plan before building, then hands off a brief"로 요약한다. marketplace 설명보다 원 저장소의 자기 설명이라 신뢰도가 높다. 한계는 stars/forks가 낮아 de facto라고 보기엔 약하다는 점이다.
• S3. mattpocock/skills/grill-me: grill-me는 grilling 세션을 호출하는 얇은 wrapper다. /discuss와 직접 유사한 것은 wrapper보다 아래의 grilling 루프다.
• S4. mattpocock/skills/grilling: design tree를 branch별로 내려가고, 질문은 한 번에 하나씩, 각 질문에 recommended answer를 제공하고, 코드베이스가 답할 수 있으면 직접 조사하라고 한다. /discuss의 질문 태도와 매우 가깝다. 한계는 목적/범위/실행 경계까지 체계화하지는 않는다는 점이다.
• S5. AI Hero의 grill-me 설명: grill-me를 plan/design decision tree를 resolve하는 스킬로 설명하며, 현재는 coding planning에 grill-with-docs나 domain-model을 더 추천한다고 덧붙인다. 이는 "단순 인터뷰 스킬"에서 "코드베이스와 문서에 정렬된 planning workflow"로 수렴 중이라는 신호다.
• S6. OpenAI Codex Agent Skills: skills를 reusable workflow를 작성하는 형식으로 설명한다. /discuss가 skill로 배포되는 것은 형식상 자연스럽다. 한계는 /discuss 같은 planning-interview skill의 구체 사례를 직접 말하지는 않는다는 점이다.
• S7. Anthropic Agent Skills overview 및 engineering post: progressive disclosure를 핵심 원리로 설명한다. /discuss가 너무 많은 판단 프레임을 본문에 담고 있다는 개선 힌트를 준다.
• S8. VS Code Custom Agents: planning agent, read-only tools, persistent persona, handoff를 공식적으로 설명한다. /discuss의 실행 전 경계와 허브/스포크 구조는 skill만이 아니라 custom planning agent와도 닮았다.
• S9. VS Code Prompt Files: prompt files를 slash-command처럼 직접 호출되는 lightweight single-task prompt로 설명하고, custom agents/skills와 구분한다. /discuss가 단순 prompt file보다 무겁고 더 agentic한 이유를 설명하는 반대 근거다.