open-multi-agent-kit 0.78.0

package/templates/skills/kimi/deepseek-api/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: deepseek-api
+description: Slash command to set the official DeepSeek API key through OMK without printing it.
+---
+
+# /deepseek-api
+
+Set the official DeepSeek API key in the user-local OMK secret env file.
+
+## Command
+
+```bash
+omk deepseek api
+```
+
+Non-interactive alternatives:
+
+```bash
+printf '%s' "$DEEPSEEK_API_KEY" | omk deepseek api
+omk deepseek api --from-env DEEPSEEK_API_KEY
+```
+
+## Rules
+
+- Never print, summarize, or store the API key in the project repository.
+- Prefer the masked prompt in an interactive terminal.
+- After setting, run `omk deepseek doctor --soft` to verify availability.

package/templates/skills/kimi/deepseek-disable/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: deepseek-disable
+description: Slash command to disable OMK DeepSeek workers and force Kimi-only fallback.
+---
+
+# /deepseek-disable
+
+Disable DeepSeek opportunistic workers. OMK continues with Kimi-only execution.
+
+## Command
+
+```bash
+omk deepseek disable "disabled from slash command"
+```
+
+## Rules
+
+- Use when DeepSeek balance/auth/provider health is uncertain.
+- Do not modify or print API keys.
+- Re-enable with `/deepseek-enable` after fixing balance or credentials.

package/templates/skills/kimi/deepseek-enable/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: deepseek-enable
+description: Slash command to enable OMK DeepSeek opportunistic read-only workers.
+---
+
+# /deepseek-enable
+
+Enable DeepSeek as an optional low-risk worker pool. Kimi remains the main orchestrator, planner, merger, and fallback runtime.
+
+## Command
+
+```bash
+omk deepseek enable
+```
+
+## Rules
+
+- Do not print API keys.
+- Use only after the account has a valid key and sufficient balance.
+- Run `omk provider doctor deepseek` if availability needs verification.

package/templates/skills/kimi/deepseekset/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: deepseekset
+description: Slash command to store a DeepSeek API key in the user-local OMK secret env file.
+---
+
+# /deepseekset
+
+Set the DeepSeek API key without writing it to the project repository.
+
+## Command
+
+```bash
+omk deepseek api
+```
+
+Safer alternatives:
+
+```bash
+printf '%s' "$DEEPSEEK_API_KEY" | omk deepseek api
+omk deepseek api --from-env DEEPSEEK_API_KEY
+```
+
+## Rules
+
+- Never print or summarize the key.
+- Store only in the user-local OMK secret env file.
+- After setting, run `omk provider doctor deepseek --soft` to verify availability.

package/templates/skills/kimi/graph-view/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: graph-view
+description: Generate and optionally open the OMK ontology graph viewer from project-local graph memory.
+---
+
+# /graph-view
+
+Render `.omk/memory/graph-state.json` into `.omk/memory/graph-view.html`.
+
+## Usage
+
+When invoked, run the local OMK CLI command:
+
+```bash
+omk graph view --open
+```
+
+If the user asks for a smaller graph or specific node types, pass through the matching flags:
+
+```bash
+omk graph view --limit 300 --type Memory,Decision,Task,Risk,File,Evidence --open
+```
+
+## Rules
+
+- Do not read or print secrets.
+- Prefer `omk graph view --open` for interactive inspection.
+- If browser opening fails, report the generated `.omk/memory/graph-view.html` path.
+- For large graphs, suggest `--limit` and `--type`.

