スキルを探す

Archive completed plans. Moves finished folder plans from .unikit/code/plans/<folder>/ to .unikit/code/archive/plans/<folder>/, so plan lookup and the plan lists stop offering them; an unfinished plan moves only when the user picks it, and is marked as unfinished. Lists every plan with its created and last-change dates; plans can be picked by number or by date. Never deletes, renames or commits. Use when user says "archive plans", "archive completed", "archive old plans", "clean up plans", or "show archived plans". Not for .unikit/code/PLAN.md or FIX_PLAN.md; to check that a plan is really done use /unikit-verify, to commit the move use /unikit-commit.

日本語の概要は準備中です。原文の説明を表示しています。

Senior {{engine_name}}/{{engine_code_language}} developer that performs direct, ad-hoc code tasks without a formal plan — and the code-execution engine other unikit skills and agents delegate to. Use it whenever the user asks to do something in code right now, e.g. "add this method to this class", "refactor this function", "write a script that does X", "change this code", "optimize this class". Phrases like "without a plan", "no plan", "just do it", or "directly" are strong signals to use this skill rather than planning. Covers writing, refactoring, optimizing, and discussing {{engine_code_language}} code and patterns (DI, ECS, MVC, state machines, event systems). For a larger multi-step feature, plan it with /unikit-plan and build it with /unikit-implement — this skill is for direct, unplanned code work.

日本語の概要は準備中です。原文の説明を表示しています。

Generate and maintain the project's TECHNICAL documentation from its codebase — scans the project structure, tech stack, and module boundaries, then writes a lean README landing page plus detailed topic pages (architecture, modules, setup, build, APIs), only the docs that are relevant. Use whenever the user wants to create, update, or validate documentation of the CODE or the project itself, e.g. "generate documentation", "create docs", "write the README", "update the project docs", "document the codebase", "document this project's architecture", "validate the project documentation". This is CODE / project documentation only — it never documents the game design. To render the GAME DESIGN (the GDD: systems, flows, content, economy) for people to read use /unikit-gd-docs.

日本語の概要は準備中です。原文の説明を表示しています。

Learn project rules from accumulated fix patches in .unikit/code/patches/. Analyzes past mistakes, extracts prevention points, classifies each as a coding rule (→ RULES.md) or a per-skill workflow rule (→ skill-context), and proposes them for approval. Use when the user wants to turn past fixes into rules — "evolve", "evolve the rules", "learn from past mistakes", "learn from the fixes", "analyze the patches", "what rules should we add from recent fixes". Best run after several /unikit-fix sessions have left patches behind. This derives rules from accumulated patch history — to add a single rule by hand use /unikit-rules, and to promote mature RULES.md entries into the knowledge base use /unikit-memory migrate-rules.

日本語の概要は準備中です。原文の説明を表示しています。

Fix a specific bug or problem in a {{engine_name}} project. Supports two modes — immediate fix or plan-first. Without arguments executes existing .unikit/code/FIX_PLAN.md. Checks {{engine_name}} compilation, suggests test coverage, and creates self-improvement patches. Use when user says "fix bug", "debug this", "something is broken", "fix the tests", "fix the errors in the tests", "read the errors in the {{engine_name}} console logs and fix the problems", or pastes an error message or {{engine_name}} console log. Also trigger when user shares a NullReferenceException, MissingReferenceException, compilation error, or any {{engine_name}}-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-<slug>.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 content_types/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-<slug>.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.

日本語の概要は準備中です。原文の説明を表示しています。

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.

日本語の概要は準備中です。原文の説明を表示しています。

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.

日本語の概要は準備中です。原文の説明を表示しています。

Execute the tasks from an already-created feature plan in .unikit/code/plans/ — read the plan manifest (the PLAN.md file in the plan folder), work through the uncompleted tasks in order, write the code, mark progress, and resume across sessions. Supports selective runs by phase or by task numbers, and continuing from where the last session stopped. Use whenever a plan exists and the user wants to build it, e.g. "implement", "implement the plan", "start coding", "execute the plan", "run the plan", "do the next task", "implement phase 3", "implement tasks 2.1 and 2.3", "continue implementation", "continue where we left off", "keep going on the feature". To create the plan first, use the planning skill — this one carries an existing plan out.

日本語の概要は準備中です。原文の説明を表示しています。

Refine an existing implementation plan with a second iteration. Re-analyzes the codebase for gaps, missing tasks, and wrong dependencies. Use after /unikit-plan or to improve a /unikit-fix plan, or when the user says "improve the plan", "what's wrong with the plan", or "update the plan from research". Optional +check flag validates refinements via a fresh-context subagent.

日本語の概要は準備中です。原文の説明を表示しています。

Curate .unikit/MCP-RECHECK-NOTES.md — the project's log of findings about the configured engine MCP server. Four jobs: re-stamp (the server moved, so every entry is suspect), replay (reproduce a `replay: safe` finding inside a disposable sandbox to see whether it still holds), retire (offer to drop what was fixed or went upstream), and upstream (print a ready diff for the packaged INDEX.md). Use for "audit the MCP notes", "are these findings still true", "recheck the MCP traps", "clean up MCP-RECHECK-NOTES", "the server was updated — revisit the notes". Replaying mutates a live editor, so it starts by telling you how to prepare it — save your scene, open an empty one — and asks once before touching anything. Everything it creates lives under a single UNIKIT_AUDIT_<runid> prefix, is deleted in one action, and the scene is never saved. To record a NEW finding use /unikit-mcp-trap instead.

