AI Agent Workflow Collection

Set up AI agent context for a game engine project. Scans engine-specific package manifests, plugins, modules, and project settings to discover the real tech stack. Bootstraps the resolved description and architecture artifacts and AGENTS.md, plus the user-editable .unikit/config.yaml. Use when starting a new game project, setting up AI context, initializing unikit, or asking "set up project", "configure AI context", "initialize unikit", "scan my project".

Generate architecture guidelines for a game project. Scans project structure to discover the real tech stack using engine-specific rules from references/ENGINERULES.md, then generates .unikit/ARCHITECTURE.md with folder structure, dependency rules, and communication patterns. Use when setting up project architecture, asking "which architecture", "describe architecture", "generate architecture doc", or after initial project setup. Also use when the user mentions project architecture, module structure, module boundaries, project organization, dependency rules, or engine-specific modularity concepts (assembly definitions, native modules, build scripts, plugin systems, etc.).

Create conventional commit messages for {{enginename}} projects by analyzing staged changes. Handles engine-specific concerns like companion file pairing, binary assets, and plan task references. ALWAYS use this skill when the user asks to commit, save changes, or create a commit — in any language. Trigger phrases include "commit", "create commit", "save changes", "сделай коммит", "закоммить", "коммит", "сохрани изменения". Even if the user simply says "commit this" or asks you to commit after finishing a task — invoke this skill, do NOT commit manually via git.

Senior {{enginename}}/{{enginecodelanguage}} developer assistant for the current {{enginename}} project. Use when writing, reviewing, or refactoring {{enginecodelanguage}} code, designing game architecture, optimizing performance, implementing game logic, or discussing patterns like DI, ECS, MVC, state machines, and event systems. Activate when the user works with game engine scripts or mentions {{enginename}}-related concepts.

Generate and maintain project documentation for game engine projects. Creates a lean README as a landing page with detailed docs/ directory split by topic. Auto-detects engine tech stack (DI frameworks, async libraries, event systems, UI frameworks), folder structure, and module boundaries to generate only relevant documentation pages. Reads language setting from .unikit/config.yaml — all generated documentation and user-facing messages are written in the configured language (default: English). Supports docs-config.json for path and document customization. Use when user says "create docs", "write documentation", "update docs", "generate readme", "document project", or wants to document their project structure, modules, or game systems — even if they don't explicitly say "docs".

Discover rules from accumulated patches and add them to project rules or skill-context. Analyzes past mistakes, extracts prevention points, classifies them as coding rules (→ RULES.md) or workflow rules (→ skill-context), and proposes them to the user. Use when user says "evolve", "evolve rules", "learn from mistakes", "update rules", "analyze patches", or wants to feed accumulated patch experience into coding rules. Also trigger after a series of /unikit-fix runs when patches have accumulated in .unikit/patches/. To migrate mature RULES.md entries to core/stack rule files, use /unikit-memory --migrate-rules instead.

Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements in {{enginename}} projects.

Fix a specific bug or problem in a {{enginename}} project. Supports two modes — immediate fix or plan-first. Without arguments executes existing .unikit/FIXPLAN.md. Checks {{enginename}} compilation, suggests test coverage, and creates self-improvement patches. Use when user says "fix bug", "debug this", "something is broken", or pastes an error message or {{enginename}} console log. Also trigger when user shares a NullReferenceException, MissingReferenceException, compilation error, or any {{enginename}}-specific error.

Dispatch an explicit, user-dictated set of edits that spans TWO OR MORE zones of the GDD — the master spec, systems, content types, and flows — in one ordered pass. Writes nothing itself: it resolves each delta to its (target, zone), orders them so a system change lands before the content or flow that depends on it, delegates each to the owning skill (/unikit-gd-spec, /unikit-gd-system, /unikit-gd-content, /unikit-gd-flow), and closes with one /unikit-gd-verify pass. Use when you already know the changes and they touch more than one part of the design, e.g. "apply these GDD changes", "update the combat system and its loot and the boss flow". It also takes a /unikit-gd-review report file (applies its apply-ready bucket), and a bare /unikit-gd-apply reads the last /unikit-gd-verify output in the session. For a single-zone change call its owner directly; to research an open question use /unikit-gd-explore first.