package/templates/skills/kimi/matt-pocock-skills/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: matt-pocock-skills
+description: Real-engineering alignment, shared-language, TDD, diagnosis, and architecture-review workflow adapted from mattpocock/skills for OMK. Use before non-trivial implementation, ambiguous product work, debugging loops, test-first changes, or codebase architecture cleanup.
+---
+
+# matt-pocock-skills
+
+Source basis: mattpocock/skills at commit f304057d61d3df3c9fd992ac2b6e3833cb9325fb. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts or code.
+
+## Use when
+
+- The request is underspecified and a wrong interpretation would waste work.
+- Product language, domain terms, or acceptance criteria are unclear.
+- A bugfix or feature needs a test-first loop.
+- The codebase is becoming hard to reason about and needs a scoped architecture pass.
+
+## OMK workflow
+
+1. Grill lightly: identify goal, non-goals, impacted users, constraints, and proof required. Ask only blocking questions; otherwise state assumptions.
+2. Create shared language: capture domain terms, abbreviations, and project-specific meanings in the plan or relevant docs.
+3. Convert the request into verifiable outcomes: failing test, typecheck, lint, screenshot, replay, or JSON gate.
+4. Work in small slices. After each slice, run the cheapest useful feedback loop before widening.
+5. For debugging, reproduce first, isolate the failing boundary, patch the smallest cause, then prove the original failure is gone.
+6. For architecture cleanup, map module responsibilities and seams before editing; avoid rewrites not tied to the user goal.
+
+## Output contract
+
+Return:
+
+- clarified assumptions or questions asked
+- shared terms or acceptance criteria
+- smallest implementation slice
+- feedback loop commands and results
+- follow-up architecture risks, if any
+
+## Guardrails
+
+- Do not turn a small task into a process-heavy spec unless ambiguity is material.
+- Do not invent product requirements.
+- Do not skip verification because the plan was detailed.

package/templates/skills/kimi/mcp-install/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: mcp-install
+description: Install, validate, and manage MCP servers for OMK using the curated catalog and parallel processing.
+---
+
+# MCP Server Installation Skill
+
+Guide for adding MCP servers to an OMK project using the built-in catalog and parallel orchestration.
+
+## Commands
+
+```bash
+# List configured MCP servers
+omk mcp list
+
+# Diagnose all MCP servers
+omk mcp doctor
+
+# Diagnose a specific server
+omk mcp doctor <server-name>
+
+# Install a single MCP server
+omk mcp install <name> <command> [args...]
+
+# Remove a server from project-local config
+omk mcp remove <name>
+
+# Sync global MCP servers into project
+omk mcp sync-global
+```
+
+## Curated Catalog
+
+OMK ships with a verified catalog in `src/mcp/server-catalog.ts` (or accessible via the runtime).
+Recommended categories:
+
+- **reasoning**: `sequential-thinking` — structured problem solving
+- **memory**: `memory` — persistent knowledge graph
+- **docs**: `pdf` — PDF text extraction
+- **web**: `puppeteer` — browser automation
+- **devtools**: `filesystem`, `sqlite` — file and database access
+- **ops**: `railway` — remote Railway MCP; `supabase` — database management and edge functions
+
+## Parallel Installation
+
+When installing multiple servers (e.g., during `omk init`), OMK uses `Promise.all` for parallel setup.
+Agents and hooks can also trigger bulk installs:
+
+1. **Agent lane**: explorer validates which servers are needed
+2. **Coder lane**: writes the MCP JSON entries
+3. **QA lane**: runs `omk mcp doctor` to verify each server
+4. **Hook**: `post-init-mcp.sh` runs non-blocking validation after init
+
+## Rules
+
+1. Prefer `npx -y <package>` so no global install is required.
+2. Use `${PROJECT_ROOT}` and `${DB_PATH}` placeholders in catalog entries; they are resolved at install time.
+3. Do not commit secrets in `mcp.json` env values.
+4. Run `omk mcp doctor` after adding servers to confirm they start.
+5. If a server fails to start, check `startup_timeout_sec` and network access.
+
+## When to Use
+
+- During `omk init` when selecting additional MCP servers.
+- When a task requires a new capability (browser, PDF, database).
+- Before reporting an MCP issue, run `omk mcp doctor --json` for structured evidence.

package/templates/skills/kimi/multica/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: multica
+description: Managed-agent teamwork, issue assignment, progress tracking, reusable-skill compounding, and handoff workflow adapted from multica-ai/multica for OMK. Use when coordinating multiple agents, converting work into agent-ready tasks, tracking blockers, or turning repeated solutions into skills.
+---
+
+# multica
+
+Source basis: multica-ai/multica at commit 24a59098d65e52797df6a4f4e4de2a6299f10afc. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts or code.
+
+## Use when
+
+- Work needs multiple lanes, agent handoffs, reviewer/QA passes, or issue-board style tracking.
+- A user asks to coordinate OMX/Kimi/Codex agents or compound reusable skills.
+- You need to turn a broad request into assignable, verifiable tasks.
+
+## OMK workflow
+
+1. Define the board: goal, stop condition, lanes, owners, write scopes, verification gates, and worker limit.
+2. Split only independent work. Keep blocking critical-path tasks local unless delegation was explicitly requested.
+3. For each lane, provide goal, scope, files, constraints, expected output, and proof required.
+4. Track lifecycle: queued, in progress, blocked, review, verified, done. Include blocker reason and next action.
+5. Merge results through a reviewer/integrator pass. Do not accept agent output without diff review and gates.
+6. When a repeated pattern proves useful, convert it into a compact OMK skill with source, trigger, workflow, output contract, and guardrails.
+
+## Output contract
+
+Return:
+
+- lane/task board
+- agent or local owner per lane
+- status and blockers
+- integration decisions
+- reusable skill candidates
+- verification evidence
+
+## Guardrails
+
+- Respect configured worker limits and user permission for parallel agents.
+- Do not run install scripts, Docker, cloud setup, or daemon startup unless the user explicitly requests that operational change.
+- Do not let agent parallelism create overlapping write scopes.

