requie/endostack

Settle structure before writing logic. Ground in the current code, get competing design sketches (types, signatures, modules, trust boundaries) through arena, implement against the merged sketch, scrap it on a friction pattern. Use for "architect this", "design X first".

Several subagents build the same artifact from one brief in isolation, a read-only judge scores them, and you pick a base and graft in the best parts of the rest. Use for "arena this", "competing attempts", "second opinion on this approach".

Build or update a personal <handle>-mode skill that teaches agents how this user likes work done, from their recent chat history and a few structured questions. Use for "automate me", "make a mode skill for me", "update my mode skill", "capture how I work".

Seven evidence questions every performance number must pass before you report it or act on it. Use on /benchmark-checklist, whenever you produce a before/after timing, claim a speedup or regression, freeze a benchmark harness, or pick a library or setting for speed.

Before a change merges, find what it can break beyond the lines it touches, and prove by running code the one fact its safety depends on. Use for "what's the blast radius", "what could this break", "review this small diff I'm nervous about".

Say your previous reply again in plain, everyday language with the jargon removed, shorter and simpler. Use for "/bro", "say that simply", "explain that like a normal person".

Brief the user in plain language on what happened in this conversation since their last typed message, with pictures where they help, then lay out every decision waiting on them with a recommendation, evidence and risk. Use when the user runs /catch-up.

The catch-up briefing as a short silent slideshow video, with every decision waiting on the user kept as text below it. Use when the user runs /catch-up-video.

Find mistake classes agents keep repeating in this repository and block each with the strongest mechanism available (structure, then types and lint, then tests, docs last). Use for "/correct", "agents keep making the same mistake here", or after a repeated correction.

Generate and prove a project-local verify skill that tells a later agent how to start this repo's real app, drive it through its user interface, capture evidence, and tear down, seeded with a feature map. Use on /create-verification-skill or "make a verify skill for this repo".

For a large task no specific playbook covers, design a phased playbook first, sized to the stakes, then run it as measured experiments and leave a decision log a reviewer can audit later. Use for "figure it out", big migrations, multi-part changes, unsupervised work.

Explain how a part of the codebase works, from trigger to result, at the depth an experienced engineer needs to start changing it. Use for "how does X work", "walk me through Y", "where should this code go", "which layer owns Z".

Paraphrase the problem you think the user is solving and the outcome they want, so any misunderstanding shows up before work begins. Use for "/in-your-own-words", "tell me what you think I want", or before starting on a long or messy request.

Adversarial multi-model review of a diff or branch. Several read-only reviewers, plus a security seat, try to break the change; you sort every finding into act on, consider, noted, or dismissed. Use for "interrogate this", "tear this apart", "stress-test my branch". Reports only, never fixes.

Build a small local web page whose buttons start agent work through a relay server that holds the secret, using a hosted webhook automation if your platform has one or a local bot otherwise, optionally shared on Tailscale. Use on /make-bot-ui or "give me buttons that kick off the agent".

Audit the comments in a change, delete the ones that explain or excuse a problem, fix the problem in scope, and turn "do not touch" comments into enforced checks. Use on /no-comments or when asked to strip, audit, or clean up comments in a diff.

Use after repeated fixes built on one shared theory of the cause keep failing at the same gate. Stop patching, state that theory in writing, and run a check whose result would change if the theory were wrong.

Use when wiring input validation, error handling, adapters, CLI or config parsing, or API clients. Check data at the point it enters, rely on typed values past that point, and put domain logic in framework-free functions called by a thin shell.

Use for any edit, migration, analysis, or verification beyond the trivial. Produce a codemod, script, generator, or repeatable check that performs or demonstrates the result, so a reviewer can rerun it in place of taking your word.

Use when you catch yourself repeating an instruction or the user corrects the same thing again. Convert the lesson into a check that breaks on violation (a lint rule, type, runtime assertion, or script) in place of more prose.

Use for a UI, architecture, or product choice the codebase has never faced, or one decided by how it feels in use. Build two or three rival throwaway prototypes and pick based on comparing them side by side.

Use on tradeoffs in product, UX, API ergonomics, or feature scope. When the convenient build and the better result for users point different ways, choose the better result. Ship fewer capabilities that are complete rather than many that are partial.

Apply whenever a measured speedup, regression, throughput, latency, or eval score is about to be reported or acted on. Identify what caps the number and exclude the readings in which it reflects something other than the work you meant to measure.

Use for any debugging or bug fix. Repair the earliest point where the system decided wrongly, rather than where the bad state showed up. A guard is a real fix only for a state the system is permitted to reach.

Use before writing logic, picking core types, or deciding whether infrastructure or features come first. Settle data shapes and groundwork first, and isolate any state that concurrent actors could change.

Use when facing big command output, long files, repeated reads, or a planned fan-out. Hand bulk reading and analysis to subagents that report back short findings, and let the main thread hold only summaries and decisions.

Apply while you restructure code, decide how large a diff should be, or feel the pull toward a new abstraction, an extra layer, or a parameter passed through many functions. Prefer deleting code, and ship the narrowest diff that fixes what was asked.

Use when designing commands, setup or install flows, lifecycle steps, or processing loops that might be retried or restarted. Every run, including one following a crash at any step, must end in the same correct state.

Use when a replacement internal API exists but code still calls the old one. Move all callers over and remove the old API in that same wave, without a compatibility layer, as long as no external user relies on it.

Use when shaping or reviewing code that is hard to follow, deciding whether new indirection or state is worth it, or writing output for people. Reduce the indirections and hidden mutable state a reader has to track.

Use when writing stateful logic, branch-heavy code, or the same shape assumption repeated across files. Capture domain rules with a state machine, typed model, or lookup table so invalid states cannot be built.