Ideate a brand-new game concept with the user, from a blank page or a one-line hint to a finished CONCEPT card. Use it whenever the user wants to come up with a new game — whether the project has no design document yet, or already has one and they're exploring a fresh idea. Through a structured divergence/convergence dialogue it explores ideas, frames the hook, generates and scores concepts (market validation delegated to /unikit-gd-explore), and settles pillars, loops, motivation, and a pre-mortem. Trigger whenever the user wants to make or invent a game, doesn't know where to start, or gives a genre/theme hint, e.g. "let's come up with a game", "I don't know what game to make", "I want to make a roguelike", "a game about zombies", "a farming game", "help me come up with a concept". For researching or dissecting existing games use /unikit-gd-explore; to write an already-chosen concept as the master GDD use /unikit-gd-spec.

Author and own ONE content type's typed schema (the CONTENT-TYPE.md) at .unikit/gamedesign/content-types/CT- .md — the content / catalog layer of the GDD (cards, items, weapons, enemies, levels, quests, loot). Use whenever the user wants to ADD a new kind of content or UPDATE its schema, e.g. "add a new content type", "design the loot content", "define the card schema", "add an enemies content type", "add a rarity field to items", "switch this catalog to curated". Create the skeleton, fill its typed field schema (CT.fields), scale, relationships, and validation, AND revise the schema under the delta discipline (a schema change bumps the version + changelog). Selects the scale (bulk | curated) and self-registers contenttypes/content. This owns the content SCHEMA, not the catalog of values — adding individual entries/units is data handled in the editor, not a schema edit. To add or detail a system use /unikit-gd-system; to add a flow use /unikit-gd-flow; to apply a multi-zone edit use /unikit-gd-apply.

Render the GAME-DESIGN document (the GDD) into a human-readable form — read-only Markdown chapters under docs/design/ (index, systems, flows, content, economy, glossary), with facts resolved inline from GD-IDS.yaml and drafts flagged 🚧. Optional --web also renders an HTML site from the unikit-docs template (falls back to Markdown-only if the template is absent). Use to export or publish the design for people to read, e.g. "render the GDD", "export the game design to docs", "generate readable design docs", "publish the GDD", "make a design doc site". Read-only — it never edits the GDD or registry, only renders it. This renders the game DESIGN — for the project's CODE documentation (README, docs/, modules, architecture) use /unikit-docs.

Research and ideation partner for GAME DESIGN — think through design ideas before writing them into the GDD; produces a brief, never edits the GDD itself. Use to assess a genre or market for viability, dissect a reference game (mechanics → dynamics → aesthetics), explore how to improve or extend an existing system, flow, or content type, research new mechanics the design lacks, investigate a part of the GDD in code, or develop the research bucket of a /unikit-gd-review report into decided edits. Trigger on "explore how to improve the flow", "ways to improve the combat system", "is this genre saturated", "break down the combat of Hades", "work out the review's open questions". GAME-DESIGN research only — for CODE or technical research use /unikit-explore; to reconstruct a design from code use /unikit-gd-recon; to write a change into the GDD use /unikit-gd-system or /unikit-gd-spec; to apply edits you know use /unikit-gd-apply; to invent a new game use /unikit-gd-brainstorm.

Author and own one flow's design document (the FLOW.md objective flow) at .unikit/gamedesign/flows/FLOW- .md — the dynamics layer of the GDD (what the player does over time). Create the skeleton and walk the collaborative section-cycle to write its objectives, pacing, dependencies, and funnel events ("design the first-session flow", "map the onboarding sequence", "write the FLOW for the boss encounter"), AND revise it after approval under the delta discipline ("retune the pacing", "add a branch", "change a GOAL", "rework the onboarding") — a cue/number change is Tuning, a small step change a Tweak, restructuring a Rework; each bumps the version and logs the delta. Selects the wiring mode (linear | conditional | emergent) and re-renders the Flow Map [gen] / Funnel [gen] blocks in GAME.md. To add or detail a system use /unikit-gd-system; to edit GAME.md content use /unikit-gd-spec; to apply a multi-zone edit use /unikit-gd-apply; for a new game concept use /unikit-gd-brainstorm.