package/templates/skills/kimi/omk-adaptorch-orchestration-review/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: omk-adaptorch-orchestration-review
+description: Review AdaptOrch, OMK, and similar DAG multi-agent orchestration frameworks. Use when assessing DAG node responsibility, dependency edges, worker write authority, fallback/retry/timeout/evidence gates, review/merge boundaries, or reproducible decision traces.
+---
+
+## Orchestration Review
+
+Use this for read-only architecture review of DAG runtimes, multi-agent pipelines, worktree teams, schedulers, and evidence-gated repair loops.
+
+## Checklist
+
+### DAG node contract
+
+- Verify each node has one responsibility, one owner role, and one observable outcome.
+- Verify inputs, outputs, side effects, and acceptance evidence are explicit.
+- Flag nodes that mix planning, implementation, review, and merge authority without a gate.
+
+### Dependency edges
+
+- Confirm each edge represents a real data dependency, verification dependency, or authority handoff.
+- Flag ordering-only edges that do not protect correctness or safety.
+- Check that failed evidence blocks dependent nodes or routes them to repair.
+
+### Worker authority
+
+- Confirm each worker has bounded write scope and cannot overwrite unrelated lanes.
+- Check shared-file ownership, merge points, and escalation paths.
+- Require reviewer/merger separation for risky or cross-cutting changes.
+
+### Resilience and gates
+
+- Look for explicit retry limits, timeout presets, fallback routes, stop conditions, and evidence gates.
+- Confirm fallback does not silently weaken acceptance criteria.
+- Check that blocked, skipped, failed, and complete states are distinct.
+
+### Decision trace
+
+- Confirm routing, scheduler decisions, tool calls, evidence, retries, and final verdict are replayable.
+- Flag missing timestamps, inputs, outputs, or rationale needed to reproduce a run.
+
+## Output
+
+```txt
+Verdict:
+DAG node issues:
+Dependency edge issues:
+Worker authority risks:
+Missing gates:
+Decision trace gaps:
+Recommended fixes:
+Files/artifacts reviewed:
+```

package/templates/skills/kimi/omk-backend-api-review/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: omk-backend-api-review
+description: Backend API review for NestJS, Express, FastAPI, database access, validation, auth, error handling, and API contracts.
+---
+
+## Backend Review
+
+Check:
+
+- request validation
+- authn/authz
+- DTO/schema correctness
+- transaction boundaries
+- N+1 queries
+- error response consistency
+- logging without secrets
+- backward compatibility
+- migration safety
+- test coverage
+
+## Output
+
+```txt
+API contract:
+Data flow:
+Auth risk:
+DB risk:
+Error handling:
+Test gaps:
+```

package/templates/skills/kimi/omk-code-review/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: omk-code-review
+description: Adversarial code review for diffs, logic correctness, type safety, test coverage, and security risk.
+---
+
+## Review Policy
+
+Review every non-trivial diff before final completion.
+
+## Checklist
+
+- [ ] Logic correctness
+- [ ] Type safety (no implicit any, proper narrowing)
+- [ ] Error handling
+- [ ] Test coverage
+- [ ] No secret leakage
+- [ ] No unnecessary dependencies
+- [ ] No generated files modified unless required
+- [ ] Conventional Commits if generating messages
+
+## Output
+
+```txt
+Verdict: approve / request-changes
+Issues:
+- line/file: issue description
+Suggestions:
+- line/file: suggestion
+Risk:
+```
+
+## When to Use
+
+Use before finishing implementation tasks or before generating commit/PR messages.

