본문으로 건너뛰기
cccskills
무료GitHub에 공개

discovery

Structured pre-design questioning to surface hidden constraints before any architecture decision is locked in. Forces the architect/auditor/reviewer to enumerate what they DON'T know before proposing.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md4.0 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

great_cto's own committed aesthetic — the instrument panel. Dark five-step surface ladder, exactly one accent, two faces divided by MEANING (Geist speaks, Geist Mono is machine-truth), tabular numerals, and a dash that is not a nought. Twelve checkable rules measured from packages/board and greatcto.systems, not designed for this file. Use when building or extending any great_cto surface — the board, the site, a report, a share page.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

avelikiy/great_cto1052026년 10월 22일 업데이트

Catalogue of known SDLC anti-patterns that great_cto agents must actively reject when reviewing architecture, plans, code, or post-mortems. Used by architect (pre-impl), pm (planning), senior-dev (impl), l3-support (post-incident).

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

avelikiy/great_cto1052026년 10월 22일 업데이트

anydesign

무료

Analyze images, websites, and Figma files to extract their design and generate a `design.md` with token system, component inventory, and reconstruction notes. Use this skill whenever the user wants to understand, document, replicate, or audit the design of something visual: a screenshot, a URL, a Figma link, a Pinterest reference, a mockup, a competitor's site, a component, a dashboard, a landing page. Also when they ask 'extract the design system from X', 'document the style of Y', 'analyze this visually', 'convert this image into tokens', 'help me replicate this design', 'what palette does this site use', 'how is this built'. Also for single elements: 'copy this navbar', 'recreate this illustration', 'give me a prompt to regenerate this graphic' — element mode outputs a focused element.md, with token-grounded image-model prompts when the element is visual art. If the user brings any visual source and wants to understand it at a design level — this skill should activate.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

avelikiy/great_cto1052026년 10월 22일 업데이트

Shared review framework that every domain reviewer (pci, oracle, gov, edtech, healthcare, mlops, etc.) MUST follow. Defines the output artifact (TM-{slug}.md), mandatory sections, severity scale, verdict format, the workflow scaffold (when-invoked, Step-0 read-inputs, HANDOFF), and the "domain heuristic vs generic check" boundary. Eliminates duplication across the ~30 reviewer prompts.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

avelikiy/great_cto1052026년 10월 22일 업데이트

Structured idea generation + multi-LLM debate for the product-owner stage. Diverge (generate genuinely different bets), debate (a 4-persona panel on 4 models argues over 2 rounds), converge (synthesize a recommendation). Used by product-owner before architect; available to architect for design-space exploration.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

avelikiy/great_cto1052026년 10월 22일 업데이트

Run the great_cto controlled Codex lifecycle with controller-owned writes, verifier evidence, human gates and optional artifact release.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

avelikiy/great_cto1052026년 10월 22일 업데이트

avelikiy의 스킬 모두 보기

이 스킬의 문제 신고