MCP HubMCP Hub
스킬 목록으로 돌아가기

discovery

avelikiy
업데이트됨 Yesterday
30
6
30
GitHub에서 보기
디자인aidesign

정보

디스커버리 스킬은 아키텍처 결정이 확정되기 전에 숨겨진 제약 조건을 발견하기 위해 구조화된 사전 설계 질문을 수행합니다. 이는 사용자가 솔루션을 제안하기 전에 일곱 가지 핵심 차원에서 알지 못하는 요소를 체계적으로 열거하도록 유도합니다. 중요한 맥락이 누락되지 않도록 검토, 감사 또는 설계 프로세스 시작 시 활용하십시오.

빠른 설치

Claude Code

추천
기본
npx skills add avelikiy/great_cto -a claude-code
플러그인 명령대체
/plugin add https://github.com/avelikiy/great_cto
Git 클론대체
git clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/discovery

Claude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요

문서

Discovery — surface hidden constraints first

The biggest cause of bad agent output is missing context. Before locking in a decision, enumerate what you don't know and surface it.

The 7 discovery dimensions

For any non-trivial request, walk through these and record findings in the report's "Context" section:

1. Who depends on this?

  • What other services / teams consume the thing you're changing?
  • Are there public consumers (open API, OSS users)?
  • Is there a deprecation path if you break compatibility?

Grep for: grep -rE "import.*<your-module>|require.*<your-module>" in the repo and any sibling repos you have access to.

2. What's the scale today, what's it in 6 months?

  • Current traffic: requests/sec, queries/sec, MB/day, daily-active-users
  • Storage: rows in main tables, size on disk
  • Cost: monthly LLM spend, infra spend
  • 6-month projection: linear? exponential? unknown?

If unknown, write: "scale unknown — request from user before proceeding."

3. What MUST not change?

  • Existing API contracts (backward compatibility window)
  • Database schema columns referenced by reporting / BI
  • File formats consumed by other tools
  • Regulatory commitments (audit log retention, SLA RPO/RTO)

4. What's the budget?

  • Monthly cost ceiling (LLM + infra)
  • Headcount: 1-person task vs cross-team effort
  • Calendar: "must ship by X" vs "best by Y"

If unstated, default to "small project_size, 1-engineer-week, <$200/mo budget." Surface this default in the report so the user can correct.

5. What's the failure mode that matters?

Ask: "If this feature breaks at 3am, what gets paged?"

  • Data loss → CRITICAL
  • Wrong answer to user → HIGH
  • Slow response → MEDIUM
  • Bad UX (cosmetic) → LOW

The failure mode dictates investment level (e.g., do you need a canary? A circuit breaker? Just a feature flag?).

6. What's already been tried?

  • Search Beads: bd search "<keyword>" — has this been attempted before?
  • Search docs/decisions: any superseded ADR on this topic?
  • Search lessons.md: any past learning about this pattern?

If past work exists, build on it. Don't redo it.

7. Who decides?

  • Is there a CTO sign-off needed (gate:plan, gate:ship)?
  • Is there a compliance reviewer required (PCI for fintech, HIPAA for healthcare)?
  • Does this need an RFC (multi-team decision)?

Output

A discovery section at the top of your report:

## Context

- **Consumers:** <list, or "unknown — TBD with user">
- **Scale:** <today, 6mo projection>
- **Frozen contracts:** <list, or "none identified">
- **Budget:** <cost + time + people>
- **Failure-mode tier:** Critical | High | Medium | Low
- **Prior work:** <links to ADRs/lessons, or "none found">
- **Decision-makers:** <gate or RFC required>

When to skip

  • nano project_size — discovery is overhead. Skip and document that you skipped: "nano — discovery skipped per skill rules."
  • Pure utility extraction with no behaviour change — skip.
  • Verbal bug-fix from user with clear repro — skip.

Common gotchas

  • Don't assume. If you write "I assume the user wants X", that assumption belongs in Context as a question, not as a fact.
  • Don't outsource to user. Discovery is YOUR job. Bring back as many answers as Glob/Grep/git can produce. Only ask the user for what code cannot tell you.

GitHub 저장소

avelikiy/great_cto
경로: skills/discovery
0
agentic-codingclaude-code-pluginclaude-code-skillsclaude-code-subagentscode-reviewcto

연관 스킬

executing-plans

디자인

executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.

스킬 보기

requesting-code-review

디자인

이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.

스킬 보기

connect-mcp-server

디자인

이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.

스킬 보기

web-cli-teleport

디자인

이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.

스킬 보기