Operations
Operations Skill
The operational powerhouse you never had headcount for — recurring briefs, a personal stakeholder CRM, meeting prep, two-way commitment tracking, and standing monitors, all backed by TypeDB with Claude as the sensemaker.
Application: Personal Assistant · Database:
alh_personal· Namespace:ops-
Purpose
Ops is built dream-first. The design question is not “what can I automate that I already do?” but “what would I build with unlimited headcount?” — a daily cross-department overview nobody currently compiles, a morning P&L-style read before coffee, a relationship tracker that briefs you before every meeting, status synthesis across ten channels you never manage to read. Every recurring brief records that wish as its ops-dream-rationale, so it always remembers the job it was created to do.
The counterweight to dreaming big is the manual-before-automate iron rule: a brief is never automated before it has been produced by hand and actually consumed for one to two weeks. Specs move designed → trial → active → retired, and the CLI enforces it — log-brief --automated is refused while a spec is designed or trial, and promote-spec fails unless the manual trial target (default 7 runs) is met. Briefs nobody reads are operational debt and get retired, which the process treats as a success, not a failure.
Five capability areas: briefs (designed, trialed manually, then automated), a stakeholder CRM that holds the intangibles and undercurrents no official CRM will, personalized meeting prep, commitments tracked in both directions (what you owe / what’s owed to you), and standing monitors. Throughout, the split holds: the script stores and queries (JSON to stdout); Claude does the sensemaking.
Capabilities
| Area | What it does |
|---|---|
| Briefs | Design a recurring report as a spec (sections, sources, cadence, dream-rationale, operator primer). Run it manually through a trial, refining as you consume it; promote to automation only once it has earned its read. The lifecycle is enforced in code. |
| Stakeholder CRM | One dossier per person who matters: relationship, current state, history. Log a touchpoint after every meaningful interaction and always capture the undercurrent — mood, hesitation, what was conspicuously not said. The undercurrents are what make later prep non-generic. |
| Meeting prep | Pull all context for the attendees (show-stakeholder / prep-meeting), then Claude writes a real briefing — relationship state, undercurrents, open commitments both ways, talking points, landmines — not a transcript summary. Operator reviews before the meeting. |
| Commitments | Track who owes what by when in both directions (--owed-by me\|them). Harvest them from touchpoints with provenance. Overdue and due-soon items surface every morning; nothing silently drops. |
| Monitors | Standing visibility questions (“Are any key customers going quiet?”) with sources to check. Mark them checked; monitors unchecked for 7+ days surface as stale. Same manual-first spirit as briefs. |
Data Model
Selected entity and relation types from schema.tql (namespace ops-; entities sub alh-domain-thing, notes sub alh-note):
| Type | Purpose |
|---|---|
ops-brief-spec |
A designed recurring brief: cadence, sections, sources, spec-status, trial-runs/trial-target, dream-rationale |
ops-brief |
One produced instance of a spec (brief-date, produced-manually flag for the audit trail) |
ops-dossier |
Stakeholder record — relationship, current-state, history-summary; the personal CRM |
ops-touchpoint |
An interaction log carrying the undercurrent and raw commitments-made text |
ops-commitment |
Who owes what by when — owed-by (me/them), due-date, status (open/done/dropped/overdue) |
ops-monitor |
A standing visibility question with sources, status, and last-checked timestamp |
ops-meeting-prep |
The agent-written prep pack, tied to its meeting title/date and attendee(s) |
ops-primer-note / ops-interview-note |
The operator’s messy brain dump and the agent-interviews-operator record |
alh-person |
The person entity — shared with the career skill (same alh_personal DB, deliberate synergy) |
ops-dossier-about / ops-touchpoint-with / ops-commitment-with / ops-prep-for |
Relations linking each record to its alh-person |
ops-spec-produced |
Relation linking a brief spec to each produced brief instance |
Key Commands
CLI="uv run --project skills/ops python skills/ops/ops.py"
| Command | What it does |
|---|---|
| Synthesis | |
report-today |
Markdown morning brief: briefs due, overdue/due-soon commitments, upcoming preps, stale monitors |
today |
The same morning snapshot as JSON |
| Briefs | |
add-spec |
Design a recurring brief (--name --cadence --sections --sources --dream --primer --trial-target) |
list-specs |
List specs with trial progress and brief counts |
log-brief |
Log a produced brief; --manual increments the trial, --automated is refused during designed/trial |
promote-spec / retire-spec |
Promote trial → active (enforced), or retire a brief nobody reads |
| Stakeholder CRM | |
add-person |
Find-or-create the shared alh-person |
add-dossier |
Create a stakeholder dossier (--person --relationship --current-state --history --primer) |
log-touchpoint |
Log an interaction with its --undercurrent and any --commitments-made |
show-stakeholder |
The pre-meeting context pull: dossier + touchpoints + open commitments + last prep |
list-stakeholders |
CRM table across all dossiers |
prep-meeting / save-prep |
Assemble attendee context JSON; store the agent-written prep pack |
| Commitments | |
add-commitment |
Record who owes what by when (--owed-by me\|them --due --from-touchpoint) |
update-commitment / list-commitments |
Change status/due; filter by --due / --owed-by / --status / --person |
| Monitors | |
add-monitor / list-monitors / update-monitor |
Add a standing question; list; mark --checked or change status |
add-note / audit |
Attach a primer/interview/general note; run declarative quality checks |
How it fits the suite
Ops lives in the Personal Assistant family, so its data sits in the shared alh_personal TypeDB database and its dashboard appears at /ops when alh_personal is selected in the hub’s database switcher. It shares the alh-person entity with the career skill — a person in a stakeholder dossier and a collaborator on a project are the same node. Open commitments, upcoming meeting preps, and live brief specs surface in chief-of-staff’s daily agenda, so the operational picture rolls up into a single morning view.
See the Personal Assistant overview and sibling skills: career, analyst, advisor, scribe, chief-of-staff, and coach.