Cold-start brownfield reconnaissance — reconstruct the WHOLE game design from an existing codebase when there is no GDD yet. Optionally accepts a free-text game description, notes, or reference links to guide and enrich the scan. Use when the user wants to build the game design from the code, e.g. "create a GDD from this codebase", "reconstruct the design from our code — it's a roguelike deck-builder", "build a design doc from the existing project, here are some refs". Scans the project (engine auto-detected), extracts a system roster + dependency graph and content-type schemas / resources / entities into one passive .unikit/gamedesign/RECON.md, tags every fact provenance:extracted-from-code, and writes a mandatory Intent Gap for what code cannot know (pillars, fantasy, the "why"). Writes nothing else and calls no skill. STRICTLY whole-project cold-start — if a GDD already exists and the user wants a specific part investigated, use /unikit-gd-explore (code lens); to author the GDD use /unikit-gd-spec.

Qualitative quality review of game design documents — answers "is this design good, and does it follow best practices?" — across all three GDD axes: systems, flows, and content types. Fans out adversarial lenses (completeness, clarity, pillar alignment, systems-math, fantasy-delivery, feasibility, scope) plus domain lenses that check it against the game-design rules, each prompted to find problems rather than validate; produces a severity-graded verdict and a two-bucket report (apply-ready fixes vs research), handed to /unikit-gd-apply or /unikit-gd-explore in one move. Scope is inferred: a named system, flow, or content type reviews that document; "all" runs a cross-document review. Use when the user wants a critique, quality judgment, or rules check of the design, e.g. "review the combat GDD", "review the onboarding flow". This is the subjective quality pass — for a mechanical consistency check (numbers, terms, IDs, references matching the registry) use /unikit-gd-verify.

Create and own the master game design document (GAME.md — the authored one-pager plus the generated [gen] system/flow maps) and the GD-IDS.yaml facts registry — the top-level, big-picture layer of the GDD and the machine interface the code side reads. Use it to write the master spec from a concept or dialogue, import an existing GDD (a file path or URL), edit GAME.md content ("change a pillar", "rework the monetization stance", "tweak the loop stack"), pitch the game ("pitch" → PITCH.md), re-decompose the systems ("remap"), and — importantly — to add a new system to the design map ("let's add a new system", "add a crafting system to the game design", "add this to the GDD"). This is the structural, map-level layer plus GAME.md content edits. To write or fill in the detailed parameters of one existing system, use /unikit-gd-system; to apply one edit spanning several zones at once use /unikit-gd-apply; to invent a brand-new game concept use /unikit-gd-brainstorm.

Author and own ONE system's design document (the A–K SYSTEM GDD) at .unikit/gamedesign/systems/SYS- .md — the depth layer of the GDD, single-system scope. Create the skeleton and walk the collaborative section-cycle to write its parameters, rules, formulas, and acceptance criteria ("detail the combat system", "write the GDD for the inventory system", "fill in the rest of this system doc", "spec out the parameters of X"), AND revise it after approval under the delta discipline ("raise the damage by 10%", "tune the economy", "rework the status system", "nerf X", "change this rule") — a number change is Tuning, a small rule a Tweak, restructuring a Rework; each bumps the version and logs the delta. To add a NEW system or restructure the system map use /unikit-gd-spec; to edit GAME.md content use /unikit-gd-spec; the moment an edit also touches a second system, a content type, a flow, or GAME.md (two or more zones) use /unikit-gd-apply; to invent a brand-new game concept use /unikit-gd-brainstorm.

