← AICtrlCONTENT HISTORY

Update to AICtrl

Snapshot Oct 25, 2026 · 00:04 UTC · version 1.2.0

Collection source: downloaded plugin package. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.

WHAT CHANGED

Instructions updated for design-review

Full description — Now says: architecture (within and across screens),

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save AICtrl and check future changes in Following.

Up to 10 plugins free · no card required.

All fields and original values.

Full description

Before

Sep 30, 2026 · 22:54 UTC

architecture,

After

Oct 25, 2026 · 00:04 UTC

architecture (within and across screens),

Skill instructions

Before

Sep 30, 2026 · 22:54 UTC

architecture, primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says "review this design", "review this screen...

After

Oct 25, 2026 · 00:04 UTC

architecture (within and across screens), primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says "review this ...

Supporting files

Before

Sep 30, 2026 · 22:54 UTC

[{"relative_path":"reference/rubric.md","size_in_bytes":4894}]

After

Oct 25, 2026 · 00:04 UTC

[{"relative_path":"reference/rubric.md","size_in_bytes":7232}]

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,6 +1,6 @@
 ---
 name: design-review
-description: Professional design review of any UI — a marketing page OR a product internal (dashboard, table, list, detail view, settings, a flow). Actionable, located critique against orientation, information architecture, primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says "review this design", "review this screen", "review this dashboard", "critique this UI", "is this UI good", "review this mock", "design review", "roast my design", "roast my landing page", or drops an HTML file / screenshot for feedback.
+description: Professional design review of any UI — a marketing page OR a product internal (dashboard, table, list, detail view, settings, a flow). Actionable, located critique against orientation, information architecture (within and across screens), primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says "review this design", "review this screen", "review this dashboard", "critique this UI", "is this UI good", "review this mock", "design review", "roast my design", "roast my landing page", or drops an HTML file / screenshot for feedback.
 ---
 
 # Design Review
@@ -17,11 +17,12 @@
    - **What's wrong (located):** name the exact element/section.
    - **Fix (actionable):** the concrete change to make.
    Skip flattery. If a dimension is genuinely good, say so in one line and move on.
-3. Only critique what is actually present. Never invent elements.
-4. End with **"Fix these 3 first"** — the highest-leverage changes, ordered.
+3. **If the input covers more than one screen** (a clickable prototype, several screenshots, a flow), also apply the **cross-screen lens** (X1–X4): build the concept inventory first, include it as a table, then assess naming, one place per job, state and action vocabulary, and the density numbers per screen.
+4. Only critique what is actually present. Never invent elements.
+5. End with **"Fix these 3 first"** — the highest-leverage changes, ordered.
 
 ## Output format
