open-multi-agent-kit 0.80.2 → 0.80.3

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

@@ -1,56 +0,0 @@
----
-name: open-design
-description: Launch nexu-io Open Design on localhost so OMK/Kimi can generate prototypes, decks, and design artifacts in a local web UI.
----
-
-# /open-design
-
-Open the local Open Design workspace for OMK/Kimi-assisted design work.
-
-## Command
-
-Run:
-
-```bash
-omk design open-design --open
-```
-
-This clones or reuses `nexu-io/open-design` under `.omk/open-design`, installs the pinned pnpm workspace when needed, starts the Open Design daemon + web app, and prints the localhost URL.
-OMK also registers an **Awesome DESIGN.md Web UI Reference (OMK)** prompt template so Open Design prompts can use VoltAgent `awesome-design-md` catalog names such as `vercel`, `linear.app`, `stripe`, or `voltagent`.
-
-## Defaults
-
-- Web UI: `http://localhost:5175`
-- Daemon: `http://localhost:7457`
-- Checkout: `.omk/open-design`
-- Agent: choose **OMK CLI** in the UI; it runs Kimi through the local OMK bridge.
-- Tested Open Design ref: `3f7a05e7462f097bf38b7cbac0d4a4593deecd80`; use `--ref` or `OMK_OPEN_DESIGN_REF` for reproducible checkouts.
-- Prompt template: choose **Awesome DESIGN.md Web UI Reference (OMK)** when the task should borrow a cataloged `DESIGN.md` style.
-
-## Options
-
-```bash
-omk design open-design --web-port 5175 --daemon-port 7457
-omk design open-design --dir .omk/open-design --update
-omk design open-design --ref 3f7a05e7462f097bf38b7cbac0d4a4593deecd80
-omk design open-design --doctor --json
-omk design open-design --foreground
-omk design open-design --print-only
-omk open-design --print-only
-```
-
-## Rules
-
-- Keep secrets out of prompts, logs, and generated artifacts.
-- The bridge filters secret-like env vars by default. Do not pass OAuth or API keys unless `OMK_OPEN_DESIGN_TRUST_SECRET_ENV=1` is intentionally set for a trusted local run.
-- Treat `awesome-design-md` entries as references; adapt the visual system instead of cloning a trademarked site.
-- Local `DESIGN.md` tokens and product rules win over Open Design catalog style references.
-- Image/screenshot inputs are forwarded as local `--image` paths; Kimi should use `ReadMediaFile` when available and fall back to advisory notes when not.
-- Timeout success is limited to artifacts under `.omk/open-design-artifacts/<run-id>/` or an explicit `--artifact-dir`.
-- Use Node.js 24.x; OMK auto-detects NVM Node 24 when available, or set `OMK_OPEN_DESIGN_NODE24=/absolute/path/to/node`.
-- Run `omk design open-design --doctor --json` before troubleshooting; it checks Node 24, Corepack/pnpm, git, port conflicts, checkout compatibility, OMK_BIN, app-config, prompt template, and smoke path without cloning/installing/starting.
-- On WSL, `--open` should open the Windows browser via `wslview` or `cmd.exe /c start`; if that is blocked, open the printed URL manually.
-- If localhost does not open, report the printed URL plus:
-  - `cd .omk/open-design && corepack pnpm tools-dev status`
-  - `cd .omk/open-design && corepack pnpm tools-dev check web`
-  - `cd .omk/open-design && corepack pnpm tools-dev logs`

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

