open-multi-agent-kit 0.78.0

package/templates/skills/agents/omk-python-typing/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: omk-python-typing
+description: Python typed development standards using type hints, pytest, ruff, pyright, uv, and maintainable package structure.
+---
+
+## Python Rules
+
+- Use type hints for public functions.
+- Prefer `Path` over raw string paths.
+- Prefer dataclasses or Pydantic models for structured data.
+- Avoid mutable default arguments.
+- Do not silence type errors without reason.
+- Keep IO, business logic, and CLI boundaries separate.
+
+## Tooling
+
+Prefer existing project tools. If missing, suggest:
+
+```bash
+ruff check .
+ruff format .
+pyright
+pytest
+```
+
+## Output
+
+```txt
+Typing issues:
+Runtime risks:
+Test gaps:
+Fix plan:
+```

package/templates/skills/agents/omk-quality-gate/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: omk-quality-gate
+description: Quality gate workflow for lint, typecheck, tests, build, regression checks, and final acceptance.
+---
+
+## Quality Gate
+
+Use this before claiming any implementation is complete.
+
+## Command Discovery
+
+Check project files and infer commands from existing scripts.
+
+For Node/TypeScript:
+
+```bash
+pnpm lint
+pnpm typecheck
+pnpm test
+pnpm build
+```
+
+For Python:
+
+```bash
+ruff check .
+pyright
+pytest
+```
+
+Use the project's actual commands if different.
+
+## Completion Criteria
+
+A task is complete only when:
+
+* changed files are listed
+* commands are run or explicitly marked unavailable
+* failures are explained
+* regression risk is assessed
+* final diff is reviewed
+
+## Report Format
+
+```txt
+Changed files:
+Commands run:
+Passing:
+Failing:
+Not run:
+Reason not run:
+Regression risk:
+Final status:
+```

package/templates/skills/agents/omk-repo-explorer/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: omk-repo-explorer
+description: Efficient repository exploration without dumping the whole codebase. Use before feature work, debugging, refactoring, and review.
+---
+
+## Repository Exploration
+
+Never read the whole repository blindly.
+
+## Steps
+
+1. Identify project type.
+2. Build a shallow map:
+   - top-level directories
+   - app entry points
+   - config files
+   - test directories
+3. Search for task keywords.
+4. Read only the smallest relevant files first.
+5. Expand outward through imports, call sites, routes, schemas, and tests.
+6. Produce an evidence-backed map.
+
+## Output
+
+```txt
+Relevant files:
+Entry points:
+Data flow:
+Existing patterns:
+Test locations:
+Unclear areas:
+Recommended next files:
+```

package/templates/skills/agents/omk-research-verify/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: omk-research-verify
+description: Web research and source verification workflow for current technical facts, libraries, APIs, pricing, policies, and documentation.
+---
+
+## Research Policy
+
+Use this when facts may be current, niche, version-sensitive, or external.
+
+## Steps
+
+1. Prefer official documentation.
+2. Check dates and versions.
+3. Compare at least two reliable sources when possible.
+4. Separate confirmed facts from inference.
+5. Cite sources in the final answer.
+6. Do not use stale memory for version-sensitive facts.
+
+## Kimi Runtime Note
+
+For API-level web search on Kimi K2.6, prefer a no-thinking research profile when builtin web search is required.
+
+## Output
+
+```txt
+Confirmed:
+Uncertain:
+Sources:
+Recommended action:
+```

package/templates/skills/agents/omk-secret-guard/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: omk-secret-guard
+description: Protect sensitive files and prevent secret leakage during Kimi coding workflows.
+---
+
+## Protected Files
+
+Never write, print, commit, or summarize secrets from:
+
+```txt
+.env
+.env.*
+*.pem
+*.key
+id_rsa
+id_ed25519
+credentials.json
+service-account*.json
+```
+
+## Rule
+
+If a task requires touching secrets, stop and request explicit user action.

