ops

Files (30)

• plugin.json · .claude-plugin/
• .python-version
• .standalone-db
• SKILL.md
• commitments-board.tsx · dashboard/components/
• okr-board.tsx · dashboard/components/
• specs-list.tsx · dashboard/components/
• stakeholders-table.tsx · dashboard/components/
• today-panel.tsx · dashboard/components/
• touchpoint-timeline.tsx · dashboard/components/
• lib.ts · dashboard/
• page.tsx · dashboard/pages/ops/
• page.tsx · dashboard/pages/ops/stakeholder/[id]/
• route.ts · dashboard/routes/briefs/
• route.ts · dashboard/routes/commitments/
• route.ts · dashboard/routes/monitors/
• route.ts · dashboard/routes/objectives/
• route.ts · dashboard/routes/specs/
• route.ts · dashboard/routes/stakeholder/[id]/
• route.ts · dashboard/routes/stakeholders/
• route.ts · dashboard/routes/today/
• route.ts · dashboard/routes/tree/[id]/
• hub.yaml · dashboard/views/
• stakeholder.yaml · dashboard/views/
• hooks.json · hooks/
• ops.py
• pyproject.toml
• quality-checks.yaml
• schema.tql
• skill.yaml

SKILL.md (first lines)

# Ops — The Operational Powerhouse

Not "automate what I already do" but **"what would I build with unlimited headcount?"**
Recurring briefs with a manual-before-automate iron rule, a personal stakeholder CRM
that holds the intangibles no official CRM will, personalized meeting prep, commitment
tracking in both directions, and standing monitors.

Script stores/queries (`ops.py`, JSON to stdout); Claude does the sensemaking.
All data lives in the shared `alh_personal` TypeDB database — people (`alh-person`)
are shared with the career skill deliberately.

## Quick Start

```bash
CLI="uv run --project skills/ops python skills/ops/ops.py"

# Morning ritual
$CLI report-today                       # Markdown morning brief
$CLI today                              # same data as JSON

# Design a brief (dream-first, primer captured)
$CLI add-spec --name "Morning cross-project overview" \
  --cadence daily --sections "wins,risks,decisions-needed,numbers" \
  --sources "slack:#eng,#sales; linear; stripe dashboard" \
  --dream "A chief of staff who reads 10 channels before I wake up" \
  --primer "<operator's messy voice-dictated brain dump>"

# Run it manually during the trial
$CLI log-brief --spec <spec-id> --manual --content-file brief.md

# Stakeholder flow
$CLI add-person --name "Dana Kim"
$CLI add-dossier --person "Dana Kim" --relationship "board member" \
  --current-state "supportive but pressing on burn rate"
$CLI log-touchpoint --person "Dana Kim" --type meeting \
  --content "Q2 review, pushed on hiring plan" \
  --undercurrent "Tense when CFO spoke; checked phone during roadmap — losing patience?"
$CLI show-stakeholder --person "Dana Kim"   # the pre-meeting context pull
```

## Dream-first design

⏸ **OPERATOR CHECKPOINT** — before designing anything, ask the operator:
**"What would you build with unlimited headcount?"** Not "what can I automate?"
Examples of the right altitude:

- A daily cross-department overview nobody currently compiles.
- A morning P&L-style analysis in your inbox before coffee.
- A stakeholder relationship tracker that briefs you before every meeting.
- Status synthesis across 10 Slack channels you never manage to read.

Don't just automate what you already do — build what you never could. Record the
answer in the spec's `--dream` (ops-dream-rationale) so every brief remembers the
wish it fulfils. Always capture the operator's messy brain dump with `--primer`
(voice-dictated is ideal; the agent structures it, never the operator), then
interview the operator (`add-note --type interview --about <spec-id>`): who consumes
this? at what moment of the day? what decision does each section serve? what sources
exist? what's missing?

## Brief lifecycle — THE IRON RULE

**Never automate a brief before running it manually for one to two weeks and
consuming the output.** The lifecycle is `designed → trial → active → retired`,
and the CLI enforces it: **`log-brief --automated` is rejected while the spec is
in `designed` or `trial` status** — you will get an error explaining the rule.

1. **Design** — `add-spec` with `--primer` and `--dream`; interview the operator;
   spec starts as `designed` with `trial-runs 0` and `trial-target 7` (override
   with `--trial-target` for a two-week trial: 10–14). The target counts
   **manual runs logged**, not calendar days.
2. **TRIAL** — every day (or per cadence), the agent + operator produce the brief
   *manually*: agent gathers from the spec's sources, writes the brief, operator
   reads it, then `log-brief --spec <id> --manual --content-file brief.md`. The
   first manual run flips the spec to `trial`; each manual run increments
   `trial-runs`. ⏸ **OPERATOR CHECKPOINT** after each run: did you actually read
   it? Which sections earned their place? Refine `--sections`/`--sources` as you
   learn (edit via a new spec or note the changes in an interview note).
3. **Promote** — `promote-spec` succeeds only when `trial-runs >= trial-target`.
   ⏸ **OPERATOR CHECKPOINT**: only promote if the brief proved its worth. If you
   stopped reading it during the trial, `retire-spec` instead — that is a success
   of the process, not a failure.
4. **Automate** — only now wire up automation via Claude Code triggers/cron/
   scheduled sessions. Concrete example — a scheduled session (cron trigger,
   weekdays 6:30am) whose prompt is:

   > Run `uv run --project skills/ops python skills/ops/ops.py report-today`,
   > then produce the "Morning cross-project overview" brief per its spec
   > (sections/sources from `list-specs`), and store it with
   > `log-brief --spec <id> --automated --content-file brief.md`.

   Or a SessionStart hook that runs `report-today` so every morning session opens
   with the ops snapshot. Automated instances are logged with `--automated`
   (`ops-produced-manually false`) so the audit can prove the rule held.

## Stakeholder CRM

One `ops-dossier` per person who matters: relationship, current state, history
summary. The dossier holds what the official CRM never will.

**Log a touchpoint after every meaningful interaction** — and always capture the
**undercurrent**: what the transcript won't show. Mood. Hesitation. The look on
someone's face when the budget came up. What was conspicuously *not* said. This is
brain-dump territory (operating principle #2): capture even when there's no
immediate use, reduce friction to near zero, speak-don't-type. The undercurrents
are precisely what make future meeting prep non-generic.

```bash
$CLI log-touchpoint --person <id|name> --type call \
  --content "..." \
  --undercurrent "Sounded flat; usually jokes. Something's up with her team." \
  --commitments-made "I promised intro to Sam by Friday; she'll send the deck"
```

If `--commitments-made` is set, harvest each promise into a tracked commitment
(see below) — the CLI reminds you.

## Meeting prep workflow

1. `show-stakeholder --person <X>` — the pre-meeting context pull (dossier +

From sciknow-io/alhazen-skill-personal-assistant, MIT.

More from sciknow-io/alhazen-skill-personal-assistant