Introducing /life-coach: A Thinking Partner That Knows Its Limits

You have a decision you can’t stop turning over. You’re not in crisis. You don’t need a therapist. But you’ve talked yourself in circles enough times that you can predict every branch of your own internal argument.

What you need is someone to help you think: without steering, without diagnosing, and without pretending the decision belongs to anyone but you.

That’s what the new life-coach Agent Skill does. It’s an open, evidence-aware framework for nonclinical coaching conversations. I shipped it today as part of my Agent Skills catalog. It takes a position you don’t see often in AI tools: deployed coaching services are disabled by default until their capability contract is completed and validated. Without verified host controls, the skill restricts itself to a narrow, no-capability mode.

Let me show you what that looks like in practice.

Demo 1: The Ambivalence Map#

Someone’s thinking about leaving their job. They’re not sure. They’ve been going back and forth for months. Here’s what an exchange could look like when someone brings a hard decision to /life-coach:

User: I’ve been thinking about leaving my job. I keep going back and forth and I don’t know how to get unstuck.

The skill opens proportionately. No intake form. No legal disclaimer wall. Just orientation and a question:

Assistant: I can support a nonclinical coaching conversation while keeping the choices yours. What would make this exchange useful?

The user says they want to understand the pattern. Not decide yet. Just see it clearly. The skill moves into exploration mode and starts building an ambivalence map, adapted from motivational interviewing practice:

Ambivalence Map

Change under consideration: Leaving current role

Reasons I want change:
- I've stopped learning anything new
- The work feels mechanical, not creative
- I used to be excited on Sunday nights; now I dread them

Reasons I don't want change:
- The compensation is excellent
- I'm respected here and have real influence
- Starting over somewhere new means rebuilding trust from zero

Benefits of the status quo:
- Financial stability for my family
- Known quantity: I know how to succeed here

Costs of the status quo:
- I'm slowly checking out mentally
- My best work was two years ago
- I'm starting to resent people I used to enjoy working with

The skill doesn’t push toward action. It doesn’t say “sounds like you should leave.” It reflects what the user gave it, with equal care for both sides. The user sees, organized on a page, the same tangle they’ve been carrying in their head for six months.

That’s not a small thing. Most people never get their ambivalence out of their head and onto a structure that treats both sides as legitimate.

What’s Happening Under the Hood#

The skill uses a method selection reference that labels every technique by its evidence base. The ambivalence map is labeled motivational-interviewing-informed: not because it conducts MI (it doesn’t, and the reference says so explicitly), but because the template draws on MI’s practice of reflecting both change talk and sustain talk with equal care, without covert persuasion.

This is the pattern throughout the skill: use a method, name its source, and be honest about what it can and can’t claim. No generic “research shows” hand-waving. No borrowed clinical authority.

The skill also ships with a capability contract. Most Agent Skills don’t have one. This one does because coaching is high-stakes enough that the deployer should know exactly what’s verified and what isn’t.

The contract is a JSON manifest. Its job: declare which capabilities are enabled, and prove the controls behind each one have been reviewed. The default ships with everything off:

{
  "schema_version": 2,
  "mode": "disabled",
  "deployment": {
    "id": "<deployment-id>",
    "environment": "<environment>"
  },
  "verification": {
    "verified_on": "YYYY-MM-DD",
    "review_due_on": "YYYY-MM-DD",
    "attested_by": "<attestor>",
    "basis_ref": "<verification-record-ref>"
  },
  "accountability": {
    "operator": "<accountable-operator>",
    "support_route": "<support-route>"
  },
  "scope": {
    "adult_only": true,
    "jurisdictions": []
  },
  "evidence": {
    "ai_scope_disclosure_ref": "<evidence-ref>",
    "safety_fallback_ref": "<evidence-ref>",
    "data_notice_ref": "<evidence-ref>"
  },
  "governance_profile_ref": null,
  "capabilities": {
    "coaching_memory":      { "enabled": false, "control_profile_ref": null },
    "sponsored_coaching":   { "enabled": false, "control_profile_ref": null },
    "proactive_contact":    { "enabled": false, "control_profile_ref": null },
    "sensitive_actions":    { "enabled": false, "control_profile_ref": null },
    "human_review":         { "enabled": false, "control_profile_ref": null }
  }
}

Every capability is off. Every reference field is a placeholder. The verification date is the literal string YYYY-MM-DD. This is intentional: the default manifest is structurally valid but explicitly ineligible for activation.

The skill supports three modes:

1. disabled (default). The manifest is valid but coaching won’t activate. The validator returns "status": "VALID BUT DISABLED" with exit code 2.

2. routine-adult-no-coaching-memory. For no-memory, no-sponsor, no-records coaching of consenting adults. All five capability flags must stay disabled. But the deployment, verification, accountability, and evidence fields must be filled in with real values, not placeholders. Two ISO dates are required: verified_on (today or earlier) and review_due_on (on or after verified_on, not in the past). Jurisdictions must be code-shaped: US, GB, US-NC.

3. capability-enabled. For deployments that need coaching memory, sponsors, proactive contact, sensitive actions, or human review. At least one capability must be enabled, and each enabled capability must reference a real control profile. A governance profile is required.

Here’s a completed routine-adult-no-coaching-memory manifest for a hypothetical wellbeing service:

