open-multi-agent-kit 0.78.8 → 0.79.1

package/templates/skills/agents/omk-git-commit-pr/SKILL.md

@@ -1,45 +0,0 @@
----
-name: omk-git-commit-pr
-description: Git commit and pull request summary workflow using Conventional Commits and evidence from the current diff.
----
-
-## Commit Policy
-
-Use Conventional Commits:
-
-```txt
-feat(scope): summary
-fix(scope): summary
-refactor(scope): summary
-test(scope): summary
-docs(scope): summary
-chore(scope): summary
-```
-
-## Steps
-
-1. Inspect current diff.
-2. Group changes by purpose.
-3. Exclude unrelated changes.
-4. Generate commit message.
-5. Generate PR summary if requested.
-
-## PR Body
-
-```md
-## What changed
-
-## Why
-
-## Test result
-
-## Risk
-
-## Notes
-```
-
-## Rules
-
-* Do not claim tests passed unless they were run.
-* Mention commands that failed or were not run.
-* Keep summary factual.

package/templates/skills/agents/omk-industrial-control-loop/SKILL.md

@@ -1,33 +0,0 @@
----
-name: omk-industrial-control-loop
-description: Industrial automation and feedback-control inspired review for AI workflows, agents, orchestration loops, state machines, and reliability.
----
-
-## Control-loop Review
-
-Use this for agent orchestration, workflow automation, state machines, retry loops, feedback loops, and industrial automation inspired systems.
-
-## Check
-
-- controller goal
-- observed signal
-- actuator/tool action
-- feedback delay
-- saturation
-- oscillation
-- runaway retry
-- missing stop condition
-- unsafe fallback
-- state transition ambiguity
-- human override path
-
-## Output
-
-```txt
-Loop:
-Signal:
-Actuator:
-Failure mode:
-Stop condition:
-Recommended fix:
-```

package/templates/skills/agents/omk-plan-first/SKILL.md

@@ -1,39 +0,0 @@
----
-name: omk-plan-first
-description: Read-only planning workflow before implementation. Use for architecture, refactor, feature development, risky edits, and ambiguous tasks.
----
-
-## Plan-first Workflow
-
-Use this when the task is non-trivial, risky, multi-file, architectural, or ambiguous.
-
-## Steps
-
-1. Restate the goal in concrete terms.
-2. Identify unknowns.
-3. Explore only relevant files.
-4. List affected modules.
-5. Propose implementation steps.
-6. Define quality gates.
-7. Define rollback strategy.
-8. Ask at most one blocking question only when impossible to proceed safely.
-
-## Rules
-
-- Do not edit files during planning.
-- Do not run destructive commands.
-- Prefer narrow, testable steps.
-- Include explicit acceptance criteria.
-
-## Plan Format
-
-```txt
-Goal:
-Assumptions:
-Files to inspect:
-Files likely to change:
-Implementation steps:
-Quality gates:
-Risks:
-Rollback:
-```

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.