Write the expected product behavior as Momentic tests before implementing it. The tests define the contract; do not make the tests fit the implementation.

Do not begin product implementation until the intended test specifications are on disk. If the user changes the requirement, update the spec first again.

Before editing product code, report each affected test path and whether it will be added, changed, or left unchanged.

The pre-implementation test should describe the requested outcome, even when the current product cannot satisfy it yet.

After writing the tests, summarize the expected failing or disabled behavior and confirm the tests express the user's request before implementing it.

Read nearby tests and follow their established conventions, including folder placement, naming, modules, setup, data, and preference for AI checks, page checks, or element checks. Apply baseline Momentic practices where the codebase does not express a preference:

For a new test, prefer an AI action V3 step when a high-level goal reads more clearly as a product specification, especially for a long flow. Reuse existing modules for known subflows and use for the new behavior rather than hiding reusable setup inside one large goal.

Keep goals short, specific, and outcome-oriented. Pair an step with the same assertion style used by nearby tests so the test verifies the result, not only that the agent stopped.

AI action V3 caches generated steps after a successful run and self-heals when a cached step misses:

Momentic is true end-to-end validation, not the coding agent's inner feedback loop. Do not run affected Momentic tests after every file edit, implementation step, commit, or small refactor.

Use faster repository checks such as unit tests, typechecking, and linting while building. Run Momentic when the app has reached a logical checkpoint that is durable and usable through the real UI:

At each checkpoint, run the smallest affected test set once, diagnose failures, make a coherent fix, and rerun only when there is a reasonable expectation that the end-to-end outcome changed. Keep future specifications disabled until their checkpoint exists.

The coding agent implementing the product change is responsible for making the checkpoint cleanly runnable. Before invoking Momentic, identify and establish the required data, account state, feature flags, permissions, integrations, and service state. Do not leave prerequisite creation for the browser agent to improvise through unrelated UI flows.

Prefer existing test setup facilities. When the application lacks a reliable way to create prerequisites, the coding agent is encouraged to build safe, test-environment-only capabilities such as:

Any new test capability must be inaccessible in production, explicitly gated to approved test environments, authenticated where appropriate, narrowly scoped, and safe to call repeatedly. Never add a production backdoor, weaken production authorization, or encode the behavior under test inside the seed mechanism.

Document the setup contract and either execute it before the Momentic run or invoke it from the test's established setup section. The resulting test should be repeatable from a clean environment without relying on accidental state from a previous run.

Use the installed skill for detailed authoring, format, and MCP guidance.

Run the repository's required product-code checks after implementation. In the handoff, list the affected tests, their enabled or disabled state, the product behavior implemented, and every validation that was or was not run.