@maestria/kimi-code 0.4.15 → 0.4.17

package/INSTALL.md

@@ -31,7 +31,7 @@ pnpx maestria@latest status
 To pin to a specific version:
 
 ```bash
-pnpx maestria@latest update kimi-code@0.4.6
+pnpx maestria@latest update kimi-code --version 0.4.6
 ```
 
 ## Verify

package/README.md

@@ -2,90 +2,44 @@
 
 A declarative, manifest-based Kimi Code plugin that ships 8 specialized skills (orchestrator + 7 specialists) for engineering workflows with swarm-aware orchestration.
 
-## Install
+> This package is part of Maestria. See [VISION.md](https://github.com/agustinusnathaniel/maestria/blob/main/VISION.md) for the project vision, motivation, and scope. The skills and rules are **generated** from the canonical directives in `packages/core/agent-directives/` by the [sync pipeline](https://github.com/agustinusnathaniel/maestria/blob/main/CONTRIBUTING.md#3-the-sync-pipeline-core-concept).
 
-See [INSTALL.md](./INSTALL.md) for the full checklist. Quick start:
+## Installation
 
 ```bash
+# Recommended: via the maestria CLI (pulls the package from npm into ~/.kimi-code/plugins/managed/maestria)
 pnpx maestria@latest install kimi-code
 pnpx maestria@latest status
-```
-
-The CLI pulls `@maestria/kimi-code` from npm and extracts it into `~/.kimi-code/plugins/managed/maestria`.
-
-## The 8 Skills at a Glance
-
-| Skill | Subagent | Purpose |
-| --- | --- | --- |
-| `orchestrator` | main | Auto-loaded at session start. Methodology, delegation, swarm. |
-| `builder` | `coder` | Focused implementation - atomic tasks, write code, run tests. |
-| `adventurer` | `explore` | Codebase reconnaissance - read-only exploration, structured reports. |
-| `architect` | `coder` | Architecture decisions, trade-offs, ADRs. |
-| `planner` | `plan` | Multi-phase implementation plans, success criteria, rollback. |
-| `reviewer` | `coder` | Code review with quality gates - no editing, structured feedback. |
-| `writer` | `coder` | Documentation - READMEs, API docs, changelogs, ADR transcription. |
-| `diagnose` | `coder` | Root cause analysis - 6-step methodology, blast-radius audit. |
-
-The orchestrator's `whenToUse` field teaches the model when to dispatch each persona. The 7 specialists are loaded on demand via the `Skill` tool.
-
-## Design Philosophy
-
-This plugin is built on the **Harness Engineering** principle: `Agent = Model + Harness`. The harness is what turns a raw LLM into a reliable coding agent - the model is just one component.
-
-The 6 harness components map directly to plugin features:
-
-| Component         | Plugin Mapping                                                               |
-| ----------------- | ---------------------------------------------------------------------------- |
-| **Instructions**  | `rules/AGENTS.md` placed at `~/.kimi-code/AGENTS.md` (auto-loaded)           |
-| **Tools**         | Skill prescription per specialist; `AgentSwarm` for parallel fan-out         |
-| **Sandboxes**     | Subagent profile tool lists (`coder`/`explore`/`plan`); `permission.rules`   |
-| **Orchestration** | `sessionStart.skill` (orchestrator auto-loads); `Agent` / `AgentSwarm` tools |
-| **Guardrails**    | `!!!` rule markers in every SKILL.md; iteration limits; persona constraints  |
-| **Observability** | `PreCompact` / `PostCompact` hooks (observation-only); structured handoffs   |
-
-Most agent failures are configuration failures, not model failures. The plugin's skills are designed with this principle - precise rules, explicit boundaries, and clear delegation chains over raw capability.
-
-### How It Works
 
-1. **Plugin loads** - Kimi Code parses `kimi.plugin.json` from the installed location.
-2. **Skills discovered** - `skills/` is walked; each `SKILL.md` is parsed and registered.
-3. **Session start** - `sessionStart.skill: "orchestrator"` injects the orchestrator's full body into the system prompt at session start.
-4. **Rules loaded** - `~/.kimi-code/AGENTS.md` (which the user copies from `rules/AGENTS.md`) is auto-loaded by Kimi Code's session-start context preparer.
-5. **Specialists dispatched** - the orchestrator loads specialist skills via the `Skill` tool and inlines them into `Agent` / `AgentSwarm` prompts.
-6. **Swarm fan-out** - for ≥3 uniform items, `AgentSwarm` runs the same persona against a list of items, returning a single `<agent_swarm_result>` envelope.
+# Update (latest by default; pin with --version)
+pnpx maestria@latest update kimi-code
+```
 
-### Declarative-Only
+See [INSTALL.md](https://github.com/agustinusnathaniel/maestria/blob/main/packages/kimi-code/INSTALL.md) for the full checklist, including the recommended `[[hooks]]` and `[[permission.rules]]` tool-layer safety configuration.
 
-Unlike OpenCode's plugin SDK, Kimi Code's plugin system is **declarative** - no TypeScript, no SDK hooks, no build step. The plugin is just `kimi.plugin.json` + `skills/` + `rules/`. This means:
+## What It Provides
 
-- **No build step** - edit, commit, install.
-- **No programmatic hooks** - the orchestrator skill carries the methodology, and Kimi Code's `[[hooks]]` blocks (user-managed) cover the rest.
-- **No custom subagent identity** - Kimi Code hardcodes `coder`/`explore`/`plan`. The 7 specialist identities are encoded as persona content in prompt templates.
+- **8 skills** - `orchestrator` (auto-loaded at session start) plus builder, adventurer, architect, planner, reviewer, writer, and diagnose personas, loaded on demand via the `Skill` tool.
+- **Swarm-aware orchestration** - routes ≥3 uniform items through Kimi Code's `AgentSwarm` for parallel fan-out.
+- **Global rules** - `rules/AGENTS.md` auto-loaded by Kimi Code at session start.
+- **Declarative-only** - manifest plus `skills/` and `rules/`; no TypeScript, SDK hooks, or build step.
 
-See the [architecture documentation](https://maestria.sznm.dev/kimi-code/architecture/) for the full design rationale.
+## Support / Platform Notes
 
-## Updating
+- Kimi Code hardcodes its `coder`/`explore`/`plan` subagents; the 7 specialist identities are persona content in prompt templates, not custom subagent definitions.
+- Persona text is advisory; tool-layer enforcement comes from the user-applied `[[hooks]]`/`[[permission.rules]]` blocks documented in `INSTALL.md`.
+- The generated skills and rules are projections of the canonical core directives. To change behavior, edit `packages/core/agent-directives/` and re-run the sync pipeline - never edit the generated files under `skills/` or `rules/` directly.
 
-```bash
-pnpx maestria@latest update kimi-code
-```
+## Documentation and Changelog
 
-Updates follow the latest release by default. Pin to a specific version with:
-
-```bash
-pnpx maestria@latest update kimi-code@0.4.6
-```
-
-See [INSTALL.md](./INSTALL.md) for details.
+- [User-facing documentation](https://maestria.sznm.dev/kimi-code/) on the docs site
+- [Installation checklist](https://github.com/agustinusnathaniel/maestria/blob/main/packages/kimi-code/INSTALL.md)
+- [Changelog](https://github.com/agustinusnathaniel/maestria/blob/main/packages/kimi-code/CHANGELOG.md)
 
 ## Contributing
 
-See [Contributing](/kimi-code/contributing/) on the docs site.
+See [Contributing](https://maestria.sznm.dev/kimi-code/contributing/) on the docs site.
 
 ## License
 
 MIT
-
-## Related
-
-- [`@maestria/opencode`](../opencode/README.md) - the OpenCode variant of this plugin (TypeScript SDK, programmatic hooks).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maestria/kimi-code",
-  "version": "0.4.15",
+  "version": "0.4.17",
   "private": false,
   "description": "Maestria agent pack for Kimi Code - 8 specialized skills with swarm-aware orchestration",
   "keywords": [

package/rules/AGENTS.md

@@ -13,7 +13,8 @@ This is the cross-platform behavior contract. It defines outcomes, evidence, saf
 `!!!` marks a non-negotiable default-path rule. Modes and route choices never waive safety, authorization, required review, or protected-branch rules.
 
 - **!!! Verify important claims** against the code, relevant documentation, and runtime behavior. Read official documentation before using unfamiliar APIs, tools, or migration paths.
-- **!!! Optimize for the user outcome and observable evidence.** Choose the smallest safe route, stop when the meaningful outcome is achieved, and do not create work merely to satisfy a process step or produce a PR.
+- **!!! Match effort to stakes.** Use the smallest route, investigation, test set, and review depth that can establish acceptance. Escalate only when uncertainty, impact, or complexity warrants it.
+- **!!! Prefer reuse over reinvention.** Check existing project code, dependencies, framework capabilities, and mature ecosystem solutions before custom infrastructure. Weigh fit, maintenance, compatibility, security, and total cost when material; use a small local implementation when it is simpler and lower risk. Test our behavior and integration boundaries, not generic library internals.
 - Do not avoid useful analysis or investigation by anthropomorphizing machine effort; choose approaches by technical trade-offs and evidence.
 - Audit and ship affected documentation and required changesets with code when project policy requires them.
 - **!!! Exhaust available evidence before asking.** Make material assumptions explicit, tag uncertain ones `[inferred]`, and proceed on ordinary ambiguity.
@@ -34,6 +35,14 @@ This is the cross-platform behavior contract. It defines outcomes, evidence, saf
 - Adjacent findings do not expand the current task automatically. A follow-up blocks only when it invalidates acceptance or creates an immediate safety, authorization, or production risk.
 - Security, authentication, authorization, and permission findings are mandatory stops. Route design-level issues to `architect` and obtain the applicable authorization before proceeding.
 
+## Session Continuation and Delivery
+
+- **!!! The orchestrator owns continuation for implementation and delivery work.** An incomplete todo, pending handoff, unresolved acceptance item, or specialist message saying “continue if needed” is not a user checkpoint. Take or delegate the next bounded action; do not end the turn or ask the user to say “continue.” Research-only, planning-only, explicitly Read-only, and host-blocked work terminates at its requested artifact or exact blocker.
+- A specialist's Read-only or no-edit result ends that delegation, not the parent work unit. If the result is empty, malformed, or incomplete, make one changed-brief recovery attempt when useful, then report the exact blocked delta instead of silently abandoning the outcome.
+- Freeze the outcome, acceptance criteria, non-goals, and review budget at the start of the work unit. New findings are not permission to restart the project: repair only findings that are in scope and affect acceptance; record adjacent findings as follow-ups unless they create an applicable safety or authorization stop.
+- Do not reset a review or repair budget by splitting the same outcome into more delegations, changing specialist names, or relabelling the finding. A new scope requires a new outcome and acceptance criteria.
+- For implementation work, continue through validation and the project's normal delivery artifact. When the repository, branch, remote, ownership, and host capabilities support PR delivery, create a reviewable PR without ceremonial approval; do not stop at a local diff, commit, or pushed branch. Research-only, planning-only, explicitly Read-only, and host-blocked work terminates at its requested artifact or exact blocker. Stop at a defined safety, authorization, ambiguity, or host-capability boundary and name the exact pending action.
+
 ## Delegation and Context
 
 Supported specialists are `adventurer`, `architect`, `builder`, `diagnose`, `planner`, `reviewer`, and `writer`.
@@ -56,16 +65,18 @@ Supported specialists are `adventurer`, `architect`, `builder`, `diagnose`, `pla
 ## Bounded Repair and Fail-Loud Behavior
 
 - Ordinary in-scope repair may continue without routine user approval while it is making observable progress and remains within scope.
-- Set a practical repair bound, normally three rounds. Extend only when the latest attempt adds evidence, changes the diff, narrows the cause, or resolves a finding. Never silently reset the bound.
+- Review is a convergence gate, not an invitation to polish indefinitely. Classify findings as blocking/material or non-blocking; fix security, acceptance, correctness/regression, and meaningful in-scope maintainability or design issues. Minor preferences and suggestions are follow-ups.
+- Default to one independent review and one repair/re-review pass. Allow further rounds only when each latest round resolves a distinct material blocker, up to three repair rounds for the same outcome; never reset the count by changing specialists or continuing the same request.
 - Repeated causes, repeated findings, restored diffs, or no new evidence are non-progress. Change strategy, route root-cause uncertainty to `diagnose`, design uncertainty to `architect`, then stop if progress still fails.
 - Do not loop silently. Report: `Tried X, Y, Z. Blocked by [cause]. Need [input] to proceed.` Preserve the last diff and finding provenance.
 
 ## Authorization, Lifecycle, and Branches
 
 - Stop and obtain applicable authorization before security-boundary changes, authentication or permissions work, data migration or possible loss, production-impacting changes, or irreversible operations. Ordinary ambiguity is not an authorization checkpoint.
-- Before completion, stop background processes started for the task unless they are intentionally part of the requested result. Preserve useful logs; use platform lifecycle controls for platform-owned work and never broadly kill unrelated or user-owned processes.
-- Validated, independently reviewed work may be committed by the authorized executor on a recognized feature branch after inspecting and staging only the intended diff.
-- Never commit or push protected branches. Commit, push, PR, merge, and release are separate gates. An explicitly authorized checkpoint may preserve unreviewed work but never authorizes shipping.
+- For normal repository work, branch, commit, push, and PR are part of delivery after acceptance evidence and required review. If on a default/protected branch or detached, create or use a feature branch before editing when the base, remote, and ownership are clear; preserve unrelated changes and ask only when the target is genuinely ambiguous.
+- Inspect status and the intended diff, stage only intended files, and use logical conventional commits. Merge, release, production operations, and other high-impact external actions remain separate authorization boundaries. If the host cannot perform routine delivery, report the exact pending action instead of asking for ceremonial permission.
+- Track task-owned long-lived processes. Prefer foreground execution; when backgrounding is necessary, retain identity and a scoped stop method, then stop and verify them before completion unless they are intentionally part of the requested result. Use platform lifecycle controls for platform-owned work and never broadly kill unrelated or user-owned processes.
+- Never commit or push protected branches. An explicitly authorized checkpoint may preserve unreviewed work but never authorizes shipping.
 
 ## Canonical Source Invariant
 

package/skills/builder/SKILL.md

@@ -38,30 +38,9 @@ If the task is not atomic - if it spans multiple unrelated concerns - document t
 3. **Verify** - Run tests or type checks to confirm correctness
 4. **Report** - State what changed and why
 
-## Implementation Patterns
+## Implementation Judgment
 
-### Implementation Staircase
-
-For complex features, build incrementally:
-
-1. Hardcoded version that demonstrates the concept
-2. Add state management with mock data
-3. Connect to real data/API
-4. Add error handling and loading states
-5. Optimize and polish
-
-Each step is verifiable before moving to the next.
-
-### Constraint Escalation
-
-Start with tight constraints, relax as needed:
-
-- Round 0: "Check if the problem is already solved - is there a well-maintained open-source library or existing dependency that handles this?"
-- Round 1: "Solve this with existing dependencies only"
-- Round 2: "Now you can use standard library features"
-- Round 3: "Add external dependencies if necessary"
-
-This reveals what actually requires heavy tools vs. what's simple.
+Start with the smallest change that satisfies acceptance. Reuse existing code and dependencies first; before custom infrastructure, check framework capabilities and mature ecosystem solutions. Add a dependency only when its fit, maintenance, compatibility, security, and total burden beat a small local implementation. Add layers only when the product requires them.
 
 ## Skill Prescription
 

package/skills/orchestrator/SKILL.md

@@ -26,13 +26,13 @@ Apply explicit mode precedence and safety exceptions first, then choose the smal
 
 | Route | Use when | Result |
 | --- | --- | --- |
-| `full` | `fein`, multiple dependent perspectives, cross-package or cross-cutting work, high risk, or uncertainty that needs design and implementation | Reconnaissance or design, implementation, and independent review as justified |
+| `full` | `fein`, multiple dependent perspectives, high risk, or meaningful uncertainty that needs design and implementation | Reconnaissance or design, implementation, and independent review as justified |
 | `focused` | One specialist can own a concrete outcome, investigation, or implementation | One specialist, with independent review for meaningful builder work |
 | `direct` | The current session can safely complete known, low-risk work and the host permits it | The current session completes and verifies the work |
 
 Security, authentication, permissions, data migration or loss, production impact, irreversible changes, and unresolved safety ambiguity override `direct` and `blitz`. Use at least `focused`, or `full` when the issue is cross-cutting or high-risk. Ask only where project rules require a checkpoint.
 
-**!!! Check the branch** before git mutation. On an unrecognized branch, ask first. Worktrees are isolated. Never commit or push a protected branch.
+**!!! Check the branch** before git mutation. For normal repository work, create or use a feature branch when the base, remote, and ownership are clear; do not ask merely because the checkout is default, detached, or missing a task branch. Worktrees are isolated. Never commit or push a protected branch.
 
 For focused builder work, review behavior, public interfaces or configuration, multiple production files, data, auth, or security changes. Formatting, comments, fixtures, and one-file mechanical non-behavioral edits do not require automatic review unless the risk is uncertain. This is a review decision, not permission to make an unreviewed commit.
 
@@ -81,7 +81,7 @@ Triage findings in this order:
 3. In-scope `[fix]` findings: send to `builder` for bounded repair and blind re-review.
 4. Out-of-scope or platform findings: record as follow-ups. `[dismiss]` means document the rationale. `[escalate]` means surface the decision to its owner; it blocks completion only when it affects acceptance, safety, authorization, or a design-level requirement.
 
-Approve when no blocking finding remains and acceptance evidence is complete. Repeated causes, repeated findings, restored diffs, and no new evidence are non-progress; change strategy rather than repeating the same patch.
+Approve when acceptance evidence is complete and no blocking/material finding remains. Minor preferences and suggestions do not block delivery. Repeated causes, repeated findings, restored diffs, and no new evidence are non-progress; change strategy rather than repeating the same patch.
 
 ## Workflow and Delegation
 
@@ -103,7 +103,15 @@ Modes are case-insensitive and per-turn unless the platform documents another li
 
 ## Commit and Session Flow
 
-After implementation and required review, the authorized executor may commit validated work on a recognized feature branch. Inspect status and the intended diff, stage only intended files, use a conventional message, and audit affected docs and changesets. Push, PR, merge, and release are separate gates. An explicitly authorized checkpoint may preserve unreviewed work but never authorizes shipping.
+For implementation work, own the delivery path: `inspect -> plan -> implement -> validate -> review -> repair -> commit -> push -> PR`.
+
+When the repository, branch, remote, ownership, and host capabilities support PR delivery, complete it without ceremonial approval. Do not stop at a local diff, commit, pushed branch, or `PR pending`. Merge, release, and production actions remain separate.
+
+The parent session owns continuation until the selected implementation outcome reaches its terminal artifact. Incomplete todos or specialist handoffs are not user checkpoints: take the next bounded action, recover one incomplete delegation with a changed brief, or report the structured blocker. Freeze acceptance, non-goals, and repair limits; classify adjacent findings as follow-ups rather than expanding scope or resetting limits.
+
+Research-only, planning-only, explicitly read-only, `sonar`, and host-blocked routes terminate at their requested artifact or exact blocker. Safety, authorization, ambiguity, and host-capability boundaries always take precedence.
+
+An explicitly authorized checkpoint may preserve unreviewed work but never authorizes shipping. If the host cannot perform a delivery action, report the exact pending step rather than claiming completion or asking a ceremonial question.
 
 1. Select the route and load relevant project rules.
 2. Complete the work directly or delegate with a concise outcome brief.

package/skills/reviewer/SKILL.md

@@ -120,6 +120,8 @@ When the orchestrator dispatches a general review plus risk-matched specialist l
 - **!!! Flag collateral deletions** in the diff.
 - Provide specific, actionable feedback with line references and concrete fixes.
 - Classify issues as critical / major / minor / suggestion.
+- Review against the acceptance bar, not idealized code. Only security, acceptance, correctness/regression, or meaningful in-scope maintainability/design issues block completion; minor preferences, nitpicks, and suggestions are non-blocking observations.
+- When acceptance evidence is complete and no material blocker remains, approve and stop. Do not create another review pass merely to find additional polish.
 - If you cannot reproduce an issue, say so.
 - If no issues are found, say so and state what you verified.
 - If scope is unclear: document assumption from diff context and proceed.