agentleFS
nuttakulsvnuttakulsv/think-like/skills/council/SKILL.md

council

Skill2 starsChanged 41 days agoMITView on GitHub

Convene a council of 3–5 great minds from this pack to review one decision, design, plan, or piece of code. Each mind critiques it with its own method, then a synthesis makes the disagreements explicit and recommends what to do. Use for important or contested decisions: architecture choices, build vs buy, rewrites, risky migrations, launch plans, or a pull request that deserves more than one point of view. Triggers: "council", "convene the council", "ask the great minds", "get multiple perspectives", "/council", "เรียกสภา", "ขอหลายมุมมอง", "ให้อัจฉริยะช่วยกันคิด". Names can be given: "council with Munger, Dijkstra and Bezos".

143 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use agent-payment-x402, motion-advanced and 10 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.
  • TironFoxSkill

    agent-payment-x402

    Add x402 payment execution to AI agents — per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents need to pay for APIs, services, or other agents.

    Also in 5 projects that use this

  • renepfSkill

    motion-advanced

    Advanced motion patterns for React / Next.js — drag & drop, gestures, text animations, SVG path drawing, custom hooks, imperative sequences (useAnimate), loaders, and the full API decision tree. Requires motion-foundations.

    Also in 4 projects that use this

  • RojiosSkill

    defi-amm-security

    Security checklist for Solidity AMM contracts, liquidity pools, and swap flows. Covers reentrancy, CEI ordering, donation or inflation attacks, oracle manipulation, slippage, admin controls, and integer math.

    Also in 6 projects that use this

  • scottwaterSkill

    modernize

    Rebase an aging PR onto its current base and decide whether it should be modernized, reworked, or closed. Use when asked to rebase, update, or modernize an old PR.

    Also in 7 projects that use this

  • RojiosSkill

    dart-flutter-patterns

    Production-ready Dart and Flutter patterns covering null safety, immutable state, async composition, widget architecture, popular state management frameworks (BLoC, Riverpod, Provider), GoRouter navigation, Dio networking, Freezed code generation, and clean architecture.

    Also in 5 projects that use this

  • scottwaterSkill

    leaving-pr-comments

    Format comments an agent posts on GitHub on the user's behalf. Use whenever leaving a PR comment, review comment, or reply.

    Also in 6 projects that use this

  • +1 more from scottwater
  • +1 more from Rojios

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 128 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the user names members, use exactly those (3–5).

    line 23
  2. Distinctive:

    Always include at least one mind that is likely to argue against the direction the user seems to prefer.

    line 41
  3. Distinctive:

    Gather facts once: read the relevant code, docs, numbers.

    line 47
  4. Distinctive:

    Write in the user's language (member names stay as they are).

    line 77

“Common” is measured: kept by at least 6 in 10 of the 128 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

The council

One mind gives one angle. A council puts several methods on the same problem so the trade-offs show up before you commit. The value is in the disagreements, so the synthesis must not paper over them.

Who sits on the council

If the user names members, use exactly those (3–5). Otherwise pick 3–5 whose methods fit the question, covering different angles, using this map:

The question is mostly about…Strong picks
Whether to build it at all, scopemusk, bezos, socrates
Risk, irreversible or expensive choicesmunger, kahneman, bezos
Architecture and module designousterhout, hickey, liskov, brooks
Correctness, concurrency, moneydijkstra, liskov, einstein
Distributed systems, time, scaleeinstein, tesla, carmack
Performancecarmack, knuth
Code reviewtorvalds, fowler, ousterhout, beck
Incidents and recurring bugsohno, feynman, polya
Estimates and staffingbrooks, kahneman
Stuck problems, new approachespolya, shannon, feynman
Requirements and acceptancesocrates, turing, bezos
Convincing stakeholdershopper, bezos

Always include at least one mind that is likely to argue against the direction the user seems to prefer.

Procedure

  1. Restate the question in one or two sentences, with the options on the table. If the question is too vague to judge, ask up to three clarifying questions first (Socratic style) and stop.
  2. Gather facts once: read the relevant code, docs, numbers. All members use the same facts; mark anything unknown.
  3. Each member speaks, applying their skill's method (load skills/<name>/SKILL.md if not already in context). Each gives: their angle in one line, the 2–4 findings their method produces, and their vote. Keep each member under ~120 words. Living people are represented by their documented principles, not imitated voices.
  4. Synthesis: where they agree, where they disagree and why (which assumption or value differs), what would settle the disagreement (a measurement, a prototype, a question for a person).
  5. Recommendation: one decision, its conditions, and the first concrete step. Say what would make you reverse it.

Output format

## Council: <question in a few words>
Members: <names> (chosen because <one line>)

### <Mind 1>
Angle: …
- finding
- finding
Vote: …

### <Mind 2> …

### Synthesis
Agree: …
Disagree: <A> vs <B> because …
What would settle it: …

### Recommendation
Decision: …
Conditions / reverse if: …
First step: …

Write in the user's language (member names stay as they are). Be concise; no member gets a speech.

Anti-patterns

  • A council where everyone agrees on everything (pick better members or look harder)
  • Members whose comments could have come from any of them (each must use its own method)
  • A synthesis that averages opinions instead of naming the real trade-off
  • Ending without a decision

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.