package/templates/skills/agents/omk-security-review/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: omk-security-review
+description: Security review for secrets, authentication, authorization, injection, unsafe shell commands, dependency risk, and sensitive file edits.
+---
+
+## Security Review
+
+Use this for auth, API, database, shell, deployment, file upload, secrets, or dependency changes.
+
+## Check
+
+- Secret leakage
+- `.env` modification
+- Hardcoded tokens
+- SQL/NoSQL injection
+- Command injection
+- XSS
+- CSRF
+- Broken authorization
+- Unsafe file path handling
+- Insecure dependency usage
+- Over-broad permissions
+- Dangerous shell commands
+
+## Protected Files
+
+Treat these as protected:
+
+```txt
+.env
+.env.*
+*.pem
+*.key
+id_rsa
+id_ed25519
+credentials.json
+service-account*.json
+```
+
+## Output
+
+```txt
+Security verdict:
+Critical:
+High:
+Medium:
+Low:
+Required fixes:
+```

package/templates/skills/agents/omk-test-debug-loop/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: omk-test-debug-loop
+description: Debug failing lint, typecheck, test, and build commands with minimal fixes and repeated verification.
+---
+
+## Test Debug Loop
+
+Use this when a command fails.
+
+## Steps
+
+1. Capture exact command and output.
+2. Classify failure:
+   - syntax
+   - type
+   - dependency
+   - runtime
+   - test assertion
+   - environment
+   - flaky
+3. Identify the smallest related file set.
+4. Fix the root cause, not the symptom.
+5. Re-run the failing command.
+6. Run adjacent checks if needed.
+7. Stop after repeated failure and report blocker.
+
+## Rules
+
+- Do not make broad refactors while debugging.
+- Do not weaken tests unless the test is demonstrably wrong.
+- Do not delete failing tests to pass.
+- Do not ignore type errors.
+
+## Report
+
+```txt
+Failing command:
+Failure class:
+Root cause:
+Fix:
+Re-run result:
+Remaining risk:
+```

package/templates/skills/agents/omk-troubleshooting/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: omk-troubleshooting
+description: Systematic troubleshooting for build failures, test failures, environment issues, dependency conflicts, and agent workflow blockers.
+---
+
+## Steps
+
+1. Capture exact error message and stack trace.
+2. Identify the smallest reproducible scope.
+3. Check environment, versions, and dependencies.
+4. Search for known issues in project memory and docs.
+5. Apply minimal fix.
+6. Verify fix with the failing command.
+7. Document the root cause in `.omk/memory/risks.md` if persistent.

package/templates/skills/agents/omk-typescript-strict/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: omk-typescript-strict
+description: TypeScript strict-mode development standards for Next.js, NestJS, Node.js, React, and full-stack projects.
+---
+
+## TypeScript Rules
+
+- Assume `strict: true`.
+- Do not use `any` unless explicitly justified.
+- Prefer `unknown` with narrowing over `any`.
+- Define return types for exported functions.
+- Avoid type assertions unless unavoidable.
+- Prefer discriminated unions for state machines.
+- Keep DTO, domain, persistence, and API response types separate.
+- Do not weaken `tsconfig` to pass builds.
+
+## Next.js
+
+- Keep server/client boundaries explicit.
+- Do not use browser APIs in server components.
+- Validate route params and search params.
+- Avoid unnecessary client components.
+
+## NestJS
+
+- Keep controller thin.
+- Put business logic in services.
+- Validate DTOs.
+- Avoid leaking ORM entities as API responses.
+
+## Output When Reviewing
+
+```txt
+Type issues:
+Boundary issues:
+Unsafe casts:
+Suggested fix:
+```

