familiar-board-stewardship
Skill75 starsChanged 4 months agoMITView on GitHub
Keep familiar-owned Coven board tasks current and actionable.
In this repository59 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- skills/heygen-skills/CLAUDE.mdCLAUDE.md
- 1passwordSkill
- ask-curlSkill
- boardSkill
- cleanup-unused-filesSkill
- codeflow-maintainerSkill
- codex-session-managerSkill
- coven-astraSkill
- coven-board-entrySkill
- coven-charmSkill
- coven-cloud-maintainerSkill
- coven-codySkill
- coven-echoSkill
- coven-identity-canonSkill
- coven-kittySkill
- coven-parallel-workSkill
- coven-sageSkill
- coven-task-managerSkill
- daily-dev-agenticSkill
- discrawlSkill
- disk-space-optimizerSkill
- epubSkill
- heygen-avatarSkill
- heygen-videoSkill
- heygen-skillsSkill
- higgsfield-generateSkill
- higgsfieldSkill
- linear-issue-managementSkill
- lit-ui-designerSkill
- lobsterSkill
- maintainer-barSkill
- memory-recallSkill
- memory-timeline-managerSkill
- ml-engineerSkill
- nodriverSkill
- ocrSkill
- openclaw-devSkill
- openclaw-trustSkill
- opencoven-designSkill
- OpenCoven Role Creation ProcessSkill
- pr-agentSkill
- project-managerSkill
- prompt-engineerSkill
- prompt-vaultSkill
- research-ingestionSkill
- ritual-dapp-frontendSkill
- rollcallSkill
- security-agentSkill
- skill-scannerSkill
- slidev-deck-pipelineSkill
- tauri-apple-releaseSkill
- threejs-animationSkill
- tinyfish-agent-runSkill
- tinyfish-browserSkill
- tinyfish-fetchSkill
- tinyfish-searchSkill
- tinyfishSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 10 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
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
- Very specific: line 8
Use when a Coven familiar starts work, finishes work, receives durable work, finds follow-up work, or prepares a handoff.
- Distinctive: line 25
Prefer existing assigned cards over inventing new work.
- Distinctive: line 28
If the work is not represented on the board and is durable, create a card with clear acceptance criteria.
- Distinctive: line 33
Update the card when scope changes, blockers appear, or follow-up cards are created.
- Distinctive: line 59
When the roster changes, update this list first, then the wiring block below, so the standard never drifts behind the live workspaces.
- Distinctive: line 64
Create a new card when work is:
- Distinctive: line 82
Before completion, release, or handoff:
- Distinctive: line 88
Leave the card unambiguous for the next familiar.
- Distinctive: line 100
Do not perform external actions merely because a card exists.
- Distinctive: line 103
Do not create noisy micro-cards for transient private thoughts.
- Distinctive: line 104
Do not mark work complete without evidence or a clear skipped-verification note.
- Very specific: line 120
Every familiar workspace consumes this standard as a symlink to the canonical source, mirroring the coven-board-entry convention.
≈ “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.
Files
Familiar Board Stewardship
Use when a Coven familiar starts work, finishes work, receives durable work, finds follow-up work, or prepares a handoff.
Default rule
The Coven board is the shared operational surface. Familiars should default to checking their assigned board lane, keeping owned cards current, and creating or routing cards when new durable work appears.
This skill is runtime-portable. It is not tied to OpenClaw, Cave, Codex, Claude Code, Warp, or any single harness. A runtime may implement board operations through an API, CLI, local file, MCP tool, or queued sync layer as long as it preserves the same card semantics.
Start-of-work check
- List active board cards for the familiar's agent id and relevant project.
- Prefer existing assigned cards over inventing new work.
- Claim or mark the card active before doing substantial work when the runtime supports claims.
- If the work is not represented on the board and is durable, create a card with clear acceptance criteria.
During work
- Update the card when scope changes, blockers appear, or follow-up cards are created.
- Decompose vague parent cards into concrete children before dispatching or executing.
- Route work according to familiar lane:
- Astra: strategy, business map, priorities, decisions, routing.
- Charm: outward-facing language, outreach drafts, public narrative.
- Sage: research, evidence, synthesis, legal/process background.
- Cody: code implementation and verification.
- Kitty: general execution support, cleanup, release readiness, operational sweeps.
- Echo: continuity, retrospection, memory promotion, pattern review.
- Nova: orchestration, system changes, board hygiene, cross-lane routing.
- Salem: guardian and watch — Coven health, session and daemon posture, claims and locks, protected boundaries, and precise escalation.
Roster canon
The eight lanes above are the canonical familiar roster: Astra, Charm, Sage, Cody, Kitty, Echo, Nova, Salem. Route board work to exactly these owners.
codex is a harness/workspace alias, not a familiar — it has no
IDENTITY/SOUL/lane and must not be assigned as a card owner. When board data
carries a codex familiarId, treat it as unrouted and reassign to the correct
lane owner.
When the roster changes, update this list first, then the wiring block below, so the standard never drifts behind the live workspaces.
Adding cards
Create a new card when work is:
- Durable beyond the current chat turn.
- Relevant to another familiar or future session.
- A discovered blocker, dependency, or follow-up.
- A recurring operating responsibility.
Each card should include:
- A specific title with a verb.
- Board/project namespace.
- Assignee or familiar when clear.
- Labels for lane and topic.
- Notes with acceptance criteria and routing context.
- Parent/child links when part of a larger effort.
Completing or handing off
Before completion, release, or handoff:
- Summarize what changed or what was learned.
- Attach proof when applicable: command, test, screenshot, source, artifact, or reason verification was skipped.
- List created child cards or follow-ups.
- Leave the card unambiguous for the next familiar.
Cadence
- At least once per active work session, check assigned board cards.
- During daily or retrospective sweeps, note stale assigned cards, blocked work, and missing cards.
- Weekly, each familiar with an active lane should either advance one owned card, update its blocker/status, or explicitly mark the lane quiet.
Boundaries
- Do not perform external actions merely because a card exists; external sends, account changes, public posts, pushes, merges, and configuration patches still need the normal approval gates.
- Do not create noisy micro-cards for transient private thoughts.
- Do not mark work complete without evidence or a clear skipped-verification note.
Canonical source
Canonical skill source:
OpenCoven/coven/skills/familiar-board-stewardship/Harnesses should consume this directory by symlink or package distribution rather than copying it into OpenClaw-specific workspace skills.
Wiring convention
Every familiar workspace consumes this standard as a symlink to the canonical
source, mirroring the coven-board-entry convention. Do not copy the directory
— edit the canonical source and let every workspace pick up the change.
# Wire the standard into a familiar workspace (idempotent):
ln -s /Users/buns/Documents/GitHub/OpenCoven/coven/skills/familiar-board-stewardship \
/Users/buns/.coven/workspaces/familiars/<familiar>/skills/familiar-board-stewardshipTarget every lane owner in the roster canon: astra, charm, cody, echo, kitty,
nova, sage, salem. Create the workspace skills/ directory first where it does
not exist. codex is excluded — it is a harness alias, not a familiar.
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
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.

