De-Koi

Apply De-Koi's repo-local version of the Chai agent workflow pack for proof discipline, investigations, feature sizing, refactor handoffs, reviews, PR readiness, reviewer feedback iteration, issue drafting, UI/UX proof, security-sensitive checks, risky-work evidence, debt notes, and final status reports. Use for nontrivial coding work, ambiguous symptoms, refactors, reviews, PR/issue workflows, or any task where an agent must prove claims while preserving De-Koi's code separation and module ownership rules.

Protect De-Koi's layered Tauri and hostable Rust runtime architecture, module ownership, dependency direction, explicit imports, Rust capability boundaries, shared-code placement, HTTP pipeline, and file-splitting discipline. Use when changing folders, imports, shared modules, TypeScript engine layers, Tauri/HTTP command wrappers, Rust capability crates, repositories, adapters, feature APIs, or any code structure that could widen impact area.

Guide De-Koi bug fixes through feedback-loop-first diagnosis and root-cause repair with clear impact areas, focused validation, and no band-aid patches. Use for regressions, broken UI actions, failing checks, provider/transport bugs, storage bugs, import/export bugs, generation bugs, mode behavior bugs, performance regressions, or any change where the fix could affect dependent modules.

Stress-test De-Koi plans against the current repo, product docs, architecture rules, and durable guidance, then capture only reusable decisions. Use when the user wants to be grilled on a design, sharpen fuzzy requirements, validate terminology, or update docs while a plan is clarified.

Find De-Koi architecture deepening opportunities that improve locality, leverage, testability, and agent navigation without violating repo boundaries. Use when the user asks to improve architecture, reduce shallow modules, plan refactors, make code more testable, or inspect module/interface design.

Build throwaway De-Koi prototypes to answer logic, state-model, API-shape, or UI-layout questions before production implementation. Use when the user asks to prototype, mock up, sanity-check a state model, try UI variants, or let them play with a design.

Guide De-Koi changes through behavior-first red-green-refactor cycles using public interfaces and repo proof rules. Use when the user asks for TDD, red-green-refactor, test-first development, regression tests, integration tests, or a risky behavior change that needs a committed proof guard.

Break De-Koi plans, PRDs, parity targets, or feature ideas into independently verifiable GitHub issues using vertical slices. Use when the user asks to create implementation tickets, split a plan into issues, prepare ready-for-implementation work, or turn a broad feature into issue-sized slices.

Turn De-Koi conversation context, feature ideas, or investigation results into a PRD-style GitHub issue draft with implementation and testing decisions. Use when the user asks for a PRD, product requirements, feature spec, or issue-ready requirements from current context.

Onboard developers and coding agents into De-Koi. Use when someone asks how to get started, asks for a repo tour, wants the docs run, needs to run/build the app, wants a first testing checklist, or wants a guided workflow for finding and fixing bugs in this repo.

Repo-local branch/PR review workflow with failure-path and nitpick lenses. Use when the user says Bunny, Bunny review, Bunny style review, PR-style review, second reviewer pass, or asks an agent to inspect a branch, PR, or diff for bugs, regressions, edge cases, proof gaps, existing tests, security, migration, performance, maintainability, realistic failure modes, or small review comments.

Enforce De-Koi's strict separation between chat/conversation, roleplay, and game mode. Use when changing mode engines, mode UI, autonomous chat, schedules, summaries, roleplay scenes, sprites, encounters, visual novel choices, game turns, game prompts, game state, generation guide routing, prompt assembly, or any shared code that could affect more than one mode.

Create distinctive, production-grade frontend UI direction for De-Koi. Use when the user asks to design or build a new UI surface, page, component, dashboard, app shell, modal, onboarding flow, editor, settings view, mode surface, visual treatment, or wants bland UI made more distinctive. In this repo, use frontend-design for initial concept, layout, and implementation direction; use impeccable afterward for critique, accessibility, responsive hardening, polish, and live iteration.

Use for frontend critique, audit, polish, hardening, UX copy, accessibility, responsiveness, performance, layout refinement, visual hierarchy, design-system extraction, live browser iteration, and final UI quality passes. In De-Koi, prefer frontend-design for first-pass concept/build work, then use impeccable to review and improve product fit, edge states, anti-patterns, theming, typography, spacing, motion, interaction quality, i18n, and AI-slop risk. Not for backend-only or non-UI tasks.