open-multi-agent-kit 0.78.0

package/templates/skills/agents/claude-for-legal/references/workflow-catalog.md

@@ -0,0 +1,38 @@
+# Claude for Legal workflow catalog
+
+Use this catalog to map a legal request to a conservative workflow. Source basis: Anthropic `claude-for-legal` repository, compacted for OMK use.
+
+## Practice areas
+
+| Lane | Use for | Typical outputs |
+| --- | --- | --- |
+| Commercial legal | Vendor/customer agreements, NDAs, SaaS terms, amendments, renewal/cancel-by review, escalation routing | Issue list, fallback positions, redline memo, renewal register, stakeholder summary |
+| Privacy legal | DSARs, DPAs, PIAs/DPIAs, processing triage, privacy policy drift, privacy regulatory gaps | DSAR timeline, DPA issue matrix, PIA draft, triage decision, policy-gap tracker |
+| Product legal | Launch review, marketing claims, quick product-risk questions, feature risk assessment | Launch risk memo, claims substantiation table, go/no-go gate, counsel questions |
+| Corporate legal | M&A diligence, board consents/minutes, disclosure schedules, closing checklists, entity compliance, integration | Diligence table, material-contract schedule, consent draft, closing tracker, entity register |
+| Employment legal | Hiring, terminations, worker classification, wage/hour, leave tracking, investigations, policies, international expansion | Jurisdiction checklist, risk flags, investigation plan/memo, policy draft, counsel handoff |
+| Regulatory legal | New rules/guidance, feed monitoring, policy diff, comments, gap tracking | Regulatory digest, policy-diff memo, comment tracker, gap remediation plan |
+| AI governance legal | AI use-case triage, AI impact assessment, vendor AI terms, AI inventory/policy drift | Use-case tiering, AIA draft, vendor risk table, inventory update, governance gaps |
+| IP legal | Trademark clearance, cease-and-desist, DMCA, OSS review, FTO triage, infringement triage, IP clauses, portfolio | Knockout screen, takedown/counter-notice draft, OSS obligations table, claim/portfolio tracker |
+| Litigation legal | Claim charts, chronologies, demand letters, subpoenas, deposition prep, privilege logs, holds, matter intake/status | Cited chronology, demand draft, subpoena plan, depo outline, privilege log flags, hold checklist |
+| Legal clinic | Client intake, deadline tracking, memos, plain-language client letters, semester handoff, supervised review | Intake memo, deadline sheet, research roadmap, client letter, handoff memo |
+| Law student | Case briefs, outlines, IRAC practice, Socratic drill, cold-call prep, study plans, bar prep | Study plan, practice questions, feedback rubric, case brief, outline scaffold |
+| Legal builder / skill QA | Evaluate/install legal skills or legal workflow templates | Security/quality review, allowlist decision, installation plan, update notes |
+
+## Intake checklist by lane
+
+- **Contracts/commercial**: side represented, contract type, counterparty, business goal, playbook positions, must-have terms, fallback authority, governing law, renewal/cancel deadline.
+- **Privacy/AI/product/regulatory**: product/process facts, data categories, jurisdictions, user groups, vendors, policy commitments, regulator/source set, launch/deadline date.
+- **Corporate/M&A**: transaction stage, buyer/seller side, materiality threshold, data-room scope, entity jurisdictions, closing conditions, board/stockholder approvals.
+- **Employment**: worker location, employer entity, employee/contractor status, protected leave/complaint facts, policy history, timing, decision-maker, local counsel involvement.
+- **IP**: mark/work/invention details, goods/services, jurisdictions, dates of first use/publication, license/dependency context, accused product/content, enforcement posture.
+- **Litigation**: forum, parties, claims/defenses, deadlines, procedural posture, evidence corpus, privilege status, settlement posture, outside counsel role.
+- **Clinic/student**: supervision level, course/clinic rules, jurisdiction, client-facing vs internal, grading/learning objective, sources allowed.
+
+## Deliverable patterns
+
+- **Triage memo**: facts, assumptions, issue list, risk labels, source-backed analysis, missing facts, recommended counsel decision.
+- **Review table**: clause/document/source, issue, risk, rationale, proposed revision or action, owner, deadline, citation.
+- **Research roadmap**: question presented, governing jurisdiction, primary sources to pull, search terms, verification plan, expected deliverable.
+- **Draft communication**: purpose, audience, tone, legal caveats, bracketed attorney-review placeholders, send gate.
+- **Tracker**: item, source, date found, owner, due date, status, risk, evidence link, next action.

