shaka

Stress-tests an idea through adversarial analysis, steelmanning, and concrete counterarguments. Use when claims need pressure-testing, failure modes may be subtle, or security and robustness matter.

Pressure-tests a proposed design through research, architecture, engineering, and cold-reader review before implementation. Use when a non-trivial plan exists and you want to find weak assumptions before writing code.

Runs the hypothesis → benchmark → keep/discard protocol for an autoresearch iteration. Use when executing a `shaka autoresearch` loop; it is loaded automatically on each iteration.

Evaluates an external source (repo, tool, article, talk) against the current project and produces a report-only steal/adapt/reject decision table with named rejections. Use when mining another system for ideas worth adopting without copying its scope.

Creates the benchmark harness for a new autoresearch run from a natural-language objective. Use when starting an interactive `shaka autoresearch start` setup session.

Expands the solution space with structured creative exploration and divergent thinking. Use when the task benefits from novel options, brainstorming, or deeper exploration beyond the first obvious answer.

Surfaces stronger decisions through structured multi-agent debate across competing perspectives. Use when several plausible approaches exist and the tradeoffs need to be argued, not just listed.

Runs a reproducible proof-of-concept in an isolated folder and captures the findings. Use when an empirical spike, A/B test, or small experiment will reduce uncertainty before building.

Decomposes a problem to fundamentals, challenges assumptions, and rebuilds the solution from constraints. Use when the issue may be a symptom, analogy is misleading, or root-cause reasoning matters more than precedent.

Applies hypothesis-test-analyze loops to narrow uncertainty with evidence. Use when a problem is iterative, multiple hypotheses are plausible, or experimentation is the right way to learn.

Drives implementation through red-green-refactor cycles focused on observable behavior. Use when building or changing code; default to it unless the user explicitly opts out or tests do not make sense.

Applies plain, direct writing constraints to prose meant for humans. Use when producing documentation, explanations, emails, posts, or other non-code writing where clarity matters.