haze-dev1/eigi-stack
understand before changing, follow the Eigi standards, delete more than you add, prove it securely, verify it against the running stack, write it plainly.
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.
Shared Eigi frontend engineering standards for creating, modifying, reviewing, or testing frontend web apps in any Eigi repo. Use for React, Next.js, Vite, Vue, Svelte, or similar client apps that need consistent folder structure, component boundaries, API clients, styling, state, environment handling, gitignore hygiene, and frontend tests.
Critical review of a project or a change — a pre-merge diff review by default, a whole-project audit on request. Works on any stack, because it first derives the project's own contract (standards, spec, commands, conventions) and then applies fifteen invariants to it. Every finding cites file:line and carries a severity. Eigi repos load the bundled profile, including its overrides, automatically.
Keeps Eigi planning and implementation scoped to what is actually required, with every addition beyond the source requirement tagged and listed for approval. Use whenever writing or reviewing a PRD, TRD, ADR, data model, schema, implementation plan, migration plan, ticket breakdown, or the code that follows from them. Use it even when the user only says "write the data models", "plan this out", "break this into tasks", or "build this feature" without mentioning scope — this skill decides what goes in and what gets flagged instead of built. Apply alongside eigi-backend-standards and eigi-frontend-standards, which govern how the in-scope work is structured.
Works through a security review's fix list one finding at a time, applying each fix in isolation, fixing sibling instances of the same pattern, running the finding's verify-after check, then re-verifying the diff against four criteria and stopping if the fix is only partial. Use after eigi-security-review has produced a ranked fix list. It does not hunt for new issues; re-run the review for that.
Reviews recent changes, or a whole app, for the security problems AI-built web apps actually have: broken access control, tenant isolation, checks that live only in the UI, input that reaches a real sink, leaked secrets. It threat-models the change, walks an OWASP/CWE checklist over every changed file, runs whichever scanners are installed, and ends with a severity-ranked fix list plus one unhedged verdict, BLOCK or PROCEED WITH NOTES. Use after a feature lands, after a batch of AI-generated changes, before launch, or when asked "is this safe", "security review", "audit this", "can this be exploited". Reviews the diff by default; whole-system in pre-launch mode.
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'.
A relentless interview to sharpen a plan or design.
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
Use for "how does X work", code walkthroughs before changing something, placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer"), and teaching requests ("teach me this", "help me really understand X", "explain this change or subsystem to me"). Explains subsystem architecture, runtime flow, and onboarding mental models; in teaching mode it turns that into one plain account a person actually understands.
Restate in your own words what you think the user's goals are and what problem they're trying to solve. Use for /in-your-own-words.
Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests (general knowledge, prose, translation, summaries, recipes).
Code review focused exclusively on over-engineering. Finds what to delete: reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. One line per finding: location, what to cut, what replaces it. Use when the user says "review for over-engineering", "what can we delete", "is this over-engineered", "simplify review", or invokes /ponytail-review. Complements correctness-focused review, this one only hunts complexity.
Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for /technical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.
Cut AI tells from any writing.
Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.