@@ -1,47 +0,0 @@
----
-name: provider
-description: Slash command for safe OMK provider routing, doctor checks, and OAuth/login guidance without exposing secrets.
----
-
-# /provider
-
-Inspect or configure OMK provider routing while keeping Kimi as the final authority and avoiding secret leakage.
-
-## Commands
-
-```bash
-omk provider list
-omk provider doctor <provider> --soft
-omk provider auth <provider> --method api-key-env|oauth|external-cli --api-key-env <ENV_NAME>
-omk provider oauth <provider>
-omk provider profiles
-omk provider set <provider> --model <model> --base-url <url> --api-key-env <ENV_NAME>
-omk provider enable <provider>
-omk provider disable <provider> "reason"
-```
-
-Machine-readable, stdout-only output:
-
-```bash
-omk provider list --json
-omk provider oauth openrouter --json
-omk provider profiles --json
-omk provider doctor deepseek --soft --json
-```
-
-DeepSeek shortcuts:
-
-```bash
-omk deepseek api
-omk deepseek enable
-omk deepseek doctor --soft
-```
-
-## Rules
-
-- Never print, summarize, or store OAuth tokens/API keys in the project repository.
-- `omk provider oauth` provides local login instructions/metadata only; browser/device exchanges must be completed in the provider's official CLI.
-- OpenRouter uses `OPENROUTER_API_KEY` and `https://openrouter.ai/api/v1`; register only env metadata with `omk provider auth openrouter --method oauth --api-key-env OPENROUTER_API_KEY`.
-- Register only API-key environment variable names with `omk provider set`; do not pass secret values.
-- Treat non-Kimi providers as advisory or low-risk workers unless explicit project policy says otherwise.
-- Run provider doctor checks with `--soft` when you want fallback diagnostics without failing the whole task.

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

