Files
Kigi-CLI/crates/codegen/kigi-shell/skills/create-skill/SKILL.md
T
ZacharyZhang-NY 6f31415ed6 §9 acceptance: grep-zero sweep — every internal x.ai/grok identifier renamed
The PRD's first acceptance gate now holds: grep -RinE '\bx\.ai\b|grok'
crates/ --include='*.rs' → 0 matches (exempt: NOTICE and third-party
license archives, README provenance, and the required 'Based on Grok
Build Open Source' attribution, now sourced from version_attribution.txt).

Wire-visible renames (both sides in this repo, changed in lockstep):
- Auth method id 'grok.com' → 'kimi-code' (AuthMethodKind::KimiCode).
- Every x.ai/* and _x.ai/* ACP ext method and meta key → kigi/* /
  _kigi/* (~200 names; grokShell → kigiShell). Session-file replay keeps
  a read-side alias for the legacy '_x.ai/session/update' method so
  existing updates.jsonl histories load; writes emit only the new name
  (both directions test-pinned).
- Agent types grok-build* → kigi* with a documented legacy-prefix alias
  at resolution time so persisted sessions keep resolving.
- ToolNamespace/BuiltinAgentName GrokBuild* → Kigi* (wire snake_case
  kigi/kigi_concise/kigi_hashline; schema regenerated); grok_build
  implementation dirs renamed to kigi*.
- x-grok-* headers → x-kigi-*, __GROK_* sentinels → __KIGI_*, themes
  grokday/groknight → kigiday/kiginight (old persisted values fall back
  to the default theme), web_fetch allowlist xAI hosts → kimi.com +
  moonshot platforms, changelog CDN → this repo, grok-build changelog
  archives deleted.
- BYOK default endpoint removed: [endpoints] api_base_url is now truly
  optional with NO default — consumers fail fast with the flag name when
  unset (no silent x.ai egress). Mock harnesses inject it explicitly.
- System-prompt identity fixed: 'released by xAI' → 'an unofficial
  community CLI for Kimi' (template + regenerated encrypted form).

Also repaired pre-existing grok-era test debt found by the sweep: the
stale trace_classify default-model pin, the grok-pager UA label test,
pty-harness stale-binary reuse and non-hermetic moonshot routing (a PTY
test could previously reach the real api.moonshot.cn), and the outdated
oauth fixture scope key.

Gates: §9 grep 0; fmt clean; workspace check/clippy 0/0 (-D warnings);
FULL cargo test --workspace: 234 suites, 21,961 passed, 0 failed;
deny advisories ok.
2026-07-18 02:48:46 -04:00

3.2 KiB

name, description, metadata
name description metadata
create-skill Interactively create a new Kigi skill (SKILL.md + optional scripts/references). Use when the user wants to create a skill, scaffold a skill, or runs /create-skill.
short-description
Create a new Kigi skill

Create Skill

Interactively gather requirements from the user and create a fully working Kigi skill on disk.

Step 1: Gather information

Ask the user the following questions one at a time as regular conversation questions (do NOT use structured option prompts for free-text inputs):

  1. Skill name - ask the user to type a name. Lowercase letters (a-z), digits (0-9), and hyphens (-) only. Must start and end with a letter or digit. Must be 2-64 characters long (e.g. deploy-k8s). Validate the name before proceeding.
  2. Scope - present the user with two options:
    • Project (Recommended): <repo-root>/.kigi/skills/<name>/SKILL.md - available only in this repo, shareable with teammates
    • User: ~/.kigi/skills/<name>/SKILL.md - available in all projects
    • Default to Project if inside a git repo, otherwise User.
  3. What it should do - ask the user to describe the workflow, paste an example prompt they keep repeating, or explain the task the skill should automate.

Step 2: Draft the description

Write a description frontmatter value that includes:

  • What the skill does (1-2 sentences)
  • Trigger phrases and keywords so Kigi knows when to auto-invoke it
  • The slash command name (e.g. "Use when the user runs /deploy-k8s")

Show the drafted description to the user and let them approve or edit it.

Step 3: Create the directory

Run this bash command to create the skill directory:

mkdir -p <SKILL_DIR>

Where <SKILL_DIR> is:

  • User scope: ~/.kigi/skills/<name>
  • Project scope: <repo-root>/.kigi/skills/<name>

If the skill needs helper scripts, also create <SKILL_DIR>/scripts/. If the skill needs reference docs, also create <SKILL_DIR>/references/.

Step 4: Write SKILL.md

Use search_replace with an empty old_string to create the file at <SKILL_DIR>/SKILL.md.

The file MUST follow this exact format:

---
name: <skill-name>
description: <the description from Step 2>
---

<markdown body with instructions, steps, code blocks>

Also write any supporting files (scripts, references) using the same create method.

Step 5: Verify and confirm

  1. Run cat <SKILL_DIR>/SKILL.md to verify the file was written correctly.
  2. Tell the user the skill is ready and how to use it:
    • Slash command: /<skill-name>
    • TUI menu: /skills <skill-name>
    • Automatic: Kigi will invoke it when the description matches user intent
  3. Tell the user the skill should appear in the slash menu within a few seconds (skills auto-reload when files change on disk).

Guidelines

  • Keep the SKILL.md body focused and actionable. It is a prompt for the agent, not documentation.
  • The description field is critical. It controls auto-invocation. Be specific with trigger words.
  • Prefer referencing existing CLI tools over writing custom scripts.
  • Do NOT skip creating the directory. The file will fail to save without it.
  • Always use absolute paths when creating files to avoid writing to the wrong location.