MCP

npx momentic mcp --config /absolute/path/to/momentic.config.yaml

claude mcp add --transport stdio momentic -- npx momentic mcp --config /absolute/path/to/momentic.config.yaml

claude mcp add --transport stdio momentic -- cmd /c npx momentic mcp --config C:\path\to\momentic.config.yaml

codex mcp add momentic -- npx momentic mcp --config /absolute/path/to/momentic.config.yaml

{
  "mcpServers": {
    "momentic": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "momentic",
        "mcp",
        "--config",
        "/absolute/path/to/momentic.config.yaml"
      ],
      "env": { "MOMENTIC_API_KEY": "your-api-key" }
    }
  }
}

{
  "mcp": {
    "momentic": {
      "type": "local",
      "command": [
        "npx",
        "momentic",
        "mcp",
        "--config",
        "/absolute/path/to/momentic.config.yaml"
      ],
      "environment": { "MOMENTIC_API_KEY": "your-api-key" },
      "enabled": true
    }
  }
}

npx momentic mcp --config /absolute/path/to/momentic.config.yaml

"momentic": {
  "env": { "MOMENTIC_API_KEY": "your-api-key" }
}

npx skills add momentic-ai/skills

$momentic-test write a test for the checkout flow

$momentic-test run the affected tests and fix stale test steps
$momentic-result-classification classify run <run-id>

$momentic-spec add a confirmation message after a file is attached

## Momentic spec-driven development

- Before starting implementation, create Momentic tests for new user-visible
  functionality or update the existing tests for behavior that will change.
  Treat these tests as the product specification; do not make them fit the code.
- Mark specifications `disabled: true` when they are not expected to pass yet,
  and record the exact tests expected to be affected.
- For new tests, prefer `act` steps (AI action V3) with a clear `goal` when a
  high-level flow reads better than individual clicks. Reuse existing modules
  for established subflows.
- Do not run Momentic after every edit or commit. Use it as end-to-end
  validation at durable, usable UI checkpoints: after full implementation for a
  small change, or after an independently testable UI slice for a large change.
- The coding agent owns required test data and state. Prefer existing setup
  facilities, or add safe test-environment-only seeding endpoints, fixtures,
  accounts, and controls when needed.
- At each checkpoint, establish the required state, enable the specifications
  expected to pass, and run the smallest affected test set.