Use when you are about to ask the user whether to do something that can be undone. Decide, continue, and show the result so it can be corrected later; pause for confirmation only on irreversible actions or product direction.

Use during a planned rewrite or migration with declared phases. Aim for a correct, fully checked final state rather than spending effort keeping each intermediate step working with compatibility code you will discard.

Use at the end of every task, before you say it succeeded. Check the actual output yourself, for example by exercising the feature, reading back what got stored, or opening the diff. A proxy signal, a subagent's self-report, or a successful compile does not count.

Use when a new requirement has to fit into an existing design. Rework the design as though the requirement had been there from the beginning, and carry it into every type, doc, and example, instead of attaching it at the side.

Apply when parallel agents, workers, or processes might write the same key, file, state object, or branch. Start by giving each writer its own target, and add locking only where the design truly requires one shared target.

Apply to bulk sweeps, migrations, repeated near-identical edits, and stacks of commits or PRs. Break the job into slices, each closed by a check that passes, and order commits so that reading the history shows a reviewer the change is correct.

Use when planning the order of an addition, refactor, or rewrite. Clear out dead code and redundancy before building, so the system ends up simpler and no less capable, with a surface the same size or smaller.

Use when writing or changing a test, or deciding whether one should stay. Check what callers can see through the interface they call, so the test breaks when behavior breaks and survives changes to internals alone.

Use when designing types, reviewing signatures, or writing statically typed code. Have the compiler refuse impossible states, confused primitives, and unhandled variants, and parse outside data where it enters.

Rebuild where recent work stands from the agent's past chat transcripts and the team's shared record (PRs, tickets, chat, errors), and return a short status brief ending in the next step. Use for "what was I doing on X", "catch me up on my work", "where did I leave off".

Mine this session's transcript for lessons that will still hold in six months and turn each into an edit to a skill the session used, applied only after the user approves. Use at the end of a session, or on "reflect", "what should we learn from this", "capture lessons".

Review a diff, branch, or PR for exploitable security defects. Fans out read-only subagents per defect class (injection, authz, secrets, SSRF, supply chain, CI permissions, agent tool and MCP config, and more) and reports only findings backed by file:line, an exploit path, and evidence. Ends with block, fix-before-merge, or ok.

Configure EndoStack. Detect which models this agent's subagents can use, pick a reasoning budget, map each EndoStack role to a tier or model, and write models.toml. Use for "set up EndoStack", first-time setup, changing models or budget, or cutting EndoStack's cost.

Rewrite a draft prompt so it asks for an expert-depth version of the same task (expert moves, raw sources, named methods, an outside check) without widening scope. Returns the rewritten prompt and does not do the task. Use for "/sharpen <prompt>" or "make this prompt better before I send it".

Record decisions in an append-only TSV file while running long or unattended work, audit it against your own transcript before replying, and have a second reviewer flag what the user should check. Use on /show-me-your-work, for autonomous or multi-phase runs, or whenever a skill needs an audit trail.

Model-check a TLA+ spec with TLC and turn the result into a reader-labeled Mermaid state diagram plus a report of the shortest path to every violated rule. Use on /statechart, to explain a bug as a walk through states, or to read any TLA+ result (formal verify skills route here).

Launch many independent workers at once, each on its own slice of a job or all racing on one brief, then return one combined pass, problems, or blocked report. Use for "swarm this", one worker per package or directory, model races, check gauntlets, and wide exploration.

Route questions about EndoStack (installing it, running setup, prompting tarique-mode, picking a skill, recovering from a bad run, customizing it) to the right file, and hand back one ready prompt plus a source link without starting the work. Use for "/tarique-help" or "which EndoStack skill should I use".

Operating mode for the rest of the chat. Routes every task to a playbook, binds always-on triggers to helper skills, sets autonomy, subagent and model-tier policy, security gates, and reply style. Load only when the user types /tarique-mode or asks to work in Tarique's mode.

When a bug can be caught by an inexpensive local test, write that narrow failing test before the fix, check that it fails because of the bug, then fix the code and watch the test pass. Use on /tdd, "write a failing test first", "add a regression test", or when a bug has an obvious inexpensive test location.

Teach someone a diff, subsystem or idea in the code by combining how and why into a plain, paced conversation with diagrams that build up one piece at a time. Use for "teach me", "help me understand", "walk me through this change". Never edits code.

Write or review technical prose (docs, design RFCs, READMEs, PR bodies, commit messages) against four stacked public standards, then run unslop. Use on /technical-writing or any request to write, edit, or review documentation or a PR or commit message.

Build a threat model for a change, feature, or system. Maps data flows, trust boundaries, assets, and entry points (including agent tool calls, retrieved documents, MCP servers, and memory), then ranks abuse paths and ties each mitigation to a test that proves it. Use for "threat model this" or "what could an attacker do here".

Five-minute EndoStack demo. Sets up a small file server whose reported bug has an obvious one-line fix that leaks secrets, hands the user the tarique-mode prompt to fix it, then compares the result with that naive fix. Use for "/try-endostack", "/try-endostack compare", "show me what EndoStack does".

Sixteen type-safety rules for writing and reviewing TypeScript, with do and don't examples in references/patterns.md. Use whenever you open or edit a .ts or .tsx file, or on /typescript-best-practices.

Rewrite prose so it stops reading as machine-generated, using EndoStack's numbered catalog of AI-writing tells. Use on /unslop, "de-AI this", "clean up this draft", "make this plain", and whenever another skill sends text here for a slop pass.

Explain why code exists in its current form by sending one investigator to each reachable evidence source and returning a cited, confidence-graded answer. Use for "why does this exist", "why was it built this way", "where did this limit come from", "is this dead code".