package/templates/skills/agents/omk-worktree-team/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: omk-worktree-team
+description: Git worktree based multi-agent team workflow for isolated parallel coding, review, QA, and integration.
+---
+
+## Worktree Team Policy
+
+Use this skill when a task can be split across packages, modules, routes, services, components, tests, or documentation.
+
+## Rules
+
+- Each worker edits only its assigned git worktree.
+- Never let two workers modify the same file unless explicitly coordinated.
+- Each worker must report:
+  - assigned task
+  - changed files
+  - commands run
+  - test result
+  - unresolved risks
+- Integrator merges patches only after worker self-test and reviewer pass.
+- Resolve conflicts in a dedicated integration step.
+
+## Worker Report
+
+```txt
+Worker:
+Branch:
+Task:
+Changed files:
+Commands:
+Result:
+Known issues:
+Ready for review: yes/no
+```
+
+## Merge Rule
+
+Merge only if:
+
+1. worker self-test passed
+2. diff review passed
+3. no protected file violation
+4. no secret leakage
+5. integration test plan exists

package/templates/skills/agents/react-doctor/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: react-doctor
+description: React, Next.js, Vite, and React Native diagnostics workflow adapted from millionco/react-doctor for OMK. Use for React health checks, component/effect bugs, performance regressions, accessibility issues, dead code, and agent-generated React review.
+---
+
+# react-doctor
+
+Source basis: millionco/react-doctor at commit 8556b31d8e4e165f791db0aa60a6b038b18ec777. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts or code.
+
+## Use when
+
+- Reviewing or debugging React, Next.js, Vite, Expo, or React Native code.
+- A change touches hooks, effects, memoization, render paths, accessibility, security, or generated UI code.
+- The user asks for a React health score or agent-written React audit.
+
+## OMK workflow
+
+1. Detect framework, package manager, React version, app routes, and existing lint/test/build scripts.
+2. Read the smallest relevant component, hook, route, and test set. Check loading, error, empty, and responsive states.
+3. Run existing local gates first: lint, typecheck, targeted tests, and build when available.
+4. If external package execution is acceptable for the task, run React Doctor from the project root and capture its score/findings. Prefer diff mode for PR review.
+5. Fix high-signal issues before suppressing rules. Use the narrowest config override when a warning is intentional.
+6. Re-run the same diagnostics and include before/after score or finding count when available.
+
+## Optional commands
+
+```bash
+npx -y react-doctor@latest .
+npx -y react-doctor@latest --fail-on warning
+```
+
+## Output contract
+
+Return:
+
+- framework and package manager detected
+- gates run and React Doctor result if run
+- findings fixed vs intentionally deferred
+- accessibility/performance/security notes
+- remaining risks
+
+## Guardrails
+
+- Do not add broad ignores such as whole generated folders unless justified.
+- Do not replace existing lint/test policy with React Doctor; use it as an extra signal.
+- Do not run network/package-install commands in restricted environments without explicit user approval.

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

@@ -0,0 +1,40 @@
+---
+name: agentmemory
+description: Persistent memory, recall, session replay, and memory-governance workflow adapted from rohitg00/agentmemory for OMK. Use when setting up agent memory, deciding what to remember, importing/replaying sessions, reducing repeated context, or auditing memory safety.
+---
+
+# agentmemory
+
+Source basis: rohitg00/agentmemory at commit 25dddc43798c09f8e1dc5179eb48e434a5c89ab2. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts or code.
+
+## Use when
+
+- A task depends on prior decisions, run history, project facts, or repeated architecture context.
+- You need to design or review MCP/hook-based persistent memory for coding agents.
+- You need replayable evidence for prompts, tool calls, diffs, checks, or completion gates.
+- You are deciding what is safe to store in project memory.
+
+## OMK workflow
+
+1. Inventory memory surfaces: `.omk/memory`, `.omk/runs`, `.kimi/skills`, `.agents/skills`, MCP config, and available graph-memory tools.
+2. Classify candidate memories as project fact, decision, command, risk, user preference, or run-scoped note.
+3. Store only stable, useful, non-secret facts. Include confidence, scope, source, and expiry/refresh trigger when the fact may drift.
+4. Prefer OMK project graph memory when available. Treat external memory servers as optional integrations that must pass local health checks before use.
+5. For replay/evidence tasks, preserve raw prompt, generated diff, verification JSON/logs, screenshots, and known limitations in one artifact bundle.
+6. Before finalizing, verify memory updates did not include credentials, private data, or unvalidated claims.
+
+## Output contract
+
+Return:
+
+- memory sources consulted
+- memories added or skipped
+- verification artifacts
+- replay/proof paths
+- limitations and refresh triggers
+
+## Guardrails
+
+- Never write secrets, tokens, private keys, cookies, or raw `.env` values into memory.
+- Do not let memory override current source files, official docs, or live command results.
+- Do not install or start external memory services unless the user asked for that operational change.

