agentleFS
avelikiyavelikiy/great_cto/skills/discovery/SKILL.md

discovery

Skill112 starsChanged 2 months agoMITView on GitHub

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.

26 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use specify, plan and 5 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • ArvorCoSkill

    specify

    Create feature specification from natural language description. Use when starting a new feature or creating a spec. Triggers on: create spec, specify feature, new feature spec.

    Also in 3 projects that use this

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 5 projects that use this

  • Hugging FaceSkill

    implement

    Make tests pass. Invoke after /write-tests produces failing tests.

    Also in 6 projects that use this

  • nicolasestremSkill

    brainstorm

    Structured idea generation and solution exploration with systematic analysis.

    Also in 4 projects that use this

  • MicrosoftSkill

    init

    Also in 3 projects that use this

  • AnthropicSkill

    architecture

    Create or evaluate an architecture decision record (ADR). Use when choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 24 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

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

    line 46
  2. Distinctive:

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

    line 61
  3. Distinctive:

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

    line 66
  4. Very specific:

    Search Beads: bd search "<keyword>" — has this been attempted before?

    line 77
  5. Distinctive:

    Search docs/decisions: any superseded ADR on this topic?

    line 78
  6. Distinctive:

    Search lessons.md: any past learning about this pattern?

    line 79
  7. Distinctive:

    If past work exists, build on it.

    line 81
  8. Distinctive:

    Don't assume: If you write "I assume the user wants X", that assumption belongs in Context as a question, not as a fact.

    line 114

“Common” is measured: kept by at least 6 in 10 of the 24 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.