package/templates/skills/kimi/omk-context-broker/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: omk-context-broker
+description: Context and memory policy for long-running Kimi coding sessions, DAG workers, and repeated project work.
+---
+
+## Context Broker Policy
+
+Use this skill when a task spans many files, many turns, multiple workers, or a long session.
+
+## Local Graph Memory
+
+Project-local ontology graph memory is the default source of truth for project/session memory. Use `omk_read_memory`, `omk_write_memory`, `omk_memory_mindmap`, `omk_graph_query`, `omk_read_run_memory`, and `omk_write_run_memory` when the omk-project MCP exposes them. `.omk/memory/` is a local mirror/cache for reviewability.
+
+## Okabe / D-Mail Checkpoints
+
+Use Kimi Code Okabe + `SendDMail` for smart context recovery:
+
+- send a D-Mail before destructive/risky refactors, multi-agent handoffs, or `/compact`;
+- include the current goal, branch/changed files, tests run, blockers, and intended next action;
+- keep D-Mail concise and pair it with project-local graph memory for durable project/session recall.
+
+## Memory Files
+
+Use:
+
+- `.omk/memory/project.md`
+- `.omk/memory/decisions.md`
+- `.omk/memory/commands.md`
+- `.omk/memory/risks.md`
+- `.omk/runs/<run-id>/events.jsonl`
+- `.omk/runs/<run-id>/plan.md`
+- `.omk/runs/<run-id>/final-report.md`
+
+## Rules
+
+- Store stable project facts in project-local graph project memory.
+- Store temporary run/session facts in project-local graph run memory.
+- Store decisions with reason, date, and affected files.
+- Do not store secrets.
+- Before compacting, summarize active state:
+  - current goal
+  - completed tasks
+  - pending tasks
+  - changed files
+  - failing commands
+  - blockers
+
+## Decision Record Format
+
+```txt
+Date:
+Decision:
+Reason:
+Alternatives:
+Affected files:
+Risk:
+```

package/templates/skills/kimi/omk-control-loop-debugger/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: omk-control-loop-debugger
+description: Diagnose agent, runtime, tool, hook, context, provider-routing, DAG, retry, fallback, and evidence-gate failures using an industrial automation feedback-control loop. Use when workflows oscillate, stall, lose context, misroute tools, or need setpoint/sensor/controller/actuator/disturbance/correction analysis.
+---
+
+## Control-loop Debugger
+
+Use this to turn agent failures into a feedback-loop diagnosis instead of a vague postmortem.
+
+## Model
+
+- Setpoint: the user's requested target result and acceptance criteria.
+- Sensor: observed evidence from tests, logs, traces, diffs, screenshots, or user feedback.
+- Controller: router, scheduler, skill selection, policy, prompt, or state machine deciding the next action.
+- Actuator: edit, tool call, Kimi run, worker lane, hook, MCP server, or external command.
+- Disturbance: tool failure, context loss, stale state, version drift, quota, permissions, flaky tests, or hidden dependency.
+- Correction: retry, fallback, narrowed scope, state cleanup, manual review, test addition, or hard block.
+
+## Debug Process
+
+1. Restate the setpoint in measurable terms.
+2. List sensors and mark which are fresh, stale, missing, or contradictory.
+3. Compare sensor evidence to the setpoint and name the control error.
+4. Identify which controller decision created or failed to correct the error.
+5. Check actuator authority, side effects, timeout, and rollback path.
+6. Name disturbances separately from root cause.
+7. Pick one correction and define evidence that proves the loop is stable.
+
+## Failure Patterns
+
+- Oscillation: repeated retries without new evidence.
+- Saturation: context, token, time, quota, or worker capacity exhausted.
+- Sensor drift: stale tests, old logs, cached docs, or wrong working directory.
+- Bad actuator: command edits the wrong path, writes too broadly, or cannot affect the failure.
+- Controller mismatch: wrong skill, worker, provider, workflow, or fallback route.
+
+## Output
+
+```txt
+Setpoint:
+Sensor evidence:
+Control error:
+Controller decision:
+Actuator path:
+Disturbance:
+Correction:
+Verification:
+Residual risk:
+```