package/templates/skills/kimi/andrej-karpathy-skills/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: andrej-karpathy-skills
+description: Minimal, goal-driven, surgical coding workflow adapted from forrestchang/andrej-karpathy-skills for OMK. Use for coding, refactoring, debugging, and review tasks where assumptions, overengineering, or broad edits could cause regressions.
+---
+
+# andrej-karpathy-skills
+
+Source basis: forrestchang/andrej-karpathy-skills at commit 2c606141936f1eeef17fa3043a72095b4765b9c2. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts or code.
+
+## Use when
+
+- Any non-trivial code change needs tight scope and proof.
+- The request is ambiguous enough that silent assumptions could be wrong.
+- A refactor or bugfix risks drive-by edits.
+- You need to turn an imperative request into verifiable success criteria.
+
+## OMK workflow
+
+1. State assumptions and tradeoffs only when they affect the implementation path. Ask if ambiguity blocks safe progress.
+2. Define success as observable checks: tests, typecheck, lint, build, screenshots, replay, or exact output.
+3. Make the smallest change that satisfies the goal. Avoid speculative abstractions and features not requested.
+4. Touch only files directly tied to the request. Preserve existing style and avoid unrelated cleanup.
+5. Remove only dead code introduced by your own change unless the user asked for broader cleanup.
+6. Verify, inspect the diff, and report remaining risks honestly.
+
+## Output contract
+
+Return:
+
+- assumptions that mattered
+- success criteria and checks
+- changed files
+- commands run
+- pass/fail status
+- risks or blocked items
+
+## Guardrails
+
+- Do not broaden scope to improve adjacent code.
+- Do not hide confusion behind a confident implementation.
+- Do not claim completion without evidence.

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

@@ -0,0 +1,54 @@
+---
+name: awesome-design-md
+description: Use VoltAgent awesome-design-md as a curated DESIGN.md template catalog for OMK, Kimi, and Open Design UI/prototype work.
+---
+
+# /awesome-design-md
+
+Use the VoltAgent `awesome-design-md` catalog when a UI, prototype, or visual task needs a named reference style.
+
+## Commands
+
+```bash
+omk design list
+omk design search <keyword>
+omk design apply <name>
+omk design lint DESIGN.md
+omk design diff DESIGN.md DESIGN.next.md
+```
+
+## Workflow
+
+1. Read the local `DESIGN.md` first when it exists.
+2. If the user requests a style reference, search the catalog:
+
+   ```bash
+   omk design search vercel
+   ```
+
+3. Apply only when replacing the project design source is intended:
+
+   ```bash
+   omk design apply vercel
+   ```
+
+4. For exploratory work, copy the selected template into `DESIGN.next.md`, compare it, then adapt.
+5. In Open Design, choose the **Awesome DESIGN.md Web UI Reference (OMK)** prompt template, set the catalog name, and run it with the OMK CLI agent.
+
+## Guardrails
+
+- Treat catalog entries as design-system references, not brand-cloning permission.
+- Preserve product-specific content, accessibility, responsive behavior, and local tokens.
+- Do not paste secrets, credentials, private screenshots, or private customer data into prompts.
+- Cite the selected catalog name and any local files inspected in the final result.
+
+## Output
+
+```txt
+Catalog source:
+Selected template:
+Local DESIGN.md action:
+Open Design template:
+Commands run:
+Risk:
+```

