collective-coord
Use when an org role acts as collective intelligence coordinator and must merge what several agents found into one reconciled, retrievable knowledge store. Read before write, origin tags for rollback, and recording unresolved contradictions.
- License 许可
- Apache-2.0
- 所属仓库
- monoes/monomind
- 最近更新
- 2026-11-10
- Stars
- ★ 23
- Forks
- 2
01 前言 Front Matter
- name
- collective-coord
- tags
- [ "operations", "coordination", "agents" ]
- tools
- []
- source
- https://github.com/monoes/monomind
- license
- Apache-2.0
- description
- Use when an org role acts as collective intelligence coordinator and must merge what several agents found into one reconciled, retrievable knowledge store. Read before write, origin tags for rollback, and recording unresolved contradictions.
03 SKILL.md 正文
Collective Intelligence Coordinator — Best Practices
Focus
Turns what several agents each found separately into one coherent, retrievable body of knowledge — the shared store other agents and later sessions actually read from.
Best practices
- Read before writing: check existing entities/vocabulary before minting new ones. Reusing an existing name is worth more than a precise-but-duplicate new one.
- Reconcile, don't concatenate — two agents reporting on the same subject should produce one entry, not two. Where they agree, merge; where they conflict, go back to the evidence each cited and decide.
- Persist only durable insight — entities, relationships, and rules that will still be true next month. Session narration, task status, and one-off observations don't belong in shared long-term knowledge.
- Tag every write with its origin (session/task id) so a bad ingest can be traced and undone without touching everything else.
- Close the loop: when retrieved knowledge materially helped a task, record that feedback so future retrieval ranks it appropriately.
- If a contradiction can't be resolved from available evidence, record the disagreement as the finding, with both positions stated — a hidden contradiction is worse than an open one.
Common pitfalls
- Treating multiple agents as having a live shared mind — they don't; the only real substrate is persistent storage others can later read, and quality depends entirely on how well it's curated.
- Writing near-duplicate entities under slightly different names, which fragments retrieval and makes the store progressively less useful.
- Fabricating confidence scores or "consensus levels" that nothing actually computed — report what was actually reconciled, not an invented metric.
- Skipping the read-before-write step and letting the store accumulate contradictory claims that no one ever reconciles.
- Persisting transient status ("agent X finished step 3") into durable knowledge, cluttering the store with things nobody will need to retrieve later.
Tools & techniques
- Search the existing knowledge store and its entity vocabulary before every ingest — that's the whole defense against duplication.
- Use an explicit rollback path keyed to the origin tag so any bad batch can be cleanly undone.
- Batch and structure writes (entities/relationships/rules) rather than dumping raw agent output verbatim.
- Periodically consolidate/condense accumulated material so the store stays retrievable instead of growing without bound.
04 同仓库更多 Skills
zk-steward
Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.
writing-plans
Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.
write-spec
Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.
write-query
Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.
workflow-automation
Org role guidance for workflow automation: build and maintain CI/CD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.
workflow-architect
Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.