netgrade-digitalnetgrade-digital/shared-agents/skills/shared-agents-knowledge/SKILL.md

shared-agents-knowledge

Skill5 starsChanged 5 months agoMITView on GitHub

Sync and use the shared-agents repo (team skills, rules + learnings). Use at session start, when loading team knowledge, searching learnings, or when the user mentions shared-agents, shared learnings, or team knowledge.

In this repository4 other files it gives its agents.
- website/AGENTS.mdAGENTS.md
- website/CLAUDE.mdCLAUDE.md
- capture-learningSkill
- sa-cliSkill

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 5 are distinctive, and 6 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Every session, first step: run sync before anything else.
line 15
Distinctive:
Do not ask the user to sync manually.
line 23
Distinctive:
Do not skip because "probably up to date".
line 24
Very specific:
Read team/learnings/index.yaml for project, domain, tags, versions.
line 32
Very specific:
Prefer learnings whose versions match the project's stack (exact patch or same MAJOR.MINOR.PATCH line).
line 34
Very specific:
If you find a learning partially or fully stale: report an outdated event in addition to your verdict (e.g.
line 51
Very specific:
Add --agent pi|cursor|… (machine identity).
line 54
Very specific:
No secrets in --note / --task (same rule as learnings).
line 55
Distinctive:
Always ask: after substantive tasks:
line 61
Very specific:
Never write directly to approved/.
line 76
Distinctive:
No secrets, API keys, or customer PII in learnings.
line 92

≈ “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

Shared Agents Knowledge

Path: $SHARED_AGENTS_HOME (default: ~/.shared-agents)

Automatic sync (always — no user action)

Every session, first step: run sync before anything else.

"${SHARED_AGENTS_HOME:-$HOME/.shared-agents}/scripts/sync.sh" pull

Pulls Core (~/.shared-agents) and Team (~/.shared-agents/team/) when configured.

Do not ask the user to sync manually.
Do not skip because "probably up to date".
Offline/errors: continue with local files; note only if learnings may be stale.

IDE hooks also pull on session start (Cursor sessionStart, Claude SessionStart). Agent must still sync if hooks may not have run (subagents, headless).

Retrieve (before non-trivial tasks)

Sync (pull) — always first.
Read team/learnings/index.yaml for project, domain, tags, versions.
Grep team/learnings/approved/ for task keywords.
Prefer learnings whose versions match the project's stack (exact patch or same MAJOR.MINOR.PATCH line); treat experimental confidence as hints.
Summarize briefly — do not dump the whole repo.
Record usage events (see below) when you open or apply a learning.

Usage events (machine tracking, no review)

Each approved learning lives in a folder: learning.md (human-gated) + usage.yaml (machine-written). Never edit learning.md for this — events only.

Record events via sa learning report (buffered locally, flushed by sa sync / sa learning push):

When	Event	Example
You open a learning file	`opened` (max 1 per task)	`sa learning report --id <id> --event opened --project <p> --task <slug> --agent <tool>`
Learning actively applied, outcome depended on it	`used`	`… --event used …`
Opened but no fit / no value for this case	`not_used`	`… --event not_used …`
Content stale / wrong / contradicts reality	`outdated` (note required)	`… --event outdated --note "what is stale"`

If you find a learning partially or fully stale: report an outdated event in addition to your verdict (e.g. used + outdated). Do not bury stale findings in prose — the outdated count drives the reviewer view.
Exactly one of used / not_used / outdated per learning per task, at task end.
Add --agent pi|cursor|… (machine identity).
No secrets in --note / --task (same rule as learnings).
Reviewer view: sa learning status (knowledge metrics vs agent telemetry, rule candidates, orphans).
Pending learnings are never tracked. Events for removed learnings are quarantined automatically.

Capture (after non-trivial tasks — ask first)

Always ask after substantive tasks:

„Soll ich ein Team-Learning in shared-agents anlegen?"

User says	Action
Yes / „ja" / „learning speichern"	Write to team `pending/` (see below)
No	Do nothing

Also capture when user explicitly asks anytime.

When writing:

Activate skill capture-learning.
Resolve path: sa pending path YYYY-MM-DD-short-slug (see docs/canonical-paths.md — never workspace-relative; not in Core-Repo).
Never write directly to approved/.
Remind user: teammate runs sa review → approved/ → then all agents can use it.

For shell commands (install, review, pending push): skill sa-cli or run sa help.

Headless agents (OpenClaw)

Wrap commands with entrypoint (sync then exec):

"$SHARED_AGENTS_HOME/scripts/agent-entrypoint.sh" <your-agent-command>

Or first line of agent run: sync.sh pull.

Boundaries

No secrets, API keys, or customer PII in learnings.

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.

Reviews can't be read right now.

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