open-multi-agent-kit 0.80.2 → 0.80.4

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:
-```

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

@@ -1,27 +0,0 @@
----
-name: omk-task-router
-description: Route tasks between Kimi native subagents, external worktree workers, print workers, and root coordinator for optimal parallel execution.
----
-
-## Routing
-
-Use native subagents for:
-
-- exploration
-- planning
-- small reviews
-- isolated analysis
-
-Use worktree workers for:
-
-- code edits
-- parallel implementation
-- risky refactors
-- large test generation
-- conflicting module work
-
-Use print workers for:
-
-- summaries
-- commit messages
-- short non-interactive checks