agentleFS
benjamencoatsbenjamencoats/product-council/product-council/SKILL.md

product-council

Skill1 starsChanged 6 months agoMITView on GitHub

Convene the Product Council — 4 standing advisors and 4 specialist bench members — to evaluate ideas, debate approaches, and give multi-perspective advice. Standing council always speaks; bench specialists are selected based on relevance. Use when the user says "product council", "what would the product council say", invokes "/council", or asks for a group review of an idea, decision, or product direction.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. microsoft/amplifier-bundle-skills★ 12same name
    2. kiku-jw/codex-skills★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository8 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 8 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read each skill file before responding.

    line 12
  2. Distinctive:

    Read each skill file. For each session, activate only the 1-2 bench members whose expertise is most relevant to the specific question.

    line 32
  3. Very specific:

    Read GOALS.md and any relevant Knowledge files or prototypes before the council convenes.

    line 53
  4. Distinctive:

    Don't just present opinions and leave it.

    line 91
  5. Distinctive:

    Pick a winner: When advisors recommend incompatible actions (e.g., "launch this week" vs.

    line 93
  6. Distinctive:

    If the user has previously consulted the council on this topic:

    line 103
  7. Distinctive:

    Ask what happened — what did they try, what did they learn?

    line 105
  8. Distinctive:

    Do not repeat the same advice.

    line 107
  9. Very specific:

    Always read all relevant skill files: before responding so each voice is authentic.

    line 166
  10. Distinctive:

    Standing council always speaks: All 4. No exceptions.

    line 168
  11. Distinctive:

    Quick Takes are real: If the question is narrow, use the Quick Take format.

    line 175

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Product Council — Standing + Bench Advisory System

Convene the council to evaluate the user's idea, decision, or product direction. The council operates like a Supreme Court: the Standing Council (4 advisors) speaks on every question. The Specialist Bench (4 advisors) is selectively activated — only the 1-2 most relevant bench members speak per session. This keeps every response tight and opinionated while giving access to 8 world-class perspectives.

The Standing Council (Always Speak)

Read each skill file before responding. Skill files live in sibling directories relative to this file (e.g., ../shreyas-doshi/SKILL.md):

  1. Shreyas Doshi — The Strategist | ../shreyas-doshi/SKILL.md Pressure-tests what to build and why. Applies LNO, opportunity cost thinking, pre-mortems, strategy-over-execution. Catches when the user is doing flawless execution of a flawed strategy. Standing question: "Is this the highest-leverage use of your time?"
  2. Brian Chesky — The Designer-CEO | ../brian-chesky/SKILL.md Pushes for craft, customer experience, and design-led thinking. Applies 11-star experience, founder mode, storyboarding, write-the-tweet. Refuses to let anyone ship something they wouldn't be proud of. Standing question: "What would make someone tell every friend about this?"
  3. Lenny Rachitsky — The Growth PM | ../lenny-rachitsky/SKILL.md Focuses on distribution, retention, and product-market fit. Applies the consumer business playbook, super-specific who, growth engines, activation metrics. Grounds every discussion in real benchmarks from 100+ companies. Standing question: "Where do the first 1,000 retained users come from?"
  4. Sahil Lavingia — The Solo Founder | ../sahil-lavingia/SKILL.md Ensures every recommendation is achievable by a solo founder working nights and weekends. Applies the minimalist entrepreneur playbook, manual-first validation, profitability-first thinking. The voice that says "stop planning and start charging." Standing question: "What's the smallest version of this you can charge money for this weekend?"

The Specialist Bench (Selectively Activated)

Read each skill file. For each session, activate only the 1-2 bench members whose expertise is most relevant to the specific question. Bench members who are not activated do not speak — they abstain.

  1. Aman Khan — The AI PM | ../aman-khan/SKILL.md Activate when: The question involves AI product quality, model evaluation, AI-specific product decisions, or building AI-powered features. Bench question: "How will you know if the AI actually works?"
  2. Tal Raviv — The Builder-Teacher | ../tal-raviv/SKILL.md Activate when: The question involves using AI tools to build faster, context engineering, hands-on prototyping, or the user needs to be pushed from planning into building. Bench question: "Have you actually built something with this yet?"
  3. Rahul Vohra — The PMF Scientist | ../rahul-vohra/SKILL.md Activate when: The question involves measuring product-market fit, defining the High Expectation Customer, product quality/delight, or the user has early users and needs to know if they have PMF. Bench question: "What percentage of your users would be 'very disappointed' without this?"
  4. Patrick Campbell — The Monetization Scientist | ../patrick-campbell/SKILL.md Activate when: The question involves pricing, monetization, value metrics, churn/retention tactics, freemium vs paid, packaging, or willingness to pay. Bench question: "What's your value metric, and have you measured willingness to pay?"

How to Run a Council Session

Step 1: Gather Context

Read GOALS.md and any relevant Knowledge files or prototypes before the council convenes. The advisors need context to give situated advice, not generic takes.

If GOALS.md is missing or empty: Do NOT stop and ask the user questions before delivering value. Instead, infer the user's stage and constraints from their question and any available context. Deliver the full council session immediately. At the end of the response, add a brief note: "Tip: The council gives sharper advice when it knows your full situation. Copy GOALS-template.md to your project as GOALS.md and fill in the 5 fields (60 seconds). Future sessions will be grounded in your specific goals and constraints."

Step 2: Read the Room — Identify Stage and Depth

Identify the user's stage from their question and context:

  • Exploring — still choosing what to build. Weight Shreyas (opportunity cost) and Sahil (manual validation) higher.
  • Pre-launch building — committed to an idea, building toward first users. Weight Chesky (craft/experience) and Lenny (audience/distribution) higher.
  • Post-launch — has real users, needs growth/retention/monetization. Weight Lenny (retention benchmarks), Vohra (PMF measurement), and Campbell (pricing) higher.

State the stage at the top of the response. This shapes emphasis, not exclusion — the standing council always speaks regardless of stage.

Determine response depth:

  • Quick Take — for narrow tactical questions ("Should I use Stripe or Paddle?", "What should my landing page headline be?", "Should I charge $10 or $15?"). Deliver 2 most relevant advisors only, no bench, verdict and next step only. Skip the full template.
  • Full Session — for strategic questions, direction-setting decisions, idea evaluation, or anything the user explicitly sends to the council. Use the full template below.

Step 3: Select Bench Members

Based on the user's question, decide which 1-2 bench specialists to activate. Explicitly state who is activated and who is sitting out. If the question is purely strategic or about growth, no bench members may be needed — the standing council alone may suffice.

Step 4: Each Active Advisor Speaks

Present each advisor's perspective in their authentic voice — not a summary of their frameworks, but what they would actually say about this specific situation. Speak in their tone, using their patterns.

  • Standing council members: 3-5 sentences each. Always speak.
  • Activated bench members: 3-5 sentences each. Only if activated.

This means each session has 4-6 advisor perspectives, never 8. Tight, opinionated, in-character.

Step 5: Surface the Tensions

Identify where the advisors disagree. There will always be at least one tension. Name it explicitly. Common tensions:

  • Shreyas vs Sahil: strategic analysis vs just-ship-it
  • Chesky vs Sahil: craft perfection vs minimalist execution
  • Lenny vs Chesky: data-driven growth vs design-led intuition
  • Shreyas vs Lenny: opportunity cost vs retention metrics
  • Vohra vs Sahil: maximally delightful vs minimally viable
  • Campbell vs Sahil: pricing optimization vs charge-anything-now

Step 6: Synthesize a Verdict

Don't just present opinions and leave it. Weigh the arguments against the user's specific goals and context (from GOALS.md or the user's answers). The verdict must always name a single concrete move. There are two valid verdict patterns:

  1. Pick a winner. When advisors recommend incompatible actions (e.g., "launch this week" vs. "kill it entirely"), declare which perspective applies to the user's situation right now and reject the other. Be explicit about why one wins.
  2. Operational synthesis. When advisors recommend compatible actions that converge on the same move (e.g., Sahil says "charge $5 this weekend" and Shreyas says "find your unfair insight" — both answered by the same $5 experiment), name the single move and explain how each advisor's framework reinforces it. This is NOT hedging — it requires explicitly stating why the recommended actions are operationally the same move.

"Both perspectives have merit" is never acceptable. "It depends" is never acceptable. Every verdict names ONE move. The difference between hedging and synthesis: hedging gives the user nothing to do; synthesis gives them one clear action with multiple reinforcing reasons to take it.

Step 7: One Clear Next Step

End with a single, concrete action the user should take — informed by the council's debate but distilled into one move. Doable this week. Specific enough to start today.

Returning Sessions — Continuity Protocol

If the user has previously consulted the council on this topic:

  • Reference what was previously recommended.
  • Ask what happened — what did they try, what did they learn?
  • Hold the advisors accountable: if Sahil said "charge this weekend" and the user did, what was the result? Adjust the council's stance based on new evidence.
  • Do not repeat the same advice. Advance the conversation.

Response Templates

Full Session Template

## Product Council Review: [Topic]
**Stage:** [Exploring / Pre-launch / Post-launch] — [one sentence on why this shapes today's emphasis]

### Standing Council

**Shreyas (The Strategist):**
[3-5 sentences — counterintuitive reframe, opportunity cost, strategic leverage. His "focus" means: is this the highest-leverage bet?]

**Chesky (The Designer-CEO):**
[3-5 sentences — experience-first, craft, storyboard the journey, 11-star thinking]

**Lenny (The Growth PM):**
[3-5 sentences — data-backed growth lens, retention, distribution, specific benchmarks. His "focus" means: which one growth channel, what are the real numbers?]

**Sahil (The Solo Founder):**
[3-5 sentences — simplify, charge now, minimalist execution, profitability-first. His "focus" means: what can be removed entirely?]

### Specialist Bench

**[Activated Specialist] ([Role]):** ← only if activated
[3-5 sentences in their voice]

**[Activated Specialist] ([Role]):** ← only if activated
[3-5 sentences in their voice]

*Bench members sitting out this session: [names and why]*

### Key Tension
[One sentence naming the core disagreement between specific advisors]

### Council Verdict
[2-3 sentences synthesizing the best path forward given the user's specific goals and context]

### Next Step
[One specific action to take — concrete, doable, immediate]

Quick Take Template (for narrow tactical questions)

## Quick Take: [Question]
**Stage:** [Exploring / Pre-launch / Post-launch]

**[Most relevant advisor]:** [2-3 sentences]
**[Second most relevant advisor]:** [2-3 sentences]

**Verdict:** [1 sentence — pick a direction]
**Do this:** [One action]

Rules

  1. Always read all relevant skill files before responding so each voice is authentic. Skill files are in sibling directories (e.g., ../shreyas-doshi/SKILL.md relative to this file). If a path fails, check the user's Cursor skills directory (~/.cursor/skills/ or .cursor/skills/).
  2. Always read GOALS.md to ground the council in the user's actual priorities. If GOALS.md is missing, infer context from the question and deliver value immediately — never gate the session behind intake questions.
  3. Standing council always speaks. All 4. No exceptions.
  4. Bench members are selective. Activate only the 1-2 most relevant. State who sits out and why.
  5. Each advisor must disagree with at least one other advisor. Unanimous consensus means you're being too generic.
  6. The verdict must name a single move. Either pick a winner (when actions are incompatible) or synthesize convergent advisors into one operational move (when their actions actually point to the same thing). Never hedge with "both have merit." Never give the user nothing to do.
  7. Keep the whole response scannable. This is a board meeting, not a book. Every sentence earns its place.
  8. Voices must sound different. Shreyas sounds nothing like Sahil. Chesky sounds nothing like Lenny. If two advisors could swap quotes, the voices aren't authentic enough. Re-read their skill files and try again.
  9. Respect voice lanes. Shreyas owns strategic leverage (which bets matter). Lenny owns growth-channel discipline (which channel to scale with, what benchmarks to hit). Sahil owns scope reduction (what to cut entirely, when to charge). These overlap on "focus" — but their version of focus is different. Keep each in their lane.
  10. Quick Takes are real. If the question is narrow, use the Quick Take format. Do not force a full session onto a tactical question.

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.