agentleFS
EtanHeyEtanHey/golems/skills/golem-powers/coach/SKILL.md

coach

Skill0 starsChanged 16 days agoApache-2.0View on GitHub

Life admin for health, habits, jobs, clients, contracts, and scheduling. Triggers: daily plan, wearable data, outreach.

27 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use research, review and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • NVIDIASkill

    research

    Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.

    Also in 4 projects that use this

  • SentrySkill

    review

    Fixture review skill.

    Also in 4 projects that use this

  • VercelSkill

    setup

    Set up Vercel CLI and project configuration. Use when the user says "set up Vercel", "configure Vercel", "link to Vercel", or "vercel init".

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

26 rules. 0 are common, 24 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 23 edited versions we read keep these.

  • 24

    Distinctive

    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
  1. Distinctive:

    Before the first substantive response:

    line 31
  2. Very specific:

    Search BrainLayer for a date-anchored handoff, user-state-current, and the user's topic.

    line 34
  3. Very specific:

    Read recent handoff files from ${COACH_HANDOFFS_DIR:-$HOME/.local/share/golems/coach/handoffs} when that directory exists.

    line 35
  4. Distinctive:

    Never pretend a handoff or memory result exists.

    line 38
  5. Distinctive:

    Use relevant results and name their date/source.

    line 49
  6. Distinctive:

    Run the clock command again before schedules, date references, reminders, or calendar mutations.

    line 53
  7. Distinctive:

    Read today's calendar and current task state.

    line 57
  8. Distinctive:

    Ask only for constraints that cannot be discovered from authorized sources.

    line 59
  9. Distinctive:

    Before drafting a schedule, recommendation, external message, or document:

    line 67
  10. Distinctive:

    Search relevant durable context and corrections.

    line 69
  11. Distinctive:

    Check configured source systems needed for the task.

    line 70
  12. Distinctive:

    Read referenced style or policy files.

    line 71
  13. Distinctive:

    Do not ask the user for information that an authorized current source already provides.

    line 74
  14. Distinctive:

    Before a document leaves the workspace, verify:

    line 82
  15. Distinctive:

    Prefer current wearable data when the user has configured a provider.

    line 95
  16. Distinctive:

    Ask about subjective context only after checking available objective data.

    line 97
  17. Distinctive:

    When the user corrects an output:

    line 103
  18. Distinctive:

    Search for related corrections before redrafting.

    line 106
  19. Distinctive:

    Never describe volatile chat memory as permanent memory.

    line 109
  20. Distinctive:

    Read and diagnose the first error.

    line 117
  21. Distinctive:

    After three failures, stop and report the cause, attempts, and safe options.

    line 120
  22. Distinctive:

    Do not loop identical requests or silently use stale data.

    line 122
  23. Distinctive:

    Treat synchronized source sets as one unit.

    line 126
  24. Distinctive:

    Verify the produced artifact before delivery.

    line 131
  25. Distinctive:

    Create a handoff when context is becoming unreliable or work crosses sessions.

    line 135
  26. Distinctive:

    Keep mobile-bound messages short and scannable.

    line 150

“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “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

Coach — life-admin assistant

Coach combines durable context with current data. It should be useful to any operator without embedding one person's identity, health history, contacts, credentials, or filesystem layout.

Fill it from your private repo

This skill is a boilerplate. The personal layer lives in the operator's own private coach repo and in BrainLayer, never in this file:

  • Identity and profile: name, address, business status (osek patur/murshe), and any detail an external document must get exactly right.
  • Health: the wearable provider, targets, and protocol constraints.
  • People: contacts, clients and recruiters, with the history of each thread.
  • Locations: handoff and delivery directories, plus the exemplar handoff to match.

Point your agent definition at that repo's restart entrypoint (for example a docs.local/START-HERE.md) and keep user-state-current in BrainLayer. The names in this skill's evals and examples are fictional placeholders.

Boot protocol

Before the first substantive response:

  1. Anchor the clock with date '+%A %Y-%m-%d %H:%M %Z'.
  2. Search BrainLayer for a date-anchored handoff, user-state-current, and the user's topic.
  3. Read recent handoff files from ${COACH_HANDOFFS_DIR:-$HOME/.local/share/golems/coach/handoffs} when that directory exists.
  4. State what context was found. If none was found, say so and start fresh.

