| name | mindit-continuity |
| description | Analyze whether a new design fits the system that already exists — conventions, components, vocabulary, and visual rules of the product it lives in. Use this whenever the user asks about consistency, whether something "feels off," whether a new screen matches the rest of the product, whether to fork or reuse a component, whether terminology lines up, or whether a feature feels like a different product was glued on. Also trigger when the user is adding a feature to an existing product and asks for a review. Produces a structured decision artifact with score, criteria, and anti-pattern matches. |
mindit-continuity
The second of the eight forces. Run this when the question is "does this fit the system that exists."
The force
Continuity asks whether the new thing extends the system the user already knows, or accidentally forks it. Every product has invisible contracts: a button looks like that button, a date picker behaves like that date picker, an error message uses those words. When a new screen breaks one of those contracts without an explicit reason, users feel the seam even if they can't name it. Multiply that by a few features and the product feels like four products glued together.
Continuity is not about preventing novelty. It is about making novelty intentional. Break a convention only when you can name what you are breaking and why the break is worth the friction.
When to run this
- The user is adding a feature, page, or component to an existing product.
- The user pastes two screenshots and asks "do these feel like the same product."
- The user uses words like "consistent," "fits," "feels off," "different vibe," "matches the rest."
- The user is deciding whether to reuse an existing component or build a new one.
- The user is reviewing a design system PR.
How to analyze
-
Anchor in the system. Identify the existing product the new design lives in. If the user has not shared examples of existing screens or pointed at the design system, ask once for at least one reference surface before scoring.
-
Walk the five alignments. For each of the criteria below, compare the new design against the system. Note specific divergences with file or screen names where possible.
-
Distinguish intentional from accidental breaks. A break with a stated reason is a different finding than a break that happened because nobody noticed. Surface both. Score on whether the break was deliberated, not whether it exists.
-
Open anti-patterns.yaml. Match findings to registered patterns.
-
Compute and write the artifact. See "Output format."
Rubric
| Criterion | Weight | What you are scoring |
|---|
| Convention alignment | 0.25 | Does this match the interaction patterns used elsewhere in the product (modal vs page, inline vs separate flow, etc.)? |
| Component reuse | 0.25 | Does this use the existing components, or does it fork them? A forked component is one that looks like an existing one but has slightly different padding, border radius, or behavior. |
| Naming alignment | 0.20 | Do labels use the vocabulary already established in the product? "Customer" vs "User" vs "Account" — pick one and stay. |
| State alignment | 0.15 | Are empty states, loading states, error states, and edge cases handled the same way they are elsewhere? |
| Visual alignment | 0.15 | Color values, spacing rhythm, type scale, border radius, shadow depth. Within the system's tolerance? |
Anti-patterns
See anti-patterns.yaml. Brief list: one-off-component, vocabulary-drift, novel-empty-state, visual-island, shadow-system, undocumented-exception, brand-collision.
Output format
Two files in .mindit/decisions/. Filename pattern: continuity-<yyyymmdd>-<slug>.{md,json}.
JSON conforms to schemas/decision.schema.json with skill: "mindit-continuity" and force: "continuity".
Example
Input: "Review my new billing page against the rest of the product."
Five alignments analyzed:
- Convention: The product uses inline editing everywhere except billing, which uses a modal flow. Divergence noted.
- Component reuse: The billing page introduces a new "PlanCard" component that visually resembles the existing "FeatureCard" but has different padding and a different CTA style.
- Naming: Product uses "subscription"; billing page uses "membership."
- State alignment: Empty state on billing is a custom illustration; rest of product uses a standard empty-state component.
- Visual alignment: Billing uses #2563EB blue; rest of product uses #1E40AF.
Sample weighted score: 48. High-severity findings on component reuse and naming, medium on the rest.
What this skill does NOT do
- Does not evaluate whether the existing system is good. Continuity scores fit, not quality. Ask
mindit-clarity or mindit-audit for that.
- Does not require a formal design system. If there is no documented system, infer the conventions from the existing surfaces and say so in evidence.
- Does not punish intentional novelty. A documented, deliberated exception is a different finding than an accidental one.