package/templates/skills/kimi/claude-for-legal/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: claude-for-legal
+description: Legal workflow drafting, triage, review, research planning, legal operations, law-student or clinic support, and legal AI governance adapted from Anthropic claude-for-legal. Use for commercial, privacy, product, corporate, employment, regulatory, AI governance, IP, litigation, legal-clinic, and law-student tasks. Draft-only; attorney review and current source verification required.
+---
+
+# Claude for Legal
+
+Use this skill when the user asks for legal workflow help: contract review, legal triage, policy/regulatory analysis, legal research planning, compliance checklists, litigation support, legal ops trackers, law-student practice, or clinic-style intake/drafting.
+
+Source basis: Anthropic `claude-for-legal` at `anthropics/claude-for-legal` commit `9cecd91b0f26f732d18315afc3c9bb5ff99e0fbb`, Apache-2.0. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts.
+
+## Non-negotiables
+
+- Treat outputs as AI-assisted drafts for qualified attorney review, not legal advice or legal conclusions.
+- Do not file, send, sign, threaten, accept, reject, waive rights, or communicate externally without an explicit user gate and attorney-review note.
+- Identify jurisdiction, governing law, audience, role of the user, deadline, and source set. If unknown and material, ask; if proceeding, state assumptions.
+- For current law, citations, statutes, regulations, court rules, agency guidance, or case law, verify with authoritative/current sources before relying. If not verified, label citations and conclusions as needing verification.
+- Never invent citations, docket facts, quotes, party facts, deadlines, or regulatory text.
+- Preserve privilege/confidentiality boundaries; avoid putting sensitive facts into external tools unless user has configured and approved them.
+- If user is not a lawyer, structure output as an attorney-facing brief with plain-English risk explanations and clear questions for counsel.
+
+## Core workflow
+
+1. **Classify lane**: choose practice area and workflow. Load `references/workflow-catalog.md` when mapping is not obvious.
+2. **Intake**: collect only missing material facts: role, jurisdiction, document/source corpus, transaction/matter context, risk appetite, deadline, intended audience, and requested output.
+3. **Source preflight**: record what sources were actually checked. Prefer official/primary sources; use legal research connectors/MCPs only if configured. Otherwise browse authoritative sources or mark `[verify]`.
+4. **Analyze conservatively**: separate facts, assumptions, legal issues, risk level, source-backed points, open questions, and attorney decisions.
+5. **Gate consequential action**: give draft language/checklist/memo, then list what must be reviewed before use.
+
+## Default output skeleton
+
+```md
+# AI-assisted legal workflow draft — attorney review required
+
+- Role/audience:
+- Jurisdiction/governing law:
+- Scope:
+- Sources checked:
+- Verification gaps:
+- Assumptions:
+
+## Executive summary
+## Key issues / risk flags
+## Analysis
+## Draft / checklist / table
+## Open questions for counsel
+## Pre-use review gate
+```
+
+## Risk language
+
+Use cautious labels: `Blocking`, `High`, `Medium`, `Low`, `Information needed`. Explain each label in business/plain-English terms. Avoid saying a position is “legal,” “compliant,” “privileged,” or “safe” unless verified and still framed for attorney judgment.
+
+## Citation rules
+
+- Attach source/provenance to every legal authority or factual extraction from documents.
+- Distinguish primary authority, secondary source, model reasoning, and user-provided facts.
+- If a citation comes from model knowledge or an unverified web result, tag it `[verify]` and place it in verification gaps.
+- Quote only short excerpts needed for analysis; prefer paraphrase and pinpoint citations.
+
+## Practice profile pattern
+
+When a matter will continue across turns, create or update a concise practice/matter profile in the working docs, not in global memory unless explicitly asked. Include: client/company context, role, jurisdiction footprint, escalation contacts, risk posture, house style, source locations, and current open questions. Do not store secrets.

package/templates/skills/kimi/claude-for-legal/references/workflow-catalog.md

