Skip to content

Metrognome AI-Assisted Workspace

A private library of Claude Cowork plugins that gives every Metrognome team member an AI-assisted version of their job. Plugins encode procedure (SOPs, skills, sub-agents); Google Drive holds shared artifacts. The plugin library mirrors the Metrognome organizational model — Platform services + Pillars + a universal layer — so each function in the org has a home for its AI capability.

Surface

Claude Cowork on the Team plan, desktop app. The shared, org-managed unit is the plugin: bundled skills + sub-agents + connectors + commands, distributed via a private Metrognome marketplace, sourced from a single GitHub repo. Org-managed plugins are read-only to members, keeping SOPs consistent across the team.

Cowork projects are per-user workspaces where individuals run their work.

Knowledge model

Surface Owns Audience
Plugins procedure Team (via AI)
Google Drive artifacts Team + vendors
docs/ vault dev intent Aaron + future devs

Drive is never the canonical source for current state — live state lives in the system that owns it. Drive holds long-form thinking, originals, deliverables, and point-in-time snapshots. See Data access for the source-of-truth hierarchy and Repo + distribution for how plugins reach each source.

Drive structure

Single Google Shared Drive ("Metrognome"), not anyone's My Drive — top-level folders survive personnel changes, members of the drive get default access, and per-folder permissions handle sensitive subtrees.

Classification follows ISO 15489 and the ICRM functional records classification guidance. The classification tree has three structural levels plus a naming convention beneath:

  • Function (top level): the company's primary business responsibilities. 13 folders, alphabetical, no wrappers, no numeric prefixes, no org-chart reflection — discoverable by name without prerequisite knowledge of MG's tier model.
  • Activity (second level): the major work-types within each function. Typically 3–5 per function; collapse to function level when only one activity exists (e.g., Vendors, Studios markets).
  • Case file (third level, inside an activity): a specific instance of work — a property, a recruitment, a campaign, a market, a board cycle. All records about that case live in one folder.
  • Subject-named records (inside case files): files named by concrete subject terms (property name, vendor name, date, fiscal year, ID), per ICRM §3.3.

Do not pre-build sub-folders below the case-file level. Workflow stages (pursuit → acquisition → construction → operations on a single property) live as documents inside the property's case file, named by content + date — not as sub-folders splitting the case file across stages. Splitting a case file across workflow-stage folders is the over-classification anti-pattern documented in ICRM §3.1. Sub-folders inside a case file emerge only when that specific case has enough records to warrant internal organization.

Function Activities (second level)
Archive by year, populated as records age out
Development Buy Box & Strategy · Capital Structure · LP Relations · Markets · Properties
Finance Portfolio · Entity · Location
Legal Corporate · Real Estate · HR Legal · IP
Marketing Brand (incl. Photography) · Campaigns · Content Strategy · Lead Generation
People Hiring · Employees · Compensation · Benefits · Performance
Sales Tour Pipeline · Conversion Analytics · Playbook · Member Agreements
SESHN (empty until SESHN launches; activities emerge from actual records)
Strategy Org Model · OKRs · Board · Planning & Memos · MG OS (EOS) · Meetings
Studios Regional · per-market case files (each market is a case file directly)
Technology Systems · MGCOM · Infrastructure · AI
Templates flat list of template documents
Vendors per-counterparty case files (each counterparty is a case file directly)

Examples of case files in practice:

  • Development/Properties/Cherry City/ — one folder containing LOIs, purchase docs, permits, GC contracts, lease, ops records. Files named by content + date.
  • People/Hiring/2026-Q2 Senior Engineer Search/ — one folder containing JD, sourcing notes, candidate files, interview feedback, offer letter, onboarding plan.
  • Marketing/Campaigns/2026-Spring Membership Drive/ — one folder containing brief, creative assets, performance reports.
  • Studios/Salem/ — one folder for facility-specific records (floor plans, equipment inventory, maintenance log, facility SOPs). Everything else about Salem lives in its canonical function (financials in Finance/Location/Salem/, marketing in Marketing/Campaigns/…, lease in Legal/Real Estate/{property}/).
  • Strategy/Meetings/Weekly Team Huddle 2026-05-12/ — recurring meeting case file containing notes, recording, action items. Each meeting is its own case file under {Function}/Meetings/. Domain-specific recurring meetings live in their owning function (Marketing/Meetings/…, Sales/Meetings/…).