@@ -1,255 +0,0 @@
----
-name: "speckit-analyze"
-description: "Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation."
-compatibility: "Requires spec-kit project structure with .specify/ directory"
-metadata:
-  author: "github-spec-kit"
-  source: "templates/commands/analyze.md"
----
-
-
-## User Input
-
-```text
-$ARGUMENTS
-```
-
-You **MUST** consider the user input before proceeding (if not empty).
-
-## Pre-Execution Checks
-
-**Check for extension hooks (before analysis)**:
-- Check if `.specify/extensions.yml` exists in the project root.
-- If it exists, read it and look for entries under the `hooks.before_analyze` key
-- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
-- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
-- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
-  - If the hook has no `condition` field, or it is null/empty, treat the hook as executable
-  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
-- For each executable hook, output the following based on its `optional` flag:
-  - **Optional hook** (`optional: true`):
-    ```
-    ## Extension Hooks
-
-    **Optional Pre-Hook**: {extension}
-    Command: `/{command}`
-    Description: {description}
-
-    Prompt: {prompt}
-    To execute: `/{command}`
-    ```
-  - **Mandatory hook** (`optional: false`):
-    ```
-    ## Extension Hooks
-
-    **Automatic Pre-Hook**: {extension}
-    Executing: `/{command}`
-    EXECUTE_COMMAND: {command}
-
-    Wait for the result of the hook command before proceeding to the Goal.
-    ```
-- If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently
-
-## Goal
-
-Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/speckit-tasks` has successfully produced a complete `tasks.md`.
-
-## Operating Constraints
-
-**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
-
-**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit-analyze`.
-
-## Execution Steps
-
-### 1. Initialize Analysis Context
-
-Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:
-
-- SPEC = FEATURE_DIR/spec.md
-- PLAN = FEATURE_DIR/plan.md
-- TASKS = FEATURE_DIR/tasks.md
-
-Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command).
-For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
-
-### 2. Load Artifacts (Progressive Disclosure)
-
-Load only the minimal necessary context from each artifact:
-
-**From spec.md:**
-
-- Overview/Context
-- Functional Requirements
-- Success Criteria (measurable outcomes — e.g., performance, security, availability, user success, business impact)
-- User Stories
-- Edge Cases (if present)
-
-**From plan.md:**
-
-- Architecture/stack choices
-- Data Model references
-- Phases
-- Technical constraints
-
-**From tasks.md:**
-
-- Task IDs
-- Descriptions
-- Phase grouping
-- Parallel markers [P]
-- Referenced file paths
-
-**From constitution:**
-
-- Load `.specify/memory/constitution.md` for principle validation
-
-### 3. Build Semantic Models
-
-Create internal representations (do not include raw artifacts in output):
-
-- **Requirements inventory**: For each Functional Requirement (FR-###) and Success Criterion (SC-###), record a stable key. Use the explicit FR-/SC- identifier as the primary key when present, and optionally also derive an imperative-phrase slug for readability (e.g., "User can upload file" → `user-can-upload-file`). Include only Success Criteria items that require buildable work (e.g., load-testing infrastructure, security audit tooling), and exclude post-launch outcome metrics and business KPIs (e.g., "Reduce support tickets by 50%").
-- **User story/action inventory**: Discrete user actions with acceptance criteria
-- **Task coverage mapping**: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases)
-- **Constitution rule set**: Extract principle names and MUST/SHOULD normative statements
-
-### 4. Detection Passes (Token-Efficient Analysis)
-
-Focus on high-signal findings. Limit to 50 findings total; aggregate remainder in overflow summary.
-
-#### A. Duplication Detection
-
-- Identify near-duplicate requirements
-- Mark lower-quality phrasing for consolidation
-
-#### B. Ambiguity Detection
-
-- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria
-- Flag unresolved placeholders (TODO, TKTK, ???, `<placeholder>`, etc.)
-
-#### C. Underspecification
-
-- Requirements with verbs but missing object or measurable outcome
-- User stories missing acceptance criteria alignment
-- Tasks referencing files or components not defined in spec/plan
-
-#### D. Constitution Alignment
-
-- Any requirement or plan element conflicting with a MUST principle
-- Missing mandated sections or quality gates from constitution
-
-#### E. Coverage Gaps
-
-- Requirements with zero associated tasks
-- Tasks with no mapped requirement/story
-- Success Criteria requiring buildable work (performance, security, availability) not reflected in tasks
-
-#### F. Inconsistency
-
-- Terminology drift (same concept named differently across files)
-- Data entities referenced in plan but absent in spec (or vice versa)
-- Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note)
-- Conflicting requirements (e.g., one requires Next.js while other specifies Vue)
-
-### 5. Severity Assignment
-
-Use this heuristic to prioritize findings:
-
-- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality
-- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion
-- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case
-- **LOW**: Style/wording improvements, minor redundancy not affecting execution order
-
-### 6. Produce Compact Analysis Report
-
-Output a Markdown report (no file writes) with the following structure:
-
-## Specification Analysis Report
-
-| ID | Category | Severity | Location(s) | Summary | Recommendation |
-|----|----------|----------|-------------|---------|----------------|
-| A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version |
-
-(Add one row per finding; generate stable IDs prefixed by category initial.)
-
-**Coverage Summary Table:**
-
-| Requirement Key | Has Task? | Task IDs | Notes |
-|-----------------|-----------|----------|-------|
-
-**Constitution Alignment Issues:** (if any)
-
-**Unmapped Tasks:** (if any)
-
-**Metrics:**
-
-- Total Requirements
-- Total Tasks
-- Coverage % (requirements with >=1 task)
-- Ambiguity Count
-- Duplication Count
-- Critical Issues Count
-
-### 7. Provide Next Actions
-
-At end of report, output a concise Next Actions block:
-
-- If CRITICAL issues exist: Recommend resolving before `/speckit-implement`
-- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
-- Provide explicit command suggestions: e.g., "Run /speckit-specify with refinement", "Run /speckit-plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'"
-
-### 8. Offer Remediation
-
-Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
-
-### 9. Check for extension hooks
-
-After reporting, check if `.specify/extensions.yml` exists in the project root.
-- If it exists, read it and look for entries under the `hooks.after_analyze` key
-- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
-- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
-- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
-  - If the hook has no `condition` field, or it is null/empty, treat the hook as executable
-  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
-- For each executable hook, output the following based on its `optional` flag:
-  - **Optional hook** (`optional: true`):
-    ```
-    ## Extension Hooks
-
-    **Optional Hook**: {extension}
-    Command: `/{command}`
-    Description: {description}
-
-    Prompt: {prompt}
-    To execute: `/{command}`
-    ```
-  - **Mandatory hook** (`optional: false`):
-    ```
-    ## Extension Hooks
-
-    **Automatic Hook**: {extension}
-    Executing: `/{command}`
-    EXECUTE_COMMAND: {command}
-    ```
-- If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently
-
-## Operating Principles
-
-### Context Efficiency
-
-- **Minimal high-signal tokens**: Focus on actionable findings, not exhaustive documentation
-- **Progressive disclosure**: Load artifacts incrementally; don't dump all content into analysis
-- **Token-efficient output**: Limit findings table to 50 rows; summarize overflow
-- **Deterministic results**: Rerunning without changes should produce consistent IDs and counts
-
-### Analysis Guidelines
-
-- **NEVER modify files** (this is read-only analysis)
-- **NEVER hallucinate missing sections** (if absent, report them accurately)
-- **Prioritize constitution violations** (these are always CRITICAL)
-- **Use examples over exhaustive rules** (cite specific instances, not generic patterns)
-- **Report zero issues gracefully** (emit success report with coverage statistics)
-
-## Context
-
-$ARGUMENTS