{"id":"58b69923-b578-40b1-9e59-663ec873d474","slug":"kang-agent-collab","kind":"skill","name":"kang-agent-collab","summary":"Agent-agnostic collaboration and handoff protocol: shared memory explains the project, Git proves the engineering state, and the current task grants permission.","owner":"KanG-ciyuan","repoUrl":"https://github.com/KanG-ciyuan/kang-agent-collab","license":"MIT","licenseTier":"permissive","trust":"community","stars":0,"match":null,"fewStars":true,"format":"skill","createdAt":"2026-09-14T11:59:15.000Z","addedAt":"2026-10-21T11:37:55.360Z","logoUrl":"https://avatars.githubusercontent.com/u/294070986?u=6d678d892777fd52d227528acc1c3520e4d77bdf&v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["developer-tools","memory-knowledge","productivity"],"tags":["ai-agents","coding-agents","developer-tools","git","handoff","project-memory","multi-agent"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-23T05:11:02.711Z","sample":false,"url":"https://conduits.dev/tools/kang-agent-collab","language":"Python","transports":["stdio"],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"# kang-agent-collab\n\nEnglish | [简体中文](README.zh-CN.md) | [日本語](README.ja.md) | [한국어](README.ko.md) | [Español](README.es.md)\n\n[![Release](https://img.shields.io/github/v/release/KanG-ciyuan/kang-agent-collab?display_name=tag&sort=semver&style=flat-square)](https://github.com/KanG-ciyuan/kang-agent-collab/releases)\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)\n[![Last commit](https://img.shields.io/github/last-commit/KanG-ciyuan/kang-agent-collab?style=flat-square)](https://github.com/KanG-ciyuan/kang-agent-collab/commits/main)\n\n> A lightweight, agent-agnostic collaboration skill for reliable project handoffs across AI coding agents using Git and shared project memory.\n\n`kang-agent-collab` gives different AI agents a small, shared contract for recovering project context, checking the live repository, and handing work over safely. It is a Skill and protocol—not an orchestrator, platform, server, or autonomous memory system.\n\n```text\nShared project memory   explains identity, decisions, and intent\nGit                     proves the current engineering state\nHandoff                 carries the smallest useful continuation state\nReceiving agent         re-verifies everything before continuing\n```\n\nNo database, daemon, dashboard, vector store, or hosted service is required. This repository is a file-based interoperability contract: a text spec, YAML schemas, and templates. No code here enforces it at runtime.\n\n## Why it exists\n\nAn agent that receives only a chat summary can easily resume the wrong project, trust stale state, overwrite another agent's changes, or confuse tool access with permission. This protocol makes those failure modes explicit.\n\nIts core rule is simple:\n\n> Shared memory explains the project. Git proves the engineering state. The current task grants permission. A handoff is navigation—not truth.\n\n### Wrong way, right way\n\n| Wrong way | Right way |\n|---|---|\n| Resume from a chat summary, or from a folder name that looks familiar | Recover from `project_id` through the authoritative project entry |\n| Trust the handoff's description of the repository | Inspect branch, full HEAD, staged, unstaged, and untracked state yourself |\n| Treat \"the runtime can write\" as \"I am authorized to write\" | Read permission from the Manifest or an explicit instruction |\n| Reduce drift by stashing, resetting, or cleaning unknown changes | STOP — unknown change ownership is `D3` |\n| Copy project state into every record | Reference the record that owns it |\n\n## How it works\n\n```mermaid\nflowchart LR\n    U[User or maintainer] --> A[Agent A]\n    A --> M[Shared project memory]\n    A --> G[(Git engineering truth)]\n    M --> H[Bounded handoff]\n    G --> H\n    H --> B[Agent B]\n    B --> I{Identity and state agree?}\n    I -- Yes --> W[Continue within current permission]\n    I -- No or unknown --> S[STOP and request the missing decision]\n    B --> G\n```\n\nThe canonical workflow is `START → READ → VERIFY STATE → WORK → VERIFY RESULT → COMMIT → DISTILL → WRITE-BACK CANDIDATE → HANDOFF → TAKEOVER`. Those ten steps are defined once, in the canonical [SKILL.md](SKILL.md) contract.\n\n## What an agent actually does\n\n1. Resolves a known `project_id` to an authoritative project entry.\n2. Confirms the canonical repository and repository identity.\n3. Inspects live Git state instead of trusting a stale summary.\n4. Reads current scope, acceptance criteria, permissions, and stop conditions.\n5. Performs only the authorized work.\n6. Records a result state with evidence.\n7. Produces a bounded write-back candidate or handoff only when needed.\n8. Re-verifies identity and state during takeover.\n\n## Core principles\n\n- **Identity before action.** A similar folder name is not proof of project identity.\n- **Git is engineering truth.** Branch, HEAD, staged, unstaged, and untracked state are checked at takeover.\n- **Memory is semantic context.** It carries decisions and intent, not a substitute copy of the repository.\n- **Capability is not permission.** A runtime may be able to write, push, browse, or deploy without being authorized to do so.\n- **Unknown ownership means stop.** Dirty changes are never silently stashed, reset, cleaned, or overwritten.\n- **References beat duplication.** Each authority owns one kind of truth, reducing drift.\n\n## Core capabilities\n\nEvery rule below is a schema or a prose obligation that a human or an agent is asked to follow. The canonical definitions live in [Shared Contracts](references/contracts.md) and [Capability Profiles](references/capability-profiles.md).\n\n| Capability | What it gives you |\n|---|---|\n| Project Identity | `project_id`, authoritative entry, canonical repository, project relationships, and a `verified \\| historical \\| to_verify` status |\n| Lite / Full Manifest | Task scope, exclusions, acceptance, write paths, baseline, commit policy, permissions and cost, and stop conditions |\n| State Drift `D0`–`D3` | A four-level classification with a required action per level; `D3` stops writes and escalates |\n| Result State | `done \\| partial \\| blocked \\| failed`, each recorded with evidence |\n| Write-back Candidate | A bounded, candidate-only update to shared memory, defaulting to no automatic write |\n| Handoff | Previous result, current engineering state, evidence, breakpoint, next action, blockers, and do-not-do guidance |\n| Engineering recovery minimum | A superset Handoff schema for engineering takeover, with a per-field conditional trigger and an explicit required-field list |\n| Takeover Check | Eleven re-verification fields, ending in `safe_to_continue: yes \\| no` |\n| Capability Profile | Dated runtime observations using `available \\| conditional \\| unavailable \\| unknown`, which never grant task permission |\n\n## Outputs and artifacts\n\nThe repository ships templates and rules; it never ships a generated instance of them.\n\n| Artifact | Shipped as |\n|---|---|\n| Lite Manifest, Full Manifest | Schema in [Shared Contracts](references/contracts.md); working template in [`examples/minimal-project/MANIFEST.example.yaml`](examples/minimal-project/MANIFEST.example.yaml) |\n| Project Identity record | Schema in [Shared Contracts](references/contracts.md); template in [`examples/minimal-project/PROJECT_IDENTITY.example.yaml`](examples/minimal-project/PROJECT_IDENTITY.example.yaml) |\n| Handoff, Takeover Check | Schemas in [Shared Contracts](references/contracts.md); templates in [`examples/handoff-example/`](examples/handoff-example/README.md) |\n| Capability Profile | Contract in [Capability Profiles](references/capability-profiles.md); template in [`examples/capability-profile-example/profile.example.yaml`](examples/capability-profile-example/profile.example.yaml) |\n| Discovery metadata | [`agents/interface.yaml`](agents/interface.yaml) |\n| Package metadata | [`manifest.json`](manifest.json) |\n| Release-process records | [`reports/`](reports/prior-art-research.md), including a stored trigger-eval output |\n\nEvery `.example.yaml` is a placeholder template, not a filled record — for example [`HANDOFF.example.yaml`](examples/handoff-example/HANDOFF.example.yaml) ships `head: REPLACE_WITH_FULL_40_CHARACTER_COMMIT_SHA`. There is no runnable validator, no eval runner, no installer, and no generated handoff instance in this repository.\n\nAt runtime the Skill is asked to return an evidence-backed result state, a safe continuation decision, and — only when a trigger applies — a bounded Handoff or write-back candidate.\n\n## Recovery\n\nRecovering an interrupted task is the reason this protocol exists. For a known `project_id`, the canonical recovery chain is:\n\n```text\nproject_id\n-> Agent Knowledge Routing Index\n-> project Obsidian Authority\n-> canonical_repo and current recovery state\n-> repository PROJECT_IDENTITY\n-> live Git state\n-> current Manifest or task permissions, when present\n-> safe_to_continue decision\n```\n\nThe routing index is discovery, not another project-state store; it is optional infrastructure that already exists in some environments and this repository neither provides nor requires one. If the runtime cannot reach the index, the Authority, or the repository, it stops and requests the minimum missing entry. It never guesses a path, never selects a semantically similar project, and never infers the canonical repository from a historical folder name. Any identity conflict among the Authority, `PROJECT_IDENTITY`, Git, and the Manifest sets identity to `to_verify` and requires STOP. See [Architecture and mental model](docs/architecture.md) and [SKILL.md](SKILL.md).\n\n## Project authority and Git truth\n\nDifferent records have different jobs:\n\n| Record | Owns | Does not replace |\n|---|---|---|\n| Project authority / shared memory | Stable project truth, decisions, current phase, and repository pointer | Source files or live Git state |\n| `PROJECT_IDENTITY` | Project ID, canonical repository, authority pointer, project relationships | Task history |\n| Manifest | Current objective, scope, acceptance, permissions, write paths, and commit policy | Project identity |\n| Handoff | Previous result, exact breakpoint, current evidence, next safe action | The Manifest or chat transcript |\n| Git | HEAD, branch, ancestry, tracked content, and working-tree state | Project purpose or permission |\n\nThat table is this README's five-record simplification, and the repository contains two other decompositions of the same idea. The canonical contract enumerates **seven** ownership entries — it adds `AGENTS` (stable execution, safety, Git, and project-boundary rules) and `README` (human-facing purpose and stable capabilities), and names the shared-memory owner as `Obsidian Authority`. [Architecture and mental model](docs/architecture.md) frames the separation as **four independent questions** instead: what project is this, what is true in the repository now, what may this agent do, and what can this runtime do, where a positive answer to one does not imply a positive answer to another. Where the files disagree, [Shared Contracts](references/contracts.md) is the canonical definition, as [CONTRIBUTING.md](CONTRIBUTING.md) states.\n\nShared memory can be an Obsidian note, a versioned project document, or another location the current runtime can access. Obsidian is optional; no automatic Vault write-back is performed by this Skill.\n\n## Capability vs. permission\n\nA [Capability Profile](references/capability-profiles.md) describes what a concrete runtime can access or execute under observed conditions. It never grants permission for the current task. Permission belongs in the Manifest or an explicit user instruction.\n\nFor example, `git: available` means the runtime can run Git. It does not mean the agent may commit, push, rewrite history, or discard changes.\n\n## Runtime model\n\nThe protocol is platform-neutral, but integration is runtime-dependent. The observations below are dated point-in-time records, not compatibility guarantees; all six carry `last_verified: 2026-09-12`.\n\n| Runtime profile | Current evidence boundary |\n|---|---|\n| Codex local | Skill loading and core local tools observed in a dated local environment; access remains session-specific |\n| Claude Code | Local Skill and repository capabilities recorded for a specific tested version; optional integrations remain conditional |\n| Hermes | Indexed Skill loading observed; active toolsets and path access must be rechecked |\n| OpenClaw | Workspace/shared Skill roots observed; tool grants remain agent-specific |\n| ChatGPT Work | Text contract exchange is possible; local Skill loading and tools are session-dependent |\n| DeepSeek Harness | Operational capabilities remain unknown until a concrete harness is verified |\n\nThese profiles do **not** establish universal compatibility. See [Runtime integration](docs/runtime-integration.md) and the dated canonical [capability profiles](references/capability-profiles.md).\n\n## Validation status\n\nProtocol version `0.2.0` is consistent across [`manifest.json`](manifest.json), [`SKILL.md`](SKILL.md), [`CHANGELOG.md`](CHANGELOG.md), this README and its four translations, the Git tag `v0.2.0`, and the published `v0.2.0` release. The public Git history is a single release commit that the tag points at; there is no earlier tag or release in this repository.\n\n### Evidence classes used here\n\n| Class | Meaning in this repository | Status |\n|---|---|---|\n| Repository-verified | Checkable from the current tracked files | `VERIFIED` |\n| Maintainer-reported Pilot evidence | Observed by the maintainer under stated conditions; the underlying private artifacts are not published here | `SIMULATED` — asserted, not reproducible from this repository |\n| Unknown / to verify | Not supported strongly enough for a public capability claim | `TO_VERIFY` |\n\n### What is repository-verified\n\n| Check | How to reproduce | Observed result |\n|---|---|---|\n| Repository-consistency suite | `python3 -m unittest discover -s tests -v` | 5 tests, `OK` — stdlib `unittest`; no dependency manifest declares `pytest` |\n| Single canonical Skill entrypoint | the same suite | exactly one `SKILL.md` in the tree |\n| Version agreement | the same suite | `0.2.0` present in `manifest.json`, `SKILL.md`, and all five READMEs |\n| Relative Markdown links | the same suite | every relative link target resolves; no failures |\n| Package structure, external and optional | `python3 /path/to/kang-meta-skill/scripts/validate_skill.py .` | `{\"ok\": true, \"failures\": [], \"warnings\": []}` |\n| Trigger-boundary fixtures, external and optional | re-run [`evals/trigger_cases.json`](evals/trigger_cases.json) with the `kang-meta-skill` trigger-eval runner | 10/10 cases, `pass_rate 1.0`; the stored [`reports/trigger-eval.json`](reports/trigger-eval.json) reproduced byte-for-byte |\n\n<details>\n<summary>What the test suite is, and what it is not</summary>\n\n- It is a real consistency suite, not an existence-check stub. It cross-compares the version across seven files, resolves relative link targets across every Markdown file in the tree, compares the five README language switchers against each other, rejects a second `SKILL.md`, and guards against machine-specific home paths.\n- It does **not** exercise the protocol. No test reads any `examples/*.example.yaml`, and no test validates a record against the schemas in [Shared Contracts](references/contracts.md). The D0–D3 rule, the `safe_to_continue` preconditions, the Result-State enum, and the Capability-Profile contract are all unenforced prose.\n- Nothing runs automatically. There is no CI: [`.github/`](.github/PULL_REQUEST_TEMPLATE.md) contains issue and pull-request templates only, so the suite, the external validator, and the trigger fixtures never run on a push, pull request, or release. The nine items in `manifest.json` `release_gates` are manual commitments, not automation.\n- The trigger fixtures are keyword-scoring fixtures over ten recorded cases against a `0.34` threshold — four `should_trigger`, three `should_not_trigger`, three `near_neighbor`. They are a recorded fixture, not a model-scored evaluation, and they say nothing about runtime behaviour.\n- Known coverage gap: the link check uses a negative-lookbehind pattern that does not suppress image-badge wrappers, so badge target links are not link-checked. The badge targets used here were verified by hand.\n\n</details>\n\n### Maintainer-reported Pilot evidence\n\nThe maintainer reports bounded Pilot observations for: fresh-session recovery; project identity recovery; authority → canonical repository → live Git recovery; clean-state takeover; recovery when authority was stale or the working tree was dirty; safe STOP behaviour when continuation was not justified; and more than one runtime under specific tested conditions.\n\nBoth limits are stated by the repository itself:\n\n- These observations are **maintainer-reported**. No project name, per-case date, runtime log, fixture, or reproduction bundle is published here, and [Validation and evidence boundaries](docs/validation.md) states that the Pilot's private paths and conversation data are intentionally withheld. No benchmark score or universal success rate is inferred from them.\n- [`reports/prior-art-research.md`](reports/prior-art-research.md) records that no comparative prior-art evaluation was run for this documentation-only release.\n\nThis is not proof for every agent, runtime, project type, or permission model.\n\n## Example: one handoff, end to end\n\nThe `.agent-collab/` directory below is a suggested project-local layout, not a required service or global registry.\n\n```bash\nmkdir -p /path/to/my-project/.agent-collab\ncp examples/minimal-project/PROJECT_IDENTITY.example.yaml /path/to/my-project/.agent-collab/PROJECT_IDENTITY.yaml\ncp examples/minimal-project/MANIFEST.example.yaml /path/to/my-project/.agent-collab/MANIFEST.yaml\n```\n\nEdit the placeholders so the identity is explicit:\n\n```yaml\nproject_id: my-project\nauthoritative_entry: docs/project-authority.md\nrepository_or_workspace: https://github.com/example/my-project\nstatus: verified\n```\n\n### Agent A: do the authorized work\n\nThe contract is language-independent — one of the ten shipped trigger fixtures is written in Chinese — and the request is ordinary natural language:\n\n```text\nUse kang-agent-collab for project_id my-project. Read the project identity and\ncurrent Manifest, verify the live Git state, complete the allowed task, and\nproduce a handoff if another agent must continue.\n```\n\nThe agent should identify the project, read the smallest necessary authority, verify Git independently, work only inside the Manifest, and return evidence.\n\n### Hand off\n\nStart from [the handoff example](examples/handoff-example/HANDOFF.example.yaml) and its matching [takeover check](examples/handoff-example/TAKEOVER_CHECK.example.yaml). A useful engineering handoff records the exact branch and full HEAD, working-tree state, completed evidence, breakpoint, next action, and anything the next agent must not do.\n\n### Agent B: take over\n\n```text\nTake over project_id my-project using the current handoff. Re-read the\nauthoritative entry, re-check the repository and Git state, classify drift,\nand continue only if safe_to_continue is yes.\n```\n\nAgent B must verify the handoff against the current authority and live Git state. It must stop on identity conflict, unknown dirty-change ownership, missing permission, or material drift that cannot be isolated.\n\nAll three example directories are listed in [`examples/`](examples/README.md), and their `.example.yaml` files are placeholders rather than canonical contracts — if an example conflicts with [Shared Contracts](references/contracts.md), the contract wins.\n\n## When to use it, and when not to\n\nUse it when a task requires one or more of:\n\n- resuming a project from shared memory and Git;\n- verifying project identity or current engineering state;\n- preparing or consuming a cross-agent handoff;\n- recording a bounded write-back candidate;\n- recovering an interrupted task without full chat history.\n\nDo not use it to choose agents, delegate roles, schedule work, create infrastructure, or grant permissions. It is not an orchestrator, scheduler, message bus, database, memory server, vector store, registry, dashboard, automatic write-back service, or agent-selection layer, and it does not manage worktrees.\n\n**Team composition is a different job.** The canonical Skill contract states the boundary in [SKILL.md](SKILL.md): *\"If team composition or specialist delegation is the job, route to `kang-agent-workforce`; that Skill may reference this contract for state transfer.\"* In one line: **Workforce defines the team. Collab protects the handoff.** That is a scope statement recorded in the Skill contract, not a dependency — no sibling project is imported, validated against, or required by this repository. The boundary is deliberate: the shipped trigger fixtures classify \"choose an agent and delegate roles for a new product team\" as `should_not_trigger`.\n\n## Safety model\n\nThe Skill stops rather than guessing when:\n\n- project identity conflicts or is ambiguous;\n- risky work lacks scope, acceptance criteria, write paths, or permission;\n- dirty-change ownership is unknown (`D3`);\n- required evidence cannot be produced;\n- continuation would exceed the Manifest or alter another agent's work;\n- credentials would need to enter a handoff, shared memory, or Git.\n\nIt does not automatically write to shared memory, manage worktrees, select agents, schedule tasks, or perform orchestration. The default permission in [`manifest.json`](manifest.json) is read-only recovery and verification; file writes require current task permission, commits require the Manifest or explicit permission, pushes require explicit publication permission, and shared-memory writes are candidate-only unless explicitly authorized.\n\n## Quick start\n\nThis is a generic setup. Runtime-specific Skill loading varies, so verify the loading mechanism in your agent or harness.\n\n### Prerequisites\n\n- [ ] The receiving runtime can read the root `SKILL.md` and its relative references.\n- [ ] The runtime has explicit access to the adopting project's authority and repository.\n- [ ] Git is available when engineering state must be verified.\n- [ ] Write, commit, push, deployment, network, and cost permissions are stated separately.\n\n### 1. Get the protocol\n\n```bash\ngit clone https://github.com/KanG-ciyuan/kang-agent-collab.git\ncd kang-agent-collab\n```\n\nPoint your agent at the repository's canonical [SKILL.md](SKILL.md). If your runtime has a Skill directory, copy or link this repository according to that runtime's documented mechanism. [Runtime integration](docs/runtime-integration.md) lists three generic patterns: repository reference, Skill directory, and instruction attachment.\n\nFor installers that support the Agent Skills registry format, the expected command is:\n\n```bash\nnpx skills add KanG-ciyuan/kang-agent-collab\n```\n\nThis installer path is runtime-dependent and has **not** been independently verified here — [`manifest.json`](manifest.json) still lists the isolated installation check as an open release gate. Run it as an isolated install check before relying on it. The Git clone and direct `SKILL.md` reference above are the generic path.\n\n### 2. Verify the package\n\nBasic repository checks require no service:\n\n```bash\npython3 -m unittest discover -s tests -v\n```\n\nIf you use `kang-meta-skill`, its validator can inspect the package:\n\n```bash\npython3 /path/to/kang-meta-skill/scripts/validate_skill.py .\n```\n\nReplace the path with your installed validator location. This command validates package structure; it does not prove runtime compatibility or Pilot outcomes.\n\n## Limitations\n\n- The Skill does not synchronize memory or Git; agents and users perform those actions with their available tools.\n- It cannot make an inaccessible repository, authority, or runtime capability available.\n- It does not resolve ambiguous ownership or permission automatically.\n- Runtime-specific installation and tool behavior must be verified in that runtime.\n- Pilot evidence is bounded and is not a guarantee of autonomous recovery in unfamiliar environments.\n- Nothing in this repository enforces the protocol at runtime: there is no CI, no validator of its own, and no test that checks an example record against a contract schema.\n- The translations are not all equivalent: `README.zh-CN.md` is a full translation of this file, while `README.es.md`, `README.ja.md`, and `README.ko.md` are condensed and currently omit the Prerequisites, Troubleshooting, and FAQ sections. Treat this English README as the complete reference.\n\n## Troubleshooting\n\n| Symptom | Likely cause | Safe action |\n|---|---|---|\n| The agent cannot find the Skill | The runtime does not discover this repository layout | Point it directly to the root `SKILL.md` or use the runtime's documented Skill directory |\n| Authority and repository identity conflict | A pointer is stale or the wrong project was selected | Set identity to `to_verify` and request the maintainer's decision |\n| Handoff says clean but Git is dirty | State changed after the handoff | Recheck ownership and classify drift; never reset unknown changes |\n| The runtime can push but the task does not mention publication | Capability was mistaken for permission | Keep work local and request explicit permission |\n| Shared memory is inaccessible | The path or integration is unavailable in this session | Request the smallest required entry instead of guessing |\n\n## Repository structure\n\n<details>\n<summary>Show the tracked tree</summary>\n\n```text\n.\n├── SKILL.md                          # The one canonical Skill entrypoint\n├── manifest.json                     # Package metadata, permissions, release gates\n├── references/\n│   ├── contracts.md                  # Canonical contract definitions (the normative spec)\n│   └── capability-profiles.md        # Dated runtime observation record\n├── docs/\n│   ├── architecture.md               # Mental model, recovery chain, non-components\n│   ├── runtime-integration.md        # Integration patterns and per-runtime notes\n│   └── validation.md                 # Evidence classes and claim boundary\n├── examples/                         # Generic, path-free placeholder templates\n├── agents/interface.yaml             # Minimal discovery metadata\n├── tests/test_repository.py          # Five repository-consistency tests\n├── evals/trigger_cases.json          # Ten recorded trigger-boundary fixtures\n├── reports/                          # Release-process records and stored eval output\n├── .github/                          # Issue and pull-request templates (no workflows)\n├── README.md                         # English canonical README\n├── README.zh-CN.md                   # Simplified Chinese\n├── README.ja.md                      # Japanese (condensed)\n├── README.ko.md                      # Korean (condensed)\n├── README.es.md                      # Spanish (condensed)\n├── CHANGELOG.md\n├── CONTRIBUTING.md\n├── SECURITY.md\n├── CODE_OF_CONDUCT.md\n└── LICENSE                           # MIT\n```\n\n</details>\n\nThe repository has exactly one canonical `SKILL.md`. Translated README files explain the protocol but do not create translated Skill contracts or additional authorities.\n\n## Documentation\n\n- [Architecture and mental model](docs/architecture.md)\n- [Runtime integration](docs/runtime-integration.md)\n- [Validation and evidence boundaries](docs/validation.md)\n- [Shared contracts](references/contracts.md)\n- [Capability profiles](references/capability-profiles.md)\n- [Examples](examples/README.md)\n- [Contributing](CONTRIBUTING.md)\n- [Security policy](SECURITY.md)\n- [Changelog](CHANGELOG.md)\n\n## FAQ\n\n<details>\n<summary>Does this require a server or database?</summary>\n\nNo. It is a file-based Skill and protocol. You may use an existing shared-memory system, but the protocol does not operate one.\n</details>\n\n<details>\n<summary>Is this a multi-agent framework?</summary>\n\nNo. It does not choose agents, route tasks, schedule work, or run a message bus. It only defines how project state is recovered and handed over.\n</details>\n\n<details>\n<summary>Can any AI agent use it?</summary>\n\nPotentially, if the runtime can read the contract and access the required project evidence. That must be verified per runtime; universal compatibility is not claimed.\n</details>\n\n<details>\n<summary>Is Obsidian required?</summary>\n\nNo. Obsidian is one possible shared-memory location. A versioned document or another accessible authority can serve the same role.\n</details>\n\n<details>\n<summary>What happens when memory and Git disagree?</summary>\n\nLive Git remains the engineering truth. If the disagreement creates an identity conflict or unsafe drift, the agent stops and requests the minimum missing decision.\n</details>\n\n## Contributing\n\nFocused improvements to the contracts, examples, runtime evidence, and documentation are welcome. Claims about a runtime must include the runtime identity, date, tested capabilities, conditions, and missing evidence. See [CONTRIBUTING.md](CONTRIBUTING.md).\n\n## Security\n\nDo not place tokens, passwords, cookies, private keys, authorization headers, or private local paths in Manifests, Handoffs, shared memory, examples, issues, or commits. See [SECURITY.md](SECURITY.md) for private reporting guidance.\n\n## Project philosophy\n\nKeep it small. Improve contracts, examples, and evidence before adding machinery. If a proposed feature needs a scheduler, database, dashboard, registry, server, or orchestration layer, it probably belongs in another project.\n\n---\n\n## Part of the Kang Open-Source AI System\n\nThis project is one part of an evidence-driven system for enterprise AI transformation,\nagent collaboration, and AI-native product delivery.\n\n| Stage | Project | Role |\n| --- | --- | --- |\n| DISCOVER | [enterprise-ai-diagnostic-skills](https://github.com/KanG-ciyuan/enterprise-ai-diagnostic-skills) | Understand how the business actually works before automating it |\n| DEFINE | [kang-product-architect](https://github.com/KanG-ciyuan/kang-product-architect) | Turn ambiguous requirements into an implementation-ready product contract |\n| DEFINE | [kang-enterprise-process-reviewer](https://github.com/KanG-ciyuan/kang-enterprise-process-reviewer) | Review whether workflows are executable, accountable and recoverable |\n| BUILD & COORDINATE | [kang-agent-workforce](https://github.com/KanG-ciyuan/kang-agent-workforce) | Role-based AI product workforce with explicit handoffs |\n| BUILD & COORDINATE | [kang-agent-collab](https://github.com/KanG-ciyuan/kang-agent-collab) | Agent collaboration and handoff protocol |\n| BUILD & COORDINATE | [kang-frontend-standard](https://github.com/KanG-ciyuan/kang-frontend-standard) | Frontend quality standard for AI-built interfaces |\n| VERIFY | [kang-b2b-ux-auditor](https://github.com/KanG-ciyuan/kang-b2b-ux-auditor) | Can users actually finish the work? |\n| VERIFY | [kang-product-acceptance-auditor](https://github.com/KanG-ciyuan/kang-product-acceptance-auditor) | Independent acceptance of AI-built products |\n| DELIVER | [kang-github-readme](https://github.com/KanG-ciyuan/kang-github-readme) | Evidence-aware README engineering |\n| DELIVER | [kang-ppt-skill](https://github.com/KanG-ciyuan/kang-ppt-skill) | Evidence-aware presentation design |\n\n**Cross-cutting infrastructure:** [kang-meta-skill](https://github.com/KanG-ciyuan/kang-meta-skill) —\nSkill engineering, evaluation and release governance.\n\n**Earlier work:** [ai-agent-rules](https://github.com/KanG-ciyuan/ai-agent-rules),\n[workflow-five-steps](https://github.com/KanG-ciyuan/workflow-five-steps),\n[renovation-agent](https://github.com/KanG-ciyuan/renovation-agent).\n\n## License\n\nReleased under the [MIT License](LICENSE).\n\nCopyright (c) 2026 KanG-ciyuan.\n"}