Ownership determines canonical home, not subject. A Cherry City marketing photo lives in Marketing/Brand/Photography/ because Marketing creates and maintains it, not in Studios/Cherry City/ because of what it depicts. A marketing plan for a specific studio lives in Marketing/Campaigns/. A landlord contract lives in Vendors/{landlord}/ regardless of which property they serve. Subject (Salem, Cherry City, a vendor name) is metadata for retrieval, not a containment axis.

Cross-cutting artifacts live in their canonical home (the function where the work actually happens) and surface elsewhere via shortcuts. A Salem lease lives in Legal/Real Estate/{property}/; shortcuts from Development/Properties/{property}/, Studios/Salem/, and Vendors/{landlord}/ make it discoverable without granting access through navigation.

Permissions live on the canonical file, never on shortcuts. Shortcuts are navigation, not sharing — clicking one without underlying access shows a request-access screen. External parties (vendors, landlords, lenders, lawyers) get access to either the specific files they need or a dedicated external-shared subfolder like Legal/Real Estate/{site}/external/, never via shortcut.

Org-language framing (pillars, platform services, the deck's tier model) lives in plugin READMEs, Strategy/Org Model/, and team communication surfaces — not duplicated as a parallel folder hierarchy. The Drive structure is divorced from corporate hierarchy per ICRM and ISO 15489 §8.3.

The authoritative convention document — written as an ISO 10013-shaped SOP with doc control, scope, roles, and revision history — lives at the root of the Metrognome shared drive as README — Metrognome Shared Drive Conventions. The team-facing canonical SOT; this spec is the dev-facing context.

Data access

Drive is never the canonical source for current state. Each kind of data lives in the system that owns it, and plugins reach those systems via MCP servers:

Need Source Reached via
Operational state (members, access, hardware, door codes) MG app Custom MG-hosted MCP, declared in mg-app/.mcp.json
Analytical / enriched (revenue, MRR, retention, bookkeeping, ad performance) Metabase Cowork's Metabase connector, declared in mg-analytics/.mcp.json
Raw financial events (vendor invoices, SaaS payments out, banking) Stripe / Mercury / QuickBooks SaaS connectors declared in mg-finance/.mcp.json
Observability (errors, performance, releases) Sentry Sentry connector declared in mg-technology/.mcp.json
Communications + scheduling (Drive, Gmail, Calendar, Slack, Asana, GitHub) Multiple SaaS + MG Google Workspace Connectors declared in mg-productivity/.mcp.json
Artifacts, originals, snapshots Drive MG Google Workspace connector (declared in mg-productivity/.mcp.json)

If a snapshot is worth keeping (board record, audit cycle, milestone), a skill writes a dated artifact to Drive — but the live answer always comes from the source. Drive never replaces the source for current state.

MG plugins encode MG-specific business knowledge as skills, sub-agents, and slash commands; they reach external services by bundling connector configs (.mcp.json) rather than reimplementing MCPs. Each plugin lists exactly the remote MCP URLs its skills use. The canonical pattern to mirror is anthropics/knowledge-work-plugins/productivity. The dependencies field in plugin.json is a separate mechanism for inheriting skills/agents from another plugin in the marketplace — not for accessing MCPs.

Repo + distribution

A single GitHub monorepo, mg-plugins. The marketplace manifest at the root lists every plugin and is registered as the private Metrognome marketplace inside Cowork. Auto-install assignment varies by role.

mg-plugins/
├── .claude-plugin/marketplace.json      # private MG marketplace manifest
├── README.md
└── <plugin-name>/
    ├── .claude-plugin/plugin.json       # required manifest (name, version, description, dependencies)
    ├── .mcp.json                        # remote MCP servers (connectors) the plugin needs — usually present
    ├── settings/*.local.md.example      # MG-specific config templates
    ├── skills/<skill-name>/SKILL.md     # auto-fired knowledge (+ optional references/)
    ├── agents/<agent-name>.md           # sub-agents (peer to skills)
    ├── commands/*.md                    # explicit slash commands
    └── README.md

Per-plugin shape mirrors anthropics/knowledge-work-plugins. Plugins stay small (typically 2–8 skills). Cross-cutting concerns get their own standalone plugin (the universal layer below).

A plugin is the scope unit for capability. Its .mcp.json MCP servers, hooks, sub-agents, and skills all share the same access within the plugin — there is no per-sub-agent MCP scoping or per-sub-agent permission override inside a plugin (those frontmatter fields are ignored on plugin-shipped agents). If two capabilities need different MCP sets or different guardrails, they belong in different plugins.

Most MG plugins ship their connectors directly in .mcp.json — remote HTTP MCP servers identified by URL. This is the canonical pattern used by anthropics/knowledge-work-plugins/productivity. Plugin dependencies via plugin.json are reserved for cases where another plugin ships reusable skills or sub-agents an MG plugin wants to inherit, not for accessing MCP servers.

Auth patterns supported by .mcp.json:

  • OAuth (the common case for SaaS connectors): triggered automatically when the remote MCP returns 401 with WWW-Authenticate. The user authorizes once per Cowork session via PKCE; no flag needed in .mcp.json. An optional oauth object in the server config customizes the flow (clientId, callbackPort, scopes, authServerMetadataUrl) only when pre-registration is required (e.g., Slack).
  • Static tokens (e.g., GitHub PAT): a headers object with Authorization: Bearer ${ENV_VAR} in the server config, or values supplied via userConfig in plugin.json with sensitive: true and stored in the OS keychain.
  • Name-based (first-party Cowork connectors with dynamic endpoints): omit the url field; the MCP server name in .mcp.json is matched against the Cowork connector directory.

No central MDM channel is required.

Library shape

Tracks the org model from the Metrognome Organizational Model deck. Some slots are aspirational and are built when the corresponding pillar is staffed.

Universal (auto-install for everyone)

Plugin Why universal
mg-brand-voice Everyone communicates externally; voice consistency required across the org
mg-productivity Everyone uses Asana, GCal, Gmail, Slack, Drive; baked-in Metrognome conventions (Asana Size field, project_id + section_id, comprehensive single tasks)
mg-analytics Wraps the existing Metabase plugin with MG-specific named-view skills for everyone who makes decisions from data — revenue, retention, programming, marketing analytics, city metrics
mg-app Hosts the MG-app MCP — raw operational state (members, access, hardware, door codes, etc.) reachable from any plugin

Platform services

Plugin Audience
mg-technology Aaron
mg-marketing Aaron
mg-finance Aaron + Paul + Nic
mg-admin Nic primarily; Aaron + Paul

Pillars

Plugin Audience Status
mg-development (real-estate / capital) plugin unbuilt; activity ongoing
mg-studios Juan + 2 market CMs active
mg-seshn (community / curriculum) slot reserved

mg-studios includes member experience, programming, facility ops, physical access (UniFi / Schlage diagnostics), and local vendor coordination — all of Pillar 02 from the org deck.

Cross-cutting concerns (pricing, member experience, physical access) live as skills inside the most-relevant pillar/platform plugin, duplicated across plugins where genuinely needed.

Team → install matrix

On Team plan, install levels (required / auto-installed / available / hidden) apply org-wide — group-level overrides are Enterprise-only. This matrix is convention: universals are marked required; role-specific plugins are marked available so each teammate installs what fits, or auto-installed for the audience that uses them with the option to disable for others.

Person Role Plugin set
Paul CEO universal + finance
Nic Ops universal + admin + finance
Juan Customer Management lead universal + studios
Market CM ×2 Frontline customer mgmt universal + studios
Aaron CTO universal + technology + marketing + finance + admin

References