/skills/mfm-factory

$ manifest

$ requires — MCP tools

$ install

Install the MFM skill 'mfm-factory' for this agent.
Use the skill page as the source of truth: https://mfm.dev/skills/mfm-factory
Read https://mfm.dev/skills.json, download the complete versioned archive, and verify its SHA-256 before extraction. This version: https://mfm.dev/downloads/skills/mfm-factory/1.3.2.tar.gz (SHA-256 08c821d90890e01a25ac474ee22df6c44157190a3d84285edfb6e97d7f789817).
Install the full folder in this harness's skill directory. Preserve any locally customized installation before replacing it. Check latest_version at the start of relevant work.
Also configure the 'mfm' MCP server at https://mcp.mfm.dev/mcp, complete OAuth, and verify these tools are visible before claiming setup is done: mfm_spec_project, mfm_spec_read, mfm_spec_validate, mfm_spec_mutate, mfm_spec_rename, mfm_spec_merge, mfm_spec_split, mfm_spec_retire, mfm_spec_history, mfm_spec_import, mfm_spec_export, mfm_factory_schema, mfm_factory_project, mfm_factory_graph, mfm_factory_read, mfm_factory_mutate, mfm_factory_history, mfm_factory_changes.
After installation, start a fresh agent session or reload the tool/skill registry if this harness requires it.

1. Download https://mfm.dev/downloads/skills/mfm-factory/1.3.2.tar.gz and verify SHA-256 08c821d90890e01a25ac474ee22df6c44157190a3d84285edfb6e97d7f789817.
2. Extract the complete 'mfm-factory/' folder into your agent's skills directory.
3. Configure the 'mfm' MCP server at https://mcp.mfm.dev/mcp.
4. Complete OAuth and confirm the required tools are visible.

(set -eu
test ! -e ~/.claude/skills/mfm-factory || { echo "Back up or move the existing skill before installing" >&2; exit 1; }
skill_tmp="$(mktemp -d)"
curl --fail --location 'https://mfm.dev/downloads/skills/mfm-factory/1.3.2.tar.gz' -o "$skill_tmp/skill.tar.gz"
printf '%s  %s\n' '08c821d90890e01a25ac474ee22df6c44157190a3d84285edfb6e97d7f789817' "$skill_tmp/skill.tar.gz" | shasum -a 256 -c -
mkdir -p ~/.claude/skills
tar -xzf "$skill_tmp/skill.tar.gz" -C ~/.claude/skills
rm -rf "$skill_tmp"
)
claude mcp add --transport http mfm https://mcp.mfm.dev/mcp
claude mcp login mfm

(set -eu
test ! -e ~/.agents/skills/mfm-factory || { echo "Back up or move the existing skill before installing" >&2; exit 1; }
skill_tmp="$(mktemp -d)"
curl --fail --location 'https://mfm.dev/downloads/skills/mfm-factory/1.3.2.tar.gz' -o "$skill_tmp/skill.tar.gz"
printf '%s  %s\n' '08c821d90890e01a25ac474ee22df6c44157190a3d84285edfb6e97d7f789817' "$skill_tmp/skill.tar.gz" | shasum -a 256 -c -
mkdir -p ~/.agents/skills
tar -xzf "$skill_tmp/skill.tar.gz" -C ~/.agents/skills
rm -rf "$skill_tmp"
)
codex mcp add mfm --url https://mcp.mfm.dev/mcp
codex mcp login mfm

(set -eu
test ! -e ~/.agents/skills/mfm-factory || { echo "Back up or move the existing skill before installing" >&2; exit 1; }
skill_tmp="$(mktemp -d)"
curl --fail --location 'https://mfm.dev/downloads/skills/mfm-factory/1.3.2.tar.gz' -o "$skill_tmp/skill.tar.gz"
printf '%s  %s\n' '08c821d90890e01a25ac474ee22df6c44157190a3d84285edfb6e97d7f789817' "$skill_tmp/skill.tar.gz" | shasum -a 256 -c -
mkdir -p ~/.agents/skills
tar -xzf "$skill_tmp/skill.tar.gz" -C ~/.agents/skills
rm -rf "$skill_tmp"
)

// Add this to ~/.cursor/mcp.json for global setup,
// or .cursor/mcp.json for project setup:
{
  "mcpServers": {
    "mfm": {
      "url": "https://mcp.mfm.dev/mcp"
    }
  }
}

Then open Cursor MCP settings and authenticate the mfm server.

install paths
.claude/skills/mfm-factory/     # project-local Claude Code fallback
.agents/skills/mfm-factory/     # project-local Codex & Cursor fallback

Raw manifest: /skills.json · source & manual fallback: https://mfm.dev/skills/mfm-factory

$ artifact — SKILL.md body

Guide the user's own agent through **Specification → Data Model → Architecture →
Construction**, returning upstream when implementation exposes missing or incorrect
design. MFM stores and validates records; it does not run an inference service or
launch construction agents. These design responsibilities can belong to one agent.
Do not introduce extra sessions, approval handoffs or delegation automatically.
Use the [glossary](references/glossary.md) when a term or role boundary is ambiguous.
All reusable schemas, conventions, examples and agent instructions belong in this
canonical skills/ directory in the madeformachine repository; project-specific intent and artifacts belong to the project.

