prepare-acceptance

Name: prepare-acceptance
Author: Codagent-AI

28stars1forks

How to install prepare-acceptance?

codagent-ai/agent-skills/prepare-acceptance

$npx -y skills add Codagent-AI/agent-skills --skill prepare-acceptance

Installs into the current project.

Summary

Exercises an implemented change through its user and client flows, reports clear defects without fixing them, waits for current-head CI, and prepares concise evidence for human review when preparing a change for acceptance, gathering review evidence, performing human-style flow t

Files · 1

View on GitHub

SKILL.md

1	## Prepare Acceptance
2
3	Prepare an implemented change for a separate human acceptance session. Exercise it as a human user or
4	real client would, report clear defects, wait for CI once no defects remain, and produce concise
5	evidence bound to the exact PR revision. Fixes and automated validation belong to separate
6	caller-managed steps when used.
7
8	### Required inputs
9
10	Resolve these from the caller before acting:
11
12	- approved requirements, scenarios, design, and task artifacts;
13	- caller-supplied implementation summary or completion evidence identifying delivered behavior;
14	- evidence output directory;
15	- unresolved-assumptions ledger path, when one exists.
16
17	Treat missing source-of-truth artifacts or an unspecified evidence directory as blockers. Do not infer
18	product behavior from implementation alone. When no assumptions-ledger path is supplied, use
19	`<evidence-directory>/acceptance-assumptions.md` and create it if needed. Keep this preparation
20	autonomous: preserve product, scope, or design ambiguity for the later human acceptance session
21	instead of asking the user here.
22
23	### Procedure
24
25	#### 1. Pin the tested revision
26
27	1. Read repository instructions, the approved artifacts, the unresolved-assumptions ledger, and the
28	existing automated-validation evidence supplied by the caller.
29	2. Record local `HEAD` as the tested SHA and preserve it through the flow pass and CI wait. Read only
30	the PR URL, current head SHA, and current PR state needed for the evidence record. Do not inspect or
31	reconstruct a diff.
32	3. Require a clean tracked worktree and local `HEAD` equal to the PR head. If they do not match, stop
33	for the caller to resolve; do not push or alter PR metadata in this skill.
34
35	#### 2. Exercise the product like a user
36
37	Derive a concise list of supported user or client flows only from the approved artifacts and the
38	caller-supplied implementation evidence. Do not inspect a diff to discover behavior. Exercise every
39	flow end to end through the same public surface a real user or client would use. A flow is a meaningful
40	journey or operation, not every input permutation.
41
42	- For a web, mobile, desktop, or terminal UI, navigate and operate it through its real interface.
43	- For an API, call it through its documented HTTP, SDK, or CLI surface as a client would. Record a
44	sanitized request shape, response status and relevant response excerpt, plus observable side effects.
45	- For a CLI or library, invoke its public commands or API as a consumer would and retain representative
46	input, output, and resulting state.
47	- For background behavior, trigger it through the normal entry point and inspect the user-visible or
48	externally observable result.
49
50	Use typical representative data, configuration, and roles. Do not run automated unit, integration, or
51	end-to-end suites, linters, builds, or other automated validation commands; those belong to the caller.
52	Do not fuzz, try bizarre inputs, attempt to break the product, or build an exhaustive edge-case matrix.
53	Test an error, empty, boundary, or transient state only when it is an approved flow or necessary to
54	complete a normal flow.
55
56	For each flow, record the action, observed outcome, concise evidence, and any limitation. Verify the
57	resulting state instead of relying on task completion or agent assertions.
58
59	When a clear implementation defect appears, do not fix it. Write
60	`<evidence-directory>/acceptance-findings.md` with the tested SHA, affected flow, expected and observed
61	behavior, concise reproduction steps, and evidence paths. Do not wait for CI or write final acceptance
62	evidence in that invocation. Report the findings clearly so the caller can run its fix and validation
63	process.
64
65	Append product, scope, or design ambiguity to the unresolved-assumptions ledger with the decision
66	needed and likely impact; never silently choose an interpretation or report ambiguity as a clear
67	defect. Every invocation re-exercises all supported flows against the current committed `HEAD`; never
68	reuse results or screenshots from an earlier invocation.
69
70	#### 3. Capture visual evidence
71
72	For any UI—including web, mobile, desktop, and TUI—store screenshots under
73	`<evidence-directory>/acceptance-screenshots/` as the flows are exercised. Capture at least one
74	meaningful stable result for every UI flow, and more only when multiple states are needed to understand
75	that flow. Do not capture loading, empty, error, responsive, or before/after states unless they are part
76	of the flow being tested.
77
78	Record for every screenshot:
79
80	- flow demonstrated;
81	- expected behavior and what the reviewer should notice;
82	- route or command, representative input, and user role when relevant;
83	- t

