open-multi-agent-kit 0.80.2 → 0.80.3

package/templates/skills/agents/omk-project-rules/SKILL.md

@@ -1,46 +0,0 @@
----
-name: omk-project-rules
-description: Discover and follow project rules from AGENTS.md, package files, lint configs, test configs, framework conventions, and existing code style.
----
-
-## Project Rule Discovery
-
-Before changing code:
-
-1. Read `AGENTS.md` if present.
-2. Read `DESIGN.md` for UI/frontend tasks if present.
-3. Inspect package manager files:
-   - `package.json`
-   - `pnpm-lock.yaml`
-   - `yarn.lock`
-   - `package-lock.json`
-   - `pyproject.toml`
-   - `requirements.txt`
-   - `uv.lock`
-3. Inspect framework/config files:
-   - `tsconfig.json`
-   - `next.config.*`
-   - `nest-cli.json`
-   - `eslint.config.*`
-   - `.eslintrc*`
-   - `ruff.toml`
-   - `pytest.ini`
-4. Derive commands:
-   - lint
-   - typecheck
-   - test
-   - build
-5. Do not invent conventions when existing code shows a pattern.
-
-## Output
-
-When asked to summarize project rules, produce:
-
-```txt
-Stack:
-Commands:
-Style:
-Testing:
-Risk:
-Missing info:
-```

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

@@ -1,33 +0,0 @@
----
-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

@@ -1,54 +0,0 @@
----
-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

@@ -1,33 +0,0 @@
----
-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

@@ -1,30 +0,0 @@
----
-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

@@ -1,23 +0,0 @@
----
-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

@@ -1,49 +0,0 @@
----
-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

@@ -1,43 +0,0 @@
----
-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

@@ -1,14 +0,0 @@
----
-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

@@ -1,38 +0,0 @@
----
-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

@@ -1,44 +0,0 @@
----
-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

@@ -1,46 +0,0 @@
----
-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

@@ -1,40 +0,0 @@
----
-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

@@ -1,41 +0,0 @@
----
-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

@@ -1,54 +0,0 @@
----
-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

@@ -1,63 +0,0 @@
----
-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.