## Start or resume through MCP

Read the project's binding and discover the actual tool capabilities. A service-backed
spec may run in local Docker; do not assume it belongs to the public MFM deployment.
Use MCP records as the working source of truth for design and construction. Repository
exports are mirrors; do not edit them as a substitute for hosted mutations.
This skill is self-contained, including hosted specification authoring. Do not load
the local spec or local model skills for this workflow. A service running in local
Docker is still hosted authority; “local” in MFM Spec Local means file authority.
Use the customer's ordinary development tools for code, fixtures and tests, and
record their exact inputs, work and evidence through MCP. This workflow also applies
when the project being constructed is the Factory itself.

Read [MCP operations and deployment boundaries](mcp.md) before making a tool call.
If required tools or commands are absent, report the specific missing capability.
Continue independent supported work, but do not simulate success, edit the database,
call HTTP endpoints instead of MCP, or silently use a local design as authority.
This skill's selected formats and workflow do not imply that a deployment supports them.

For an existing project, read project policy, the current spec map and Factory
project/run records. Resume recorded tasks and exact inputs before creating work.
For a new project, bootstrap its hosted spec using `mfm_spec_import`; native deployments
create its Factory project and primary variant together. Create further named variants
inside that project as described in [MCP operations](mcp.md).
Check deployment capabilities first; do not invent a command if support is missing.
An explicitly authorized first spec import is a bootstrap, never an overwrite of
an existing hosted project. Read its policy and HEAD before subsequent authoring.
When the user explicitly authorizes reconciling local authoring into an existing
service project, compare the complete local and service versions, preserve service-only
work unless its removal is explicitly intended, validate the result and write against
the current service revision. Read back/export and verify the result before treating
repository files as mirrors. This transition is not ongoing bidirectional authoring.

## Develop variants and designs

A project has named **spec variants**. Each owns exactly one unnamed **Data Model**
once modeling has begun and any number of named **architecture variants**. A model
can be absent before construction. Explore different logical meanings in separate
spec variants. Preserve stable IDs across name changes. Content revisions start at 1;
empty layers display “No version yet”. A change creates a revision; review alone does
not. There is no separate draft choice, and completeness is visible independently.

Use the existing MFM Spec format for intent, responsibilities, features and criteria.
Read [hosted spec authoring](references/spec-authoring.md) when working on that layer.
The authoritative project policy and actual mutation schema govern how to edit it.
On native deployments, select the project and spec variant explicitly; validated edits
return directly pinnable Factory revisions with no separate synchronization step.
Read the map, then the affected nodes; validate one coherent mutation batch before
committing it with the read revision and a meaningful change note. Re-read conflicts.
Use dedicated rename/merge/split/retire operations after reading referrers, preserving
prior identities rather than composing delete-and-create replacements.

For modeling or architecture work, read [starting formats](references/formats.md).
Data Model defines meaning; Architecture defines a component/interface graph,
concrete representations and scenario expectations. Preserve the distinction between
the containment tree, runtime interactions and construction work scheduling.

After a spec change, inspect the existing model and affected architectures. After a
model change, inspect affected architectures. Change only necessary content; record
the assessment and explain retained choices. Identify alternatives not reassessed.
Do not bump downstream revisions solely to change provenance, and do not create a
semantic-validity certificate or imply a schema check proves compatibility.

## Construct and learn

Before starting construction, establish the user's selected spec variant and
architecture variant. An unambiguous earlier instruction is sufficient; ask only
when the choice is missing or ambiguous. A browser default is not that instruction.
Read the selected spec, its model and architecture. Check their consistency,
completeness and known logical faults; surface gaps and decide how to proceed within
the user's authority. Preserve the exact tuple actually chosen for the run.

Read [construction and feedback](references/construction.md). Build an **executable
mock product first**, using coherent agent-generated scenario data to exercise the
agreed complete product flows through actual declared interfaces. Use the discovered
current pull protocol, one fresh invocation per system claim, aggregate direct-child
feedback and explicit user resolution of design pauses. Accept the mock separately.
Actual-product construction is a separately initiated run adopting an accepted mock;
it replaces mocked behavior component by component and repeats relevant scenarios.
Mock acceptance does not mean the product is production-complete.

When a finding changes intent, data meaning or architecture, correct the responsible
hosted design through MCP within existing authority. Ask the user about unresolved
product decisions, not routine implementation details already authorized. Assess
downstream impact and explicitly adopt changed inputs into successor work; preserve
old runs and evidence. Components can be introduced, split, replaced or retired.
Their code, data, callers and ownership need explicit migration/removal work.

Conclude with the actual hosted revisions, construction state, evidence and remaining
gaps. Distinguish records that were persisted from proposed work and local artifacts.

## API evolution

Use one current Factory API and MCP toolset. Do not select older protocols or add
compatibility shims. Breaking changes update callers and this skill together.
Historical record identities preserve evidence, not executable older workflows.

## Distribution and updates

Install the complete skill folder from https://mfm.dev/skills/mfm-factory.
At the start of relevant work, compare this version with https://mfm.dev/skills.json.
Use the catalog artifact URL and SHA-256 to verify an authorized update; preserve local
customizations and reload the skill registry when required by the agent harness.