open-multi-agent-kit 0.78.7 → 0.79.1

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

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

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

@@ -1,52 +0,0 @@
----
-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:
-```

package/templates/skills/kimi/omk-flow-bugfix/SKILL.md

@@ -1,20 +0,0 @@
----
-name: omk-flow-bugfix
-description: Bugfix flow from reproduction to root cause, minimal fix, regression test, and verification.
-type: flow
----
-
-```mermaid
-flowchart TD
-BEGIN([BEGIN]) --> A[Collect bug report, expected behavior, actual behavior, and reproduction info]
-A --> B[Find relevant files, tests, logs, and recent changes]
-B --> C[Reproduce or reason about the failure with evidence]
-C --> D[Identify root cause and minimal fix]
-D --> E[Implement minimal fix]
-E --> F[Add or update regression test when possible]
-F --> G[Run targeted test and relevant quality gates]
-G --> H{Bug fixed and no regression?}
-H -->|No| C
-H -->|Yes| I[Write final bugfix report]
-I --> END([END])
-```

package/templates/skills/kimi/omk-flow-design-to-code/SKILL.md

@@ -1,23 +0,0 @@
----
-name: omk-flow-design-to-code
-description: Convert DESIGN.md, screenshots, mockups, or Stitch outputs into reviewed frontend implementation.
-type: flow
----
-
-```mermaid
-flowchart TD
-BEGIN([BEGIN]) --> A[Read AGENTS.md and DESIGN.md]
-A --> B[Inspect existing frontend structure and component system]
-B --> C[Review screenshot, mockup, Stitch output, or user visual request]
-C --> D[Plan components, tokens, states, and responsive behavior]
-D --> E[Implement minimal frontend changes]
-E --> F[Run lint, typecheck, tests, and build if available]
-F --> G{Do checks pass?}
-G -->|No| H[Debug with minimal changes]
-H --> F
-G -->|Yes| I[Review visual consistency, accessibility, and diff]
-I --> J{Blocking issue?}
-J -->|Yes| E
-J -->|No| K[Write final report]
-K --> END([END])
-```

package/templates/skills/kimi/omk-flow-feature-dev/SKILL.md

@@ -1,24 +0,0 @@
----
-name: omk-flow-feature-dev
-description: End-to-end feature development flow with exploration, plan, implementation, test, review, and final report.
-type: flow
----
-
-```mermaid
-flowchart TD
-BEGIN([BEGIN]) --> A[Clarify goal, constraints, acceptance criteria]
-A --> B[Explore relevant repository files and summarize architecture]
-B --> C[Write implementation plan with affected files and quality gates]
-C --> D{Is the plan specific and testable?}
-D -->|No| C
-D -->|Yes| E[Implement the smallest complete change]
-E --> F[Run lint, typecheck, tests, and build if available]
-F --> G{Did quality gates pass?}
-G -->|No| H[Debug failures with minimal changes]
-H --> F
-G -->|Yes| I[Review final diff for correctness, security, and regressions]
-I --> J{Any blocking issue?}
-J -->|Yes| E
-J -->|No| K[Write final report with changed files and commands]
-K --> END([END])
-```

package/templates/skills/kimi/omk-flow-pr-review/SKILL.md

@@ -1,17 +0,0 @@
----
-name: omk-flow-pr-review
-description: Pull request review flow for current diff, risk classification, test gap analysis, and merge recommendation.
-type: flow
----
-
-```mermaid
-flowchart TD
-BEGIN([BEGIN]) --> A[Inspect git status and current diff]
-A --> B[Map changed files to features and risk areas]
-B --> C[Review correctness, security, types, tests, and regressions]
-C --> D{Any blocking issue?}
-D -->|Yes| E[List blocking issues with exact files and suggested fixes]
-D -->|No| F[Generate pass review with remaining risks]
-E --> END([END])
-F --> END([END])
-```

package/templates/skills/kimi/omk-flow-refactor/SKILL.md

@@ -1,21 +0,0 @@
----
-name: omk-flow-refactor
-description: Safe refactor flow with behavior preservation, incremental edits, tests, and regression review.
-type: flow
----
-
-```mermaid
-flowchart TD
-BEGIN([BEGIN]) --> A[Define refactor goal and behavior that must not change]
-A --> B[Find affected files, call sites, tests, and public APIs]
-B --> C[Write incremental refactor plan]
-C --> D[Apply one small refactor step]
-D --> E[Run targeted checks]
-E --> F{Checks pass?}
-F -->|No| G[Revert or fix the smallest failed step]
-G --> E
-F -->|Yes| H{More steps?}
-H -->|Yes| D
-H -->|No| I[Run final quality gates and review diff]
-I --> END([END])
-```

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

@@ -1,20 +0,0 @@
----
-name: omk-flow-release
-description: Safe release flow with version bump, changelog update, quality gates, tag, and deployment verification.
-type: flow
----
-
-```mermaid
-flowchart TD
-BEGIN([BEGIN]) --> A[Determine version bump from diff and commits]
-A --> B[Update version in package files]
-B --> C[Update CHANGELOG.md]
-C --> D[Run full quality gates]
-D --> E{All gates pass?}
-E -->|No| F[Fix failures or abort]
-F --> D
-E -->|Yes| G[Create git tag]
-G --> H[Build and deploy if configured]
-H --> I[Verify deployment health]
-I --> END([END])
-```

package/templates/skills/kimi/omk-flow-team-run/SKILL.md

@@ -1,24 +0,0 @@
----
-name: omk-flow-team-run
-description: Run a multi-agent Kimi worktree team with task split, isolated implementation, QA, review, and integration.
-type: flow
----
-
-```mermaid
-flowchart TD
-BEGIN([BEGIN]) --> A[Clarify goal and acceptance criteria]
-A --> B[Explore repository and define task partitions]
-B --> C[Create worker plan with non-overlapping file ownership]
-C --> D[Spawn isolated worktree workers]
-D --> E[Workers implement and self-test]
-E --> F[Reviewer checks worker diffs]
-F --> G{Any worker failed?}
-G -->|Yes| H[Return failed worker to implementation]
-H --> E
-G -->|No| I[Integrator merges patches]
-I --> J[Run final regression gates]
-J --> K{Final checks pass?}
-K -->|No| H
-K -->|Yes| L[Write final report and merge summary]
-L --> END([END])
-```

package/templates/skills/kimi/omk-frontend-implementation/SKILL.md

@@ -1,13 +0,0 @@
----
-name: omk-frontend-implementation
-description: Implement frontend UI components from DESIGN.md, mockups, or screenshots with strict adherence to existing component system and accessibility.
----
-
-## Rules
-
-1. Read DESIGN.md before writing UI code.
-2. Reuse existing components and tokens.
-3. Do not invent arbitrary colors or spacing.
-4. Validate responsive behavior.
-5. Check accessibility (a11y) basics.
-6. Run lint, typecheck, and build before claiming done.

package/templates/skills/kimi/omk-frontend-ui-review/SKILL.md

@@ -1,29 +0,0 @@
----
-name: omk-frontend-ui-review
-description: Frontend UI review for React, Next.js, Tailwind, accessibility, responsive layout, state handling, and component architecture.
----
-
-## Frontend Review
-
-Check:
-
-- component boundaries
-- server/client boundary
-- accessibility
-- responsive layout
-- loading/error/empty states
-- form validation
-- state ownership
-- unnecessary re-renders
-- Tailwind consistency
-- visual regression risk
-
-## Output
-
-```txt
-UI issues:
-Accessibility issues:
-State issues:
-Responsive issues:
-Suggested fixes:
-```

package/templates/skills/kimi/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/kimi/omk-global-rules/SKILL.md

@@ -1,31 +0,0 @@
----
-name: omk-global-rules
-description: Global open-multi-agent-kit operating rules: avoid repeated instructions, use todos, subagents, relevant skills, MCP tools, quality gates, and concise factual reports.
----
-
-## Rules
-
-Apply these rules silently.
-
-1. Do not make the user repeat common instructions.
-2. Use todos for multi-step work.
-3. Use subagents for non-trivial tasks.
-4. Use relevant skills before implementation.
-5. Use MCP tools when configured and useful.
-6. Treat project-local graph memory as the default project/session source of truth; use memory tools when available and never store secrets.
-7. Prefer Kimi Okabe + SendDMail checkpoints for risky context transitions and rollback recovery.
-8. Prefer plan-first execution.
-9. Prefer small diffs.
-10. Verify before completion.
-11. Report exact changed files and commands.
-12. Never overclaim test results.
-
-## Final Response
-
-```txt
-Changed:
-Files:
-Commands:
-Result:
-Risk:
-```

package/templates/skills/kimi/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/kimi/omk-kimi-runtime/SKILL.md

@@ -1,46 +0,0 @@
----
-name: omk-kimi-runtime
-description: Kimi K2.6 runtime policy for thinking mode, no-thinking research mode, tool use, context budget, and long-horizon coding tasks.
----
-
-## Runtime Policy
-
-Use this skill when running OMK workflows on Kimi K2.6.
-
-## Mode Selection
-
-- Use thinking mode for architecture, coding, debugging, review, planning, and multi-step tool work.
-- Use no-thinking mode for fast summarization, commit messages, simple classification, and web-search-heavy research.
-- Do not expose temperature/top_p tuning as user-facing options.
-- Prefer structured task execution over one-shot answers.
-
-## Tool Use
-
-- Keep tool calls scoped to the current task.
-- Before writing files, inspect nearby code and project conventions.
-- For web-heavy work, use a no-thinking research profile when available.
-- For multimodal UI/debug work, inspect screenshots, traces, or video before proposing code.
-
-## Okabe + D-Mail
-
-- Generated OMK agents should inherit the Okabe-compatible base, not plain `default`, so `SendDMail` is available while custom `--agent-file` configs remain supported.
-- Use `SendDMail` for checkpoint rollback scenarios: risky refactors, dependency migrations, context compaction, or long-running work where a future recovery note prevents lost state.
-- Treat D-Mail as context insurance, not a substitute for tests, git diff review, or project-local graph durable memory.
-
-## Context Policy
-
-- Never load the whole repository just because Kimi supports long context.
-- First build a file map.
-- Then read only relevant files.
-- Store stable facts through project-local graph memory; `.omk/memory/` is only a local mirror/cache.
-- Use Okabe/D-Mail checkpoints before risky context transitions.
-- Compact or summarize before context pressure becomes high.
-
-## Completion Rule
-
-A task is not complete until the required quality gates pass:
-1. lint
-2. typecheck
-3. tests
-4. build, if available
-5. diff review

package/templates/skills/kimi/omk-multimodal-ui-review/SKILL.md

@@ -1,26 +0,0 @@
----
-name: omk-multimodal-ui-review
-description: Review UI from screenshots, mockups, browser captures, traces, or videos before proposing frontend code changes.
----
-
-## Multimodal UI Review
-
-Use this when the task includes screenshots, mockups, browser captures, Playwright traces, or videos.
-
-## Steps
-
-1. Inspect the visual input first.
-2. Identify layout, spacing, typography, color, component hierarchy, and interaction state.
-3. Compare against existing implementation if available.
-4. Propose minimal code changes.
-5. Verify responsive and accessibility impact.
-
-## Output
-
-```txt
-Visual observations:
-Likely code locations:
-Mismatch:
-Fix plan:
-Verification:
-```

package/templates/skills/kimi/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/kimi/omk-project-rules/SKILL.md

@@ -1,21 +0,0 @@
----
-name: omk-project-rules
-description: Project-level operating rules extracted from AGENTS.md, DESIGN.md, and .omk/memory/. Apply silently before implementation.
----
-
-## Rules
-
-1. Read `AGENTS.md` before planning or editing.
-2. Read `.kimi/AGENTS.md` if present for Kimi-specific rules.
-3. Read `DESIGN.md` before any UI/frontend/visual work.
-4. Use `SetTodoList` for multi-step tasks.
-5. Use `Agent` subagents for non-trivial work.
-6. Prefer small, reviewable diffs.
-7. Run quality gates before claiming completion.
-8. Do not repeat boilerplate phrases to the user.
-9. Do not expose or request temperature/top_p tuning.
-10. Store stable facts in `.omk/memory/`.
-
-## When to Use
-
-Use at the start of every task to confirm the project conventions before editing.

package/templates/skills/kimi/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/kimi/omk-quality-gate/SKILL.md

@@ -1,36 +0,0 @@
----
-name: omk-quality-gate
-description: Run lint, typecheck, test, and build gates before completing any implementation task.
----
-
-## Quality Gate Policy
-
-Before saying a task is complete, run available checks.
-
-## Commands
-
-Use actual project scripts when different from the defaults:
-
-```bash
-pnpm lint
-pnpm typecheck
-pnpm test
-pnpm build
-```
-
-## Rules
-
-1. Do not claim tests passed unless they were actually run.
-2. If commands are unavailable, report that clearly.
-3. Include results in the final report:
-   - Changed files
-   - Commands run
-   - Passed / Failed / Not run
-   - Reason not run
-   - Remaining risk
-4. Do not silence errors without justification.
-5. Do not delete tests to pass.
-
-## When to Use
-
-Use at the end of every implementation task before final response.

package/templates/skills/kimi/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:
-```