agentsclimarketplace

Unikit evolve

Skill NintendaDev/unikit-ai/skills/unikit-evolve

AI-Powered Code Toolkit for Game Engines

Install
npx -y skills add NintendaDev/unikit-ai --skill unikit-evolve

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 16 stars16 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

11.5 KB, as published. Nobody here has run it

Evolve — Rules Discovery from Patches

Analyze accumulated patches (past mistakes) and propose new rules: coding rules → .unikit/RULES.md, workflow rules → .unikit/skill-context/<skill>/SKILL.md.

Core Idea

patches (past mistakes)
    |
extract prevention points (concrete, actionable rules)
    |
classify: coding rule vs workflow rule
    |
cross-check against existing rules (RULES.md + knowledge base + skill-context)
    |
present uncovered candidates to user
    |
user picks → coding rules to RULES.md, workflow rules to skill-context

Two rule destinations:

  • RULES.md — coding conventions: HOW to write code (patterns, naming, null-checks, async, serialization). These reach unikit-devcontext via RULES.md → /unikit-memory → memory/.
  • skill-context — workflow overrides: HOW a skill should behave (delegation strategy, commit frequency, compilation checks, parallelism). These go to .unikit/skill-context/<skill>/SKILL.md and are read by the target skill directly.

Rule migration from RULES.md to core/stack rule files is handled by /unikit-memory migrate-rules.

Language Awareness — BLOCKING PRE-REQUISITE

BEFORE producing ANY output, silently read .unikit/system/LANGUAGE_RULES.md and apply its rules to ALL subsequent output. If the file is missing or unreadable, fall back to English. Do not produce any user-facing output until language rules are loaded. Do not announce, confirm, or mention the language setting.

Workflow

Step 1: Read Patches (Incremental)