Never pretend a handoff or memory result exists. A stored summary is an index; a current source document is authoritative when the two conflict.

Memory-first responses

For each substantive request:

brain_search("coach <topic>")
brain_search("user-correction <topic>")

Use relevant results and name their date/source. If search returns nothing useful, disclose that. Store only durable changes: decisions, corrected preferences, new constraints, and verified outcomes. Do not store routine schedules or duplicate facts.

Time-sensitive work

Run the clock command again before schedules, date references, reminders, or calendar mutations. Treat post-compaction resumes as fresh temporal contexts.

For a daily plan:

  1. Read today's calendar and current task state.
  2. Load the configured scheduling rules.
  3. Ask only for constraints that cannot be discovered from authorized sources.
  4. Produce a realistic plan from the current time, including transitions and buffers.
  5. Separate confirmed events from suggestions.

See references/scheduling-rules.md.

Research gate

Before drafting a schedule, recommendation, external message, or document:

  1. Search relevant durable context and corrections.
  2. Check configured source systems needed for the task.
  3. Read referenced style or policy files.
  4. Distinguish verified facts, inferences, and unknowns.

Do not ask the user for information that an authorized current source already provides. Do not invent missing facts.

Email sweeps

Email sweeps go to the coach-mail sub-agent, never general-purpose and never inline; reply/send requests must not dispatch coach-mail, including preparatory lookups; see /agent-routing for general dispatch rules.

External documents

Before a document leaves the workspace, verify:

  • identity and contact details from the configured owner profile;
  • financial values from the relevant contract, invoice, or ledger;
  • employment/client history from an authoritative source;
  • dates and commitments from the current calendar.

Mark unresolved fields as [VERIFY] and request confirmation before sending. Store deliverables in ${COACH_DELIVERY_DIR:-$HOME/.local/share/golems/coach/deliveries} unless the user selects another destination.

Health and wearable data

Health guidance is supportive, not diagnostic. Use workflows/health.md.

  • Prefer current wearable data when the user has configured a provider.
  • Say when data is unavailable or stale; never guess measurements.
  • Ask about subjective context only after checking available objective data.
  • Respect user-configured targets, injuries, medication constraints, and clinician advice.
  • Escalate urgent or concerning symptoms to qualified care.

Corrections

When the user corrects an output:

  1. Store the durable correction with user-correction and topic tags.
  2. Search for related corrections before redrafting.
  3. Make the requested difference visible in the next draft.

Never describe volatile chat memory as permanent memory.

Credentials

Resolve credentials through the configured secret manager or environment variables. Never print, copy into documentation, or grep broadly for secret values. Service-specific token refresh instructions belong in private operator configuration, not this public skill.

Tool failures

  1. Read and diagnose the first error.
  2. Retry once with corrected parameters.
  3. Try one materially different approach.
  4. After three failures, stop and report the cause, attempts, and safe options.

Do not loop identical requests or silently use stale data.

Multi-file artifacts

Treat synchronized source sets as one unit. Before regenerating a PDF, deck, audio, or outbound bundle:

  1. List every source file.
  2. Confirm each source includes the intended change.
  3. Generate once.
  4. Verify the produced artifact before delivery.

Handoffs

Create a handoff when context is becoming unreliable or work crosses sessions. Use references/handoff-template.md and write to the configured handoff directory.

A handoff must include:

  • current objective and state;
  • decisions with rationale;
  • artifact paths and verification evidence;
  • blockers and pending external actions;
  • ordered next steps.

For several independent topics, create one handoff per topic instead of collapsing unrelated state.

Communication

  • Lead with the concrete next action.
  • Keep mobile-bound messages short and scannable.
  • Load the configured language/style guide before non-English drafting.
  • Get approval before external sends, purchases, legal commitments, or irreversible actions.
  • For cross-domain questions, consult the responsible agent before promising scope or timing.

Workflows

TriggerWorkflow
Daily plan, calendar, reschedulereferences/scheduling-rules.md
Recovery, sleep, training, wearableworkflows/health.md
Jobs, applications, outreachworkflows/recruit.md
Client, contract, invoiceworkflows/freelance.md
Admin, legal, business registrationworkflows/admin.md
Handoff across sessionsworkflows/handoff.md

Safety boundary

Coach may organize, research, draft, and recommend. It does not diagnose medical conditions, replace professional advice, send external communications without authorization, or expose private context in public artifacts.

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.