People who liked this also viewed

6 picks

Type

prepare-acceptance

28stars1forks

View on GitHub

How to install prepare-acceptance?

codagent-ai/agent-skills/prepare-acceptance

$npx -y skills add Codagent-AI/agent-skills --skill prepare-acceptance

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Prepare Acceptance
2
3	Prepare an implemented change for a separate human acceptance session. Exercise it as a human user or
4	real client would, report clear defects, wait for CI once no defects remain, and produce concise
5	evidence bound to the exact PR revision. Fixes and automated validation belong to separate
6	caller-managed steps when used.
7
8	### Required inputs
9
10	Resolve these from the caller before acting:
11
12	- approved requirements, scenarios, design, and task artifacts;
13	- caller-supplied implementation summary or completion evidence identifying delivered behavior;
14	- evidence output directory;
15	- unresolved-assumptions ledger path, when one exists.
16
17	Treat missing source-of-truth artifacts or an unspecified evidence directory as blockers. Do not infer
18	product behavior from implementation alone. When no assumptions-ledger path is supplied, use
19	`<evidence-directory>/acceptance-assumptions.md` and create it if needed. Keep this preparation
20	autonomous: preserve product, scope, or design ambiguity for the later human acceptance session
21	instead of asking the user here.
22
23	### Procedure
24
25	#### 1. Pin the tested revision
26
27	1. Read repository instructions, the approved artifacts, the unresolved-assumptions ledger, and the
28	existing automated-validation evidence supplied by the caller.
29	2. Record local `HEAD` as the tested SHA and preserve it through the flow pass and CI wait. Read only
30	the PR URL, current head SHA, and current PR state needed for the evidence record. Do not inspect or
31	reconstruct a diff.
32	3. Require a clean tracked worktree and local `HEAD` equal to the PR head. If they do not match, stop
33	for the caller to resolve; do not push or alter PR metadata in this skill.
34
35	#### 2. Exercise the product like a user
36
37	Derive a concise list of supported user or client flows only from the approved artifacts and the
38	caller-supplied implementation evidence. Do not inspect a diff to discover behavior. Exercise every
39	flow end to end through the same public surface a real user or client would use. A flow is a meaningful
40	journey or operation, not every input permutation.
41
42	- For a web, mobile, desktop, or terminal UI, navigate and operate it through its real interface.
43	- For an API, call it through its documented HTTP, SDK, or CLI surface as a client would. Record a
44	sanitized request shape, response status and relevant response excerpt, plus observable side effects.
45	- For a CLI or library, invoke its public commands or API as a consumer would and retain representative
46	input, output, and resulting state.
47	- For background behavior, trigger it through the normal entry point and inspect the user-visible or
48	externally observable result.
49
50	Use typical representative data, configuration, and roles. Do not run automated unit, integration, or
51	end-to-end suites, linters, builds, or other automated validation commands; those belong to the caller.
52	Do not fuzz, try bizarre inputs, attempt to break the product, or build an exhaustive edge-case matrix.
53	Test an error, empty, boundary, or transient state only when it is an approved flow or necessary to
54	complete a normal flow.
55
56	For each flow, record the action, observed outcome, concise evidence, and any limitation. Verify the
57	resulting state instead of relying on task completion or agent assertions.
58
59	When a clear implementation defect appears, do not fix it. Write
60	`<evidence-directory>/acceptance-findings.md` with the tested SHA, affected flow, expected and observed
61	behavior, concise reproduction steps, and evidence paths. Do not wait for CI or write final acceptance
62	evidence in that invocation. Report the findings clearly so the caller can run its fix and validation
63	process.
64
65	Append product, scope, or design ambiguity to the unresolved-assumptions ledger with the decision
66	needed and likely impact; never silently choose an interpretation or report ambiguity as a clear
67	defect. Every invocation re-exercises all supported flows against the current committed `HEAD`; never
68	reuse results or screenshots from an earlier invocation.
69
70	#### 3. Capture visual evidence
71
72	For any UI—including web, mobile, desktop, and TUI—store screenshots under
73	`<evidence-directory>/acceptance-screenshots/` as the flows are exercised. Capture at least one
74	meaningful stable result for every UI flow, and more only when multiple states are needed to understand
75	that flow. Do not capture loading, empty, error, responsive, or before/after states unless they are part
76	of the flow being tested.
77
78	Record for every screenshot:
79
80	- flow demonstrated;
81	- expected behavior and what the reviewer should notice;
82	- route or command, representative input, and user role when relevant;
83	- t

People who liked this also viewed

6 picks

Type