Extending Remy - skills, actions, pages, sources

How to add to Remy without forking it. Everything below works on the same client memory, the same actions register and the same contract checks as the shipped skills - so a bank-authored addition shows up on the dashboard like the others and is governed the same way.

Service model

One folder is one service. A service owns its schema, its store, its command line, its prose and its tests, and carries its own version. Three kinds of edge are declared and enforced separately: imports (code, checked at symbol level), invokes (one service calls another's command line) and owns (exactly one writer per path). Dependencies point downwards only - presentation → workflow → memory → kernel. A contract check in CI covers manifests, ownership, layering, imports, skill names, "no two skills produce the same thing", version bumps and the dependency map in the README. Around 375 tests cover the services; types are checked. The services and what each owns are listed on Architecture and data flow.

python -m remy._kernel.cli check          # every contract problem
python -m remy._kernel.cli map            # regenerate the dependency map
python -m remy._kernel.cli versions --write
python -m pytest remy -q

Writing a skill

A skill is prose. It calls its service's command line and never touches the knowledge base itself. Anatomy of a skill folder:

<skill-name>/
├── SKILL.md            frontmatter (name, description, trigger phrases) + the procedure
├── references/         policy files, templates, method notes the skill reads
└── scripts/            helpers the skill runs (never a substitute for the service CLI)

Raising an action

A monitor-style skill raises findings through the actions register contract and nothing else:

1. One row per finding on the client's actions.md, with a stable ID so a re-run updates rather than duplicates; the row is removed when a re-run comes back clean (history stays on the alert ledger).

2. One prepared letter under the letter policy (action-email); rows sharing an addressee share one draft per day - read today's letter and rewrite it, never create a second.

3. One alert ledger per monitor in _meta/ - the dashboard and export contract.

4. A change-log entry.

5. Never write another skill's page; never write the registers by hand.

The dashboard reads the register; a new monitor appears on it with no UI work.

Adding a topic page or a monitor

• A topic page is an entry in the description file: name, bucket, authorship class, what it receives. Mining routes facts to it through the page-routing map. Apply the test: would a write here create a competing system of record? If yes, it is a mirror page.

• A monitor is a skill plus a policy file in _meta/ and an alert ledger. Add a row to the scheduler's default set with a staggered time (monitors never share a minute, because they all write actions.md).

Adding a source

• Connect the system as an MCP server on the space. No change to the memory structure.

• Give it a row in the identity map: system, identifier, kind, match basis, confidence. Identity is resolved once, then the system is read by stored ID.

• Record each read in the mining log so runs stay idempotent; declare its trust tier.

• Extend the page-routing map for the fact types it contributes; mirror fields are copied, never inferred.

Building a page

A side-panel page is sandboxed HTML that reaches the platform through three channels only (data, rendering, actions) and is refused at build time if it breaks the contract. The channels, the build-time checks and the design system are specified on User interface reference. Follow the design system; brand packs override it.

Local development

What is avoided by design

• A skill per individual client.

• Hard-coded document identifiers.

• Bank names embedded in shared prompts.

• A skill that writes a path it does not own, or a page it did not declare.

• A version change without a bump.