Skip to content
cccskills
FreePublished on GitHub

figure-it-out

Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions. Use for /figure-it-out or 'figure it out'.

The English summary is being prepared. Showing the original description.

neohaskell/NeoHaskell348 stars(GitHub 348 + cccskills 0)

Run score Not tested

See how to install

Files included (2)

  • SKILL.md4.4 KB
  • agents/openai.yaml43 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

Figure it out

When the task matches no playbook, design one. The deliverable before any code is the workflow itself: a sequence of phases that scales rigor to the task, runs the scientific method, and leaves a decision trail a human can audit after stepping away.

Start

Open a todolist whose first item is to read the shared principles in AGENTS.md. Then add the phases below as todos. Keep intermediate workflow plans, evidence and worker outputs under .agents-state.

Phase A: Frame

Ground first, then commit. Don't start the run until you can state:

  • The definition of done as a falsifiable predicate (the prove-it-works principle skill).
  • Scope, quantified: rough units and effort, plus the blockers grounding surfaced.
  • The rigor level, biased high. One-way doors and high blast radius get more. Reversible low-stakes steps get less. Rigor is gates and artifacts, not "try harder".

Present the framing and tradeoffs before committing to a long run. Reversible work proceeds (the never-block-on-the-human principle skill), but a multi-hour run earns one checkpoint.

Phase B: Design the workflow

Decompose into coherent, independently-landable units. A Haskell unit may span types, instances, generated declarations and their consumers when they form one contract change. For planned migrations with temporary breakage, follow the declared phase boundaries and targeted checks in the outcome-oriented-execution principle skill. Sequence riskiest-unknown-first. Scaffold and verification come before features (the foundational-thinking principle skill).

  • Build the verification harness before the work, with the baseline captured from the pre-change state, so the check reads as "old value vs new value".
  • For one-way-door design decisions, run the architect skill (it runs arena). Skip it for mechanical work whose shape is already concrete. A second arena over a settled design is over-engineering (the minimal-change principle skill).
  • Decide what fans out. Parallelize only across independent seams. Give implementation workers isolated worktrees or checkouts with explicit file ownership; read-only workers can use the shared source with independent outputs. A branch name alone does not isolate filesystem writes. Don't over-fan. Follow the delegation instructions in AGENTS.md.
  • Write the designed phase list down. That list is what the human reviews.

Then execute the design. Add its steps to the todolist as concrete items between the Phase C and Phase D entries. Run each under the Phase C loop discipline, and weave the Phase D log through them, a row as each step lands, rather than saving the whole trail for the end.

Phase C: Run the loop

Each unit is an experiment. State the hypothesis, make the smallest change, measure against the predicate on the real artifact, keep it if it advanced, revert it if it didn't. Apply the sequence-verifiable-units principle skill, verifying each unit before starting the next instead of batching checks at the end.

  • Verify by inspecting the artifact, never a self-report. When something passes too easily, suspect the observation method before the system.
  • Pair delegated work with a judge. If a worker games the gate, reset and harden the contract. If the gate itself is wrong, fix the gate in its own change rather than routing around it.
  • A verdict is VERIFIED, NOT VERIFIED, or INCONCLUSIVE. Inconclusive is not a pass. Don't hide a negative.

Phase D: Keep the audit trail

Log the run via the show-me-your-work skill. figure-it-out's work is usually ambitious enough to commit the trail so the reviewer can read it in the PR. The trail plus the diff is what lets the human come back and trust the work.

Phase E: Verify and hand back

Check the whole against the Phase A predicate on the real product, not just the harness. Encode any recurring correction through a Haskell type, the owning API, a gate, a lint rule, a check, or a script (the encode-lessons-in-structure principle skill).

Reply: the playbook you designed, the rigor level and why, the decision-trail path, what's verified against the predicate, and what's still open.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.

The English summary is being prepared. Showing the original description.

neohaskell/NeoHaskell348Updated Oct 26, 2026

arena

Free

Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.

The English summary is being prepared. Showing the original description.

neohaskell/NeoHaskell348Updated Oct 26, 2026

Inspect or supervise a PR or stack through review and CI to merge-ready, using current GitHub evidence and the requested mode.

The English summary is being prepared. Showing the original description.

neohaskell/NeoHaskell348Updated Oct 26, 2026

Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you benchmark or report a measured speedup or regression, including complete framework flows and compilation of projects that consume the framework.

The English summary is being prepared. Showing the original description.

neohaskell/NeoHaskell348Updated Oct 26, 2026

bro

Free

Restate the last message in plain human language, with no jargon.

The English summary is being prepared. Showing the original description.

neohaskell/NeoHaskell348Updated Oct 26, 2026

Build or adapt a local harness to drive, inspect, and profile an interactive CLI or TUI without external services. Use for CLI UX checks, startup regressions, memory leaks, hangs, prompt flows, or terminal demos.

The English summary is being prepared. Showing the original description.

neohaskell/NeoHaskell348Updated Oct 26, 2026

See all skills by neohaskell

Report a problem with this skill