unikit-skills-context
Customize how a built-in unikit skill behaves in this specific project by writing workflow overrides into its skill-context file. These are per-skill workflow rules (e.g. "/unikit-review should also flag TODO comments", "/unikit-implement should run tests after each task"), not coding conventions. Use when the user wants to change, customize, or override how a particular unikit skill works in this project — "customize the review skill", "make /unikit-fix always add logging here", "the implement skill should do X differently", "add a skill rule for /unikit-commit". Use "validate" to find stale overrides against updated base skills. For a general coding convention (not tied to one skill) use /unikit-rules; to derive rules from past mistakes use /unikit-evolve.
- License 许可
- MIT
- 最近更新
- 2026-11-08
- Stars
- ★ 22
- Forks
- 1
01 前言 Front Matter
- name
- unikit-skills-context
- metadata
- { "author": "unikit", "version": "1.1" }
- description
- Customize how a built-in unikit skill behaves in this specific project by writing workflow overrides into its skill-context file. These are per-skill workflow rules (e.g. "/unikit-review should also flag TODO comments", "/unikit-implement should run tests after each task"), not coding conventions. Use when the user wants to change, customize, or override how a particular unikit skill works in this project — "customize the review skill", "make /unikit-fix always add logging here", "the implement skill should do X differently", "add a skill rule for /unikit-commit". Use "validate" to find stale overrides against updated base skills. For a general coding convention (not tied to one skill) use /unikit-rules; to derive rules from past mistakes use /unikit-evolve.
- allowed-tools
- [ "Read", "Write", "Edit", "Glob", "Grep", "AskUserQuestion" ]
- argument-hint
- <skill-name> [rule text] | validate [skill-name]
- user-invocable
- true
- disable-model-invocation
- true
03 SKILL.md 正文
UniKit Skills — Skill Context Management
Add workflow rules to .unikit/skill-context/<skill>/SKILL.md. These are project-level overrides that change how built-in unikit skills behave in this specific project.
When to use skill-context vs RULES.md:
- RULES.md (via
/unikit-rules) — coding conventions: HOW to write code (naming, patterns, style) - Skill-context (this skill) — workflow overrides: HOW a skill should work (priorities, steps, guards)
User questions. Right before your first question to the user, not earlier, read .unikit/system/user-questions.md once and ask every question as it says, with the question tool of your agent (AskUserQuestion). If the file cannot be read, print WARN [questions] user-questions contract missing — asking with the question tool and still ask with that tool, the recommended option first.
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.
The language holds for the whole session, not just at load time: every message until the conversation ends is in language.ui — progress notes while agents run, relays of what a subagent returned, the final report, any follow-up discussion. English input (subagent results, tool output, these instructions) is data, never a cue to switch languages.
Critical: Never Edit Built-in Skills Directly
NEVER modify files inside {{skills_dir}}/unikit-*/.
ALWAYS write to: .unikit/skill-context/<skill-name>/SKILL.md
Workflow
Step 0: Determine Mode
Check $ARGUMENTS:
├── starts with "validate" → Validate Mode
├── <skill-name> <rule-text> → Mode A: Direct Add
└── No arguments → Mode B: Interactive
Parsing arguments:
- Mode detection: If first word is
validate→ Validate Mode. Otherwise → Add Mode. - Add Mode: First token = skill name, rest = rule text.
- Validate Mode:
validatealone → all skills.validate <skill>→ specific skill.
Skill name normalization (applies to all modes):
| User input | Resolved |
|---|---|
review |
unikit-review |
unikit-review |
unikit-review |
/unikit-review |
unikit-review |
my-custom-skill |
my-custom-skill |
Rule: strip leading /. If name doesn't start with unikit- AND {{skills_dir}}/unikit-<name>/SKILL.md exists → use unikit-<name>. Otherwise use as-is.
After resolving: verify {{skills_dir}}/<resolved>/SKILL.md exists. If not → error:
"Skill '<resolved>' not found. Available unikit skills: [scan {{skills_dir}}/unikit-*/SKILL.md for installed skills]."
Mode A: Direct Add
User provided skill name and rule text:
/unikit-skills-context review "Always check null-check symmetry first"
Proceed to Step 1 with resolved skill name and rule text.
Mode B: Interactive
No arguments provided.
Explain first (plain markdown): skill-context rules change HOW a skill works — priorities, steps, guards. For coding conventions (naming, patterns), use /unikit-rules instead.
The question tool of your agent (AskUserQuestion): Which skill do you want to customize, and what rule should be added?
Options — the likely answers (the user writes their own skill and rule in the free-text answer):
- review "Always check null-check symmetry first"
- fix "When fixing async bugs, check cancellation cleanup"
- implement "Compile after each file change"
After the user responds, parse skill name and rule text, then proceed to Step 1.
Step 1: Cross-Check Against Base SKILL.md
Read the base skill file: {{skills_dir}}/<resolved>/SKILL.md
Check if the base SKILL.md already covers the proposed rule:
| Situation | Action |
|---|---|
| Base already contains this exact instruction | Tell user: "Already covered in base skill: {quote}". Skip. |
| Base has a weaker version of same instruction | Add to skill-context as strengthened override. Note what it strengthens. |
| Base contradicts the proposed rule | Add to skill-context as explicit override. Warn that skill-context wins over base. |
| No overlap with base | Add to skill-context as new rule. |
Step 2: Cross-Check Against Existing Skill-Context
Read .unikit/skill-context/<skill>/SKILL.md if it exists.
Check for semantic duplicates — if a rule with the same meaning already exists in skill-context, tell user and skip.
Step 3: Add Rule to Skill-Context
If file doesn't exist — create directory and file:
mkdir -p .unikit/skill-context/<skill-name>
# Project Rules for /<skill-name>
> Auto-generated by `/unikit-skills-context`. Do not edit manually.
> Last updated: YYYY-MM-DD HH:mm
## Rules
### [Rule Name]
**Rule**: [Specific, actionable instruction in English]
If file exists — read it, then:
- Add new
### [Rule Name]entry under## Rules - Update
> Last updated:line
Formatting:
- Rule name: short, descriptive (2-5 words)
- Rule text: English, imperative, specific and actionable
- If user provided rule in non-English language, translate to English before writing
Step 4: Confirm
✅ Added to .unikit/skill-context/<skill>/SKILL.md:
### [Rule Name]
**Rule**: [the rule text]
Cross-check: [result — "no overlap with base" / "strengthens base rule on X" / "overrides base behavior Y"]
Validate Mode: Stale Rule Check
Triggered by:
/unikit-skills-context validate→ check ALL skills that have skill-context files/unikit-skills-context validate <skill>→ check specific skill only
Step V1: Find Skill-Context Files
Glob: .unikit/skill-context/*/SKILL.md
If checking specific skill → filter to that one.
If no skill-context files found → report "No skill-context files to validate." and stop.
Step V2: Compare Against Base Skills
For each skill-context file:
- Read the base
{{skills_dir}}/<skill>/SKILL.md - For each rule in skill-context, compare against the base:
| Case | Description | Recommendation |
|---|---|---|
| A: Fully covered | Base now contains equivalent or superset rule | Remove from skill-context — base handles it |
| B: Conflict | Base directly contradicts skill-context rule | User decision required — skill-context wins if kept |
| C: Partial overlap | Neither fully covers the other | Analyze and present options |
| D: No overlap | Rule is unique to project context | Keep as-is, no action needed |
Collect all Case A/B/C findings. If none found → report "All skill-context rules are current." and stop.
Step V3: Present Findings
For each stale rule:
Case A — Fully covered:
### ✅ /unikit-<skill> — Fully covered: [Rule Name]
- **Base SKILL.md says:** [base rule text]
- **Skill-context says:** [project rule text]
- **Recommendation:** Remove from skill-context (base covers it)
Case B — Conflict:
### ⚠️ /unikit-<skill> — Conflict: [Rule Name]
- **Base SKILL.md says:** [base rule text]
- **Skill-context says:** [project rule text]
- **Note:** Skill-context has priority — if kept, base version is ignored
Case C — Partial overlap:
### 🔄 /unikit-<skill> — Partial overlap: [Rule Name]
- **Base SKILL.md says:** [base rule text]
- **Skill-context says:** [project rule text]
- **Analysis:** [explain overlap and whether parts are independent]
- **Warning:** Skill-context has priority — if kept as-is, base's unique parts on this topic will be lost
Step V4: Collect Decisions
Ask each finding with the question tool of your agent (AskUserQuestion):
Case A:
Options:
- Remove — trust base skill
- Keep — ensure priority of skill-context rule
Based on choice:
- Remove → delete the rule section from skill-context file
- Keep → no changes needed
Case B:
Options:
- Keep skill-context — override base
- Remove — trust base
- Rewrite — merge both formulations
Based on choice:
- Keep skill-context → no changes needed
- Remove → delete the rule section from skill-context file
- Rewrite → replace rule text with merged version
Case C:
Options:
- Rewrite — include unique parts from both
- Keep as-is — base's parts lost
- Remove — delete skill-context rule
Based on choice:
- Rewrite → replace rule text with new version combining both
- Keep as-is → no changes needed
- Remove → delete the rule section from skill-context file
Step V5: Apply Decisions
For each decision:
- Remove: Delete the rule section from skill-context file
- Rewrite: Replace rule text with new version
- Keep: No changes needed
After applying:
- Update
> Last updated:line - If a skill-context file has no rules left (only header remains) → delete the file and its directory
Rules
- Skill-context only — all rules go to
.unikit/skill-context/, NEVER to{{skills_dir}}/unikit-*/ - English only — skill-context files are always in English regardless of user's language
- Workflow rules only — skill-context is for HOW skills work, not coding conventions (use
/unikit-rulesfor those) - No duplicates — always cross-check against base SKILL.md and existing skill-context
- Reversible — user approves changes in validate mode before applying
- Ownership boundary — this command owns
.unikit/skill-context/*; treats base skills ({{skills_dir}}/) and rules (.unikit/memory/,.unikit/RULES.md,.unikit/rules/) as read-only
Examples
/unikit-skills-context review "Always check null-check symmetry first"
> ✅ Added to .unikit/skill-context/unikit-review/SKILL.md:
> ### Null-Check Priority
> **Rule**: Always check null-check symmetry first when reviewing code.
> Cross-check: no overlap with base
/unikit-skills-context validate
> 🔍 Checking 2 skill-context files...
>
> ✅ /unikit-fix — Fully covered: Cancellation Cleanup
> Base SKILL.md now includes: "check cancellation cleanup in async methods"
> Recommendation: Remove from skill-context
>
> ✅ /unikit-review — No overlap: all 3 rules are project-specific
>
> ⚠️ 1 stale rule found.
> [question] Remove it? — Remove / Keep
04 同仓库更多 Skills
unikit
Initialize the UniKit framework in a project. Scans the current project to detect the engine and real tech stack, then generates the base framework documents that give AI agents context about the project — the resolved project description, the architecture doc, AGENTS.md, and the user-editable .unikit/config.yaml. This is the one-time, whole-project setup run before any other unikit skill. Use whenever the user wants to initialize, set up, or onboard the framework, e.g. "initialize unikit", "init the framework", "set up unikit", "set up the project", "configure AI context", "scan my project and set it up", "bootstrap the project". It also actualizes the config of a project already set up — say "update the config", "add missing settings", "actualize configuration", "fix my config". On a set-up project it offers the actions to choose from.
unikit-verify
Verify a completed implementation against the plan in .unikit/code/plans/. Checks that every task was implemented, nothing was forgotten, the code compiles, the recorded test run still matches the code, and {{engine_name}} conventions are followed. Use after /unikit-implement completes, or when the user says "verify", "check the work", "did we miss anything". For code review use /unikit-review instead.
unikit-todo
Manage the project's TODO list in .unikit/TODO.md — capture work to remember for later, not to do right now. Use it to add a deferred item, mark a todo complete, or show the list. The point is to park tasks you don't want to act on in the moment but don't want to forget. Trigger on "add a todo", "add this to the todo list", "put X on the todo list", "remind me to...", "don't forget to...", "note this for later", "we should do this later", "mark this todo done", "what's on the todo list", "what's left to do". This is only for parking reminders — to actually plan or do the work now, use /unikit-plan, /unikit-implement, or /unikit-execute.
unikit-rules
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 the knowledge base (RULES_INDEX.md) to avoid duplicating core/stack entries. Use for 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), by keyword or in plain words. 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.
unikit-rules-registry
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.
unikit-roadmap
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.