package/templates/skills/agents/matt-pocock-skills/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: matt-pocock-skills
+description: Real-engineering alignment, shared-language, TDD, diagnosis, and architecture-review workflow adapted from mattpocock/skills for OMK. Use before non-trivial implementation, ambiguous product work, debugging loops, test-first changes, or codebase architecture cleanup.
+---
+
+# matt-pocock-skills
+
+Source basis: mattpocock/skills at commit f304057d61d3df3c9fd992ac2b6e3833cb9325fb. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts or code.
+
+## Use when
+
+- The request is underspecified and a wrong interpretation would waste work.
+- Product language, domain terms, or acceptance criteria are unclear.
+- A bugfix or feature needs a test-first loop.
+- The codebase is becoming hard to reason about and needs a scoped architecture pass.
+
+## OMK workflow
+
+1. Grill lightly: identify goal, non-goals, impacted users, constraints, and proof required. Ask only blocking questions; otherwise state assumptions.
+2. Create shared language: capture domain terms, abbreviations, and project-specific meanings in the plan or relevant docs.
+3. Convert the request into verifiable outcomes: failing test, typecheck, lint, screenshot, replay, or JSON gate.
+4. Work in small slices. After each slice, run the cheapest useful feedback loop before widening.
+5. For debugging, reproduce first, isolate the failing boundary, patch the smallest cause, then prove the original failure is gone.
+6. For architecture cleanup, map module responsibilities and seams before editing; avoid rewrites not tied to the user goal.
+
+## Output contract
+
+Return:
+
+- clarified assumptions or questions asked
+- shared terms or acceptance criteria
+- smallest implementation slice
+- feedback loop commands and results
+- follow-up architecture risks, if any
+
+## Guardrails
+
+- Do not turn a small task into a process-heavy spec unless ambiguity is material.
+- Do not invent product requirements.
+- Do not skip verification because the plan was detailed.

package/templates/skills/agents/multica/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: multica
+description: Managed-agent teamwork, issue assignment, progress tracking, reusable-skill compounding, and handoff workflow adapted from multica-ai/multica for OMK. Use when coordinating multiple agents, converting work into agent-ready tasks, tracking blockers, or turning repeated solutions into skills.
+---
+
+# multica
+
+Source basis: multica-ai/multica at commit 24a59098d65e52797df6a4f4e4de2a6299f10afc. This OMK skill is a compact adaptation, not a vendored copy of upstream prompts or code.
+
+## Use when
+
+- Work needs multiple lanes, agent handoffs, reviewer/QA passes, or issue-board style tracking.
+- A user asks to coordinate OMX/Kimi/Codex agents or compound reusable skills.
+- You need to turn a broad request into assignable, verifiable tasks.
+
+## OMK workflow
+
+1. Define the board: goal, stop condition, lanes, owners, write scopes, verification gates, and worker limit.
+2. Split only independent work. Keep blocking critical-path tasks local unless delegation was explicitly requested.
+3. For each lane, provide goal, scope, files, constraints, expected output, and proof required.
+4. Track lifecycle: queued, in progress, blocked, review, verified, done. Include blocker reason and next action.
+5. Merge results through a reviewer/integrator pass. Do not accept agent output without diff review and gates.
+6. When a repeated pattern proves useful, convert it into a compact OMK skill with source, trigger, workflow, output contract, and guardrails.
+
+## Output contract
+
+Return:
+
+- lane/task board
+- agent or local owner per lane
+- status and blockers
+- integration decisions
+- reusable skill candidates
+- verification evidence
+
+## Guardrails
+
+- Respect configured worker limits and user permission for parallel agents.
+- Do not run install scripts, Docker, cloud setup, or daemon startup unless the user explicitly requests that operational change.
+- Do not let agent parallelism create overlapping write scopes.