@@ -0,0 +1,38 @@
+# Claude for Legal workflow catalog
+
+Use this catalog to map a legal request to a conservative workflow. Source basis: Anthropic `claude-for-legal` repository, compacted for OMK use.
+
+## Practice areas
+
+| Lane | Use for | Typical outputs |
+| --- | --- | --- |
+| Commercial legal | Vendor/customer agreements, NDAs, SaaS terms, amendments, renewal/cancel-by review, escalation routing | Issue list, fallback positions, redline memo, renewal register, stakeholder summary |
+| Privacy legal | DSARs, DPAs, PIAs/DPIAs, processing triage, privacy policy drift, privacy regulatory gaps | DSAR timeline, DPA issue matrix, PIA draft, triage decision, policy-gap tracker |
+| Product legal | Launch review, marketing claims, quick product-risk questions, feature risk assessment | Launch risk memo, claims substantiation table, go/no-go gate, counsel questions |
+| Corporate legal | M&A diligence, board consents/minutes, disclosure schedules, closing checklists, entity compliance, integration | Diligence table, material-contract schedule, consent draft, closing tracker, entity register |
+| Employment legal | Hiring, terminations, worker classification, wage/hour, leave tracking, investigations, policies, international expansion | Jurisdiction checklist, risk flags, investigation plan/memo, policy draft, counsel handoff |
+| Regulatory legal | New rules/guidance, feed monitoring, policy diff, comments, gap tracking | Regulatory digest, policy-diff memo, comment tracker, gap remediation plan |
+| AI governance legal | AI use-case triage, AI impact assessment, vendor AI terms, AI inventory/policy drift | Use-case tiering, AIA draft, vendor risk table, inventory update, governance gaps |
+| IP legal | Trademark clearance, cease-and-desist, DMCA, OSS review, FTO triage, infringement triage, IP clauses, portfolio | Knockout screen, takedown/counter-notice draft, OSS obligations table, claim/portfolio tracker |
+| Litigation legal | Claim charts, chronologies, demand letters, subpoenas, deposition prep, privilege logs, holds, matter intake/status | Cited chronology, demand draft, subpoena plan, depo outline, privilege log flags, hold checklist |
+| Legal clinic | Client intake, deadline tracking, memos, plain-language client letters, semester handoff, supervised review | Intake memo, deadline sheet, research roadmap, client letter, handoff memo |
+| Law student | Case briefs, outlines, IRAC practice, Socratic drill, cold-call prep, study plans, bar prep | Study plan, practice questions, feedback rubric, case brief, outline scaffold |
+| Legal builder / skill QA | Evaluate/install legal skills or legal workflow templates | Security/quality review, allowlist decision, installation plan, update notes |
+
+## Intake checklist by lane
+
+- **Contracts/commercial**: side represented, contract type, counterparty, business goal, playbook positions, must-have terms, fallback authority, governing law, renewal/cancel deadline.
+- **Privacy/AI/product/regulatory**: product/process facts, data categories, jurisdictions, user groups, vendors, policy commitments, regulator/source set, launch/deadline date.
+- **Corporate/M&A**: transaction stage, buyer/seller side, materiality threshold, data-room scope, entity jurisdictions, closing conditions, board/stockholder approvals.
+- **Employment**: worker location, employer entity, employee/contractor status, protected leave/complaint facts, policy history, timing, decision-maker, local counsel involvement.
+- **IP**: mark/work/invention details, goods/services, jurisdictions, dates of first use/publication, license/dependency context, accused product/content, enforcement posture.
+- **Litigation**: forum, parties, claims/defenses, deadlines, procedural posture, evidence corpus, privilege status, settlement posture, outside counsel role.
+- **Clinic/student**: supervision level, course/clinic rules, jurisdiction, client-facing vs internal, grading/learning objective, sources allowed.
+
+## Deliverable patterns
+
+- **Triage memo**: facts, assumptions, issue list, risk labels, source-backed analysis, missing facts, recommended counsel decision.
+- **Review table**: clause/document/source, issue, risk, rationale, proposed revision or action, owner, deadline, citation.
+- **Research roadmap**: question presented, governing jurisdiction, primary sources to pull, search terms, verification plan, expected deliverable.
+- **Draft communication**: purpose, audience, tone, legal caveats, bracketed attorney-review placeholders, send gate.
+- **Tracker**: item, source, date found, owner, due date, status, risk, evidence link, next action.