stakeholder-register

name

stakeholder-register

description

Use when the user wants to register a new stakeholder for ongoing reflection — a manager, peer, direct report, or team. Trigger phrases include "add a new stakeholder", "register Jill in managing-across", "I just got a new manager", "I'm now leading the X team", "let me set up reflection for [name]". Creates a persistent file at `~/bettersense-work-reflections/<category>/<slug>.md` that the `stakeholder-reflect`, `stakeholder-due`, and `stakeholder-synthesize` skills will use.

Stakeholder Register

Register a stakeholder so the user can reflect on them over time. This skill is the entry point for the stakeholder-reflection bundle (stakeholder-register, stakeholder-reflect, stakeholder-due, stakeholder-synthesize).

Data location

All stakeholder data lives at $BETTERSENSE_WORK_REFLECTIONS_HOME (default: ~/bettersense-work-reflections/), outside the public repo.

~/bettersense-work-reflections/
├── stakeholders.json        # registry: who exists in which category
├── managing-up/<slug>.md
├── managing-across/<slug>.md
├── managing-down/<slug>.md
├── teams/<slug>.md
└── self/reflections.md      # owned by the self-reflect skill

On first run

If ~/bettersense-work-reflections/ does not exist, create it silently — the full privacy ceremony belongs to user-profile, which is designed to run first. If for some reason user-profile wasn't run, issue a short notice before proceeding:

I'm creating ~/bettersense-work-reflections/ to store your stakeholder files. This directory stays on your local machine only. Set $BETTERSENSE_WORK_REFLECTIONS_HOME if you'd prefer a different location.

Whether or not the root existed already:

1. Create the category subdirectories if missing (managing-up, managing-across, managing-down, teams).
2. Initialize stakeholders.json as {"version": 1, "stakeholders": []} if it doesn't exist.
3. Ensure a .gitignore exists at the root containing *, and a README.md that says:

   Private. Contains candid reflections about real people. Do not commit, share, or back up to public locations. Encrypt the parent disk if you can.

Exit signals

If the user says "stop", "exit", "I'm done", "skip this", "pause", or similar — stop immediately. If a name and category were already captured, offer to save a minimal stub so they can continue later. Don't push for more answers.

In the opening message, add one short sentence: "You can say 'stop' at any time and we'll save what we have."

The register flow

When invoked, walk the user through:

1. Name. Full name as the user thinks of them.
2. Category. One of: managing-up, managing-across, managing-down, teams. (For self, use the self-reflect skill — it's a separate flow.)
3. Role. One sentence. "VP Product, my skip-level." "iOS team lead, peer." "Senior eng on my team, joined Sep 2024." For teams: "Client delivery team, 6 people, primary contact Sarah."
4. Anything worth capturing up front? Optional. Communication style, known sensitivities, the broader relationship context, recent history. Keep it short — this is just seed context, not a full dossier. The reflection sessions will fill in the rest over time.
5. Cadence preference. Optional. Default frequencies are baked into each question (weekly/biweekly/monthly/quarterly/biyearly). If the user wants to override the default cadence for a stakeholder (e.g. weekly check-ins on a struggling report), capture that as a cadence_overrides block.

File format

Slug the name: lowercase, hyphenated, no special chars. "John Adams" → john-adams.md. If a slug collision exists, append a number: john-adams-2.md.

---
name: John Adams
slug: john-adams
category: managing-up
role: VP Product, my skip-level
since: 2026-05-01
cadence_overrides: {}
---

## Background

(Whatever the user offered in step 4. Plain prose. No headings inside.)

---

# Reflections

<!-- The stakeholder-reflect skill appends per-question entries below this line. -->

Update the registry

Append to ~/bettersense-work-reflections/stakeholders.json:

{
  "version": 1,
  "stakeholders": [
    {
      "slug": "john-adams",
      "name": "John Adams",
      "category": "managing-up",
      "role": "VP Product, my skip-level",
      "registered": "2026-05-01"
    }
  ]
}

Operating principles

• Don't over-collect at register time. The registration form is a doorway, not an interview. Three questions, maybe four. The depth comes from the reflection sessions, not the intake.
• Confirm before writing. Always show the user the file path and frontmatter you're about to create, and wait for a yes.
• Suggest the next step. When done, tell the user how to start reflecting: "Try let me reflect on John or run stakeholder-due to see what's on your plate. To list, edit, re-categorize, or archive stakeholders later, just describe what you want — the stakeholder-manage skill handles the lifecycle."
• Privacy is non-negotiable. Re-warn if you notice the user's $BETTERSENSE_WORK_REFLECTIONS_HOME is inside a git repo that isn't already gitignoring it.

Anti-patterns to flag

• User wants to register 10 stakeholders in one go. Fine, but do them one at a time and confirm each. Bulk imports are how typos and miscategorizations sneak in.
• User puts a peer in managing-down because they have informal influence. Push back gently — the categories drive which questions get asked. Influence belongs in the role description; structural reporting drives the category.
• User wants to register themselves. Redirect to self-reflect — different file, different question set.
• User wants to register an external stakeholder (a customer, a vendor). The current question library is internal-org-shaped. Tell them they can still register, but acknowledge the reflection questions will fit imperfectly.