ecosystem-reasoning
Skill7 starsChanged 42 days agoMITView on GitHub
Route clarification, plan review, multi-perspective decisions, and prompt engineering through the right fth-skills reasoning skills, with a fixed precedence so question gates never stack. Use when the user wants options compared or debated, a plan stress-tested, requirements clarified before building, or a prompt designed or optimized.
In this repository83 other files it gives its agents.
- AGENTS.mdAGENTS.md
- accessibility-enforcerSkill
- access-policy-designerSkill
- adaptive-guardSkill
- agent-reviewerSkill
- anti-ai-slop-designSkill
- api-mock-designerSkill
- api-observability-plannerSkill
- app-store-reviewerSkill
- ask-first-act-laterSkill
- assumption-checkerSkill
- auth-flow-designerSkill
- b2b-founder-roadmapSkill
- brand-name-labSkill
- breaking-change-detectorSkill
- changelog-generatorSkill
- checkpoint-guardianSkill
- claude-style-codingSkill
- claw-integration-designSkill
- context-compressorSkill
- contract-first-designerSkill
- coolify-orchestratorSkill
- crash-analystSkill
- data-lineage-tracerSkill
- data-maskerSkill
- deep-link-architectSkill
- design-intelligenceSkill
- design-md-enforcerSkill
- ecosystem-apiSkill
- ecosystem-databaseSkill
- ecosystem-mobileSkill
- ecosystem-orchestrationSkill
- ecosystem-productSkill
- ecosystem-securitySkill
- ecosystem-webSkill
- error-recoverySkill
- fth-design-crafterSkill
- geo-auditorSkill
- geo-optimizerSkill
- index-advisorSkill
- jev-orchestratorSkill
- mastermind-loggerSkill
- memory-ledgerSkill
- migration-strategistSkill
- mobile-perf-auditorSkill
- mobile-security-auditorSkill
- multi-brain-debateSkill
- multi-brain-expertsSkill
- multi-brain-scoreSkill
- multi-brainSkill
- offline-sync-designerSkill
- onboarding-designerSkill
- output-criticSkill
- parallel-plannerSkill
- pgbouncer-architectSkill
- plan-hardenerSkill
- plan-implement-verify-recoverSkill
- proje-analizcisiSkill
- project-analyzerSkill
- project-focus-firstSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 3 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Philosophy: Ask only what changes the outcome.
- Distinctive: line 34
Follow this protocol whenever this ecosystem is invoked.
- Very specific: line 40
Execute: Run steps in order. Steps that share a parallel group are independent and may run concurrently (@parallel-planner).
- Very specific: line 41
Gates: Before any destructive, irreversible, or production-impacting action, stop at @checkpoint-guardian, or ask for explicit confirmation …
- Very specific: line 42
Failures: When a step misses its *Done when*, hand off to @error-recovery.
- Very specific: line 43
State: Keep a run log (workflow id, step, status, artifact).
- Distinctive: line 46
Skip this protocol: when the user names one specific skill (invoke it directly) or asks a quick factual question that needs no workflow.
- Very specific: line 100
Run at most one clarification gate per request, choosing the first one whose condition holds.
≈ “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.
Files
🧠 Reasoning Ecosystem
This skill is the entry point of its ecosystem. It chooses a workflow, checks which member skills are installed, runs them in order with explicit handoffs, and degrades gracefully when a member is missing. The workflow map lives in references/workflows.json; the handoff format lives in references/handoff-contract.md.
Catalog
<!-- BEGIN GENERATED: ecosystem-catalog (generated from the ecosystem workflow map by build_ecosystems.py — do not edit by hand) -->Domain: Reasoning, Planning Gates & Prompting — Clarify intent, stress-test plans, compare perspectives, and craft prompts, without stacking redundant question gates.
Philosophy: Ask only what changes the outcome. Run at most one clarification gate per request, in a fixed precedence, then act. Use multiple perspectives when trade-offs are real, not by default.
| Skill | Role | Handoff artifact |
@project-focus-first | Hard gate: fixes one primary focus before a new project is discussed. | inline handoff block |
@ask-first-act-later | Consultant mode: asks targeted questions before any implementation. | inline handoff block |
@assumption-checker | Surfaces and verifies technical, data, business, and intent assumptions. | inline handoff block |
@plan-hardener | Stress-tests plans with assumption-first review modes. | inline handoff block |
@multi-brain | Synthesizes three perspectives into one consensus answer. | inline handoff block |
@multi-brain-experts | Selects three domain experts for the perspectives. | inline handoff block |
@multi-brain-debate | Runs a two-round adversarial debate before a verdict. | inline handoff block |
@multi-brain-score | Adds confidence scores and weighted consensus. | inline handoff block |
@prompt-crafter | Designs, optimizes, and evaluates prompts and agent specs. | inline handoff block |
@turkish-prompt-compiler | Measures and compresses long Turkish prompts without losing intent. | inline handoff block |
<!-- END GENERATED: ecosystem-catalog -->Router Protocol
<!-- BEGIN GENERATED: ecosystem-router (generated from the ecosystem workflow map by build_ecosystems.py — do not edit by hand) -->Follow this protocol whenever this ecosystem is invoked.
- Match. Compare the request with each workflow's When phrases. Pick one workflow, or route straight to a single member skill when the request is narrow. If two workflows fit equally, ask one question to choose. If the request belongs to another domain, use the ecosystem index in
@ecosystem-orchestration. - Preflight. Find out which step skills are installed: check the skills your host lists, or run
python <skill-dir>/scripts/install_all.py --status --workflow <id>(<skill-dir>is the folder containing thisSKILL.md). Show a short plan: step, skill, installed or missing, condition, expected artifact. - Missing skills never block. Offer once: (a) install them —
install_all.py --workflow <id>prints the commands and only runs them with--executeafter the user agrees; or (b) continue in fallback mode — perform the step yourself using its Does and Done when columns and label that outputfallback. - Conditions. Skip optional steps whose condition does not hold, and say which steps you skipped and why.
- Execute. Run steps in order. Steps that share a parallel group are independent and may run concurrently (
@parallel-planner). Pass artifacts as described inreferences/handoff-contract.md. Check each step's Done when before moving on. - Gates. Before any destructive, irreversible, or production-impacting action, stop at
@checkpoint-guardian, or ask for explicit confirmation when it is not installed. - Failures. When a step misses its Done when, hand off to
@error-recovery. Without it, retry once with a changed approach, then report the blocker with evidence instead of guessing. - State. Keep a run log (workflow id, step, status, artifact). Record it with
@memory-ledgerwhen installed, and write a@session-transferhandoff if the run will continue in another session. - Finish. Summarize artifacts, skipped steps, open risks, and the most relevant next workflow.
Skip this protocol when the user names one specific skill (invoke it directly) or asks a quick factual question that needs no workflow.
<!-- END GENERATED: ecosystem-router -->Workflows
<!-- BEGIN GENERATED: ecosystem-workflows (generated from the ecosystem workflow map by build_ecosystems.py — do not edit by hand) -->1. Clarification Gate Flow (reason-clarify)
When: “new project idea”; “ambiguous request”; “ask me before you build”
| # | Skill | Does | Done when | Condition | Parallel group |
| 1 | @project-focus-first (optional) | Establish the primary focus for a brand-new project. | User chose one primary focus. | New project and no focus stated | — |
| 2 | @ask-first-act-later (optional) | Ask the few questions that change the outcome. | Requirements are confirmed by the user. | User explicitly asked to be consulted first | — |
| 3 | @assumption-checker | List remaining assumptions and verify the risky ones. | No unverified high-risk assumption remains. | — | — |
2. Decision Quality Flow (reason-decision)
When: “which option is better”; “debate these approaches”; “give me a robust recommendation”
| # | Skill | Does | Done when | Condition | Parallel group |
| 1 | @multi-brain | Produce three perspectives and a consensus. | Consensus names the chosen option and why. | — | — |
| 2 | @multi-brain-experts (optional) | Swap generic perspectives for domain experts. | Three relevant experts were selected. | Domain expertise matters (security, cost, UX) | — |
| 3 | @multi-brain-debate (optional) | Stress the top two options through rebuttals. | Verdict addresses every rebuttal. | Two strong options clash | — |
| 4 | @multi-brain-score (optional) | Weight the consensus by stated confidence. | Low-confidence areas are flagged. | — | — |
| 5 | @output-critic (optional) | Score the final recommendation before delivery. | Recommendation meets the acceptance threshold. | — | — |
3. Plan Hardening Flow (reason-plan-review)
When: “review my plan”; “find risks in this architecture”; “red-team this plan”
| # | Skill | Does | Done when | Condition | Parallel group |
| 1 | @plan-hardener | Pick the review mode by size and risk and run it. | Every critical risk has a mitigation or an owner. | — | — |
| 2 | @task-decomposer (optional) | Turn the hardened plan into executable subtasks. | Subtasks carry the mitigations. | — | — |
4. Prompt Engineering Flow (reason-prompting)
When: “write a system prompt”; “optimize this prompt”; “compress this Turkish prompt”
| # | Skill | Does | Done when | Condition | Parallel group |
| 1 | @prompt-crafter | Design or optimize the prompt with an explicit output contract. | Prompt passes the final check list. | — | — |
| 2 | @turkish-prompt-compiler (optional) | Measure and compress a long Turkish prompt. | Savings reported with fidelity preserved. | Prompt is long and in Turkish | — |
Direct handoffs
@project-focus-first→@b2b-founder-roadmap: The chosen focus is B2B go-to-market.@prompt-crafter→@ugc-crafter: The prompt targets UGC-style image or video generation.@prompt-crafter→@jev-orchestrator: The prompt only returns a small fixed label set.
Gate precedence
Run at most one clarification gate per request, choosing the first one whose condition holds. A gate that another gate already satisfied must be skipped. @checkpoint-guardian is not a clarification gate; it always applies before irreversible actions.
@project-focus-first— A brand-new project with no stated primary focus.@ask-first-act-later— The user explicitly asked for questions before action.@assumption-checker— A multi-step or ambiguous task is about to start.@plan-hardener— A written plan exists and must be stress-tested.
<!-- END GENERATED: ecosystem-workflows -->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
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.