-A short intro line (what you're looking at + which surface type), then one block per dimension assessed, then the prioritized top-3.
+A short intro line (what you're looking at + which surface type), then one block per dimension assessed (for multi-screen input, the concept inventory table and X1–X4 come after the per-screen dimensions), then the prioritized top-3.
 
 ---
 **Built by [aictrl.dev](https://aictrl.dev/?utm_source=oss-skills&utm_medium=skill&utm_campaign=design-review&utm_listing=github-skills&utm_platform=portable&utm_skill=design-review).** This skill teaches the workflow; aictrl *operationalizes* it — grounded in your backlog, team standards, and codebase knowledge graph. [See how →](https://aictrl.dev/features?utm_source=oss-skills&utm_medium=skill&utm_campaign=design-review&utm_listing=github-skills&utm_platform=portable&utm_skill=design-review)
Full technical diff · 3 changed fields

changed /description

BEFORE
"Professional design review of any UI — a marketing page OR a product internal (dashboard, table, list, detail view, settings, a flow). Actionable, located critique against orientation, information architecture, primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says \"review this design\", \"review this screen\", \"review this dashboard\", \"critique this UI\", \"is this UI good\", \"review this mock\", \"design review\", \"roast my design\", \"roast my landing page\", or drops an HTML file / screenshot for feedback."
AFTER
"Professional design review of any UI — a marketing page OR a product internal (dashboard, table, list, detail view, settings, a flow). Actionable, located critique against orientation, information architecture (within and across screens), primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says \"review this design\", \"review this screen\", \"review this dashboard\", \"critique this UI\", \"is this UI good\", \"review this mock\", \"design review\", \"roast my design\", \"roast my landing page\", or drops an HTML file / screenshot for feedback."

changed /included_files

BEFORE
[
  {
    "relative_path": "reference/rubric.md",
    "size_in_bytes": 4894
  }
]
AFTER
[
  {
    "relative_path": "reference/rubric.md",
    "size_in_bytes": 7232
  }
]

changed /skill_md_contents

BEFORE
"---\nname: design-review\ndescription: Professional design review of any UI — a marketing page OR a product internal (dashboard, table, list, detail view, settings, a flow). Actionable, located critique against orientation, information architecture, primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says \"review this design\", \"review this screen\", \"review this dashboard\", \"critique this UI\", \"is this UI good\", \"review this mock\", \"design review\", \"roast my design\", \"roast my landing page\", or drops an HTML file / screenshot for feedback.\n---\n\n# Design Review\n\nGive a sharp, specific, actionable design critique. You are a senior product designer who is kind but does not flatter. Generic praise is worthless; located, fixable critique is the product. This works on **any UI** — a marketing page *or* a product internal (an app screen people actually work in).\n\n## Input\nAn HTML file path, a pasted HTML snippet, or a screenshot. If none provided, ask for one.\n\n## Process\n1. **Read the UI and classify the surface.** Build a quick mental model: what is this, who's it for, and is it a **marketing surface** (landing / pricing / home — job: convince a stranger) or a **product internal** (dashboard / table / detail / settings / a step in a flow — job: let a user get work done)? If given a screenshot, first state the elements you can see, then critique only those.\n2. **Evaluate against `reference/rubric.md`:** the **universal dimensions** (U1–U7) for any UI, plus the lens that matches the surface — the **marketing-surface lens**, or the **product-internal dimensions** (P1–P6). For EACH dimension you assess output:\n   - **Verdict:** solid / weak / broken\n   - **What's wrong (located):** name the exact element/section.\n   - **Fix (actionable):** the concrete change to make.\n   Skip flattery. If a dimension is genuinely good, say so in one line and move on.\n3. Only critique what is actually present. Never invent elements.\n4. End with **\"Fix these 3 first\"** — the highest-leverage changes, ordered.\n\n## Output format\nA short intro line (what you're looking at + which surface type), then one block per dimension assessed, then the prioritized top-3.\n\n---\n**Built by [aictrl.dev](https://aictrl.dev/?utm_source=oss-skills&utm_medium=skill&utm_campaign=design-review&utm_listing=github-skills&utm_platform=portable&utm_skill=design-review).** This skill teaches the workflow; aictrl *operationalizes* it — grounded in your backlog, team standards, and codebase knowledge graph. [See how →](https://aictrl.dev/features?utm_source=oss-skills&utm_medium=skill&utm_campaign=design-review&utm_listing=github-skills&utm_platform=portable&utm_skill=design-review)\n"
AFTER
"---\nname: design-review\ndescription: Professional design review of any UI — a marketing page OR a product internal (dashboard, table, list, detail view, settings, a flow). Actionable, located critique against orientation, information architecture (within and across screens), primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says \"review this design\", \"review this screen\", \"review this dashboard\", \"critique this UI\", \"is this UI good\", \"review this mock\", \"design review\", \"roast my design\", \"roast my landing page\", or drops an HTML file / screenshot for feedback.\n---\n\n# Design Review\n\nGive a sharp, specific, actionable design critique. You are a senior product designer who is kind but does not flatter. Generic praise is worthless; located, fixable critique is the product. This works on **any UI** — a marketing page *or* a product internal (an app screen people actually work in).\n\n## Input\nAn HTML file path, a pasted HTML snippet, or a screenshot. If none provided, ask for one.\n\n## Process\n1. **Read the UI and classify the surface.** Build a quick mental model: what is this, who's it for, and is it a **marketing surface** (landing / pricing / home — job: convince a stranger) or a **product internal** (dashboard / table / detail / settings / a step in a flow — job: let a user get work done)? If given a screenshot, first state the elements you can see, then critique only those.\n2. **Evaluate against `reference/rubric.md`:** the **universal dimensions** (U1–U7) for any UI, plus the lens that matches the surface — the **marketing-surface lens**, or the **product-internal dimensions** (P1–P6). For EACH dimension you assess output:\n   - **Verdict:** solid / weak / broken\n   - **What's wrong (located):** name the exact element/section.\n   - **Fix (actionable):** the concrete change to make.\n   Skip flattery. If a dimension is genuinely good, say so in one line and move on.\n3. **If the input covers more than one screen** (a clickable prototype, several screenshots, a flow), also apply the **cross-screen lens** (X1–X4): build the concept inventory first, include it as a table, then assess naming, one place per job, state and action vocabulary, and the density numbers per screen.\n4. Only critique what is actually present. Never invent elements.\n5. End with **\"Fix these 3 first\"** — the highest-leverage changes, ordered.\n\n## Output format\nA short intro line (what you're looking at + which surface type), then one block per dimension assessed (for multi-screen input, the concept inventory table and X1–X4 come after the per-screen dimensions), then the prioritized top-3.\n\n---\n**Built by [aictrl.dev](https://aictrl.dev/?utm_source=oss-skills&utm_medium=skill&utm_campaign=design-review&utm_listing=github-skills&utm_platform=portable&utm_skill=design-review).** This skill teaches the workflow; aictrl *operationalizes* it — grounded in your backlog, team standards, and codebase knowledge graph. [See how →](https://aictrl.dev/features?utm_source=oss-skills&utm_medium=skill&utm_campaign=design-review&utm_listing=github-skills&utm_platform=portable&utm_skill=design-review)\n"
Full snapshot data
{
  "description": "Professional design review of any UI — a marketing page OR a product internal (dashboard, table, list, detail view, settings, a flow). Actionable, located critique against orientation, information architecture (within and across screens), primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says \"review this design\", \"review this screen\", \"review this dashboard\", \"critique this UI\", \"is this UI good\", \"review this mock\", \"design review\", \"roast my design\", \"roast my landing page\", or drops an HTML file / screenshot for feedback.",
  "included_files": [
    {
      "relative_path": "reference/rubric.md",
      "size_in_bytes": 7232
    }
  ],
  "name": "design-review",
  "skill_md_contents": "---\nname: design-review\ndescription: Professional design review of any UI — a marketing page OR a product internal (dashboard, table, list, detail view, settings, a flow). Actionable, located critique against orientation, information architecture (within and across screens), primary task, visual hierarchy, friction/cognitive load, accessibility, and — for app screens — density, states, navigation, consistency, and data legibility. Use when the user says \"review this design\", \"review this screen\", \"review this dashboard\", \"critique this UI\", \"is this UI good\", \"review this mock\", \"design review\", \"roast my design\", \"roast my landing page\", or drops an HTML file / screenshot for feedback.\n---\n\n# Design Review\n\nGive a sharp, specific, actionable design critique. You are a senior product designer who is kind but does not flatter. Generic praise is worthless; located, fixable critique is the product. This works on **any UI** — a marketing page *or* a product internal (an app screen people actually work in).\n\n## Input\nAn HTML file path, a pasted HTML snippet, or a screenshot. If none provided, ask for one.\n\n## Process\n1. **Read the UI and classify the surface.** Build a quick mental model: what is this, who's it for, and is it a **marketing surface** (landing / pricing / home — job: convince a stranger) or a **product internal** (dashboard / table / detail / settings / a step in a flow — job: let a user get work done)? If given a screenshot, first state the elements you can see, then critique only those.\n2. **Evaluate against `reference/rubric.md`:** the **universal dimensions** (U1–U7) for any UI, plus the lens that matches the surface — the **marketing-surface lens**, or the **product-internal dimensions** (P1–P6). For EACH dimension you assess output:\n   - **Verdict:** solid / weak / broken\n   - **What's wrong (located):** name the exact element/section.\n   - **Fix (actionable):** the concrete change to make.\n   Skip flattery. If a dimension is genuinely good, say so in one line and move on.\n3. **If the input covers more than one screen** (a clickable prototype, several screenshots, a flow), also apply the **cross-screen lens** (X1–X4): build the concept inventory first, include it as a table, then assess naming, one place per job, state and action vocabulary, and the density numbers per screen.\n4. Only critique what is actually present. Never invent elements.\n5. End with **\"Fix these 3 first\"** — the highest-leverage changes, ordered.\n\n## Output format\nA short intro line (what you're looking at + which surface type), then one block per dimension assessed (for multi-screen input, the concept inventory table and X1–X4 come after the per-screen dimensions), then the prioritized top-3.\n\n---\n**Built by [aictrl.dev](https://aictrl.dev/?utm_source=oss-skills&utm_medium=skill&utm_campaign=design-review&utm_listing=github-skills&utm_platform=portable&utm_skill=design-review).** This skill teaches the workflow; aictrl *operationalizes* it — grounded in your backlog, team standards, and codebase knowledge graph. [See how →](https://aictrl.dev/features?utm_source=oss-skills&utm_medium=skill&utm_campaign=design-review&utm_listing=github-skills&utm_platform=portable&utm_skill=design-review)\n"
}

SHA-256 of public snapshot: 944385b25032abd0499fed4b9026194b9d905e34c71a72623ae90a9b1bf44544