pre-deploy-qa

Name: pre-deploy-qa
Author: pavel-molyanov

241stars75forks

How to install pre-deploy-qa?

pavel-molyanov/molyanov-ai-dev/pre-deploy-qa

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill pre-deploy-qa

Installs into the current project.

Summary

Pre-deploy acceptance testing methodology: run test suite (unit/integration/E2E), verify acceptance criteria from user-spec and tech-spec. Does not require live environment. Use when: "приёмочное тестирование", "pre-deploy qa", "проверь перед деплоем", "run tests and check AC", "

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Pre-deploy QA
4
5	## Input Requirements
6
7	Read before starting:
8	- `user-spec.md` — acceptance criteria
9	- `tech-spec.md` — technical acceptance criteria
10	- `decisions.md` — deviations from plan (if exists)
11	- Project Knowledge — architecture.md, patterns.md (incl. Testing & Git Workflow sections)
12
13	If user-spec or tech-spec missing — request before proceeding.
14
15	## Verification Directions
16
17	Three verification directions (order doesn't matter):
18
19	### Test Suite
20
21	Run all tests (unit, integration, E2E). All must pass.
22
23	- Identify test runner from project config (package.json, pyproject.toml, Makefile, etc.)
24	- Run full test suite
25	- Record: total tests, passed, failed, skipped
26
27	### Acceptance Criteria
28
29	Check every criterion from user-spec and tech-spec:
30
31	- passed — criterion met, evidence provided
32	- failed — the feature exists but does not meet the criterion
33	- not_verifiable — cannot be checked without live environment, external service, or MCP tool (scope of post-deploy-qa)
34
35	For each criterion — provide evidence (test name, code path, log output).
36
37	### Coverage Verification
38
39	After test suite passes, verify that tests actually exercise the feature:
40
41	- For each file in the feature's scope (from tech-spec "Files to modify"): verify a corresponding test exists. Feature code without any test → severity `critical`
42	- If project has coverage tooling configured (jest --coverage, pytest --cov, vitest --coverage) — run it. Coverage of feature files dropping below project threshold → severity `critical`
43	- For each acceptance criterion with status `passed` — verify the linked test actually exercises the relevant code path, not just an import check or mock-only test. Test that doesn't actually test the feature behavior → severity `major`
44	- Edge cases mentioned in user-spec (error handling, boundary values, empty states) — verify they have corresponding tests. Missing edge case test for M/L features → severity `major`
45
46	## Severity Classification
47
48	- critical — acceptance criterion failed, tests fail, core functionality broken
49	- major — works but with significant issues (edge cases, UX bugs, degraded behavior). Escalate to critical if it affects data integrity or core user workflow.
50	- minor — cosmetic, inaccuracies, improvements
51
52	## Output
53
54	### JSON report → `logs/working/qa-report.json`
55
56	Full report saved to file. Reason: orchestrator parses this to decide pass/fail.
57
58	```json
59	{
60	"status": "passed \| failed",
61	"summary": {
62	"totalChecks": 0,
63	"passed": 0,
64	"failed": 0,
65	"notVerifiable": 0,
66	"criticals": 0,
67	"majors": 0,
68	"minors": 0
69	},
70	"testSuite": {
71	"status": "passed \| failed",
72	"details": "All 42 tests passed"
73	},
74	"acceptanceCriteria": [
75	{
76	"criterion": "User can login with email",
77	"status": "passed \| failed \| not_verifiable",
78	"evidence": "Test login_test.py::test_email_login passes"
79	}
80	],
81	"findings": [
82	{
83	"severity": "critical \| major \| minor",
84	"title": "Login fails for emails with + sign",
85	"expected": "Login succeeds",
86	"actual": "400 Bad Request",
87	"reproduction": "Steps to reproduce..."
88	}
89	]
90	}
91	```
92
93	Status decision: `passed` if zero criticals, `failed` if one or more criticals.
94
95	### decisions.md entry — concise summary only
96
97	Write a brief entry to decisions.md following the template (`~/.claude/shared/work-templates/decisions.md.template`). Link to `logs/working/qa-report.json` for the full report.
98
99	Example:
100	```
101	## Task 9: Pre-deploy QA
102
103	Status: Done
104	Agent: qa-runner
105	Summary: QA passed. 391 tests green, 28 acceptance criteria checked (25 passed, 3 not_verifiable). No blockers.
106	Deviations: None.
107
108	Verification:
109	- Full report: [logs/working/qa-report.json]
110	```
111
112	## Guidelines
113
114	- Work from specs only (user-spec, tech-spec, decisions.md). Task files (tasks/*.md) are already verified by reviewers and are outside QA scope.
115	- Account for decisions.md — deviations from original plan may be justified.
116	- Every finding includes concrete reproduction: steps, expected vs actual.
117	- Criteria requiring live environment or MCP tools — mark as `not_verifiable`, note that post-deploy verification is needed.
118	- Empty findings array = clean audit.
119
120	### Deferred to Post-deploy
121
122	If any acceptance criteria are marked `not_verifiable` — add a `deferredToPostDeploy` section to the JSON report. This section is the handoff contract: post-deploy QA reads it and verifies each deferred criterion on live environment.
123
124	For each deferred criterion, spec

People who liked this also viewed

6 picks

Type

pre-deploy-qa

241stars75forks

View on GitHub

How to install pre-deploy-qa?

pavel-molyanov/molyanov-ai-dev/pre-deploy-qa

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill pre-deploy-qa

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Pre-deploy QA
4
5	## Input Requirements
6
7	Read before starting:
8	- `user-spec.md` — acceptance criteria
9	- `tech-spec.md` — technical acceptance criteria
10	- `decisions.md` — deviations from plan (if exists)
11	- Project Knowledge — architecture.md, patterns.md (incl. Testing & Git Workflow sections)
12
13	If user-spec or tech-spec missing — request before proceeding.
14
15	## Verification Directions
16
17	Three verification directions (order doesn't matter):
18
19	### Test Suite
20
21	Run all tests (unit, integration, E2E). All must pass.
22
23	- Identify test runner from project config (package.json, pyproject.toml, Makefile, etc.)
24	- Run full test suite
25	- Record: total tests, passed, failed, skipped
26
27	### Acceptance Criteria
28
29	Check every criterion from user-spec and tech-spec:
30
31	- passed — criterion met, evidence provided
32	- failed — the feature exists but does not meet the criterion
33	- not_verifiable — cannot be checked without live environment, external service, or MCP tool (scope of post-deploy-qa)
34
35	For each criterion — provide evidence (test name, code path, log output).
36
37	### Coverage Verification
38
39	After test suite passes, verify that tests actually exercise the feature:
40
41	- For each file in the feature's scope (from tech-spec "Files to modify"): verify a corresponding test exists. Feature code without any test → severity `critical`
42	- If project has coverage tooling configured (jest --coverage, pytest --cov, vitest --coverage) — run it. Coverage of feature files dropping below project threshold → severity `critical`
43	- For each acceptance criterion with status `passed` — verify the linked test actually exercises the relevant code path, not just an import check or mock-only test. Test that doesn't actually test the feature behavior → severity `major`
44	- Edge cases mentioned in user-spec (error handling, boundary values, empty states) — verify they have corresponding tests. Missing edge case test for M/L features → severity `major`
45
46	## Severity Classification
47
48	- critical — acceptance criterion failed, tests fail, core functionality broken
49	- major — works but with significant issues (edge cases, UX bugs, degraded behavior). Escalate to critical if it affects data integrity or core user workflow.
50	- minor — cosmetic, inaccuracies, improvements
51
52	## Output
53
54	### JSON report → `logs/working/qa-report.json`
55
56	Full report saved to file. Reason: orchestrator parses this to decide pass/fail.
57
58	```json
59	{
60	"status": "passed \| failed",
61	"summary": {
62	"totalChecks": 0,
63	"passed": 0,
64	"failed": 0,
65	"notVerifiable": 0,
66	"criticals": 0,
67	"majors": 0,
68	"minors": 0
69	},
70	"testSuite": {
71	"status": "passed \| failed",
72	"details": "All 42 tests passed"
73	},
74	"acceptanceCriteria": [
75	{
76	"criterion": "User can login with email",
77	"status": "passed \| failed \| not_verifiable",
78	"evidence": "Test login_test.py::test_email_login passes"
79	}
80	],
81	"findings": [
82	{
83	"severity": "critical \| major \| minor",
84	"title": "Login fails for emails with + sign",
85	"expected": "Login succeeds",
86	"actual": "400 Bad Request",
87	"reproduction": "Steps to reproduce..."
88	}
89	]
90	}
91	```
92
93	Status decision: `passed` if zero criticals, `failed` if one or more criticals.
94
95	### decisions.md entry — concise summary only
96
97	Write a brief entry to decisions.md following the template (`~/.claude/shared/work-templates/decisions.md.template`). Link to `logs/working/qa-report.json` for the full report.
98
99	Example:
100	```
101	## Task 9: Pre-deploy QA
102
103	Status: Done
104	Agent: qa-runner
105	Summary: QA passed. 391 tests green, 28 acceptance criteria checked (25 passed, 3 not_verifiable). No blockers.
106	Deviations: None.
107
108	Verification:
109	- Full report: [logs/working/qa-report.json]
110	```
111
112	## Guidelines
113
114	- Work from specs only (user-spec, tech-spec, decisions.md). Task files (tasks/*.md) are already verified by reviewers and are outside QA scope.
115	- Account for decisions.md — deviations from original plan may be justified.
116	- Every finding includes concrete reproduction: steps, expected vs actual.
117	- Criteria requiring live environment or MCP tools — mark as `not_verifiable`, note that post-deploy verification is needed.
118	- Empty findings array = clean audit.
119
120	### Deferred to Post-deploy
121
122	If any acceptance criteria are marked `not_verifiable` — add a `deferredToPostDeploy` section to the JSON report. This section is the handoff contract: post-deploy QA reads it and verifies each deferred criterion on live environment.
123
124	For each deferred criterion, spec

People who liked this also viewed

6 picks

Type