agentleFS
Sign inStart free
dadwadw233dadwadw233/team-collab-skills/skills/protocol/SKILL.md

team-collab-protocol

Skill4 starsChanged 6 months agoApache-2.0View on GitHub

Use when the current repo is explicitly governed by team-collab: `obsidian-docs/` exists in cwd/ancestor, repo `AGENTS.md`/`CLAUDE.md` imports team-collab, the cwd is under a registered code/docs path, or the user asks for team-collab handoff/checkpoint/docs governance/Feishu automation. Do not use solely because a global config file exists.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 8 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Use this protocol only from a strong signal:

    line 14
  2. Very specific:

    Read recent _handoffs/, personal 开发记录/, design docs, or the human playbook only when the user task requires that history.

    line 27
  3. Distinctive:

    Do not scan the whole Obsidian vault, all docs, or all memories to orient yourself.

    line 28
  4. Distinctive:

    If multiple references could apply, load the smallest set that covers the task.

    line 29
  5. Very specific:

    Never force-push protected/shared/unclear branches: main, master, release/*, prod/*, docs default branches, other people's branches, or …

    line 52
  6. Distinctive:

    Never git commit --no-verify.

    line 54
  7. Distinctive:

    Never blindly recover from semantic git failures: non-fast-forward, protected-branch rejection, permission denied, hook/gitleaks failure, …

    line 55
  8. Distinctive:

    Never write secrets, credentials, customer private data, unreleased internal endpoints, or unannounced commercial secrets into docs.

    line 56
  9. Distinctive:

    Do not fabricate a handoff for an empty session.

    line 58
  10. Distinctive:

    Do not modify another owner's TODO item without explicit user direction.

    line 60

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Team Collaboration Protocol

Slim runtime entrypoint for team projects using the OPC collective docs architecture. Load only the reference that matches the current task; do not read the whole playbook or vault by default.

Activation

Use this protocol only from a strong signal:

  • obsidian-docs/ exists in the current repo or an ancestor.
  • Repo-root AGENTS.md / CLAUDE.md references team-collab, obsidian-docs, CURRENT/NEXT/RISKS/TODO, _handoffs, or 开发记录/<用户名>/.
  • The cwd is under a registered codePath, docsPath, or docsGitRoot in ~/.team-collab/config.json or legacy ~/.team-docs-config.
  • The user asks about handoff, checkpoint, team progress, docs refresh, team docs workflow, TODO ownership, Feishu automation, docs audit, setup, migration, or normalization.

Weak signal: a global team-collab config exists somewhere. Do not activate from that alone; it is a project registry, not proof that every repo is governed.

Context budget

  • Global/project pointers should only trigger this skill; they should not duplicate protocol details.
  • On normal startup in a team project, read repo-root AGENTS.md and the state quartet only: CURRENT.md, RISKS.md, NEXT.md, TODO.md.
  • Read recent _handoffs/, personal 开发记录/, design docs, or the human playbook only when the user task requires that history.
  • Do not scan the whole Obsidian vault, all docs, or all memories to orient yourself.
  • If multiple references could apply, load the smallest set that covers the task.

Reference router

SituationLoad
Session start, repo orientation, docs sync, setup, onboarding, migration, Feishu, compliance, auditreferences/startup-and-audit.md
$handoff <topic> or /handoff <topic> end-of-session flowreferences/handoff.md
$checkpoint or /checkpoint mid-session snapshotreferences/checkpoint.md
Git sync, push, force-push, conflicts, rejected push, hooks, gitleaksreferences/git-policy.md
Creating or substantially editing project docs, frontmatter, filenames, taxonomyreferences/docs-standards.md
$docs-refresh <audit> / /docs-refresh <audit> or updating Obsidian docs from a stale audit/dev recordreferences/docs-refresh.md
$team-progress <window> / /team-progress <window> or checking teammate progress, blockers, and PR/MR review needsreferences/team-progress.md
Multi-agent opt-in, wave layout, lifecycle overview, or command boundariesreferences/multi-agent.md
$wave (start/enter wave), $digest <slug> (wave status), $gate --pr <n> (merge-gate)references/multi-agent.md / references/gate-check.md
Agent start/checkpoint/finish/close/status files and status schemareferences/agent-status.md
multi-agent gate, plan --check, review summaries, or lint-multi-agentreferences/gate-check.md
Claims, heartbeat/stale state, truth_source, code/docs freshness, or resource conflictsreferences/claim-and-freshness.md
Phase 4 live-session/tmux bind/watch/send/monitor concepts or message ACK safetyreferences/live-session.md
Starting, claiming, completing, blocking, or reassigning TODO itemsreferences/todo-ownership.md

Always-on constraints

  • Never force-push protected/shared/unclear branches: main, master, release/*, prod/*, docs default branches, other people's branches, or unclear ownership branches.
  • Self-owned non-protected working branches may be force-pushed after rebase or cleanup; prefer --force-with-lease and first check branch, status, and upstream.
  • Never git commit --no-verify; never bypass gitleaks or equivalent secret checks.
  • Never blindly recover from semantic git failures: non-fast-forward, protected-branch rejection, permission denied, hook/gitleaks failure, or rebase conflicts must stop and be reported.
  • Never write secrets, credentials, customer private data, unreleased internal endpoints, or unannounced commercial secrets into docs.
  • In docs repos, never git add .; precise-add intended files only.
  • Do not fabricate a handoff for an empty session.
  • Personal dev records go under obsidian-docs/开发记录/<用户名>/; do not create parallel devlog folders.
  • Do not modify another owner's TODO item without explicit user direction.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free