Glob: .unikit/code/patches/*.md

If no patches found → report "No patches to analyze" and STOP.

Cursor file: .unikit/evolutions/patch-cursor.json

{
  "last_processed_patch": "YYYY-MM-DD-HH.mm.md",
  "updated_at": "YYYY-MM-DD HH:mm"
}

Processing rules:

  1. Glob patch files and sort by filename ascending (timestamp format is lexical-friendly).
  2. If no cursor file exists → first run: read all patches.
  3. If cursor file exists and referenced patch is present → read only patches with filename > last_processed_patch.
  4. If cursor file exists but referenced patch is missing (deleted/renamed) → emit WARN [evolve] and do a full rescan.
  5. Do not advance cursor in this step. Cursor is updated only after successful apply in Step 7.

Overlap window (anti-miss guard):

LLMs may miss prevention points on a single pass. To reduce the risk:

  1. When running in incremental mode, ALSO read the newest min(5, total) patches (tail-5), then de-duplicate.
  2. Track separately:
    • "New patches" = patches with filename > last_processed_patch
    • "Overlap patches" = tail-5 patches
    • "Processed patches" = union(New, Overlap)
  3. Cursor updates in Step 7 are based on "New patches" only — never advance cursor when only overlap patches were processed.

Read every patch in the processed set. For each one, extract:

  • Problem categories (null-check, async, serialization, DI, lifecycle, etc.)
  • Root cause patterns
  • Prevention points — each independent actionable rule from the Prevention/Solution section. A single patch often contains multiple independent prevention points. Extract EACH one separately. Do NOT treat a patch as a single unit.
  • Tags

Step 2: Load Context

Read the following files:

  1. .unikit/DESCRIPTION.md — tech stack, project constraints
  2. .unikit/RULES.md — current project rules. If doesn't exist, will be created in Step 6
  3. .unikit/memory/code/RULES_INDEX.md — index of knowledge base rule files. If doesn't exist or empty, skip knowledge base cross-check in Step 4 (check only RULES.md)

Step 3: Build Prevention Point Registry

Build a flat list of ALL extracted prevention points:

| # | Patch | Prevention Point (specific action) | Type |
|---|-------|-------------------------------------|------|
| 1 | <patch-file> | <concrete rule to enforce> | code |
| 2 | <patch-file> | <different rule from same patch> | workflow:<skill> |
| 3 | <other-patch> | <rule> | code |

CRITICAL: A patch with 5 prevention points produces 5 rows, not 1.

Type classification:

Each prevention point must be classified:

  • code — about HOW to write code: patterns, null-checks, async handling, serialization, naming, DI registration, lifecycle management. Destination: RULES.md.
  • workflow:<skill-name> — about HOW a skill should behave: delegation strategy, when to compile, commit frequency, parallelism decisions, what to check before/after a step. Destination: .unikit/skill-context/<skill>/SKILL.md.

Classification heuristic:

  • If the prevention point says "code MUST do X", "always use pattern Y", "never call Z" — it's code
  • If the prevention point says "skill should check X before Y", "run compilation after each file", "delegate to agent instead of inline" — it's workflow:<skill>
  • When in doubt, default to code — it reaches devcontext through RULES.md → memory/ and applies broadly

Step 4: Filter — Remove Already Covered

For each prevention point, cross-check against the appropriate destination:

For code type:

  1. .unikit/RULES.md — is this rule already codified? If RULES.md doesn't exist, no rules are covered — all prevention points are candidates.
  2. Knowledge base via RULES_INDEX.md — identify relevant rule files by topic, read them, check if covered. If RULES_INDEX.md doesn't exist or is empty — skip this check, use only RULES.md.

For workflow:<skill> type:

  1. .unikit/skill-context/<skill>/SKILL.md — is this workflow override already recorded?
  2. Base skill {{skills_dir}}/<skill>/SKILL.md — does the base skill already include this behavior?

A prevention point is "covered" ONLY when there is a rule that addresses the specific action described — not merely the same topic area.

Mark uncovered prevention points as candidates.

Verification: Count total, covered, uncovered. If uncovered = 0, report "all prevention points already covered" and skip to Step 7 (log only, no rules added).

Step 5: Present Candidates to User

Group candidates by type and format each uncovered prevention point:

## Rule Candidates

Based on N patches analyzed, M uncovered prevention points found:

### Coding Rules (→ RULES.md)

#### 1. [Rule Name]
- **Source:** patch-YYYY-MM-DD-HH.mm.md
- **Category:** #tag
- **Proposed rule:** "[specific, actionable instruction]"
- **Target section:** [suggested RULES.md section name]

### Workflow Rules (→ skill-context)

#### 2. [Rule Name]
- **Source:** patch-YYYY-MM-DD-HH.mm.md
- **Target skill:** [skill name]
- **Proposed rule:** "[specific, actionable instruction]"

AskUserQuestion: Apply proposed rules?

Options:

  1. ✅ Apply all
  2. 🔍 Let me pick — present in batches of up to 4
  3. 🚫 Skip all

Based on choice:

  • Apply all → run /unikit-rules for each code rule, add workflow rules to skill-context
  • Let me pick → present batches of up to 4, Apply/Skip per rule
  • Skip all → skip rule creation, proceed to cursor update

Do NOT add any rules until the user answers.

Step 6: Add Accepted Rules

For code type — run /unikit-rules <rule text> for each accepted rule.

The skill handles everything: cross-check against knowledge base, dedup against existing RULES.md entries, section placement, and confirmation. If a rule is already covered, it will report it — note and move on.

For workflow:<skill> type — add directly to skill-context:

  1. Read .unikit/skill-context/<skill>/SKILL.md if it exists
  2. If file doesn't exist — create it with the standard header:
# Project Rules for /<skill-name>

> Managed by `/unikit-evolve` and `/unikit-skills-context`. Do not edit manually.
> Last updated: YYYY-MM-DD HH:mm

## Rules

### [Rule Name]
**Source**: patch-YYYY-MM-DD-HH.mm.md
**Rule**: [Specific, actionable instruction in English]
  1. If file exists — append new ### [Rule Name] entry under ## Rules, update > Last updated: line
  2. Cross-check against base {{skills_dir}}/<skill>/SKILL.md — if base already covers the rule, skip and report

Step 7: Save Evolution Log & Update Cursor

7.1: Create evolution log

mkdir -p .unikit/evolutions

Create .unikit/evolutions/YYYY-MM-DD-HH.mm.md:

# Evolution: YYYY-MM-DD HH:mm

## Intelligence Summary
- Patches analyzed: X (new: N, overlap: M)
- Prevention points extracted: X
- Already covered: X
- Rules added: X

## Rules Added

- [rule text] <- Source: [patch filename]
  **Section:** [RULES.md section name]

## Patterns Identified
- [pattern]: [frequency] occurrences

7.2: Update cursor

  1. If no new patches were processed → keep cursor unchanged.
  2. If new patches were processed:
    • If rules were added → advance cursor to newest "New patch" filename.
    • If no rules were added (user skipped all) → advance cursor. Patches have been analyzed; re-reading them wastes context.
  3. If execution fails before changes finalized → do not advance cursor.

Context Cleanup

After completing evolution, suggest /clear or /compact — context is heavy after patch analysis and skill processing.


Rules

  1. Traceable — every proposed rule must link to a specific patch
  2. Minimal — add rules to RULES.md, don't rewrite the knowledge base
  3. Reversible — user approves before any changes are applied
  4. Cumulative — each evolution builds on previous ones
  5. No hallucination — only propose rules backed by evidence from patches
  6. English only — all rules in RULES.md are in English
  7. No generic advice — "write clean code" is not a rule; only specific, actionable instructions
  8. One prevention point = one rule — don't merge multiple independent rules into a single vague summary
  9. Preserve concrete formats — if a patch specifies exact format/syntax/template, the rule must include it verbatim
  10. Ownership boundary — this command owns .unikit/evolutions/*.md and .unikit/evolutions/patch-cursor.json; may append coding rules to .unikit/RULES.md (via /unikit-rules); may write workflow rules to .unikit/skill-context/<skill>/SKILL.md; treats everything else as read-only. Rule migration from RULES.md to memory/ is handled by /unikit-memory migrate-rules

Example

/unikit-evolve

> Analyzed 5 patches (3 new, 2 overlap)
> Extracted 8 prevention points, 6 already covered, ⚠️ 2 uncovered
>
> Rule candidates:
> 1. "Constructor null checks MUST be symmetric..." <- patch-2026-03-10-12.00.md
> 2. "Event subscriptions before fallible operations..." <- patch-2026-03-10-12.00.md
>
> Apply all / Let me pick / Skip all?

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.