afaraha8403/balakit-engineering

Author Skills (SKILL.md) and rules/instructions across Claude Code, Cursor, OpenCode, Codex, and GitHub Copilot. Covers frontmatter, file layout, activation, mirroring, and craft: progressive disclosure, Apply-when descriptions, leading words, playbook steps copied into todos, skip reasons, the deletion test, and user-facing questions in plain English. Apply when the user asks to write, scaffold, refactor, port, or review a Skill, Cursor rule (.mdc), AGENTS.md, copilot-instructions, or prompt file — or to make one Skill/rule work across multiple agents. Use blinded-eval when a behavior-changing draft needs blinded proof. Use dissect to audit an existing system, not to author a skill.

Blinded evaluation of a Skill, rule, or prompt change. The parent designs the experiment, isolates candidates in throwaway directories, runs the same organic user prompt, and scores artifacts against a held-back rubric. Apply when the user invokes /blinded-eval, asks to eval or A/B a skill change, or authoring Phase 4 says the change would alter agent behavior. Use authoring-skills-and-rules to write the skill; use dissect to audit an existing system.

Stealth browser fallback using CloakBrowser (custom-compiled Chromium with C++ source-level fingerprint patches). Use when the built-in browser tool or Chrome DevTools fails due to bot detection, Cloudflare/Turnstile walls, reCAPTCHA, 403/429/"access denied"/"are you human" interstitials, or empty/ blocked responses. Also use when the user asks for "cloakbrowser", "stealth browser", or to bypass a block.

Runs a checkpoint-gated decision process for consequential, forward-looking design choices. Optional --circuit skips intermediate checkpoint waits and asks at the final recommendation; --autopilot takes recommended choices and proceeds to implement. Use only when the user explicitly invokes deep-deliberation to compare approaches, challenge assumptions, and reach an evidence-grounded recommendation. Use inception for a work-breakdown plan. Use dissect instead to audit an existing system or written plan.

Investigate why code is shaped this way. Git and PRs first, then every evidence category that actually exists (tickets, docs, chat, observability, errors, analytics). Every claim is labeled Direct / Supported / Inferred / Speculative / Unknown. Never treat code as its own intent. Apply when the user asks why a design exists, why a flag is off, or why a threshold is what it is. Use subsystem-walkthrough for runtime behavior. Use dissect to audit entities. Use proving-change-safety before merge.

Evidence-driven dissection of an existing service, written plan, or codebase area. Interrogates every entity (table, field, component, endpoint, module, boundary) against ground truth from multiple sources at once, red-teams each verdict devil's-advocate style, and arrives at the minimal-build optimization plan. Runs as a staged pipeline with human checkpoints and parallel read-only sub-agents so each investigation stays laser-focused. Optional --circuit skips intermediate checkpoint waits and asks at the final recommendation; --autopilot takes recommended choices and proceeds. Use when the user invokes /dissect, or asks to audit / optimize / challenge / "tear apart" an existing system, schema, or plan. If the session is in Cursor or Claude Plan Mode, update the existing plan in place — never rewrite it. Use inception to author a new plan.

Write clear, scannable documentation with a research-first, phase-separated workflow. Pick one Diátaxis mode, then apply STE and Global English. Apply when the user asks for documentation, READMEs, doc sites, API reference, migration guides, or technical markdown. Use marketing-psychology for marketing copy. Use authoring-skills-and-rules to write a Skill, not a README. Not commit-message lint — changelog.mdc owns changelog headings.

Asks workers on the current harness to research read-only, then this chat does the work. Default roster is the current model on every slot. Apply when the user invokes execute or /execute, or wants workers to research before this chat writes. Use opinion when nobody should write. Use inception to produce the plan first. Use kit-workflows for one-agent implementation. Use deep-deliberation for checkpointed decisions.

Generate a project-local verification skill that drives the real app the way a user does — web, CLI, API, or desktop. Apply when the user invokes /generating-app-verify, asks for a control or verify skill, or the project has no scripted way to prove behavior. Use refreshing-app-verify to keep the feature map honest. Use testing.mdc for when to write tests.

Produces a durable, file-level implementation plan by loosely composing Balakit specialists. Stops before code except --autopilot, which then runs execute. Default interactive; --circuit skips mid-plan waits and silent-stops at the plan. Apply when the user invokes inception or /inception, or wants a long-running detailed plan. If host Plan Mode is on, write into that native plan. If not, write .balakit/plans/<slug>.md. Use dissect to audit an existing plan. Use deep-deliberation to pick among approaches. Use execute to implement.

Portable playbooks for a bug fix, a named-data-shape feature, or a behavior-preserving refactor. Apply when the user asks to reproduce and fix a defect, ship a small feature, or reshape code without changing behavior. Use unmatched-workflow when no playbook fits. Use deep-deliberation for a consequential design fork. Use dissect for an existing-system audit.

Asks workers on the current harness the same question and returns labeled takes. Default roster is the current model on every slot. Nobody writes project files. Optional --agents N (default 3, min 2, max 5). Apply when the user invokes opinion or /opinion, wants other takes, or says auto-pick. Use execute when this chat should do the work after the takes. Use deep-deliberation for checkpointed decisions. Use blinded-eval to A/B a skill change.

Find what a change could break beyond the diff, then prove the one fact it is safe because of by running real code. Apply when the user asks what a change could break, whether a small diff is safe to merge, or to prove a safety fact before shipping. Use subsystem-walkthrough for how it works. Use design-rationale for motivation. Use dissect for a system-wide entity audit.

Keep a generated verification skill and feature map honest: source wave per feature, one live pass driving every feature, at most one PR of proven corrections. Apply when the user invokes /refreshing-app-verify or asks to audit the verify skill. Use generating-app-verify if none exists. Never edit product code on this pass.

Release and deploy via GitHub tags and GitHub Actions (not every commit). Creates production releases from main and beta releases from staging using the GitHub CLI. Use when the user asks to release, ship, deploy, cut a version, tag a release, publish beta/production, create a GitHub Release, or bump a semver tag. On first use in a project, run the setup interview and write a project-specific config under projects/.

Walk through how a subsystem works: architecture, runtime flow, ownership, layering. Apply when the user asks "how does X work", "where should this live", or wants an onboarding mental model before changing code. Use design-rationale for motivation. Use dissect to audit entities. Use proving-change-safety before merging a change you do not trust.

Design a rigorous, auditable playbook when no narrower skill fits: a large migration, multi-part change, or work a human will review after stepping away. Apply when no playbook matches, the work is a migration, or they will be gone while the work runs. Use inception when the deliverable is the plan. Use deep-deliberation to choose among options without implementing. Use kit-workflows for a known bug-fix, feature, or refactor. Use blinded-eval to prove a skill change.