日本語の概要は準備中です。原文の説明を表示しています。

Record a finding about the configured engine MCP server into .unikit/MCP-RECHECK-NOTES.md — the project's log of what has to be re-checked here. Use right after a call reported success while changing nothing, ate an argument, or validated a broken state, e.g. "write this down", "record this MCP finding", "the server lied — note it", "add a recheck note", "trap this". Takes three forms of input: the finding in one line, a path to a plan file (harvests the "## MCP Findings" table of that plan and nothing else), or nothing at all — then it takes findings already in the session first, and offers to scan the tables of plans touched since the last audit. The table only, never the plan body. Writes in the one allowed genre — a check to perform; never a lifted gate, never a named workaround, never a claim about what the server can or cannot do. Makes zero MCP calls and needs no editor. To replay, retire, or upstream existing notes use /unikit-mcp-audit instead.

日本語の概要は準備中です。原文の説明を表示しています。

Curate the project's knowledge base and memory in .unikit/memory/ — the indexed reference library of coding standards and framework usage patterns. ALWAYS use this skill whenever the user adds knowledge from a source: a URL, a file, a folder path, a PDF, an article, or a book — any path/link/document is a strong signal for the knowledge base, not a quick rule. Also use it to research or document how the project uses a framework, or to add a researched core/stack knowledge entry. Sub-commands by phrasing: "migrate the rules" or "promote rules" runs migrate-rules; "optimize the knowledge base" or "optimize the rules" runs optimise (extract large sections into references); "validate" re-syncs RULES_INDEX.md; "--module <id>" targets a module. For a quick one-line convention or correction typed as a prompt ("always do X", "never use Y", "remember this") with no source, use /unikit-rules; for architecture decisions use ARCHITECTURE.md.

日本語の概要は準備中です。原文の説明を表示しています。

Write, open and — when allowed — merge a pull request for the current feature branch of a {{engine_name}} project, with or without a plan. Builds a plain-language PR text (one feature per line) from the plan's `## Modules` and task `WHY:` lines, or — without a plan — from the commits and the code changes themselves; pushes the current state (asking where to end when it stands inside a plan module), opens or updates the branch's single open PR through the GitHub MCP, and merges with a merge commit only when the merge brings nothing from the base branch. Levels: remind (text only), create, merge; capped by `git.pull_requests.max_level`. Trigger phrases: "pull request", "open a PR", "create PR", "PR description", "merge the PR". For commit messages use /unikit-commit; for reviewing a PR's code use /unikit-review.

日本語の概要は準備中です。原文の説明を表示しています。

Perform a code review on {{engine_name}} {{engine_code_language}} code. Checks for bugs, security issues, performance problems, and best practices against the project's coding rules, design principles, and framework-specific conventions. Supports four modes — staged changes, a pull request, a commit range, or individual files. Use when the user says "review code", "check my code", "code review", "review PR", "review staged changes", "review these commits", or "is this code okay". Optional +check flag validates findings via a fresh-context subagent.

日本語の概要は準備中です。原文の説明を表示しています。

Create or update a strategic project roadmap with major milestones. Generates .unikit/ROADMAP.md — a high-level checklist of project goals. Use when user says "roadmap", "project plan", "milestones", "what to build next", "strategic goals", or wants to see big-picture progress. Also use when the user asks to check which milestones are done or wants to plan the overall project direction.

日本語の概要は準備中です。原文の説明を表示しています。

Orchestrate the remote rules registry — the shared registry (often connected as a local folder or git repo) that the project's rules are published to and pulled from. Three modes, picked from the user's wording: create scaffolds a new local rules registry ("create a local rules registry", "init a rules registry"); update migrates/promotes local knowledge-base rules from .unikit/memory/ into the remote registry with automatic semver bumps ("migrate local rules to the remote registry", "promote my rules to the registry", "push local rules", "publish local rules", "update the rules registry"); sync pulls registry updates back into memory ("sync the rules registry", "pull registry updates"). Pass "--module <id>" to scope to one knowledge-base module. This skill ONLY orchestrates the CLI (`unikit-ai rules *`) — it never edits .unikit.json or .unikit/memory/ sources directly.

日本語の概要は準備中です。原文の説明を表示しています。

Add a short, project-specific rule, convention, or override to .unikit/RULES.md — the quick-capture inbox for this project's rules (common rules always load; topic files in .unikit/rules/ load when the work matches), automatically loaded by /unikit-implement (later promotable via /unikit-memory migrate-rules). Works only with a rule typed as a prompt — it does NOT read files, folders, URLs, or PDFs. Cross-checks against the knowledge base (RULES_INDEX.md) to avoid duplicating core/stack entries. Use for fast, one-line conventions and corrections: "add a rule", "remember this", "convention", "always do X", "never use Y", "from now on do Z", or when the user corrects agent behavior and wants it remembered; also "split the rules into topics" (optimise), "clean up the rules" (prune), "shorten RULES.md" (compact). If the user points to a source (file, folder, URL, PDF, article, book) or wants to research/document framework usage, use /unikit-memory; for architecture decisions use ARCHITECTURE.md.

日本語の概要は準備中です。原文の説明を表示しています。