critic

Name: critic
Author: mgifford

27stars2forks

How to install critic?

mgifford/accessibility-skills/critic

$npx -y skills add mgifford/accessibility-skills --skill critic

Installs into the current project.

Summary

The Critic reviews accessibility decisions to ensure they meet professional standards and evidence requirements.

Files · 1

View on GitHub

SKILL.md

1	# Critic Workflow
2
3	The Critic reviews accessibility decisions to ensure they meet professional standards and evidence requirements.
4
5	## Purpose
6
7	The Critic's role is to:
8
9	1. Validate ARRM grounding - Verify that findings use real ARRM tasks with correct role assignments
10	2. Assess automation safety - Determine if deterministic fixes are appropriate
11	3. Check role engagement - Ensure appropriate professional perspectives are consulted
12	4. Evaluate evidence quality - Verify claims are supported and evidence types are distinguished
13	5. Handle perspectives responsibly - Identify user impacts and avoid simulating lived experience
14	6. Maintain decision quality - Ensure disagreements and unresolved risks are visible
15
16	## When to Use
17
18	Use the Critic for any accessibility finding:
19
20	* After Planner assessment of a finding
21	* For manual review of implementation proposals
22	* When validating accessibility test results
23	* When cross-role decisions are being considered
24
25	The Critic works best after initial planning but before implementation begins.
26
27	## When Not to Use
28
29	The Critic is not appropriate for:
30
31	* Simple technical fixes with clear requirements
32	* Quick accessibility checks where expert review isn't needed
33	* Routine validation without professional judgment concerns
34
35	## Integration with Topic Skills
36
37	The Critic checks that AI workflow decisions respect relevant topic skills:
38
39	* forms → forms, content-design, keyboard
40	* keyboard → keyboard, touch-pointer, manual-testing
41	* color-contrast → color-contrast, light-dark-mode, visual-design
42	* charts-graphs → charts-graphs, image-alt-text, tables
43	* And other topic skills as appropriate
44
45	## ARRM Task Validation
46
47	### Grounding Requirements
48
49	For each accessibility finding, the Critic verifies:
50
51	1. Real ARRM Task Usage
52	- Task IDs must exist in the ARRM CSV
53	- Must use real ARRM task IDs, not placeholders like "IMG-001"
54	- Must match actual W3C WAI ARRM dataset
55
56	2. Role Assignment Accuracy
57	- Primary Ownership must match ARRM data
58	- Secondary Ownership must match ARRM data
59	- Contributor assignments must match ARRM data
60	- No invented or made-up role assignments
61
62	3. Completeness
63	- All relevant ARRM tasks should be identified
64	- No critical ARRM tasks should be omitted
65	- All role responsibilities should be assigned appropriately
66
67	### Example Valid ARRM Usage:
68	```json
69	{
70	"arrm": {
71	"task_id": "CSS-010", // Real ARRM task ID
72	"wcag_sc": "1.4.1",
73	"level": "A",
74	"primary": ["Visual Design"],
75	"secondary": ["Content Authoring"],
76	"contributors": []
77	}
78	}
79	```
80
81	### Example Invalid ARRM Usage:
82	```json
83	{
84	"arrm": {
85	"task_id": "IMG-001", // Placeholder ID
86	"wcag_sc": "1.1.1",
87	"primary": ["Content Authoring"],
88	"secondary": ["UX Design"], // Made-up role
89	"contributors": ["Developer"] // Not in ARRM
90	}
91	}
92	```
93
94	## Automation Safety Assessment
95
96	### Safety Criteria
97
98	The Critic assesses whether an automated fix is appropriate based on:
99
100	1. Rule Certainty
101	- High rule certainty: Clear technical requirements with authoritative source
102	- Medium rule certainty: Partially clear requirements
103	- Low rule certainty: Unclear or conflicting requirements
104
105	2. Intent Certainty
106	- High intent certainty: Intended meaning and interaction clearly understood
107	- Medium intent certainty: Reasonable understanding with some ambiguity
108	- Low intent certainty: Intent unclear or uncertain
109
110	3. Change Risk
111	- Low change risk: No impact on meaning, workflow, policy, visual hierarchy
112	- Medium change risk: Moderate impact on one or more areas
113	- High change risk: Significant impact on functionality or user experience
114
115	4. Testability
116	- High testability: Can be reliably verified with automated tools
117	- Medium testability: Requires some manual verification
118	- Low testability: Requires extensive manual testing
119
120	### Safety Decision Matrix
121
122	\| Rule Certainty \| Intent Certainty \| Change Risk \| Testability \| Recommendation \|
123	\|---------------\|------------------\|-------------\|-------------\|----------------\|
124	\| High \| High \| Low \| High \| Safe for automation \|
125	\| High \| High \| Medium \| Medium \| Human confirmation needed \|
126	\| High \| Medium \| Low \| High \| Cross-role decision \|
127	\| High \| Medium \| Medium \| Medium \| Cross-role decision \|
128	\| High \| Low \| Any \| Any \| Need more information \|
129	\| Medium \| Any \| Any \| Any \| Insufficient evidence \|
130	\| Low \| Any \| Any \| Any \| Insufficient evidence \|
131
132	### Safe Automated Fix Example
133	```json
134	{
135	"decision": {
136	"state": "auto-fixable",
137	"rule_certainty": "high",
138	"intent_certainty": "high",
139	"change_risk": "low",
140	"testability": "high"
141	}
142	}
143	```
144
145	### Unsafe Automated Fix Example
146	```json
147	{
148	"decision": {
149	"state": "human-co

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

critic

27stars2forks

View on GitHub

How to install critic?

mgifford/accessibility-skills/critic

$npx -y skills add mgifford/accessibility-skills --skill critic

Installs into the current project.

Summary

The Critic reviews accessibility decisions to ensure they meet professional standards and evidence requirements.

Files · 1

View on GitHub

SKILL.md

1	# Critic Workflow
2
3	The Critic reviews accessibility decisions to ensure they meet professional standards and evidence requirements.
4
5	## Purpose
6
7	The Critic's role is to:
8
9	1. Validate ARRM grounding - Verify that findings use real ARRM tasks with correct role assignments
10	2. Assess automation safety - Determine if deterministic fixes are appropriate
11	3. Check role engagement - Ensure appropriate professional perspectives are consulted
12	4. Evaluate evidence quality - Verify claims are supported and evidence types are distinguished
13	5. Handle perspectives responsibly - Identify user impacts and avoid simulating lived experience
14	6. Maintain decision quality - Ensure disagreements and unresolved risks are visible
15
16	## When to Use
17
18	Use the Critic for any accessibility finding:
19
20	* After Planner assessment of a finding
21	* For manual review of implementation proposals
22	* When validating accessibility test results
23	* When cross-role decisions are being considered
24
25	The Critic works best after initial planning but before implementation begins.
26
27	## When Not to Use
28
29	The Critic is not appropriate for:
30
31	* Simple technical fixes with clear requirements
32	* Quick accessibility checks where expert review isn't needed
33	* Routine validation without professional judgment concerns
34
35	## Integration with Topic Skills
36
37	The Critic checks that AI workflow decisions respect relevant topic skills:
38
39	* forms → forms, content-design, keyboard
40	* keyboard → keyboard, touch-pointer, manual-testing
41	* color-contrast → color-contrast, light-dark-mode, visual-design
42	* charts-graphs → charts-graphs, image-alt-text, tables
43	* And other topic skills as appropriate
44
45	## ARRM Task Validation
46
47	### Grounding Requirements
48
49	For each accessibility finding, the Critic verifies:
50
51	1. Real ARRM Task Usage
52	- Task IDs must exist in the ARRM CSV
53	- Must use real ARRM task IDs, not placeholders like "IMG-001"
54	- Must match actual W3C WAI ARRM dataset
55
56	2. Role Assignment Accuracy
57	- Primary Ownership must match ARRM data
58	- Secondary Ownership must match ARRM data
59	- Contributor assignments must match ARRM data
60	- No invented or made-up role assignments
61
62	3. Completeness
63	- All relevant ARRM tasks should be identified
64	- No critical ARRM tasks should be omitted
65	- All role responsibilities should be assigned appropriately
66
67	### Example Valid ARRM Usage:
68	```json
69	{
70	"arrm": {
71	"task_id": "CSS-010", // Real ARRM task ID
72	"wcag_sc": "1.4.1",
73	"level": "A",
74	"primary": ["Visual Design"],
75	"secondary": ["Content Authoring"],
76	"contributors": []
77	}
78	}
79	```
80
81	### Example Invalid ARRM Usage:
82	```json
83	{
84	"arrm": {
85	"task_id": "IMG-001", // Placeholder ID
86	"wcag_sc": "1.1.1",
87	"primary": ["Content Authoring"],
88	"secondary": ["UX Design"], // Made-up role
89	"contributors": ["Developer"] // Not in ARRM
90	}
91	}
92	```
93
94	## Automation Safety Assessment
95
96	### Safety Criteria
97
98	The Critic assesses whether an automated fix is appropriate based on:
99
100	1. Rule Certainty
101	- High rule certainty: Clear technical requirements with authoritative source
102	- Medium rule certainty: Partially clear requirements
103	- Low rule certainty: Unclear or conflicting requirements
104
105	2. Intent Certainty
106	- High intent certainty: Intended meaning and interaction clearly understood
107	- Medium intent certainty: Reasonable understanding with some ambiguity
108	- Low intent certainty: Intent unclear or uncertain
109
110	3. Change Risk
111	- Low change risk: No impact on meaning, workflow, policy, visual hierarchy
112	- Medium change risk: Moderate impact on one or more areas
113	- High change risk: Significant impact on functionality or user experience
114
115	4. Testability
116	- High testability: Can be reliably verified with automated tools
117	- Medium testability: Requires some manual verification
118	- Low testability: Requires extensive manual testing
119
120	### Safety Decision Matrix
121
122	\| Rule Certainty \| Intent Certainty \| Change Risk \| Testability \| Recommendation \|
123	\|---------------\|------------------\|-------------\|-------------\|----------------\|
124	\| High \| High \| Low \| High \| Safe for automation \|
125	\| High \| High \| Medium \| Medium \| Human confirmation needed \|
126	\| High \| Medium \| Low \| High \| Cross-role decision \|
127	\| High \| Medium \| Medium \| Medium \| Cross-role decision \|
128	\| High \| Low \| Any \| Any \| Need more information \|
129	\| Medium \| Any \| Any \| Any \| Insufficient evidence \|
130	\| Low \| Any \| Any \| Any \| Insufficient evidence \|
131
132	### Safe Automated Fix Example
133	```json
134	{
135	"decision": {
136	"state": "auto-fixable",
137	"rule_certainty": "high",
138	"intent_certainty": "high",
139	"change_risk": "low",
140	"testability": "high"
141	}
142	}
143	```
144
145	### Unsafe Automated Fix Example
146	```json
147	{
148	"decision": {
149	"state": "human-co

People who liked this also viewed

6 picks

Type