package/templates/skills/agents/omk-adaptorch-orchestration-review/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: omk-adaptorch-orchestration-review
+description: Review AdaptOrch, OMK, and similar DAG multi-agent orchestration frameworks. Use when assessing DAG node responsibility, dependency edges, worker write authority, fallback/retry/timeout/evidence gates, review/merge boundaries, or reproducible decision traces.
+---
+
+## Orchestration Review
+
+Use this for read-only architecture review of DAG runtimes, multi-agent pipelines, worktree teams, schedulers, and evidence-gated repair loops.
+
+## Checklist
+
+### DAG node contract
+
+- Verify each node has one responsibility, one owner role, and one observable outcome.
+- Verify inputs, outputs, side effects, and acceptance evidence are explicit.
+- Flag nodes that mix planning, implementation, review, and merge authority without a gate.
+
+### Dependency edges
+
+- Confirm each edge represents a real data dependency, verification dependency, or authority handoff.
+- Flag ordering-only edges that do not protect correctness or safety.
+- Check that failed evidence blocks dependent nodes or routes them to repair.
+
+### Worker authority
+
+- Confirm each worker has bounded write scope and cannot overwrite unrelated lanes.
+- Check shared-file ownership, merge points, and escalation paths.
+- Require reviewer/merger separation for risky or cross-cutting changes.
+
+### Resilience and gates
+
+- Look for explicit retry limits, timeout presets, fallback routes, stop conditions, and evidence gates.
+- Confirm fallback does not silently weaken acceptance criteria.
+- Check that blocked, skipped, failed, and complete states are distinct.
+
+### Decision trace
+
+- Confirm routing, scheduler decisions, tool calls, evidence, retries, and final verdict are replayable.
+- Flag missing timestamps, inputs, outputs, or rationale needed to reproduce a run.
+
+## Output
+
+```txt
+Verdict:
+DAG node issues:
+Dependency edge issues:
+Worker authority risks:
+Missing gates:
+Decision trace gaps:
+Recommended fixes:
+Files/artifacts reviewed:
+```

package/templates/skills/agents/omk-backend-api-review/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: omk-backend-api-review
+description: Backend API review for NestJS, Express, FastAPI, database access, validation, auth, error handling, and API contracts.
+---
+
+## Backend Review
+
+Check:
+
+- request validation
+- authn/authz
+- DTO/schema correctness
+- transaction boundaries
+- N+1 queries
+- error response consistency
+- logging without secrets
+- backward compatibility
+- migration safety
+- test coverage
+
+## Output
+
+```txt
+API contract:
+Data flow:
+Auth risk:
+DB risk:
+Error handling:
+Test gaps:
+```

package/templates/skills/agents/omk-code-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: omk-code-review
+description: Adversarial code review for current diff, focusing on correctness, security, regressions, maintainability, and unnecessary changes.
+---
+
+## Review Policy
+
+Review the diff as if it will be merged to production.
+
+## Focus
+
+1. Correctness
+2. Broken edge cases
+3. Security
+4. Type safety
+5. Data consistency
+6. Error handling
+7. Performance regressions
+8. Unnecessary scope creep
+9. Test gaps
+10. Framework convention violations
+
+## Rules
+
+- Do not rewrite code unless asked.
+- Do not praise.
+- Do not nitpick formatting unless it affects maintainability.
+- Prioritize blocking issues.
+- Cite exact files/functions when possible.
+
+## Output
+
+```txt
+Verdict: pass/fail
+Blocking issues:
+Non-blocking issues:
+Test gaps:
+Suggested fixes:
+Files reviewed:
+```

