litianyi-007
User由 AI 维护的项目记忆 wiki——把业务语义编译一次，不必每次追问时重推。18 个 skill 覆盖 ingest / search / graph / dream / sync / 跨 wiki federation。 · An AI-maintained wiki for project memory: compile business semantics once instead of re-deriving them on every query. 18 skills spanning ingest, search, graph, dream, sync and cross-wiki federation.
Categories
Indexed Skills (43)
kata
Kata — a self-evolving knowledge system for AI-paired builders. CORE: self-closing wiki loop + auto-dreaming on Karpathy's LLM-Wiki principle. Phase 1 (current): AI-paired engineering — compile project business semantics so agents read project conventions before they write code. Phase 2 (designed): team spec authoring + dispute resolution. 18 skills (init / import / ingest / search / graph / tier / digest / query / lint / config / dream / watch / sync / spec / session-ingest / mcp-server / federate / skill-create). **v1.13 SHM complete (Phase 0+2+3+4)**. **v1.15 work-loop bridge**: `wiki-skill-create` generates project-local skills wrapping kata's query/ingest with the project's actual work pipeline (issue-fix / feature-build / bug-debug / custom patterns); closes consult-before / file-back-after as structural default rather than discipline.
wiki-config
Unified read/write for SCHEMA.md config — show all settings in one place, get/set scalar values by dotted path with schema validation, explain what each key does. Domain-specific skills (wiki-tier, wiki-init) still own their UX shortcuts; wiki-config is the generic interface.
wiki-digest
Generate a digest of the wiki: recent activity summary, key themes by cluster, tier distribution (active/archived/frozen), coverage gaps, cross-cutting synthesis, stale custom dimensions, and suggested next actions. The weekly health report for your knowledge base.
wiki-dream
Auto-dreaming: re-evaluate frozen and archived pages against recent activity, surface candidates whose relevance has resurfaced, optionally promote them back to the active tier. Reads only the wiki filesystem (log.md + page frontmatter dates ingested_at/updated); never reads chat sessions or file mtimes. Designed for market-research wikis but the strategy is pluggable.
wiki-federate
Cross-wiki federation — query peer kata wikis via MCP and merge results with provenance. v1.12 Phase 2: federation client side. wiki A's search/query can fan out to katas B, C, ... listed in {wiki_path}/.federation.yaml, returning ranked merged results with kata://<peer>/<path> URIs for citation. Read-only across the boundary; peer wiki_id is verified before trusting (PRD D1.5). Phase 0+1 made each kata an MCP server; this skill is the other half — making it an MCP client too.
wiki-graph
Query the wiki as a graph without maintaining a graph DB. Structured frontmatter queries, neighbor traversal, shortest paths, hub/orphan detection — each call scans the .md files fresh and computes the answer on the fly. Defaults to active-tier pages when memory tiers are enabled.
wiki-import
Import an existing document system (folder tree, Obsidian vault, Notion/Confluence export, etc.) into the wiki. Scans source structure, maps to wiki types, deduplicates against existing content, prompts once per batch for any custom frontmatter dimensions declared in SCHEMA.md, and processes in priority order with checkpoint support.
wiki-ingest
Ingest a source into the wiki: save raw content and referenced images, prompt the user for any custom frontmatter dimensions declared in SCHEMA.md, extract key information, create or update wiki pages per SCHEMA.md conventions, and update index.md and log.md.
wiki-init
Interactive bootstrap for a new LLM wiki: ask about domain, propose categories that fit, write a customized SCHEMA.md, create index.md and log.md, and suggest git init.
wiki-lint
Health-check the wiki: structural checks (orphans, broken links, frontmatter, stale content, tier consistency, custom-dimension completeness), content gaps with web-search suggestions, and taxonomy evolution proposals for SCHEMA.md.
wiki-mcp-server
Run a kata wiki as a Model Context Protocol (MCP) server over stdio. Any MCP-aware agent (Claude Code, Cursor, Continue, another kata acting as a federation client) can connect and call exposed read-only tools (wiki-search in Phase 0; wiki-query / wiki-graph / wiki-spec-preflight in Phase 1+). Read-only by design — write skills are never exposed across the MCP boundary.
wiki-query
Answer a question using the wiki's compiled knowledge. Searches relevant pages, synthesizes with citations, reports explicit answer confidence, supports multiple output formats (markdown/table/slides/chart/canvas), files substantive answers back into the wiki, and optionally falls back to external plugins (e.g. deepwiki-cli for source code) when local wiki coverage is insufficient — with results funneled back through wiki-ingest so future queries hit local first.
wiki-search
Search the wiki by keyword, tag, topic, or type. Returns ranked results with page summaries and matching excerpts. Defaults to active-tier content when memory tiers are enabled. No orientation required — runs directly against wiki files.
wiki-session-ingest
Ingest the active AI CLI session into the wiki: detect which CLI you're in (Claude Code / Codex CLI / Gemini / Copilot / OpenCode / Kimi / unknown), read the session transcript, write a raw session dump, extract knowledge-point candidates, multi-select with the user, and distill each into wiki pages via the existing wiki-ingest pipeline. v1.11 MVP. Captures the conversation-born knowledge that's normally lost when the user 'forgets to write it down.'
wiki-skill-create
Generate a project-local skill that bridges kata's documentation loop (search/query/ingest) with the actual work pipeline of THIS project (code edit / test / build / human verify). Picks a pattern (issue-fix / feature-build / bug-debug / custom), captures project context (tech stack, build commands, kata wiki binding), renders a SKILL.md that encodes the 7-step work loop, runs static verification. v1.15 MVP. Closes the gap between 'what was figured out' and 'what kata's wiki knows.'
wiki-spec
Spec history management. Before authoring a new spec (PRD / design / RFC / ADR / task-spec / decisions), surface related prior specs from the kata wiki so the author can declare relationships (supersedes / refines / extends / parallel / contradicts). v1.13 Phase 0+2: scan + advisory + enforcement. Phase 3 auto-propagates. Cross-source authoring is served by wiki-import (bulk human ingest) or v1.12 cross-wiki federation.
wiki-sync
Multi-machine git sync for the wiki: pull, merge with custom drivers (log.md union+sort), push. Local sync lock + force-push detect + identity check + per-machine sync reports under ~/.kata/sync-reports/. Hard stops on import-in-progress, merge-in-progress, identity mismatch, force-push detected, unrelated histories. NEVER touches anything in the wiki repo without committing it first; reports go to ~/.kata/ to avoid self-conflict.
wiki-tier
Inspect and manage the memory-tier system: view the active/archived/frozen distribution, preview a threshold change before committing, update SCHEMA.md thresholds, and pin manual tier overrides on specific pages.
wiki-watch
Watch raw/{articles,papers,transcripts,external}/ for new files, queue them, and let the user drain the queue with one command. Closes the 'I dropped a file but forgot to ingest' gap. NEVER auto-runs wiki-ingest — drain is always explicit.
hopper-dispatch
Use when the user asks Hopper to dispatch, run, start, resolve, or preflight one .hopper queue task through hopper-dispatch.
hopper-result
Use when the user asks Hopper to show, fetch, print, inspect, or summarize the completed result of a dispatched task.
hopper-setup
Use when the user wants a Hopper vendor readiness check or doctor — which vendor CLIs are installed and authenticated, which support sandbox control or web search, cached/known models, and (with --deep) live model-catalog drift. Triggers: 'hopper setup', 'hopper doctor', 'are my vendors ready', 'check vendor health', 'which vendors can I dispatch to'.
hopper-update
Use when the user asks Hopper to check for updates, upgrade the plugin, reconcile a project after upgrading, migrate .hopper/ config to a newer schema, or explain why an existing project stopped dispatching after a version bump. Triggers: 'hopper update', 'update hopper', 'is hopper up to date', 'migrate my .hopper config', 'my project stopped dispatching after upgrading', 'hopper-dispatch --update-check', '--migrate-config'.
hopper
Use when the user asks to operate Hopper or llm-hopper broadly, troubleshoot Hopper's file-backed .hopper protocol, or choose among Hopper dispatch, status, progress, result, probe, models, vendors, setup/doctor (vendor readiness), and smoke workflows.
hopper-models
Use when the user asks Hopper which vendor models are available, wants cached model names, or needs model/reasoning options before dispatch.
hopper-probe
Use when the user asks Hopper to refresh vendor capabilities, probe installed CLIs, update cached models, or diagnose model cache staleness.
hopper-progress
Use when the user asks Hopper to check progress, watch a background task, stream terminal events, inspect in-progress state, or monitor completion.
hopper-smoke
Use when the user asks Hopper to verify plugin installation, check CLI readiness, run a smoke test, or confirm hopper-dispatch is callable.
hopper-status
Use when the user asks Hopper for queue status, pending/in-progress/done/failed counts, or a read-only .hopper queue summary.
hopper-vendors
Use when the user asks Hopper to list registered vendor adapters, confirm supported vendors, or check vendor naming.
harnessloop-channels
Use when the user references harnessloop:channels or asks to list all external systems, access channels, tools, MCP servers, CLIs, APIs, CI systems, databases, broker services, or other integrations declared in Harnessloop evidence contracts, data sources, transfer packets, goals, rounds, or handoffs. This skill is inventory-only and must not probe connectivity.
harnessloop-connectivity
Use when the user references harnessloop:connectivity or asks to check external system, access channel, tool, MCP server, CLI, API, CI, database, broker, or integration connectivity declared in Harnessloop evidence contracts or channel inventory. This skill only runs declared verification methods and must ask the user first when required tools, parameters, credentials, or permissions are missing.
harnessloop-continue
Use when the user references harnessloop:continue, asks Harnessloop to continue, resume, advance, or proceed through the control gate. This skill reads current Harnessloop state, runs the continuation gate, and allows only the next action permitted by evidence, control, environment, intake, and self-audit state.
harnessloop-delegation
Use when the user references harnessloop:delegation, asks to check subagent or swarm readiness, verify delegated task model/effort success, inspect delegation capability, record expected versus observed model/reasoning, or decide whether Harnessloop may delegate discovery, evidence collection, execution, adversarial review, or acceptance testing.
harnessloop-evidence
Use when the user references harnessloop:evidence or asks to add, check, revise, reject, or explain Harnessloop evidence contracts during a loop. This skill updates or validates acceptable evidence entries, freshness rules, validation methods, citation requirements, and continuation effects without continuing business execution.
harnessloop-goal
Use when the user references harnessloop:goal or asks to inspect, propose, negotiate, update, split, reprioritize, archive, cancel, supersede, or assess deletion impact for Harnessloop goals, subgoals, or tasks. This skill manages goal contracts and goal breakdowns without executing business work or accepting rounds.
harnessloop-init
Use when the user explicitly asks to initialize Harnessloop, references harnessloop:init, says to set up the Harnessloop framework, or wants to create project-local .harnessloop files before running the full Harnessloop loop. This skill performs only initialization and handoff into the main harnessloop-loop protocol.
harnessloop-intake
Use when the user references harnessloop:intake, wants Harnessloop to take over an existing agent session, provides a transfer packet, asks to run an intake gate, or needs a gap review before importing previous work into a Harnessloop goal. This skill reviews imported session context and blocks business execution until the packet is evidence-backed.
harnessloop-issue
Use when the user references harnessloop:issue or asks to record, analyze, or propose a fix for a Harnessloop evolution issue, framework question, protocol defect, self-audit concern, skill gap, template gap, packaging gap, or plugin behavior problem. This skill records user questions as evolution issues and analyzes them without copying project-private context.
harnessloop-loop
Use when running or taking over a long-running goal-driven task in an installed project: create or import Harnessloop state, run intake gates for existing agent sessions, decompose goals, define evidence and validation contracts, enforce scope-locks, manage file-system handoffs, verify with real static/dynamic/runtime/source evidence, classify feedback, self-audit for drift or dead loops, and continue only through evidence-backed control gates.
harnessloop-secrets
Use when the user references harnessloop:secrets or asks to create, check, update, resolve, or audit local channel parameters, secret references, credential keys, API tokens, environment-variable names, local-only values, or redaction rules needed by Harnessloop evidence, channels, connectivity, or external-system access.
harnessloop-setup
Use when the user references harnessloop:setup, runs $harnessloop-setup, or asks to complete, fill in, resume, or check Harnessloop project setup — environment detection, data sources, cost/context policy, or control-contract profile selection — before running $harnessloop-goal, $harnessloop-loop, or $harnessloop-continue. This skill runs the five-step setup wizard backed by check_setup.py and must not execute business work or accept a round.
harnessloop-status
Use when the user references harnessloop:status, asks for Harnessloop status, wants to inspect the active goal, round, evidence health, open handoffs, control state, environment state, self-audit state, next proposed action, or blocking reason. This skill is strictly read-only and must not mutate files or continue work.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.