em-core v0.8.1 Foundation

The shared foundation for all Qualitara EM tooling: the em-manifest configuration standard, the onboarding command, and the cross-cutting worker skills every other plugin builds on. Install this first.

Problem it solves: stops every automation from reinventing config, identity, and Notion-write logic. One config standard, one onboarding flow, and shared low-level workers so the whole toolkit stays consistent.

/em-setupCommand

One-time interactive onboarding that builds or updates em-manifest.json - the single config every em-* skill reads. Captures the EM's identity and resolves each account's friendly database names into Notion data-source ids.

Reference - what it brings, its process, and what it needs
BringsThe one file that unlocks the whole toolset; the EM never hand-copies a database id. Stays local, never committed.
Process
  1. Check for an existing manifest; offer update / restart / cancel.
  2. Gather EM identity (name, work email, task DB, output dir).
  3. Resolve each account's DB roles via Notion search.
  4. Write JSON, read back, confirm it parses.
NeedsNotion MCPmanifest template
em-task-managerUser skillWorkerHeavy · ~80-300k

The single gatekeeper for writing, updating, completing and querying tasks in JP_TASKS. Owns the schema, prioritization formula, dedup and due-date defaults. Three modes: API (machine), Audit (interactive review), Manual (conversational "add a task").

Reference - what it brings, its process, and what it needs
BringsEvery task - from any skill or agent - lands deduped, prioritized and consistently shaped. Plus hands-on audit tooling (stale checks, duplicate merges, 1:1 walkthrough).
Process
  1. Load & validate manifest config.
  2. Route to API / Audit / Manual from the input.
  3. Dedup on Source Key; apply priority & due defaults.
  4. Return JSON, a markdown summary, or a new task URL.
NeedsNotion MCPtask_database_id
em-identity-resolverWorkerLight · ~5-20k

Resolves a name / email / handle to a single Notion Stakeholder or Teammate page, scoped to one account, via a deterministic 5-step ladder. The first step before any profile write - refuses to guess, returning needs_human on ambiguity.

Reference - what it brings, its process, and what it needs
BringsOne source of truth for "who is this?" across the toolkit; prevents wrong-person writes by surfacing candidates instead of guessing.
Process
  1. Take queries (each requires an account).
  2. Walk the resolution ladder applying scoping rules.
  3. Return match, ambiguous + candidates, or no-match - as JSON. Never writes.
NeedsNotion MCP (read-only)
account-changelogUser skillWorkerMedium · ~20-80k

Writes one human-readable row to the Account Changelog for any meaningful change. Mode A takes a JSON payload (silent, called by risk and OKR skills); Mode B is a 5-question interactive Q&A for humans.

When to use it
record that we added/removed a stakeholdernote the engagement stage changelog this to the account changelog
Reference - what it brings, its process, and what it needs
BringsAn auditable, append-only history per account (stakeholders, risks, OKRs, NPS, ownership) that surfaces on the account and engagement pages.
Process
  1. Detect mode (JSON vs Q&A).
  2. Resolve account / engagement to page ids.
  3. Create the row with Change Type + Source.
  4. Return the new entry link. Failure never rolls back the caller.
NeedsNotion MCPaccount_changelog_db
notion-writingWorkerLight · ~5-20k

Standardizes how any agent writes to Notion. Mode 1 is machine-readable (max density, parseable, for AI-to-AI handoffs like the daily digest); Mode 2 is human-readable (Swiss design - grid, typographic hierarchy, semantic color) for pages a person reads.

Reference - what it brings, its process, and what it needs
BringsAgent-written Notion pages come out either reliably machine-parseable or cleanly scannable - consistent structure, color meaning and typography across every automation.
Process
  1. Choose mode by reader (agent vs human).
  2. Fetch the enhanced-markdown spec before writing.
  3. Apply the mode's layout rules (metadata block + tables, or grid + semantic callouts).
NeedsNotion MCPmarkdown spec resource
em-setupUser skillLight · ~5-20k

The day-one bootstrap: builds or updates the EM's local em-manifest OVERLAY (output_directory root, renderer locations, Tability workspace) and rebuilds the merged em-manifest.json so every other em-* skill can resolve identity and accounts.

Reference - what it brings, its process, and what it needs
BringsA working toolkit on day one - identity, accounts and engagements resolve correctly instead of half the toolkit silently failing on a missing config key.
Process
  1. Check for an existing overlay; offer update / restart / cancel.
  2. Gather the file-only overlay fields (output dir, renderers, Tability workspace).
  3. Rebuild the merged em-manifest.json; seed a first account/engagement pointer if unset.
NeedsReadWriteEditBash