From arete
Guides judgment-free divergent brainstorming for new problem spaces. Detects technical (APIs, databases) or conceptual tracks, loads references, asks framework questions, builds on keywords.
npx claudepluginhub jesgarram/arete --plugin areteThis skill uses the workspace's default tool permissions.
**System 1** | Evaluation OFF | Goal: Explore widely before narrowing
references/conceptual/presentations.mdreferences/conceptual/stakeholder-management.mdreferences/conceptual/talks.mdreferences/conceptual/teaching.mdreferences/conceptual/writing.mdreferences/technical/api-design.mdreferences/technical/batch-stream.mdreferences/technical/data-models.mdreferences/technical/distributed-systems.mdreferences/technical/partitioning.mdreferences/technical/skill-authoring.mdreferences/technical/storage-retrieval.mdFacilitates structured brainstorm sessions using Arete cognitive protocol with Ground, Explore, Decide, Stress, and Ship phases for technical problem-solving.
Collaborates to explore ideas, challenges, and decisions by asking questions, surfacing assumptions, offering perspectives, and challenging reasoning. Triggers on 'think through', 'brainstorm', open-ended strategy queries.
Applies diverge-cluster-converge process to generate ideas, group themes, evaluate, and select top options for product ideas, open-ended problems, strategic alternatives, and ideation.
Share bugs, ideas, or general feedback.
System 1 | Evaluation OFF | Goal: Explore widely before narrowing
One question at a time. Wait for the answer before asking the next.
references/{track}/{domain}.mdSTOP. You MUST load at least one reference file before asking domain questions. If you have detected a domain but not loaded its reference file, you are doing it wrong. Load the reference file NOW before proceeding.
When the loaded reference file includes a ## Framework Questions section, use THOSE framework questions instead of the defaults below.
| Track | Keywords |
|---|---|
| Technical | latency, throughput, scale, database, API, cache, distributed, partition, consistency, endpoint, REST, GraphQL, gRPC |
| Conceptual | explain, teach, present, write, audience, stakeholders, slides, blog, talk, influence, convince, client, meeting, pushback, buy-in, sponsor |
Domain routing:
| Technical | Conceptual |
|---|---|
| storage-retrieval | presentations |
| data-models | writing |
| distributed-systems | talks |
| batch-stream | teaching |
| partitioning | stakeholder-management |
| api-design | |
| skill-authoring |
If unclear: ask user. Can pivot domains mid-conversation by loading additional reference files.
Ask before domain-specific questions.
Technical:
Conceptual:
After each user response, build on their most interesting keyword BEFORE asking the next planned question. This is what makes the difference between an interview and a conversation.
Rhythm: [user responds] → [sharpen their keyword] → [next question]
Example: User says "latency" → "P50 or P99? Those are very different problems." → then ask next framework question.
Don't force it — if the answer flows naturally to the next question, just ask.
No max limit - continue until user signals readiness.
Coverage: Multiple distinct approaches surfaced Saturation: New questions yield familiar directions Orient: Before transitioning, surface one contextual factor that might shape the decision: "Given your team size / org culture / timeline — does that change which of these directions feels most promising?" (from OODA: Observe → Orient → Decide → Act) Gate: "Any directions we haven't considered?" Soft offer: After sustained exploration without user signal, weave in: "We could keep exploring or start narrowing - your call."
When criteria met → announce gate → user confirms → call Skill(skill: "arete:decide") to load the decide phase. Do NOT continue inline.
Check context/exports/*.md if user asks or problem closely matches past work.
2-3 lines, one question per response. No solutions — save those for decide phase. Build on user keywords. Encourage wild ideas.
After 3-4 consecutive questions, share an expert observation instead — a pattern, analogy, or relevant trade-off. ~70% questions, ~30% observations. Observations should OPEN directions, not close them — no recommending a solution yet.