| name | mindit-constraint |
| description | Analyze which hard limits a design honors — technical, accessibility, brand, legal, time, and platform. Use this whenever the user asks about feasibility, accessibility, WCAG, screen readers, contrast, performance budgets, platform guidelines (iOS HIG, Material), legal requirements (GDPR, CCPA, accessibility law), brand restrictions, or engineering capacity. Also trigger when a user says "can we ship this," "is this realistic," or "what are we forgetting." Produces a structured decision artifact with score, criteria, and anti-pattern matches. |
mindit-constraint
The third of the eight forces. Run this when the question is "what hard limits is this honoring."
The force
Every design lives inside a fence. The fence is made of accessibility law, browser support targets, engineering capacity, platform guidelines, brand rules, performance budgets, and policy constraints. Designers cannot push the fence by ignoring it. The fence pushes back later, often through the legal team, the support inbox, or a launch slip.
Constraint asks: of the fences this design has to live inside, which ones did it design for and which ones did it design around?
When to run this
- The user asks "can we actually ship this," "is this realistic," or "what are we forgetting."
- The user mentions accessibility, WCAG, screen readers, contrast ratios, keyboard navigation, or focus rings.
- The user mentions performance, payload, latency, or "is this too heavy."
- The user mentions a platform: iOS, Android, watchOS, web embed, email client.
- The user mentions a legal or policy question: GDPR, CCPA, COPPA, accessibility law, content moderation, age gating.
- The user is reviewing brand-adjacent work and asks whether it stays inside brand rules.
How to analyze
-
Enumerate the fences. For the subject under review, list every hard limit that applies: WCAG target, browser support matrix, performance budget, engineering capacity, platform guidelines, brand rules, legal regimes, policy constraints. If the user has not stated these, ask once for the relevant ones before scoring.
-
Per-fence assessment. For each fence, score whether the design honors it, ignores it, or is silent on it. Silence is its own finding: a design that does not say what its keyboard behavior is has not made a decision about keyboard behavior.
-
Score the criteria below. Note that not every criterion applies to every subject. If a criterion is N/A (e.g. there is no native platform involved), give it the average score of the remaining criteria and note N/A in the criterion's note field.
-
Check anti-patterns.yaml. Many constraint failures are recognizable patterns.
-
Write the artifact.
Rubric
| Criterion | Weight | What you are scoring |
|---|
| Accessibility limits | 0.25 | WCAG conformance (target the user states, or AA as default), screen reader behavior, keyboard navigation, focus order, color-contrast ratios, motion sensitivity, target sizes. |
| Technical limits | 0.20 | Browser support targets, payload budget, latency targets, offline behavior, image weight, font weight, JS execution time. |
| Legal & policy limits | 0.20 | Regional law (GDPR, CCPA, accessibility law), industry policy, internal content/policy rules. |
| Brand limits | 0.15 | Typography, color, logo usage, voice, photography style. Inside the rules the brand team has set. |
| Platform limits | 0.10 | Native conventions for the platform the design ships to (iOS HIG, Material, watchOS, email client quirks). |
| Time & resource limits | 0.10 | Is this buildable by the team that will build it, in the time available, with the technology they use today? |
Anti-patterns
See anti-patterns.yaml. Brief list: accessibility-afterthought, contrast-fail, hover-only-affordance, fixed-pixel-typography, desktop-first-only, legal-blind, pretend-budget, platform-disrespect, motion-without-reduce, color-only-signal.
Output format
Two files in .mindit/decisions/. Filename: constraint-<yyyymmdd>-<slug>.{md,json}.
JSON conforms to schemas/decision.schema.json with skill: "mindit-constraint" and force: "constraint".
Example
Input: "Review the checkout flow for constraints. We target WCAG 2.1 AA and a 200ms LCP budget."
Sample findings:
- Accessibility: payment-method radio buttons rely on color alone to indicate selection (contrast-fail, color-only-signal). Severity high.
- Technical: hero image is 1.2MB unoptimized; LCP budget will not hold (pretend-budget). Severity high.
- Legal: cookie banner copy does not explicitly state withdrawal mechanism (GDPR Article 7 sub-clause). Severity high.
- Platform: form uses HTML5 datepicker which renders inconsistently in Safari iOS. Severity medium.
- Time: design includes an animated 3D model that the team has no rendering pipeline for. Severity high.
Sample weighted score: 38.
What this skill does NOT do
- Does not give legal advice. It surfaces things that look like legal constraints; a lawyer must confirm.
- Does not run a real accessibility audit. It catches anti-patterns visible from a design review; real audits require keyboard testing, screen reader testing, and color contrast measurement on the live build.
- Does not measure performance. It flags weight signals (large hero images, heavy fonts, JS-heavy interactions) but the engineer must measure.
- Does not invent fences. If the user has not stated a constraint, ask before assuming.
