chore(impeccable): 审计工具链重构与精简
更新 .agents/skills/impeccable:移除旧 detector/live 脚本簇与若干 reference, 改用打包后的 scripts/bin 与精简 reference(含 degraded/*、native/*)。 纯工具链,不触及营销站源码与站点运行时。
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
### Purpose
|
||||
|
||||
Resolve one stable target, run two independent assessments, synthesize a design critique, persist a snapshot, and ask the user what to improve next. The chat response is the primary deliverable; the snapshot is an archive/backlog for future commands.
|
||||
Resolve one stable target, run two independent assessments, synthesize a design critique, persist a snapshot, and ask the user what to improve next. The chat response is the primary deliverable; the snapshot is an archive of that run.
|
||||
|
||||
### Hard Invariants
|
||||
|
||||
@@ -8,10 +8,12 @@ Resolve one stable target, run two independent assessments, synthesize a design
|
||||
- Assessment A and B MUST run as two isolated sub-agents whenever a sub-agent/Task tool is exposed. Running them inline in this context is "possible" but is NOT permitted; it is a degraded run. Inline is allowed ONLY when no sub-agent tool exists (or the user declined, on harnesses that ask).
|
||||
- If you degrade for any reason, the report's first line MUST be a banner: `⚠️ DEGRADED: single-context (<reason>)`. A silent degraded critique is a failed critique.
|
||||
- Assessment A must finish before detector findings enter the parent synthesis context. Detector output is deterministic, but it still anchors judgment.
|
||||
- A skipped detector is a failed critique run unless `detect.mjs` is missing or crashes after a real attempt.
|
||||
- A skipped detector is a failed critique run unless `impeccable detect` is missing or crashes after a real attempt.
|
||||
- Viewable targets require browser inspection when available.
|
||||
- Any local server started only for critique visualization must run in the background, have a recorded stop method, and be stopped before final reporting unless the user asks to keep it.
|
||||
- Do not claim a user-visible overlay exists unless script injection succeeded and the detector ran in the page.
|
||||
- The question is the LAST thing in the response. Write the entire report out first, then ask; nothing follows the question. Prose emitted after a structured question is withheld until the user answers it, so a report written after the question reads as if the critique never ran.
|
||||
- A run that ends with neither the targeted questions nor a literal `Questions skipped: <reason>` line is an incomplete run. The report is not the finish; the close is.
|
||||
|
||||
### Setup
|
||||
|
||||
@@ -19,11 +21,11 @@ Resolve one stable target, run two independent assessments, synthesize a design
|
||||
- "the homepage" -> `site/pages/index.astro` or `index.html`
|
||||
- "the settings modal" -> the primary component file
|
||||
- "this page" -> the current URL or source file
|
||||
2. **Compute the slug**:
|
||||
2. **Confirm the target slugs cleanly**:
|
||||
```bash
|
||||
node .agents/skills/impeccable/scripts/critique-storage.mjs slug "<resolved-path-or-url>"
|
||||
.agents/skills/impeccable/scripts/impeccable critique-storage slug "<resolved-path-or-url>"
|
||||
```
|
||||
Keep it. If the command exits non-zero, skip persistence and trend for this run, but continue the critique.
|
||||
Every later command also accepts the resolved target directly and derives the same slug internally; never hand-write a slug. If this exits non-zero, skip persistence and trend for this run, but continue the critique.
|
||||
3. **Read `.impeccable/critique/ignore.md`** if it exists. Drop matching findings silently; it is the only prior-run input critique consumes.
|
||||
|
||||
### Assessment Orchestration
|
||||
@@ -52,13 +54,13 @@ If browser automation is available, each assessment creates its own new tab. Nev
|
||||
Read relevant source files and visually inspect the live page when browser automation is available. Think like a design director.
|
||||
|
||||
Evaluate:
|
||||
- **AI slop**: Would someone believe "AI made this" immediately? Check all DON'T guidance from the parent Impeccable skill.
|
||||
- **Design specificity**: Is the composition, interaction, and visual language grounded in this product, or could an unrelated product use it unchanged? Make this judgment before seeing detector output.
|
||||
- **Holistic design**: hierarchy, IA, emotional fit, discoverability, composition, typography, color, accessibility, states, copy, and edge cases.
|
||||
- **Cognitive load**: consult the [Cognitive Load Assessment](#cognitive-load-assessment) section below; report checklist failures and decision points with >4 visible options.
|
||||
- **Emotional journey**: peak-end rule, emotional valleys, reassurance at high-stakes moments.
|
||||
- **Nielsen heuristics**: consult the [Heuristics Scoring Guide](#heuristics-scoring-guide) section below; score all 10 heuristics 0-4.
|
||||
- **Nielsen heuristics**: consult the [Heuristics Scoring Guide](#heuristics-scoring-guide) section below; score all 10 heuristics 0-4, marking any heuristic the mode-applicability rule allows as `n/a` instead of forcing a number.
|
||||
|
||||
Return: AI slop verdict, heuristic scores, cognitive load, emotional journey, 2-3 strengths, 3-5 priority issues, persona red flags, minor observations, and provocative questions.
|
||||
Return: design-specificity verdict, heuristic scores, cognitive load, emotional journey, 2-3 strengths, 3-5 priority issues, persona red flags, minor observations, and provocative questions.
|
||||
|
||||
### Assessment B: Detector + Browser Evidence
|
||||
|
||||
@@ -66,7 +68,7 @@ Run the bundled detector and browser visualization evidence. Assessment B is man
|
||||
|
||||
CLI scan:
|
||||
```bash
|
||||
node .agents/skills/impeccable/scripts/detect.mjs --json [target]
|
||||
.agents/skills/impeccable/scripts/impeccable detect --json [target]
|
||||
```
|
||||
|
||||
- Pass markup files/directories as `[target]`; do not pass CSS-only files.
|
||||
@@ -80,14 +82,14 @@ Browser visualization is required for a viewable target when browser automation
|
||||
1. Create a fresh tab and navigate. Prefer the harness's native/browser-canvas screenshot path before hand-rolling a Playwright/Puppeteer script; only fall back to a custom script when no native browser tool is exposed.
|
||||
2. Preflight mutable injection by setting `document.title` and appending a `<script>` tag. Read-only evaluate APIs do not count.
|
||||
3. If mutation is unavailable, skip live server, browser presentation, and injection; report fallback signal.
|
||||
4. If mutation is available, start `node .agents/skills/impeccable/scripts/live-server.mjs --background`, present the browser if supported, label `[Human]`, scroll top, inject `http://localhost:PORT/detect.js`, wait 2-3 seconds, read `impeccable` console messages, then stop the live server.
|
||||
4. If mutation is available, start `.agents/skills/impeccable/scripts/impeccable live-server --background`, present the browser if supported, label `[Human]`, scroll top, inject `http://localhost:PORT/detect.js`, wait 2-3 seconds, read `impeccable` console messages, then stop the live server.
|
||||
5. For multi-view targets, inject on 3-5 representative pages.
|
||||
|
||||
Codex Browser note: Use the Browser skill. Do not spend a Browser attempt on `file://`. Only call `visibility.set(true)` after mutable script injection is confirmed for the `[Human]` overlay path; verify with `get()`. Use `tab.dev.logs({ filter: "impeccable" })` for console results. Its Playwright `evaluate(...)` surface is read-only; do not rely on it for mutation.
|
||||
|
||||
Return: CLI findings JSON/counts, browser console findings if applicable, false positives, and skipped/failed browser steps with concrete reasons.
|
||||
|
||||
After Assessment B returns usable CLI findings, reuse them. Do not rerun `detect.mjs` in the parent unless Assessment B failed, was truncated, or omitted count, rule names, or file locations.
|
||||
After Assessment B returns usable CLI findings, reuse them. Do not rerun `impeccable detect` in the parent unless Assessment B failed, was truncated, or omitted count, rule names, or file locations.
|
||||
|
||||
Codex failure accounting: final Run Notes must include target slug, ignore list, assessment independence, CLI detector, browser visibility, overlay injection, live-server cleanup, temp-file cleanup, and any fallback signal used. Do not run repo status checks, late API spelunking, or unrelated verification after the report is assembled.
|
||||
|
||||
@@ -95,7 +97,7 @@ Codex failure accounting: final Run Notes must include target slug, ignore list,
|
||||
|
||||
Synthesize both assessments into a single report. Do NOT simply concatenate. Weave the findings together, noting where the LLM review and detector agree, where the detector caught issues the LLM missed, and where detector findings are false positives.
|
||||
|
||||
The chat response is the primary user-facing deliverable. Present the full structured critique below in chat; do not replace it with a summary and a link. The persisted snapshot is only an archive/backlog for later commands.
|
||||
The chat response is the primary user-facing deliverable. Present the full structured critique below in chat; do not replace it with a summary and a link. The persisted snapshot is an archive of that run.
|
||||
|
||||
Codex final-answer note: `$impeccable critique` produces a report artifact, so the final chat response should intentionally exceed the usual concise close-out style. Do not title the final response "Critique Summary" unless the user explicitly asked for a summary.
|
||||
|
||||
@@ -124,15 +126,19 @@ Present the Nielsen's 10 heuristics scores as a table:
|
||||
| 8 | Aesthetic and Minimalist Design | ? | |
|
||||
| 9 | Error Recovery | ? | |
|
||||
| 10 | Help and Documentation | ? | |
|
||||
| **Total** | | **??/40** | **[Rating band]** |
|
||||
| **Total** | | **??/[applicable max]** | **[Rating band]** |
|
||||
|
||||
Be honest with scores. A 4 means genuinely excellent. Most real interfaces score 20-32.
|
||||
The applicable maximum is 4 times the number of heuristics you actually scored: **/40** when all ten apply, **/32** when two are `n/a`. Never print `/40` over a partial set.
|
||||
|
||||
#### Anti-Patterns Verdict
|
||||
Be honest with scores. A 4 means genuinely excellent. Most real interfaces score 20-32 out of 40.
|
||||
|
||||
**Start here.** Does this look AI-generated?
|
||||
**Mode applicability**: heuristics 7 (Flexibility and Efficiency) and 10 (Help and Documentation) may be scored `n/a` on Persuade and Experience surfaces (landing pages, campaigns, portfolios, bodies of work), as may any other heuristic that genuinely cannot apply to the surface under review. Write `n/a` in the Score cell with a one-line reason, and renormalize the total to the applicable maximum (e.g. **24/32** when two heuristics are n/a) so the rating band stays proportional. The persisted snapshot must record the applicable maximum and which heuristics were scored n/a.
|
||||
|
||||
**LLM assessment**: Your own evaluation of AI slop tells. Cover overall aesthetic feel, layout sameness, generic composition, missed opportunities for personality.
|
||||
#### Design Specificity Verdict
|
||||
|
||||
**Start here.** Does the result feel authored for this product, or category-interchangeable?
|
||||
|
||||
**LLM assessment**: Your unanchored evaluation of design specificity. Cover overall coherence, structural sameness, category-interchangeable choices, and missed opportunities for product character.
|
||||
|
||||
**Deterministic scan**: Summarize what the automated detector found, with counts and file locations. Note any additional issues the detector caught that you missed, and flag any false positives.
|
||||
|
||||
@@ -188,44 +194,60 @@ Codex Run Notes are final-chat only. Do not include this section in the persiste
|
||||
- Prioritize ruthlessly. If everything is important, nothing is.
|
||||
- Don't soften criticism. Developers need honest feedback to ship great design.
|
||||
|
||||
### Deliver the Report
|
||||
|
||||
Write the full report into the chat response now, before any persistence work. This is the deliverable; everything below it is bookkeeping.
|
||||
|
||||
Do this first because the alternative is the most common way this command fails: the report gets composed once, straight into the persistence heredoc, and the run ends with a perfect archive nobody has read. Composing it into a file is not delivering it. If the report exists only in `.impeccable/critique/`, the run produced nothing.
|
||||
|
||||
Persistence is not the end of the run. After it, the response continues with the trend line and the close.
|
||||
|
||||
### Persist the Snapshot
|
||||
|
||||
Once the report above is finalized, write it to `.impeccable/critique/` so the user can refer back, and so `$impeccable polish` can pick up the priority issues without a copy-paste.
|
||||
|
||||
Skip this step if the Setup slug was null (vague or root-level target).
|
||||
|
||||
1. **Write the body to a temp file** so you can pipe it to the helper. Use the full critique report (heuristic table, anti-patterns verdict, priority issues, persona red flags, minor observations, and questions), but stop before the "Ask the User" / "Recommended Actions" sections that come later.
|
||||
1. **Write the body to a temp file** so you can pipe it to the helper. Use the full critique report (heuristic table, design-specificity verdict, priority issues, persona red flags, minor observations, and questions), but stop before the "Ask the User" / "Recommended Actions" sections that come later.
|
||||
|
||||
This is a copy of the report you already delivered above, for later commands to read. It is not delivery. If you find yourself composing the report for the first time inside this heredoc, you have skipped Deliver the Report; go back and send it.
|
||||
|
||||
Codex: exclude Run Notes from the temp body file; Run Notes are final-chat only because persistence, trend read, and temp cleanup happen after the snapshot write.
|
||||
|
||||
2. **Pass the structured metadata** through `IMPECCABLE_CRITIQUE_META` (JSON), then run the write command:
|
||||
```bash
|
||||
IMPECCABLE_CRITIQUE_META='{"target":"<user phrasing>","total_score":<n>,"p0_count":<n>,"p1_count":<n>}' \
|
||||
node .agents/skills/impeccable/scripts/critique-storage.mjs write <slug> <body-file>
|
||||
IMPECCABLE_CRITIQUE_META='{"target":"<user phrasing>","total_score":<n>,"max_score":<n>,"na_heuristics":"<comma-separated numbers, or empty>","p0_count":<n>,"p1_count":<n>}' \
|
||||
.agents/skills/impeccable/scripts/impeccable critique-storage write "<resolved target>" <body-file>
|
||||
```
|
||||
The helper prints the absolute path it wrote.
|
||||
`max_score` is the applicable maximum from the heuristic table (40 when every heuristic applied), so a later run can tell a renormalized total from a full one. For a local file target, the helper also records an exact content fingerprint so polish can distinguish the assessed bytes from later edits without relying on Git state or timestamps. The helper prints the absolute path it wrote. Leave that file on disk. Polish closes it; this run does not.
|
||||
|
||||
3. **Delete the temp body file** after the write attempt completes, whether the write succeeded or failed. If deletion fails, mention `temp-file cleanup failed: <reason>` briefly in the final output, but do not block the critique.
|
||||
|
||||
4. **Read the trend** for context:
|
||||
```bash
|
||||
node .agents/skills/impeccable/scripts/critique-storage.mjs trend <slug> 5
|
||||
.agents/skills/impeccable/scripts/impeccable critique-storage trend "<resolved target>" 5
|
||||
```
|
||||
This returns a JSON array of the last 5 frontmatter entries (including the one you just wrote).
|
||||
|
||||
5. **Append a single line to the user-visible output**, after the report and before the questions:
|
||||
|
||||
> **Trend for `<slug>` (last 5 runs): 24 → 28 → 32 → 29 → 32**
|
||||
> **Trend for `<slug>` (last 5 runs): 24 → 28 → 32 → 29 → 32 (out of 40)**
|
||||
> Wrote `.impeccable/critique/<filename>`.
|
||||
|
||||
Read `max_score` on each trend entry. When every entry shares one maximum, state it once as above. When they differ, print each score with its own denominator (`24/32 → 30/40`) and note that the runs scored different heuristic sets, so the line is not a like-for-like comparison. Treat a missing `max_score` on an older entry as 40.
|
||||
|
||||
If this is the first run for the slug, the trend is just one score; say so: "First run for this target, no trend yet."
|
||||
|
||||
6. **Close the run.** Go to Ask the User below and emit the questions, or the `Questions skipped: <reason>` line when the count allows it. The run is not complete until you do. Persistence is bookkeeping and cleanup is not an ending; stopping here leaves the user with a report and no way forward, and leaves `$impeccable polish` with no priorities to inherit.
|
||||
|
||||
This is fire-and-forget. Do not show the user the helper's JSON output; only the human-readable trend line and the written path. Failures here should not block the rest of the flow; print the error and move on.
|
||||
|
||||
### Ask the User
|
||||
|
||||
**After presenting findings**, use targeted questions based on what was actually found. STOP and use Codex's structured user-input/question tool when available; if unavailable, ask directly in chat to clarify what you cannot infer. These answers will shape the action plan.
|
||||
|
||||
Ask in the same message that carries the report, with the report written out first and the question last. Do not split the two across turns: a turn that ends on the report is a turn that ends, and the questions never arrive. Order within the message is what matters, because prose emitted after a structured question is withheld until the user answers.
|
||||
|
||||
Ask questions along these lines (adapt to the specific findings; do NOT ask generic questions):
|
||||
|
||||
1. **Priority direction**: Based on the issues found, ask which category matters most to the user right now. For example: "I found problems with visual hierarchy, color usage, and information overload. Which area should we tackle first?" Offer the top 2-3 issue categories as options.
|
||||
@@ -240,9 +262,9 @@ Ask questions along these lines (adapt to the specific findings; do NOT ask gene
|
||||
- Every question must reference specific findings from the report. Never ask generic "who is your audience?" questions.
|
||||
- Keep it to 2-4 questions maximum. Respect the user's time.
|
||||
- Offer concrete options, not open-ended prompts.
|
||||
- If findings are straightforward (e.g., only 1-2 clear issues), skip questions and go directly to Recommended Actions.
|
||||
- Skipping is allowed only when the report listed **fewer than 3 Priority Issues**. Count them; do not judge the findings "straightforward" by feel. At 3 or more, the questions are required.
|
||||
|
||||
Codex final-question gate: The user-visible response must either include the targeted questions or explicitly say `Questions skipped: <reason>` because the findings were straightforward. Each question must include 2-3 concrete answer options tied to the actual critique findings. Do not end with only open-ended questions.
|
||||
**Final-question gate.** The user-visible response must either include the targeted questions or carry the literal line `Questions skipped: <reason>` naming the count that permitted the skip. Each question must include 2-3 concrete answer options tied to the actual critique findings. Do not end with only open-ended questions, and do not end with neither: stopping after the report, having asked nothing and printed no skip line, is the most common way this command fails.
|
||||
|
||||
### Recommended Actions
|
||||
|
||||
@@ -343,11 +365,11 @@ At any decision point, count the number of distinct options, actions, or pieces
|
||||
- **8+ items**: Overloaded; users will skip, misclick, or abandon
|
||||
|
||||
**Practical applications**:
|
||||
- Navigation menus: ≤5 top-level items (group the rest under clear categories)
|
||||
- Form sections: ≤4 fields visible per group before a visual break
|
||||
- Action buttons: 1 primary, 1–2 secondary, group the rest in a menu
|
||||
- Dashboard widgets: ≤4 key metrics visible without scrolling
|
||||
- Pricing tiers: ≤3 options (more causes analysis paralysis)
|
||||
- Navigation menus: ≤5 top-level items (group the rest under clear categories)
|
||||
- Long-form articles: one reading path; gather related links into a single block at the end instead of scattering them mid-flow
|
||||
- Documentation sidebars: ≤4 sibling choices visible per level before grouping kicks in
|
||||
- Portfolio and gallery indexes: one decision per screen (which piece to open), not filter, sort, and tag controls all at once
|
||||
|
||||
---
|
||||
|
||||
@@ -607,6 +629,8 @@ Even if the system is usable without docs, help should be easy to find, task-foc
|
||||
| 12–19 | Poor | Major UX overhaul required; core experience broken |
|
||||
| 0–11 | Critical | Redesign needed; unusable in current state |
|
||||
|
||||
When heuristics were scored `n/a`, the maximum is lower than 40; read the band off the percentage instead of the raw number (90%+ Excellent, 70%+ Good, 50%+ Acceptable, 30%+ Poor, below that Critical). 24/32 is 75%, so Good.
|
||||
|
||||
---
|
||||
|
||||
#### Issue Severity (P0–P3)
|
||||
|
||||
Reference in New Issue
Block a user