Run any Skill in Manus with one click

docko-docs

Stars1

Forks0

UpdatedJuly 1, 2026 at 02:56

Documentation and docs-sync guidance for the docko repository. Use when editing README, docs, examples, snippets, onboarding guides, or public positioning so the written guidance stays aligned with the implemented protocol and adapters.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

4riel

4riel/docko

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	docko-docs
description	Documentation and docs-sync guidance for the docko repository. Use when editing README, docs, examples, snippets, onboarding guides, or public positioning so the written guidance stays aligned with the implemented protocol and adapters.

docko Docs

Read first

docs/docs-sync.md
docs/INDEX.md
README.md
The specific guide or example you are changing

Writing rules

Treat protocol docs and schemas as the source of truth.
Do not create a second truth system for command behavior or runtime semantics.
Distinguish clearly between implemented behavior, recommended usage, and roadmap material.
Confirm commands, file paths, and runtime claims in source, templates, or tests before documenting them.
Keep examples short, copy-pastable, and clearly marked when they assume POSIX shell behavior.
Update indexes and contributor-facing docs when adding new guides.
Label runtime examples clearly as one of: shipped Claude asset, manual Codex guidance, or future/planned adapter guidance.
Do not present non-Claude runtimes as first-class implementations unless matching packages, templates, and tests exist.

Verify

Re-read every changed doc against the implementation.
Run pnpm build or pnpm test when the documentation depends on command behavior that changed.
Call out any unverified command examples or environment-specific assumptions.

More from this repository

same repository

docko-adapters

4riel/docko

Runtime adapter guidance for the docko repository. Use when working on runtime-specific packages, template installers, hook flows, snippet assets, runtime documentation, or when extending support beyond the current Claude Code adapter.

2026-07-241

workspace-orchestration

4riel/docko

Use when working in a persistent-slot workspace that uses docko. Covers slot claims, delegated teammate inheritance, and the rule that code edits inside slots/ require an active claim.

2026-07-241

docko-protocol

4riel/docko

Protocol, schema, and CLI contract guidance for the docko repository. Use when changing registry or session shapes, claim and delegation behavior, stale cleanup, authorization, or the public CLI behavior that reflects those semantics.

2026-07-011

docko-repo

4riel/docko

Repository onboarding and working conventions for the docko monorepo. Use when an agent needs to understand the repo layout, choose the right docs or commands, plan a change, or verify work without crossing the core, cli, adapters, docs, and tests boundaries.

2026-07-011

name	docko-docs
description	Documentation and docs-sync guidance for the docko repository. Use when editing README, docs, examples, snippets, onboarding guides, or public positioning so the written guidance stays aligned with the implemented protocol and adapters.

docko Docs

Read first

docs/docs-sync.md
docs/INDEX.md
README.md
The specific guide or example you are changing

Writing rules

Treat protocol docs and schemas as the source of truth.
Do not create a second truth system for command behavior or runtime semantics.
Distinguish clearly between implemented behavior, recommended usage, and roadmap material.
Confirm commands, file paths, and runtime claims in source, templates, or tests before documenting them.
Keep examples short, copy-pastable, and clearly marked when they assume POSIX shell behavior.
Update indexes and contributor-facing docs when adding new guides.
Label runtime examples clearly as one of: shipped Claude asset, manual Codex guidance, or future/planned adapter guidance.
Do not present non-Claude runtimes as first-class implementations unless matching packages, templates, and tests exist.

Verify

Re-read every changed doc against the implementation.
Run pnpm build or pnpm test when the documentation depends on command behavior that changed.
Call out any unverified command examples or environment-specific assumptions.