mandrel 2.6.0 → 2.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/README.md +104 -330
- package/.agents/agents/auditor.md +135 -0
- package/.agents/agents/plan-critic.md +80 -0
- package/.agents/audit-checklists/dependencies.md +7 -0
- package/.agents/audit-checklists/documentation.md +1 -0
- package/.agents/docs/SDLC.md +69 -162
- package/.agents/docs/configuration.md +133 -499
- package/.agents/docs/quality-gates.md +59 -180
- package/.agents/instructions.md +170 -295
- package/.agents/rules/changelog-style.md +8 -66
- package/.agents/rules/ci-remediation.md +65 -124
- package/.agents/rules/gherkin-standards.md +10 -31
- package/.agents/rules/git-conventions-reference.md +28 -61
- package/.agents/rules/git-conventions.md +1 -1
- package/.agents/rules/orchestration-error-handling.md +5 -15
- package/.agents/rules/security-baseline.md +7 -13
- package/.agents/rules/shell-conventions.md +4 -13
- package/.agents/rules/test-seams.md +2 -2
- package/.agents/rules/testing-standards.md +7 -17
- package/.agents/scripts/lib/feedback-loop/audit-results-graduator.js +7 -2
- package/.agents/scripts/lib/feedback-loop/graduator-core.js +144 -12
- package/.agents/scripts/lib/feedback-loop/retro-proposals-graduator.js +11 -1
- package/.agents/scripts/lib/observability/runtime-friction.js +97 -36
- package/.agents/scripts/lib/orchestration/single-story-close/phases/post-land.js +29 -5
- package/.agents/skills/core/api-and-interface-design/SKILL.md +23 -297
- package/.agents/skills/core/api-and-interface-design/reference.md +76 -0
- package/.agents/skills/core/browser-testing-with-devtools/SKILL.md +20 -327
- package/.agents/skills/core/browser-testing-with-devtools/reference.md +74 -0
- package/.agents/skills/core/code-review-and-quality/reference.md +16 -398
- package/.agents/skills/core/debugging-and-error-recovery/reference.md +14 -281
- package/.agents/skills/core/documentation-and-adrs/reference.md +42 -338
- package/.agents/skills/core/git-workflow-and-versioning/SKILL.md +28 -326
- package/.agents/skills/core/idea-refinement/SKILL.md +67 -193
- package/.agents/skills/core/security-and-hardening/SKILL.md +15 -31
- package/.agents/skills/core/security-and-hardening/reference.md +15 -273
- package/.agents/skills/skills.index.json +5 -5
- package/.agents/skills/stack/qa/gherkin-authoring/SKILL.md +16 -222
- package/.agents/skills/stack/qa/gherkin-authoring/reference.md +157 -0
- package/.agents/skills/stack/qa/playwright/SKILL.md +0 -29
- package/.agents/skills/stack/qa/qa-explore-driving/SKILL.md +19 -23
- package/.agents/skills/stack/qa/qa-harness/SKILL.md +35 -53
- package/.agents/skills/stack/qa/vitest/SKILL.md +0 -29
- package/.agents/workflows/audit-accessibility.md +34 -108
- package/.agents/workflows/audit-architecture.md +35 -123
- package/.agents/workflows/audit-clean-code.md +19 -78
- package/.agents/workflows/audit-data-model.md +32 -100
- package/.agents/workflows/audit-dependencies.md +47 -111
- package/.agents/workflows/audit-devops.md +16 -83
- package/.agents/workflows/audit-documentation.md +46 -93
- package/.agents/workflows/audit-navigability.md +26 -80
- package/.agents/workflows/audit-performance.md +40 -106
- package/.agents/workflows/audit-privacy.md +17 -80
- package/.agents/workflows/audit-quality.md +35 -99
- package/.agents/workflows/audit-security.md +20 -78
- package/.agents/workflows/audit-seo.md +20 -98
- package/.agents/workflows/audit-sre.md +20 -88
- package/.agents/workflows/audit-to-stories.md +1 -8
- package/.agents/workflows/audit-ux-ui.md +17 -80
- package/.agents/workflows/deliver.md +54 -9
- package/.agents/workflows/git-cleanup.md +50 -275
- package/.agents/workflows/helpers/audit-lens-core.md +230 -0
- package/.agents/workflows/helpers/code-review.md +11 -23
- package/.agents/workflows/helpers/deliver-story-reference.md +114 -17
- package/.agents/workflows/helpers/deliver-story.md +26 -186
- package/.agents/workflows/helpers/qa-core.md +174 -0
- package/.agents/workflows/helpers/qa-run-scenario-reference.md +35 -0
- package/.agents/workflows/helpers/qa-run-scenario.md +11 -25
- package/.agents/workflows/helpers/worktree-lifecycle.md +6 -67
- package/.agents/workflows/mandrel-update.md +7 -13
- package/.agents/workflows/plan.md +17 -15
- package/.agents/workflows/qa-assist.md +140 -269
- package/.agents/workflows/qa-explore.md +125 -316
- package/.agents/workflows/qa-run.md +180 -380
- package/docs/CHANGELOG.md +18 -0
- package/package.json +1 -1
- package/.agents/workflows/helpers/audit-dual-path.md +0 -59
- package/.agents/workflows/helpers/audit-self-check.md +0 -70
- package/.agents/workflows/helpers/audit-severity-scale.md +0 -19
|
@@ -4,6 +4,19 @@ description: Audit SEO fundamentals and Generative Engine Optimization signals (
|
|
|
4
4
|
|
|
5
5
|
# SEO & Generative Engine Optimization Audit
|
|
6
6
|
|
|
7
|
+
You are a Senior Technical SEO & Generative Engine Optimization (GEO) Specialist
|
|
8
|
+
(semantic HTML, JSON-LD Schema, Core Web Vitals) surfacing structural, semantic,
|
|
9
|
+
and content-level improvements that increase discoverability in both traditional
|
|
10
|
+
search indexes and AI answer engines. The shared lens machinery — read-only
|
|
11
|
+
constraint, scope interpretation, report envelope + finding-block skeleton,
|
|
12
|
+
severity scale, self-cross-check, and execution strategy — lives in
|
|
13
|
+
[`helpers/audit-lens-core.md`](helpers/audit-lens-core.md). Write the report to
|
|
14
|
+
`{{auditOutputDir}}/audit-seo-results.md`. Each finding carries a **Category:**
|
|
15
|
+
(`SEO | GEO | Core Web Vitals | Crawlability`); the report adds a **Detailed
|
|
16
|
+
Audit Table** (an at-a-glance index — not machine-parsed; every row MUST also
|
|
17
|
+
have a full Detailed Findings entry) and a **GEO-Specific Recommendations**
|
|
18
|
+
section.
|
|
19
|
+
|
|
7
20
|
## Applicability
|
|
8
21
|
|
|
9
22
|
**Web targets only.** This lens is registered with `target: "web"` in
|
|
@@ -14,40 +27,19 @@ checkout (configured navigability `routeGlobs`, a declared web-framework
|
|
|
14
27
|
dependency, or a tracked `.html` / `.css` / `.jsx` / `.tsx` source file), not
|
|
15
28
|
from an `.agentrc` key, and the probe fails open when indeterminate.
|
|
16
29
|
|
|
17
|
-
##
|
|
18
|
-
|
|
19
|
-
Senior Technical SEO and Generative Engine Optimization (GEO) Specialist. You
|
|
20
|
-
are an expert in semantic HTML, JSON-LD Schema markup, Core Web Vitals, and
|
|
21
|
-
optimizing content structure for both traditional search engines (Google, Bing)
|
|
22
|
-
and Large Language Models (ChatGPT, Perplexity, Gemini).
|
|
23
|
-
|
|
24
|
-
## Context & Objective
|
|
25
|
-
|
|
26
|
-
You are performing a comprehensive, read-only SEO and GEO audit of this
|
|
27
|
-
codebase. Your goal is to surface structural, semantic, and content-level
|
|
28
|
-
improvements that will increase discoverability in both traditional search
|
|
29
|
-
indexes and AI-powered answer engines — without making any immediate changes.
|
|
30
|
+
## Scope
|
|
30
31
|
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
|
|
34
|
-
following block is populated with the Story (or plan-run) change-set file list.
|
|
35
|
-
Otherwise — for any manual `/audit-<dimension>` invocation — the block
|
|
36
|
-
renders the literal substitution token and you MUST treat it as **no
|
|
37
|
-
scope filter — run the lens codebase-wide** exactly as you would have
|
|
38
|
-
before this section existed.
|
|
32
|
+
Interpret this lens's change-set fence per the core's Scope interpretation:
|
|
39
33
|
|
|
40
34
|
```text
|
|
41
35
|
{{changedFiles}}
|
|
42
36
|
```
|
|
43
37
|
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
proceed with the full codebase-wide scan defined in the remaining
|
|
50
|
-
steps.
|
|
38
|
+
## Execution strategy
|
|
39
|
+
|
|
40
|
+
Run this lens as a single `subagent_type: auditor` dispatch returning the report
|
|
41
|
+
path + Executive Summary; sequential inline execution is the fallback (see the
|
|
42
|
+
core's Execution strategy).
|
|
51
43
|
|
|
52
44
|
## Step 0: Indexability gate (run first)
|
|
53
45
|
|
|
@@ -67,8 +59,6 @@ a login-gated dashboard is *supposed* to be invisible to crawlers, so a missing
|
|
|
67
59
|
|
|
68
60
|
## Step 1: Framework-aware metadata detection matrix
|
|
69
61
|
|
|
70
|
-
> Apply [`helpers/parallel-tooling.md`](helpers/parallel-tooling.md) when batching the scan below — independent reads belong in one turn, long shells run via `run_in_background` + `Monitor`.
|
|
71
|
-
|
|
72
62
|
Modern web consumers almost never ship literal `<head><meta></head>` HTML — the
|
|
73
63
|
metadata is produced by a framework mechanism. **Identify the mechanism first,
|
|
74
64
|
then probe the surfaces that mechanism uses.** Reporting "no `<meta>` tags found"
|
|
@@ -113,71 +103,3 @@ Evaluate the gathered context against the following dimensions:
|
|
|
113
103
|
4. **Crawlability:** `robots.txt`, `sitemap.xml` (including generated
|
|
114
104
|
`sitemap.*`/`robots.*` route handlers), and any `noindex` directives that may
|
|
115
105
|
unintentionally block indexable pages.
|
|
116
|
-
|
|
117
|
-
## Step 3: Output Requirements
|
|
118
|
-
|
|
119
|
-
Generate and save a highly structured Markdown audit report to
|
|
120
|
-
`{{auditOutputDir}}/audit-seo-results.md`, using the exact template below.
|
|
121
|
-
|
|
122
|
-
> Grade every finding's severity on the shared
|
|
123
|
-
> [`Critical | High | Medium | Low` scale](helpers/audit-severity-scale.md).
|
|
124
|
-
|
|
125
|
-
```markdown
|
|
126
|
-
# SEO & GEO Audit Report
|
|
127
|
-
|
|
128
|
-
## Executive Summary
|
|
129
|
-
|
|
130
|
-
[A high-level view of the site's current optimization health, highlighting the
|
|
131
|
-
primary gaps and the most impactful opportunities.]
|
|
132
|
-
|
|
133
|
-
## Detailed Audit Table
|
|
134
|
-
|
|
135
|
-
[A supplementary at-a-glance index only. Every row MUST also have a full
|
|
136
|
-
`## Detailed Findings` entry below — the Detailed Findings blocks are the
|
|
137
|
-
machine-parsed source of record; this table is not parsed.]
|
|
138
|
-
|
|
139
|
-
| Issue | Impact | Category | Suggested Fix |
|
|
140
|
-
| ------------------- | --------------------------- | ---------- | ------------- |
|
|
141
|
-
| [Issue description] | Critical / High / Med / Low | SEO or GEO | [Brief fix] |
|
|
142
|
-
|
|
143
|
-
## GEO-Specific Recommendations
|
|
144
|
-
|
|
145
|
-
[Specific advice on how to make this codebase more readable for AI models —
|
|
146
|
-
e.g., adding specific Schema types, flattening nested DOM structures, or
|
|
147
|
-
reformatting key content as FAQ blocks.]
|
|
148
|
-
|
|
149
|
-
## Detailed Findings
|
|
150
|
-
|
|
151
|
-
[Mandatory: emit one entry per issue in the Detailed Audit Table above, using
|
|
152
|
-
the following strict structure. Lead each title with the primary file the
|
|
153
|
-
finding lives in:]
|
|
154
|
-
|
|
155
|
-
### `path/to/primary-file.ext` — [Short title of the issue]
|
|
156
|
-
|
|
157
|
-
- **Category:** [SEO | GEO | Core Web Vitals | Crawlability]
|
|
158
|
-
- **Impact:** [Critical | High | Medium | Low]
|
|
159
|
-
- **Location:** `path/to/primary-file.ext:line`
|
|
160
|
-
- **Current State:** [What exists in the codebase and why it's suboptimal]
|
|
161
|
-
- **Recommendation & Rationale:** [The specific fix and how it improves
|
|
162
|
-
discoverability or LLM retrieval]
|
|
163
|
-
- **Acceptance signal:** [the command or observable that proves this finding is remediated — e.g. the meta tag now present in the rendered head, or a re-run of this lens]
|
|
164
|
-
- **Agent Prompt:**
|
|
165
|
-
`[A copy-pasteable, highly specific prompt to execute this fix independently]`
|
|
166
|
-
```
|
|
167
|
-
|
|
168
|
-
---
|
|
169
|
-
|
|
170
|
-
## Constraint
|
|
171
|
-
|
|
172
|
-
Do NOT rewrite or modify any files. Do NOT implement the changes. Focus strictly
|
|
173
|
-
on analyzing the code. Output the report and stop.
|
|
174
|
-
|
|
175
|
-
## Self-cross-check (mandatory — filter false positives before you finalize)
|
|
176
|
-
|
|
177
|
-
Before you write the report artifact from the previous step, run the shared
|
|
178
|
-
adversarial self-cross-check over your Detailed Findings — see
|
|
179
|
-
[`helpers/audit-self-check.md`](helpers/audit-self-check.md). It defines the
|
|
180
|
-
per-finding evidence bar, the exclusion list, and the final re-open-and-drop
|
|
181
|
-
pass whose `kept <k> / dropped <d>` counts you record in the Executive
|
|
182
|
-
Summary, so the sequential single-pass path filters unverified findings just as
|
|
183
|
-
the orchestrated path's adversarial reviewer does.
|
|
@@ -4,42 +4,33 @@ description: "Audit production-readiness for a release candidate: SLOs, observab
|
|
|
4
4
|
|
|
5
5
|
# Production Release Candidate Audit
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
## Scope
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
following block is populated with the Story (or plan-run) change-set file list.
|
|
23
|
-
Otherwise — for any manual `/audit-<dimension>` invocation — the block
|
|
24
|
-
renders the literal substitution token and you MUST treat it as **no
|
|
25
|
-
scope filter — run the lens codebase-wide** exactly as you would have
|
|
26
|
-
before this section existed.
|
|
7
|
+
You are a Senior SRE & Lead Developer running an operational-readiness audit for
|
|
8
|
+
a production release candidate — rollback & recovery paths, observability &
|
|
9
|
+
instrumentation, resilience & failure handling, and runbooks & operational
|
|
10
|
+
docs. The shared lens machinery — read-only constraint, scope interpretation,
|
|
11
|
+
report envelope + finding-block skeleton, severity scale, self-cross-check, and
|
|
12
|
+
execution strategy — lives in
|
|
13
|
+
[`helpers/audit-lens-core.md`](helpers/audit-lens-core.md). Write the report to
|
|
14
|
+
`{{auditOutputDir}}/audit-sre-results.md`. Each finding carries a **Category:**
|
|
15
|
+
(`Rollback & Recovery | Observability | Resilience | Runbooks`); the report adds
|
|
16
|
+
a **Release Readiness Checklist** table (per-category ✅ Clear / ⚠️ Issues
|
|
17
|
+
Found).
|
|
18
|
+
|
|
19
|
+
## Scope
|
|
20
|
+
|
|
21
|
+
Interpret this lens's change-set fence per the core's Scope interpretation:
|
|
27
22
|
|
|
28
23
|
```text
|
|
29
24
|
{{changedFiles}}
|
|
30
25
|
```
|
|
31
26
|
|
|
32
|
-
|
|
33
|
-
restrict your analysis to those files (and their direct dependencies
|
|
34
|
-
when the lens explicitly calls for cross-file reasoning).
|
|
35
|
-
- If the block above renders as the literal string `{{changedFiles}}`
|
|
36
|
-
(i.e. no substitution was supplied), ignore this section entirely and
|
|
37
|
-
proceed with the full codebase-wide scan defined in the remaining
|
|
38
|
-
steps.
|
|
27
|
+
## Execution strategy
|
|
39
28
|
|
|
40
|
-
|
|
29
|
+
Run this lens as a single `subagent_type: auditor` dispatch returning the report
|
|
30
|
+
path + Executive Summary; sequential inline execution is the fallback (see the
|
|
31
|
+
core's Execution strategy).
|
|
41
32
|
|
|
42
|
-
|
|
33
|
+
## Step 1: Resilience Detection Battery (Read-Only, Tool-First)
|
|
43
34
|
|
|
44
35
|
This lens audits **operational readiness** — can this release be observed,
|
|
45
36
|
survive failure, and be rolled back? It deliberately does **not** re-audit
|
|
@@ -111,62 +102,3 @@ Evaluate the release candidate against these **production-readiness** criteria.
|
|
|
111
102
|
wired into the orchestrator so a bad rollout is caught before it takes
|
|
112
103
|
traffic?
|
|
113
104
|
- **On-Call Escalation:** Is ownership / escalation for this surface documented?
|
|
114
|
-
|
|
115
|
-
## Step 3: Output Requirements
|
|
116
|
-
|
|
117
|
-
Generate and save a highly structured Markdown audit report to
|
|
118
|
-
`{{auditOutputDir}}/audit-sre-results.md`, using the exact template below.
|
|
119
|
-
|
|
120
|
-
> Grade every finding's severity on the shared
|
|
121
|
-
> [`Critical | High | Medium | Low` scale](helpers/audit-severity-scale.md).
|
|
122
|
-
|
|
123
|
-
```markdown
|
|
124
|
-
# Production Release Candidate Audit
|
|
125
|
-
|
|
126
|
-
## Executive Summary
|
|
127
|
-
|
|
128
|
-
[A brief overview of the release candidate's health. Highlight the most critical
|
|
129
|
-
risks that must be resolved before deployment.]
|
|
130
|
-
|
|
131
|
-
## Detailed Findings
|
|
132
|
-
|
|
133
|
-
[Group findings by the categories below. Use this structure for each item.
|
|
134
|
-
Lead each title with the primary file the finding lives in:]
|
|
135
|
-
|
|
136
|
-
### `path/to/primary-file.ext` — [Short title of the issue]
|
|
137
|
-
|
|
138
|
-
- **Category:** [Rollback & Recovery | Observability | Resilience | Runbooks]
|
|
139
|
-
- **Severity:** [Critical | High | Medium | Low]
|
|
140
|
-
- **Location:** `path/to/primary-file.ext:line`
|
|
141
|
-
- **Current State:** [What exists and why it's a risk]
|
|
142
|
-
- **Recommendation:** [The specific fix and rationale]
|
|
143
|
-
- **Acceptance signal:** [the command or observable that proves this finding is remediated — e.g. `npm test`, a grep that now returns empty, or a re-run of this lens]
|
|
144
|
-
- **Agent Prompt:**
|
|
145
|
-
`[A copy-pasteable, highly specific prompt to execute this fix independently]`
|
|
146
|
-
|
|
147
|
-
## Release Readiness Checklist
|
|
148
|
-
|
|
149
|
-
| Category | Status |
|
|
150
|
-
| -------------------- | -------------------------- |
|
|
151
|
-
| Rollback & Recovery | ✅ Clear / ⚠️ Issues Found |
|
|
152
|
-
| Observability | ✅ Clear / ⚠️ Issues Found |
|
|
153
|
-
| Resilience | ✅ Clear / ⚠️ Issues Found |
|
|
154
|
-
| Runbooks | ✅ Clear / ⚠️ Issues Found |
|
|
155
|
-
```
|
|
156
|
-
|
|
157
|
-
---
|
|
158
|
-
|
|
159
|
-
## Constraint
|
|
160
|
-
|
|
161
|
-
Do NOT generate code fixes, edit files, or create branches. This is strictly a
|
|
162
|
-
read-only analysis. Output the report and stop.
|
|
163
|
-
|
|
164
|
-
## Self-cross-check (mandatory — filter false positives before you finalize)
|
|
165
|
-
|
|
166
|
-
Before you write the report artifact from the previous step, run the shared
|
|
167
|
-
adversarial self-cross-check over your Detailed Findings — see
|
|
168
|
-
[`helpers/audit-self-check.md`](helpers/audit-self-check.md). It defines the
|
|
169
|
-
per-finding evidence bar, the exclusion list, and the final re-open-and-drop
|
|
170
|
-
pass whose `kept <k> / dropped <d>` counts you record in the Executive
|
|
171
|
-
Summary, so the sequential single-pass path filters unverified findings just as
|
|
172
|
-
the orchestrated path's adversarial reviewer does.
|
|
@@ -19,12 +19,6 @@ report under `temp/audits/`. Every `### Finding` block in those reports
|
|
|
19
19
|
already carries the fields a Story body needs (Severity / Impact,
|
|
20
20
|
Dimension / Category, Current State, Recommendation, Agent Prompt).
|
|
21
21
|
|
|
22
|
-
`/audit-to-stories` closes the loop: it parses those reports, groups
|
|
23
|
-
related findings (including across audit dimensions), classifies each
|
|
24
|
-
group as eligible-to-create or already-tracked, and — at the operator's
|
|
25
|
-
choice — either chains into `/plan --seed-file` for a planned Story
|
|
26
|
-
(or N>1 under the split policy) or opens standalone Stories directly.
|
|
27
|
-
|
|
28
22
|
The audit producers themselves are **not modified** by this workflow.
|
|
29
23
|
They remain read-only emitters of audit reports.
|
|
30
24
|
|
|
@@ -295,8 +289,7 @@ and prints a run-summary JSON (create / skip-open / skip-reoccurring /
|
|
|
295
289
|
suppressed-by-ledger tallies, plus the re-detected open Issue numbers an
|
|
296
290
|
operator may want a "re-detected" comment on). `--dry-run` performs zero GitHub
|
|
297
291
|
writes and skips the ledger write, emitting only the summary. The host
|
|
298
|
-
scheduler owns the cadence; this workflow owns the routing.
|
|
299
|
-
folds in the `loops/nightly-audit.md` starter unit retired in issue 4482.)
|
|
292
|
+
scheduler owns the cadence; this workflow owns the routing.
|
|
300
293
|
|
|
301
294
|
## See also
|
|
302
295
|
|
|
@@ -4,6 +4,16 @@ description: Audit UX/UI consistency and design system adherence
|
|
|
4
4
|
|
|
5
5
|
# UX/UI & Design System Audit
|
|
6
6
|
|
|
7
|
+
You are a Lead Product Designer & Frontend Architect evaluating the frontend for
|
|
8
|
+
UI consistency, UX best practices, and adherence to the project's design system,
|
|
9
|
+
ensuring the app feels premium and cohesive. The shared lens machinery —
|
|
10
|
+
read-only constraint, scope interpretation, report envelope + finding-block
|
|
11
|
+
skeleton, severity scale, self-cross-check, and execution strategy — lives in
|
|
12
|
+
[`helpers/audit-lens-core.md`](helpers/audit-lens-core.md). Write the report to
|
|
13
|
+
`{{auditOutputDir}}/audit-ux-ui-results.md`. Dimension values:
|
|
14
|
+
`Visual Consistency | UX Best Practices | Accessibility`; the report adds a
|
|
15
|
+
**Micro-animation Opportunities** section.
|
|
16
|
+
|
|
7
17
|
## Applicability
|
|
8
18
|
|
|
9
19
|
**Web targets only.** Registered with `target: "web"` in
|
|
@@ -11,36 +21,19 @@ description: Audit UX/UI consistency and design system adherence
|
|
|
11
21
|
on a project with no rendered frontend. See the `target` key's schema
|
|
12
22
|
description for how applicability is probed from the consumer's checkout.
|
|
13
23
|
|
|
14
|
-
##
|
|
15
|
-
|
|
16
|
-
Lead Product Designer & Frontend Architect
|
|
17
|
-
|
|
18
|
-
## Context & Objective
|
|
24
|
+
## Scope
|
|
19
25
|
|
|
20
|
-
|
|
21
|
-
adherence to the project's design system. Ensure the application feels premium
|
|
22
|
-
and cohesive.
|
|
23
|
-
|
|
24
|
-
## Scope (Story / plan-run mode)
|
|
25
|
-
|
|
26
|
-
When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
|
|
27
|
-
following block is populated with the Story (or plan-run) change-set file list.
|
|
28
|
-
Otherwise — for any manual `/audit-<dimension>` invocation — the block
|
|
29
|
-
renders the literal substitution token and you MUST treat it as **no
|
|
30
|
-
scope filter — run the lens codebase-wide** exactly as you would have
|
|
31
|
-
before this section existed.
|
|
26
|
+
Interpret this lens's change-set fence per the core's Scope interpretation:
|
|
32
27
|
|
|
33
28
|
```text
|
|
34
29
|
{{changedFiles}}
|
|
35
30
|
```
|
|
36
31
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
proceed with the full codebase-wide scan defined in the remaining
|
|
43
|
-
steps.
|
|
32
|
+
## Execution strategy
|
|
33
|
+
|
|
34
|
+
Run this lens as a single `subagent_type: auditor` dispatch returning the report
|
|
35
|
+
path + Executive Summary; sequential inline execution is the fallback (see the
|
|
36
|
+
core's Execution strategy).
|
|
44
37
|
|
|
45
38
|
## Step 0: Discover the design-system SSOT (run first)
|
|
46
39
|
|
|
@@ -66,8 +59,6 @@ ideal. If **no** design-system SSOT exists, say so and downgrade findings to
|
|
|
66
59
|
|
|
67
60
|
## Step 1: Mechanical detector battery, then LLM triage
|
|
68
61
|
|
|
69
|
-
> Apply [`helpers/parallel-tooling.md`](helpers/parallel-tooling.md) when batching the scan below — independent reads belong in one turn, long shells run via `run_in_background` + `Monitor`.
|
|
70
|
-
|
|
71
62
|
Run the **mechanical detectors first** (cheap, deterministic greps that surface
|
|
72
63
|
candidates), then apply **LLM triage** to each candidate against the Step 0
|
|
73
64
|
baseline — a mechanical hit is a *candidate*, not automatically a finding.
|
|
@@ -107,57 +98,3 @@ baseline — a mechanical hit is a *candidate*, not automatically a finding.
|
|
|
107
98
|
This lens keeps token/component design-system adherence; defer every WCAG
|
|
108
99
|
success-criterion judgement to the accessibility lens so the two never
|
|
109
100
|
double-report.
|
|
110
|
-
|
|
111
|
-
## Step 3: Output Requirements
|
|
112
|
-
|
|
113
|
-
Generate and save a highly structured Markdown audit report to
|
|
114
|
-
`{{auditOutputDir}}/audit-ux-ui-results.md`, using the exact template below.
|
|
115
|
-
|
|
116
|
-
> Grade every finding's severity on the shared
|
|
117
|
-
> [`Critical | High | Medium | Low` scale](helpers/audit-severity-scale.md).
|
|
118
|
-
|
|
119
|
-
```markdown
|
|
120
|
-
# UX/UI & Design System Audit report
|
|
121
|
-
|
|
122
|
-
## Executive Summary
|
|
123
|
-
|
|
124
|
-
[Overview of design system health (Score 1-10) and adherence to
|
|
125
|
-
tokens/components.]
|
|
126
|
-
|
|
127
|
-
## Detailed Findings
|
|
128
|
-
|
|
129
|
-
[For every inconsistency or UX improvement identified, use the following strict
|
|
130
|
-
structure. Lead each title with the primary file the finding lives in:]
|
|
131
|
-
|
|
132
|
-
### `path/to/primary-file.ext` — [Short title of the issue]
|
|
133
|
-
|
|
134
|
-
- **Dimension:** [e.g., Visual Consistency | UX Best Practices | Accessibility]
|
|
135
|
-
- **Impact:** [Critical | High | Medium | Low]
|
|
136
|
-
- **Location:** `path/to/primary-file.ext:line`
|
|
137
|
-
- **Current State:** [What is currently implemented and why it is sub-optimal]
|
|
138
|
-
- **Recommendation & Rationale:** [The specific UI/UX change and how it improves
|
|
139
|
-
premium feel or usability]
|
|
140
|
-
- **Acceptance signal:** [the command or observable that proves this finding is remediated — e.g. the token now applied in the rendered component, or a re-run of this lens]
|
|
141
|
-
- **Agent Prompt:**
|
|
142
|
-
`[A copy-pasteable, highly specific prompt to execute this UI change independently]`
|
|
143
|
-
|
|
144
|
-
## Micro-animation Opportunities
|
|
145
|
-
|
|
146
|
-
- [Suggest 2-3 places where subtle transitions could enhance the "premium"
|
|
147
|
-
feel.]
|
|
148
|
-
```
|
|
149
|
-
|
|
150
|
-
## Constraint
|
|
151
|
-
|
|
152
|
-
This is a **read-only** audit. Provide the critique and implementation
|
|
153
|
-
suggestions, but do not modify styles or components.
|
|
154
|
-
|
|
155
|
-
## Self-cross-check (mandatory — filter false positives before you finalize)
|
|
156
|
-
|
|
157
|
-
Before you write the report artifact from the previous step, run the shared
|
|
158
|
-
adversarial self-cross-check over your Detailed Findings — see
|
|
159
|
-
[`helpers/audit-self-check.md`](helpers/audit-self-check.md). It defines the
|
|
160
|
-
per-finding evidence bar, the exclusion list, and the final re-open-and-drop
|
|
161
|
-
pass whose `kept <k> / dropped <d>` counts you record in the Executive
|
|
162
|
-
Summary, so the sequential single-pass path filters unverified findings just as
|
|
163
|
-
the orchestrated path's adversarial reviewer does.
|
|
@@ -34,11 +34,9 @@ Any named ticket that is not `type::story`, or that still carries an
|
|
|
34
34
|
re-plan as a v2 Story). Resolution refuses the whole set rather than
|
|
35
35
|
silently dropping the offending id and under-delivering.
|
|
36
36
|
|
|
37
|
-
> **
|
|
38
|
-
>
|
|
39
|
-
>
|
|
40
|
-
> ordering already lives in the dependency edges themselves. Deliver the
|
|
41
|
-
> ids; the graph resolves itself.
|
|
37
|
+
> **No batch identity (Story #4540).** There is no `--run`, `plan-run::<id>`,
|
|
38
|
+
> or `--dep` axis: ordering lives in the dependency edges, so delivering the
|
|
39
|
+
> ids resolves the graph itself.
|
|
42
40
|
|
|
43
41
|
## Flags
|
|
44
42
|
|
|
@@ -162,11 +160,58 @@ to respect.
|
|
|
162
160
|
A blocked Story outranks a wedge (its blockers are moot while a human
|
|
163
161
|
owes a decision) but not a cycle (exit 2 — fix the graph first).
|
|
164
162
|
|
|
165
|
-
|
|
163
|
+
**Dispatch each `ready` Story (role-scoped by default).** When
|
|
164
|
+
`delivery.routing.roleScopedAgents` is enabled (the **default**) and the
|
|
165
|
+
host exposes agent dispatch, spawn each ready Story as its own
|
|
166
|
+
`subagent_type: story-worker` sub-agent — it boots on the role-scoped
|
|
167
|
+
[`story-worker`](../agents/story-worker.md) context (its own system prompt,
|
|
168
|
+
no `CLAUDE.md` @-closure) carrying the load-bearing delivery MUSTs
|
|
169
|
+
standalone. The sub-agent executes
|
|
170
|
+
[`helpers/deliver-story.md`](helpers/deliver-story.md) end to end
|
|
171
|
+
(init → implement → acceptance self-eval → close-and-land). Thread into its
|
|
172
|
+
prompt:
|
|
173
|
+
- `storyId` — the id to deliver.
|
|
174
|
+
- `docsDigestPath` — the per-run docs digest (digest-first reading,
|
|
175
|
+
[`instructions.md` § 3](../instructions.md)); null when
|
|
176
|
+
`project.docsContextFiles` is unset.
|
|
177
|
+
- `checklistPath` — the footprint-matched write-time audit checklist,
|
|
178
|
+
produced at dispatch (below).
|
|
179
|
+
- the **change-set discipline** — the worker computes the change set once
|
|
180
|
+
with `computeChangeSet` and hands that one list to every acceptance critic
|
|
181
|
+
(Story #4593); it never lets a critic re-derive the diff.
|
|
182
|
+
|
|
183
|
+
**Produce `checklistPath` before the spawn (Story #4627).** Compute the
|
|
184
|
+
payload from the Story's predicted footprint (its `changes[]` /
|
|
185
|
+
`references[]` path entries) with `buildDispatchChecklist` and write it to
|
|
186
|
+
the run temp dir, then thread the resulting path (empty when nothing
|
|
187
|
+
matched):
|
|
188
|
+
|
|
189
|
+
```bash
|
|
190
|
+
node --input-type=module -e '
|
|
191
|
+
import { buildDispatchChecklist } from "<main-repo>/.agents/scripts/lib/audit-suite/index.js";
|
|
192
|
+
import { parse } from "<main-repo>/.agents/scripts/lib/story-body/story-body.js";
|
|
193
|
+
// storyBody is the fetched Story issue body.
|
|
194
|
+
const { changes, references } = parse(process.env.STORY_BODY);
|
|
195
|
+
const { checklistPath } = buildDispatchChecklist({
|
|
196
|
+
storyId: <storyId>, changes, references, runTempDir: "temp/run-<id>",
|
|
197
|
+
});
|
|
198
|
+
console.log(checklistPath ?? "");
|
|
199
|
+
'
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
`buildDispatchChecklist` (`lib/audit-suite/dispatch-checklist.js`) is a pure
|
|
203
|
+
function of the footprint and the on-disk checklists; an empty match prints
|
|
204
|
+
nothing and the worker runs with no write-time checklist — the maker-blind
|
|
205
|
+
close-scope pass still covers it.
|
|
206
|
+
|
|
207
|
+
**Inline fallback (`roleScopedAgents: false` / no-nesting harness).** When
|
|
208
|
+
the kill-switch is off, or the host cannot spawn a sub-agent at this nesting
|
|
209
|
+
depth, do **not** stall: read
|
|
166
210
|
[`helpers/deliver-story.md`](helpers/deliver-story.md) **in full** and
|
|
167
|
-
execute it
|
|
168
|
-
|
|
169
|
-
turn.
|
|
211
|
+
execute it directly, in this turn, threading the same `docsDigestPath` /
|
|
212
|
+
`checklistPath` / change-set discipline. Under `--yes` / injected helper
|
|
213
|
+
content, execute directly without a re-read turn. The engine, gates, and
|
|
214
|
+
terminal envelope are identical either way — only the isolation differs.
|
|
170
215
|
|
|
171
216
|
4. **Per-run epilogue (N>1).** Once step 3 reports `epilogueDue: true`
|
|
172
217
|
(every Story done), keyed on the delivered id set:
|