Granular 4-phase, 4-role GDS Service Standard assurance skills and synthesis engine.
87%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
Tessl plugin that assesses a UK public sector service against the Service Standard at Discovery, Alpha, Beta, and Live.
The panel is four disciplines — lead, user research, design, and technical — plus a synthesis skill that writes the report. Sixteen assessor skills cover the four phases. One skill, assessment-report-synthesis, merges them.
rules/phase-expectations.md.SKILL.md and works through its lines-of-questioning.md.skills/assessment-report-synthesis.skills/assessment-report-synthesis/report-template.md. Overall result is Met or Not Met. Any in-scope Not Met, or any fired red line, makes the overall result Not Met.Points outside the phase are Not assessed. At Live, unchanged points the panel does not own are Not reassessed. Neither is a failure.
| Phase | Lead | User research | Design | Technical |
|---|---|---|---|---|
| Discovery | 2, 6, 7 | 1 | 2, 3 | 9, 11, 13 |
| Alpha | 6, 7 | 1, 2 | 2, 3, 4 | 8, 9, 11 |
| Beta | 6, 7, 10 | 1, 2, 5 | 3, 4, 5, 13 | 8, 9, 11, 12, 13, 14 |
| Live | 6, 7 | 1, 10 | 3, 4, 5 | 8, 9, 14 |
Beta is the first phase that scores all 14 points. The technical skill also records point 5 when the independent WCAG 2.2 AA audit is missing.
Hard fails live in context/rubrics/. The ones that decide most panels:
context/few-shot-examples/discovery-lead-stop.md.context/few-shot-examples/alpha-tech-spikes.md.context/few-shot-examples/beta-ur-fail-assistive-tech.md..tessl-plugin/plugin.json manifest
rules/ always-on standard and phase boundaries
skills/ 16 assessor skills and the synthesis skill
context/rubrics/ phase red lines
context/few-shot-examples/ curated exemplars, plus scraped reports if you ingest them
scripts/scrape_gds_reports.py optional ingestion of published reports
evals/ ground-truth assertions for four casesCurated exemplars in context/few-shot-examples/ are fictional and should be kept. To add real published assessments from GOV.UK, from this directory:
pip install requests beautifulsoup4
python scripts/scrape_gds_reports.pyThe script asks the GOV.UK search API for every service_standard_report (the index currently lists about 500, across multiple pages) and writes one Markdown file per report into context/few-shot-examples/. It then rebuilds context/past-assessments/, one JSON catalogue per phase. Filenames are the report URL slug, so similarly titled reports do not overwrite each other. It will not overwrite the four curated exemplars. Run it from the plugin root so the output path resolves. A full run takes a few minutes because it pauses briefly between requests.
On an assessment, each skill reads the catalogue for its phase, opens at most eight comparable reports, and cites them. The rule is rules/past-assessments.md. Rebuild the catalogue without scraping again with python scripts/build_past_assessment_catalogue.py.
Ground-truth cases:
evals/test-discovery-premature-build.json — Discovery technical work that is already a build must fail, and the finding must call it premature architecture in the problem space.evals/test-alpha-tech-spikes.json — disposable Alpha spikes pass.evals/test-beta-ur-assistive-tech.json — Beta research with no assistive-technology users fails point 5.evals/test-synthesis-beta-report.json — a point 5 failure becomes an overall Not Met report even when the other three assessors pass.With the Tessl CLI, from this directory:
tessl skill lint
tessl skill review --optimize
tessl eval runtessl eval run expects the plugin root (the directory that contains .tessl-plugin/plugin.json). The JSON files in evals/ are the regression assertions for this plugin's own skills. Tessl's hosted evaluator, if you use it, looks for scenario directories (task.md and criteria.json) and will not read those JSON files as scenarios.
The 14 titles used in every report are fixed in rules/gds-service-standard.md. WCAG 2.2 AA is the non-negotiable bar on point 5 from Beta onwards. The mandatory performance measures are completion rate, user satisfaction, digital take-up, and cost per transaction, read with step-level drop-off.
repository in the plugin manifest, or publish from a GitHub Action to verify it.