{
  "schema_version": 2,
  "mode": "routine-adult-no-coaching-memory",
  "deployment": {
    "id": "life-coach-web",
    "environment": "production"
  },
  "verification": {
    "verified_on": "2026-07-25",
    "review_due_on": "2026-07-25",
    "attested_by": "Jane Kelly",
    "basis_ref": "governance/verification/2026-07"
  },
  "accountability": {
    "operator": "Wellbeing service operations",
    "support_route": "https://support.example.test/coaching"
  },
  "scope": {
    "adult_only": true,
    "jurisdictions": ["GB", "US-NC"]
  },
  "evidence": {
    "ai_scope_disclosure_ref": "evidence/ai-scope-v3",
    "safety_fallback_ref": "evidence/safety-fallback-v2",
    "data_notice_ref": "evidence/data-notice-v4"
  },
  "governance_profile_ref": null,
  "capabilities": {
    "coaching_memory":      { "enabled": false, "control_profile_ref": null },
    "sponsored_coaching":   { "enabled": false, "control_profile_ref": null },
    "proactive_contact":    { "enabled": false, "control_profile_ref": null },
    "sensitive_actions":    { "enabled": false, "control_profile_ref": null },
    "human_review":         { "enabled": false, "control_profile_ref": null }
  }
}

This says: deployed in production, verified today, Jane Kelly attested, jurisdictions are Great Britain and North Carolina, and every optional capability is explicitly disabled with null control profiles. The validator returns "status": "DECLARATIONS VALID" with exit code 0.

To validate, run:

python3 life-coach/scripts/validate-capabilities.py capability-contract.json --json

The validator catches real mistakes:

• Placeholder values (<replace>, unknown, tbd, todo, yyyy-mm-dd) in active modes fail.
• Non-calendar date formats fail.
• Future verified_on dates fail.
• Review dates earlier than the verification date, or in the past, fail.
• Blank, duplicate, or non-code-shaped jurisdictions (like "United States" instead of "US") fail.
• Enabling a capability without a control profile reference fails.
• Setting a control profile on a disabled capability fails.
• Duplicate JSON keys (two mode fields) are caught at parse time.
• Schema v1 manifests get an explicit migration error instead of a silent fail.

The validator has 22 tests and runs in CI. Completed manifests and operator onboarding state live outside the tracked skill tree; the repo ships a template, not your deployment details. The validator checks declarations, not live implementation. It won’t tell you the crisis route actually works. It will tell you that you haven’t declared one.

A disclaimer, because I mean it: this is an enthusiast-made open source Agent Skill. I am not a therapist, a coach, a lawyer, or anyone you should trust with your mental health. This skill may produce unhelpful, incorrect, or actively weird output. It may fail to recognize situations it should refer. It may, despite every safety clause in its architecture, generate a Spotify playlist you will be embarrassed to explain. If something terrible happens, I am not responsible. If your erection lasts more than four hours, that is a medical issue and you should see a doctor, not an AI coaching framework. Use at your own risk.

Demo 2: From Ambivalence to Experiment#

After mapping the ambivalence, the user is ready to test something. Not commit to leaving. Just a bounded experiment:

User: I think I want to explore whether another kind of role would actually feel different. Can you help me design an experiment?

The skill shifts modes. It pulls in the goal and experiment canvas:

Goal and Experiment Canvas

Goal (in my words): Find out whether a different kind of role
would feel meaningfully better than what I have now.

Goal type: Learning

Success looks like: I can describe at least two specific things
that would need to be different, backed by actual conversations
with people in those roles.

Experiment: Three informational interviews with people who've
moved from my kind of role to something adjacent but different.
One conversation per week. Write notes immediately after each.

First step: Identify three people to reach out to by Friday.

Review date: Three weeks from now.

This isn’t a SMART goal (though you could make one if you wanted). It’s a learning experiment. The output isn’t a decision: it’s data the user can use to make a better one.

The Boundary#

The skill’s safety reference is loaded before every substantive coaching response. It’s not an appendix. It’s a hard override.

The skill distinguishes four response levels:

A. Continue coaching. The topic is voluntary, nonclinical, and within ordinary function.

B. Coach a bounded goal alongside human support. A qualified professional is appropriate, but a clearly separate practical coaching goal remains safe.

C. Pause coaching and refer. Distress, impairment, requested treatment, abuse, addiction, or safeguarding makes coaching unsuitable.

D. Imminent danger or emergency. The host’s verified emergency protocol takes over. The coaching framework defers entirely.

If someone says they’re having thoughts of self-harm, the skill doesn’t try to coach them through it. It stops, names the boundary, and routes:

“Coaching is not the right container for this conversation. I recommend timely qualified human help. Would you like assistance finding resources or preparing questions for a professional?”

The referral preparation template exists for this moment. It’s short. It doesn’t diagnose. It names observations, not disorders. It gets out of the way.

This is where the safety architecture shows its work. Many coaching tools treat every conversation as within scope. This one was designed to know the difference.

Why This Matters#

AI coaching is going to happen. It’s already happening in wellness apps, companion chatbots, and the generic coaching mode shipping inside major platforms. Some of those implementations have serious safety architecture. Many don’t. The question isn’t whether people will use AI to think through hard things. They will. The question is whether the tools they use will be honest about what they are.

I built the life-coach Agent Skill because I couldn’t find a coaching framework that did what I wanted: label its methods honestly, verify its deployment boundaries, and refuse to pretend it was something it wasn’t. It’s an enthusiast-made open source project, not a product. It ships with a validator that catches placeholder evidence. It labels its methods. It knows where it stops. It may also, depending on what model you run it on and what kind of day that model is having, confidently suggest you quit your job and become a beekeeper in rural Vermont. If that happens, that’s between you and your model provider.

If you deploy it, the contract asks you to declare what you’ve actually put in place: jurisdiction, crisis routing, privacy controls, human accountability. The validator will reject placeholders. Whether your deployment honors the contract is, as with all open source, your call.

You can find the skill, its references, templates, evaluator, and capability validator at:

github.com/magnus919/agent-skills

It’s MIT-licensed. Use it, audit it, adapt it. Don’t pretend it’s something it isn’t. The validator will notice. Your Spotify Wrapped, if things go sideways, is your own problem.