Menu
SkillsMP has collected 54 skills from Archive228/loopkit. Open a skill to review its source and details.
Showing 40 of 54 collected skills.
Before compaction Loopkit extracts decisions into claude-decisions.json (machine-readable). Read it alongside claude-progress.txt at session start — prose is for humans, JSON is for the loop.
Split the Plan/Act/Verify loop across three model tiers — frontier planner, cheap executor, frontier judge — via env vars read by run.sh.
Run the fixed 6-step session-opening sequence — pwd, read progress, git log, count remaining features, init.sh, smoke-test last feature — before touching any new work. The orientation ritual that lets fresh-context sessions reconstruct project state in under…
Read git log since initial scaffold + last 3 progress notes, draft feature additions to a SEPARATE suggestions file so feature_list.json stays immutable
Use when starting any conversation in a loopkit-enabled project - establishes how to find and use loopkit's 49 skills, requiring skill invocation before ANY response including clarifying questions.
One sentence that describes WHEN to invoke this skill. Write it as a trigger phrase, not a summary — include the words a user would say ("fix bug", "add feature", "review diff"). The agent routes on this field.
Escalate blocked runs to a human via configured channel or fallback to BLOCKED.md and exit the loop. Use when the loop hits an ambiguous spec, a missing credential, a destructive action needing approval, or 3+ consecutive verify failures on the same task.
Calibrate a reviewer persona with few-shot rubric examples so skepticism stays consistent and doesn't drift lenient over long runs.
Enumerate every end-to-end feature as strict JSON entries with passes:false, editable-passes-only discipline, and priority order. The ledger fresh-context sessions read to know what's done, what's next, and what they're forbidden to touch.
Systematically remove one harness component at a time and measure impact, killing scaffolding that no longer earns its complexity.
Author idempotent init.sh under 120s plus sibling test.sh, stop.sh, reset.sh, serve.sh with fixed names the harness relies on.
Expand a 1-4 sentence product brief into a full spec with a design language, acceptance surface, and an ordered feature list.
Detect and interrupt the pattern where an agent confidently praises work it just produced instead of reviewing it critically. Same-context grading is not review — it's rationalization.
Negotiate a pre-code contract between generator and evaluator personas that defines what "done" means before any code is written. Turns fuzzy specs into a testable target the evaluator can hold the generator to.
Before picking new work, smoke-test the last "completed" feature. If it's broken, revert and re-open it before touching anything else. Kills the "looks shipped, isn't shipped" bug across sessions.
Build a repeatable eval loop that grades agent output with an LLM judge, so prompt/skill changes get scored against a baseline instead of eyeballed. Reuses loopkit's verifier subagent as the grader — do not build a new one.
Get a PDF into the model without blowing the context window or losing structure. Native PDF beats OCR-then-text for most cases; extract-then-summarize beats native for very long docs.
Cache the parts of the prompt that don't change so a long-running loop stops paying full price on every turn. Use when the system prompt, tool defs, or reference docs are stable across many turns.
Write and read the between-session handoff file so a fresh agent with no memory can pick up where the last one stopped without re-deriving context. Structured prose, not JSON — the model writes prose better.
Get JSON out of the model reliably. Prefer tool_use with a schema over prompted-JSON, validate on receive, retry on parse fail. Use when downstream code will parse the response.
Use before claiming work is complete, fixed, or passing — before committing, opening a PR, or handing off. Requires running the verification command in THIS turn and reading its output before any success claim.
Verify that an endpoint checks ownership, not just authentication. Use on any handler that reads or mutates user data.
Keep the agent's context lean so accuracy doesn't collapse. Use on long sessions, big files, or when the agent starts hallucinating.
Test the boundary between two systems by the contract, not the implementation. Use for APIs, integrations, and shared interfaces.
Validate and constrain untrusted input at the boundary. Use on any handler that accepts external data.
Design the three states every data UI forgets. Use for any component that fetches or lists data.
Extract the actual cause from a stack trace instead of pattern-matching the error type. Use on any crash or exception.
Flatten deeply nested conditionals into readable, early-return code. Use on any function with 3+ levels of indentation.
Undo a bad change without nuking unrelated work. Use when a specific commit or change broke something.
Write the goal spec on disk before the agent acts, so it can't drift. Use before any multi-step task.
Parallelize independent sub-jobs across fresh-context subagents instead of one bloated context. Use when a goal branches into many independent pieces.
Don't over-equip an agent with tools/MCP servers. More tools = more ways to fail and a higher cognitive load. Use when wiring tools or an agent underperforms.
Catch the accessibility failures that ship in almost every AI-built UI. Use after building any interactive component.
Review a diff against the goal spec assuming the code is BROKEN. The reviewer that lives in the maker's head always agrees with itself — this pulls review into a hostile, separate pass. Invoke after every code change before marking work done.
Find the exact commit that introduced a bug. Use when something worked before and broke, and you don't know which change did it.
Turn a set of commits or a diff into a clean, user-facing changelog entry. Use before a release or PR description.
Turn messy WIP into clean, atomic commits with messages that explain why. Use before opening a PR.
Find the untested code paths that actually matter, not just the coverage percentage. Use after adding tests.
Capture an architectural decision so the next session (or engineer) knows WHY. Use after any non-obvious technical choice.
Decide whether to add, keep, or remove a dependency. Use before adding any package.