open-multi-agent-kit 0.79.1 → 0.80.0

package/templates/skills/kimi/omk-security-review/SKILL.md

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

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

package/templates/skills/kimi/omk-test-debug-loop/SKILL.md

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

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

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

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

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

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

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