Mechanical consistency check for game design — answers "is the design consistent with itself?" — plus changed-scope impact analysis across all three GDD axes: systems, flows, and content types. Offline and deterministic: greps the facts registry against the documents (numbers, terms, IDs, duplicate & dangling references, roster↔disk, map freshness, Depends 3-way, status/version, AC presence, placeholder leaks, flow & content schema), and from a git diff computes which dependent systems, flows, and content a change affects. Scope is inferred: a named document checks that document; an unverified diff triggers a changed-scope pass; otherwise everything. Use when the user wants a consistency or impact check, e.g. "verify the design", "what did this change affect", "find broken references in the design". Conflicts triage into four tracks; the entailed fixes hand off to /unikit-gd-apply in one pass. This is the mechanical pass — for a subjective "is this design good" quality critique use /unikit-gd-review.

Navigator and help guide for the UniKit framework — use when the user is unsure what to do next, where to start, or which unikit skill fits their situation. It diagnoses intent and points to the right skill or pipeline: starting a project, writing code, testing, planning, the spec-driven code workflow, authoring or detailing game design, finding a new mechanic, or deciding what game to build. Trigger on questions like "what do I do next", "where do I start", "how do I start coding", "how do I test my code", "how do I create the game design", "how do I detail a system", "how do I find a new mechanic", "which unikit skill should I use", "how does the code pipeline relate to game design", "I'm lost in unikit", "help me with unikit". Read-only — it explains and points to the right command, it never edits project files. For technical code research use /unikit-explore; for game-design research use /unikit-gd-explore; to initialize the framework use /unikit.

Execute implementation tasks from a feature plan in .unikit/plans/. Reads TASKS.md and PLAN-BRIEF.md, then implements uncompleted tasks sequentially executing tasks inline (Read/Edit/Write/Bash) with rules loaded once at start. Supports selective execution by phase or task numbers. Use when the user says "implement", "start coding", "execute plan", "continue implementation", "do the next task", "implement phase 3", or wants to work through a planned feature. Also use when the user references tasks from .unikit/plans/ or asks to "continue where we left off".

Refine and enhance an existing feature plan for the current {{enginename}} project. Re-analyzes TASKS.md and PLAN-BRIEF.md, checks for gaps, missing tasks, wrong dependencies, architectural issues, and improves plan quality. Also detects updated or new researches from /unikit-explore and incorporates their findings into the plan. Use this skill whenever the user wants to review, polish, or improve a feature plan from .unikit/plans/, even if they say "check the plan", "review the feature", "improve the roadmap", "what's wrong with the plan", or "update plan from research".

Add or update rules in .unikit/memory/: core rules (code style, design principles, testing, performance) and stack rules (framework-specific patterns — Zenject, DOTween, Addressables, R3, UniTask, etc.). Accepts descriptions, URLs, or file paths; enriches docs via Context7 MCP when available. Use when user says "add rule", "add core rule", "add stack rule", "document how we use X", "add rules for DOTween", "add coding convention", pastes framework docs URLs, or wants to codify coding standards, best practices, or tech-specific conventions. Use "--migrate-rules" (or pass RULES.md / .unikit/RULES.md as input) to migrate mature rules from RULES.md into permanent core/stack files; also trigger on "migrate rules", "transfer rules to memory". Use "validate" to sync RULESINDEX.md with actual files in memory/ — adds missing entries, removes phantom ones. Do NOT use for architecture decisions — those belong in ARCHITECTURE.md.

Create a detailed feature plan for a {{enginename}} project. Generates TASKS.md (dependency-ordered checklist with WHY context, effort estimates and file paths) and PLAN-BRIEF.md (technical context: constraints, interfaces, patterns — always created, based on current codebase state). Three modes: fast (no branch), full (optionally creates git branch), and add (modify existing plan). Use when starting a new feature, planning implementation, or when user says "plan feature", "create roadmap", "new feature plan". Also use when user says "add tasks to plan", "extend the plan", "add phase to plan".