package/templates/skills/kimi/omk-design-md/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: omk-design-md
+description: Generate, read, validate, diff, and apply Google DESIGN.md files for Kimi UI/frontend tasks, Tailwind themes, screenshots, and visual coding.
+---
+
+## Use When
+
+Use this skill when:
+
+- creating UI
+- modifying frontend components
+- reviewing screenshots
+- converting mockups into code
+- generating landing pages
+- working with Tailwind, shadcn/ui, React, Next.js, or design tokens
+
+## Rules
+
+1. Read `DESIGN.md` before UI implementation if it exists.
+2. If `DESIGN.md` does not exist, infer a minimal design system from existing UI.
+3. Do not invent arbitrary colors if tokens exist.
+4. Validate `DESIGN.md` when the CLI is available:
+
+```bash
+npx @google/design.md lint DESIGN.md
+```
+
+5. For major design changes, create `DESIGN.next.md` and compare:
+
+```bash
+npx @google/design.md diff DESIGN.md DESIGN.next.md
+```
+
+6. When using Tailwind, export tokens if needed:
+
+```bash
+npx @google/design.md export --format tailwind DESIGN.md > tailwind.theme.json
+```
+
+7. When a named visual reference is requested, use the bundled `awesome-design-md` skill and OMK catalog commands:
+
+```bash
+omk design search <keyword>
+omk design apply <name>
+```
+
+## Output
+
+```txt
+Design source:
+Tokens used:
+Components affected:
+Accessibility risk:
+Commands run:
+```

package/templates/skills/kimi/omk-design-system/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: omk-design-system
+description: Build and maintain a terminal-native, orchestration-first design system for agent team HUDs, status surfaces, and control planes.
+---
+
+## Principles
+
+- Clear hierarchy
+- Compact status surfaces
+- High signal-to-noise ratio
+- Strong distinction between planning, execution, review, and risk states
+
+## Colors
+
+- Primary: core text and terminal-like surfaces
+- Accent: active orchestration controls, selected workers, primary CTAs
+- Success/Warning/Danger: reserved for quality gates and safety decisions
+
+## Components
+
+- Buttons: compact, high contrast, status-aware
+- HUD cards: prioritize task state, worker state, commands, and risk

package/templates/skills/kimi/omk-docs-release/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: omk-docs-release
+description: Documentation, changelog, release note, README, migration guide, and developer handoff workflow.
+---
+
+## Documentation Policy
+
+Use this after implementation or when generating docs.
+
+## Include
+
+- what changed
+- why it changed
+- how to use it
+- commands
+- configuration
+- migration notes
+- known limitations
+- test result
+
+## Rules
+
+- Do not overclaim.
+- Do not hide failed or skipped tests.
+- Use concise technical writing.
+- Prefer examples over abstract explanation.
+
+## Output
+
+```md
+## Summary
+
+## Usage
+
+## Configuration
+
+## Test result
+
+## Migration notes
+
+## Known limitations
+```

package/templates/skills/kimi/omk-evidence-contract/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: omk-evidence-contract
+description: Generate task-specific evidence contracts before a done/completed claim. Use for feature, bugfix, refactor, research, release, security, docs, or orchestration tasks that need changed files, non-empty diffs, test/build/typecheck results, citations, uncertainty, conflicting evidence, and final risk notes.
+---
+
+## Evidence Contract
+
+Use this before declaring work complete. Define the claim first, then list the minimum evidence that can prove or falsify it.
+
+## Process
+
+1. Classify the task type: feature, bugfix, refactor, research, release, security, docs, or orchestration.
+2. Write the completion claim in one sentence.
+3. List required evidence and the command or artifact that proves it.
+4. Mark any unavailable evidence as a gap with a concrete reason.
+5. Report remaining risk without converting gaps into success.
+
+## Feature / Bugfix / Refactor Evidence
+
+- Changed files.
+- Non-empty relevant git diff, unless the task was explicitly read-only.
+- Unit or integration test result for changed behavior.
+- Build, typecheck, lint, or static-analysis result appropriate to the stack.
+- Regression note covering edge cases and untested paths.
+
+## Research Evidence
+
+- Cited sources or local files inspected.
+- Date checked for external or version-sensitive facts.
+- Confidence and uncertainty.
+- Conflicting evidence or missing primary-source coverage.
+- Recommendation with assumptions separated from verified facts.
+
+## Release / Security Evidence
+
+- Secret scan or explicit reason it was not run.
+- Audit, permission, or destructive-action review when relevant.
+- Changelog/PR/release checklist evidence.
+- Rollback or recovery note for risky changes.
+
+## Output
+
+```txt
+Task type:
+Completion claim:
+Required evidence:
+Evidence gathered:
+Gaps:
+Conflicting evidence:
+Final risk:
+Done verdict:
+```