package/templates/skills/agents/omk-context-broker/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: omk-context-broker
+description: Context and memory policy for long-running Kimi coding sessions, DAG workers, and repeated project work.
+---
+
+## Context Broker Policy
+
+Use this skill when a task spans many files, many turns, multiple workers, or a long session.
+
+## Local Graph Memory
+
+Project-local ontology graph memory is the default source of truth for project/session memory. Use `omk_read_memory`, `omk_write_memory`, `omk_memory_mindmap`, `omk_graph_query`, `omk_read_run_memory`, and `omk_write_run_memory` when the omk-project MCP exposes them. `.omk/memory/` is a local mirror/cache for reviewability.
+
+## Okabe / D-Mail Checkpoints
+
+Use Kimi Code Okabe + `SendDMail` for smart context recovery:
+
+- send a D-Mail before destructive/risky refactors, multi-agent handoffs, or `/compact`;
+- include the current goal, branch/changed files, tests run, blockers, and intended next action;
+- keep D-Mail concise and pair it with project-local graph memory for durable project/session recall.
+
+## Memory Files
+
+Use:
+
+- `.omk/memory/project.md`
+- `.omk/memory/decisions.md`
+- `.omk/memory/commands.md`
+- `.omk/memory/risks.md`
+- `.omk/runs/<run-id>/events.jsonl`
+- `.omk/runs/<run-id>/plan.md`
+- `.omk/runs/<run-id>/final-report.md`
+
+## Rules
+
+- Store stable project facts in project-local graph project memory.
+- Store temporary run/session facts in project-local graph run memory.
+- Store decisions with reason, date, and affected files.
+- Do not store secrets.
+- Before compacting, summarize active state:
+  - current goal
+  - completed tasks
+  - pending tasks
+  - changed files
+  - failing commands
+  - blockers
+
+## Decision Record Format
+
+```txt
+Date:
+Decision:
+Reason:
+Alternatives:
+Affected files:
+Risk:
+```

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

@@ -0,0 +1,49 @@
+---
+name: omk-control-loop-debugger
+description: Diagnose agent, runtime, tool, hook, context, provider-routing, DAG, retry, fallback, and evidence-gate failures using an industrial automation feedback-control loop. Use when workflows oscillate, stall, lose context, misroute tools, or need setpoint/sensor/controller/actuator/disturbance/correction analysis.
+---
+
+## Control-loop Debugger
+
+Use this to turn agent failures into a feedback-loop diagnosis instead of a vague postmortem.
+
+## Model
+
+- Setpoint: the user's requested target result and acceptance criteria.
+- Sensor: observed evidence from tests, logs, traces, diffs, screenshots, or user feedback.
+- Controller: router, scheduler, skill selection, policy, prompt, or state machine deciding the next action.
+- Actuator: edit, tool call, Kimi run, worker lane, hook, MCP server, or external command.
+- Disturbance: tool failure, context loss, stale state, version drift, quota, permissions, flaky tests, or hidden dependency.
+- Correction: retry, fallback, narrowed scope, state cleanup, manual review, test addition, or hard block.
+
+## Debug Process
+
+1. Restate the setpoint in measurable terms.
+2. List sensors and mark which are fresh, stale, missing, or contradictory.
+3. Compare sensor evidence to the setpoint and name the control error.
+4. Identify which controller decision created or failed to correct the error.
+5. Check actuator authority, side effects, timeout, and rollback path.
+6. Name disturbances separately from root cause.
+7. Pick one correction and define evidence that proves the loop is stable.
+
+## Failure Patterns
+
+- Oscillation: repeated retries without new evidence.
+- Saturation: context, token, time, quota, or worker capacity exhausted.
+- Sensor drift: stale tests, old logs, cached docs, or wrong working directory.
+- Bad actuator: command edits the wrong path, writes too broadly, or cannot affect the failure.
+- Controller mismatch: wrong skill, worker, provider, workflow, or fallback route.
+
+## Output
+
+```txt
+Setpoint:
+Sensor evidence:
+Control error:
+Controller decision:
+Actuator path:
+Disturbance:
+Correction:
+Verification:
+Residual risk:
+```

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

@@ -0,0 +1,22 @@
+---
+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/agents/omk-docs-release/SKILL.md

@@ -0,0 +1,42 @@
+---
+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/agents/omk-evidence-contract/SKILL.md

@@ -0,0 +1,52 @@
+---
+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/agents/omk-frontend-implementation/SKILL.md

@@ -0,0 +1,13 @@
+---
+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/agents/omk-frontend-ui-review/SKILL.md

@@ -0,0 +1,29 @@
+---
+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/agents/omk-git-commit-pr/SKILL.md

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

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

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

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