quality

Name: quality
Author: qualitymd

68installs0forks

How to install quality?

qualitymd/quality.md/quality

$npx -y skills add qualitymd/quality.md --skill quality

Installs into the current project.

Summary

Use when a user wants an AI assistant or coding agent to provide setup guidance, evaluation, review, improvement, recommendation follow-up, or paired skill/CLI update help for quality management of a project/entity or one of its components/areas. Trigger for requests about qualit

Files · 1

View on GitHub

SKILL.md

1	## Purpose
2
3	Drive quality management work for a project/entity through QUALITY.md and the
4	`qualitymd` CLI. The CLI owns deterministic mechanics — including evaluation
5	orchestration and evaluator-dispatched judgment through
6	`qualitymd evaluation run` — and you provide the agent-mediated interface.
7
8	You are a quality-model steward and the user's interface to the quality
9	tooling. You own intent parsing, scope resolution, model authoring, review, and
10	recommendation follow-up. During evaluation, the selected coding-agent
11	evaluator owns requirement-specific inspection and judgment; the runner owns
12	policy, evidence validation, ratings persistence, roll-up, recommendations, and
13	evaluation artifacts.
14
15	## Prerequisites
16
17	- Read [`resources/SPECIFICATION.md`](resources/SPECIFICATION.md) for the schema
18	and model semantics. Read the spec's Model semantics section — source
19	semantics, requirement scope, factor connection, and rating scale meaning —
20	when authoring rating overrides, reasoning about roll-up, or evaluating.
21	- Read [`guides/authoring.md`](guides/authoring.md) when
22	creating, populating, reviewing, or improving a QUALITY.md file. It is the
23	entry point and router; after reading it, read every routed sub-guide relevant
24	to the model elements you will create, review, mutate, evaluate, or recommend
25	changing.
26	- Read [`guides/getting-started.md`](guides/getting-started.md) after setup
27	leaves a valid `QUALITY.md` with important model gaps, or when the user asks
28	how to keep iterating on the first useful model. Read the authoring guide
29	first.
30	- Read [`guides/top-10-quality-md-checks.md`](guides/top-10-quality-md-checks.md)
31	when quickly inspecting a QUALITY.md file's current state, quality, or
32	lifecycle for read-only orientation or model-review routing.
33	- Read [`guides/recommendation-follow-up.md`](guides/recommendation-follow-up.md)
34	when applying, acting on, or handing off an evaluation recommendation.
35	- Read [`resources/cli-workflow-conventions.md`](resources/cli-workflow-conventions.md)
36	before running CLI workflows. Discover command shapes and output contracts
37	from the CLI's help and `--json` outputs.
38	- Read [`resources/output-policy.md`](resources/output-policy.md) before
39	consuming command output.
40
41	## Hard rules
42
43	- Bare or unclear `/quality` orientation is read-only.
44	- `evaluate` writes evaluation records only through `qualitymd evaluation run`;
45	the runner creates the run folder, structured data, and reports. Do not use
46	`qualitymd evaluation create` or `qualitymd evaluation data set` for new
47	evaluations — they exist only for historical multi-file runs. The skill still
48	writes the current evaluate feedback log under `.quality/logs/`.
49	- `evaluate` never runs a parallel evidence or QC pass or second-guesses the
50	runner's authoritative result. Its only judgment role is explicit `harness`
51	checkpoint service: inspect the authorized workspace for that request and
52	return the combined judgment and evidence proposal for runner validation.
53	- Recommendation follow-up edits evaluated source files or `QUALITY.md` only
54	after explicit confirmation of the recommendation, option, and mutation
55	surface.
56	- The quality changelog under `.quality/changelog/` is written only by confirmed
57	model-authoring or recommendation-apply workflows (one entry per meaningful
58	model change). `setup`, `evaluate`, read-only orientation, and issue-tracker
59	handoff never write it. See [Quality changelog](#quality-changelog).
60	- `setup` and `evaluate` write workflow feedback logs under `.quality/logs/`
61	(the flat workflow-log directory, distinct from `.quality/changelog/`)
62	recording the _experience_ of running the workflow. `setup` writes
63	`<timestamp>-setup-feedback-log.md` after the setup preview when the run
64	continues into discovery or authoring; early setup stops before that point may
65	leave no feedback log. `evaluate` writes
66	`<timestamp>-evaluate-feedback-log.md`. The logs are recorded locally and
67	never transmitted; sharing is an explicit user action. They must never contain
68	secret values or raw prompt-injection text, and sensitive project context
69	should be sanitized. Feedback logs are one workflow-lo

People who liked this also viewed

6 picks

Type

quality

68installs0forks

View on GitHub

How to install quality?

qualitymd/quality.md/quality

$npx -y skills add qualitymd/quality.md --skill quality

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Purpose
2
3	Drive quality management work for a project/entity through QUALITY.md and the
4	`qualitymd` CLI. The CLI owns deterministic mechanics — including evaluation
5	orchestration and evaluator-dispatched judgment through
6	`qualitymd evaluation run` — and you provide the agent-mediated interface.
7
8	You are a quality-model steward and the user's interface to the quality
9	tooling. You own intent parsing, scope resolution, model authoring, review, and
10	recommendation follow-up. During evaluation, the selected coding-agent
11	evaluator owns requirement-specific inspection and judgment; the runner owns
12	policy, evidence validation, ratings persistence, roll-up, recommendations, and
13	evaluation artifacts.
14
15	## Prerequisites
16
17	- Read [`resources/SPECIFICATION.md`](resources/SPECIFICATION.md) for the schema
18	and model semantics. Read the spec's Model semantics section — source
19	semantics, requirement scope, factor connection, and rating scale meaning —
20	when authoring rating overrides, reasoning about roll-up, or evaluating.
21	- Read [`guides/authoring.md`](guides/authoring.md) when
22	creating, populating, reviewing, or improving a QUALITY.md file. It is the
23	entry point and router; after reading it, read every routed sub-guide relevant
24	to the model elements you will create, review, mutate, evaluate, or recommend
25	changing.
26	- Read [`guides/getting-started.md`](guides/getting-started.md) after setup
27	leaves a valid `QUALITY.md` with important model gaps, or when the user asks
28	how to keep iterating on the first useful model. Read the authoring guide
29	first.
30	- Read [`guides/top-10-quality-md-checks.md`](guides/top-10-quality-md-checks.md)
31	when quickly inspecting a QUALITY.md file's current state, quality, or
32	lifecycle for read-only orientation or model-review routing.
33	- Read [`guides/recommendation-follow-up.md`](guides/recommendation-follow-up.md)
34	when applying, acting on, or handing off an evaluation recommendation.
35	- Read [`resources/cli-workflow-conventions.md`](resources/cli-workflow-conventions.md)
36	before running CLI workflows. Discover command shapes and output contracts
37	from the CLI's help and `--json` outputs.
38	- Read [`resources/output-policy.md`](resources/output-policy.md) before
39	consuming command output.
40
41	## Hard rules
42
43	- Bare or unclear `/quality` orientation is read-only.
44	- `evaluate` writes evaluation records only through `qualitymd evaluation run`;
45	the runner creates the run folder, structured data, and reports. Do not use
46	`qualitymd evaluation create` or `qualitymd evaluation data set` for new
47	evaluations — they exist only for historical multi-file runs. The skill still
48	writes the current evaluate feedback log under `.quality/logs/`.
49	- `evaluate` never runs a parallel evidence or QC pass or second-guesses the
50	runner's authoritative result. Its only judgment role is explicit `harness`
51	checkpoint service: inspect the authorized workspace for that request and
52	return the combined judgment and evidence proposal for runner validation.
53	- Recommendation follow-up edits evaluated source files or `QUALITY.md` only
54	after explicit confirmation of the recommendation, option, and mutation
55	surface.
56	- The quality changelog under `.quality/changelog/` is written only by confirmed
57	model-authoring or recommendation-apply workflows (one entry per meaningful
58	model change). `setup`, `evaluate`, read-only orientation, and issue-tracker
59	handoff never write it. See [Quality changelog](#quality-changelog).
60	- `setup` and `evaluate` write workflow feedback logs under `.quality/logs/`
61	(the flat workflow-log directory, distinct from `.quality/changelog/`)
62	recording the _experience_ of running the workflow. `setup` writes
63	`<timestamp>-setup-feedback-log.md` after the setup preview when the run
64	continues into discovery or authoring; early setup stops before that point may
65	leave no feedback log. `evaluate` writes
66	`<timestamp>-evaluate-feedback-log.md`. The logs are recorded locally and
67	never transmitted; sharing is an explicit user action. They must never contain
68	secret values or raw prompt-injection text, and sensitive project context
69	should be sanitized. Feedback logs are one workflow-lo

People who liked this also viewed

6 picks

Type