review-assumptions

Name: review-assumptions
Author: Codagent-AI

28stars1forks

How to install review-assumptions?

codagent-ai/agent-skills/review-assumptions

$npx -y skills add Codagent-AI/agent-skills --skill review-assumptions

Installs into the current project.

Summary

Reviews risky/notable assumptions and context gaps surfaced by implementor session reports, fixes high-confidence issues directly, and asks one clarifying question at a time for ambiguous findings. Use when the user says "review assumptions", "audit implementor assumptions", or w

Files · 1

View on GitHub

SKILL.md

1	# Review Assumptions
2
3	The implementor(s) produced session report(s) (via `codagent:session-report`) listing `risky` / `notable` assumptions and context gaps. Assume the implementors did not have the plan's intent; audit the findings against that intent, act on confident fixes, and ask about ambiguous cases.
4
5	## Checklist
6
7	Work through these in order:
8
9	1. Build the report map — identify every session report, its iteration id, and the exact task file it belongs to.
10	2. Extract findings via a subagent — keep extraction noise off your context.
11	3. Create a finding ledger — every extracted finding gets one stable id and one final disposition.
12	4. Classify and act on each finding one at a time.
13	5. Summarize what was fixed, what the user decided, what was accepted as-is, and any remaining context gaps.
14
15	## Report map
16
17	Before extracting findings, map reports to tasks:
18
19	- Use the report filename's iteration marker (for example `implement-tasks_0`) only as an iteration id; do not infer the task name from order or memory.
20	- Cross-reference the matching `step_start` / `iteration_start` metadata when available to recover the `task_file` parameter.
21	- Record each report as `[iteration id \| task file path \| short task name]`.
22	- If a report cannot be mapped to a task, label it `task unknown` and treat that as an ambiguity to surface in the final summary.
23
24	Do not renumber tasks in the final summary. Use the mapped task file path or short task name. This prevents mixing up "task 0" and "task 1" when workflow iteration order differs from human-readable task order.
25
26	## Extracting findings
27
28	Dispatch a subagent with this task:
29
30	- From the session report(s), extract the `## Assumption Audit` (with `### Risky` / `### Notable` subsections) and `## Context Gaps` sections.
31	- Use the report map supplied by the parent agent. Preserve the iteration id and mapped task file for every finding.
32	- Return a compact markdown list: one line per finding with stable id, iteration id, task file, severity, finding title, and a tight verbatim quote or paraphrase of the bullet. No commentary.
33
34	If nothing turns up, report "no findings to review" and stop.
35
36	## Finding ledger
37
38	Create a ledger before acting:
39
40	```markdown
41	\| id \| iteration \| task \| severity \| finding \| disposition \| evidence \| action \|
42	\| --- \| --- \| --- \| --- \| --- \| --- \| --- \| --- \|
43	```
44
45	Allowed dispositions:
46
47	- `fixed` — high-confidence issue fixed in code/docs.
48	- `resolved-with-user` — ambiguous issue answered by the user, then acted on or left as-is.
49	- `accepted` — reviewed and intentionally left unchanged because it matches the plan or risk is acceptable.
50	- `deferred` — real issue or risk remains but is outside this review's authority/scope; include why and who should handle it.
51	- `context-gap` — only for findings originally reported under `## Context Gaps`, or for cases where the report itself cannot be mapped to a task.
52
53	Hard requirements:
54
55	- Every extracted assumption and context gap must appear in the ledger exactly once.
56	- Do not silently drop low-severity, notable, or "acceptable" findings.
57	- Do not reclassify an assumption as a context gap just to avoid fixing or asking about it. If it is acceptable, mark it `accepted`; if it needs product input, mark it ambiguous and ask.
58	- Before the final response, compare the number of extracted findings with the number of ledger rows. If they differ, stop and reconcile the missing item(s).
59
60	## Classifying and acting
61
62	For each finding, pick one bucket and act accordingly:
63
64	- High-confidence fix — a bug, obvious gap, or clear deviation from the plan. Fix it directly: edit (or dispatch an implementor subagent for nontrivial changes), then commit with a message citing the task and assumption. Don't ask permission.
65	- Examples: implementor picked a default that contradicts a spec scenario; implementor skipped an error path the spec required; implementor left a TODO the plan explicitly required finishing.
66	- Ambiguous — product intent, scope, or UX preference only the user can weigh in on. Ask the user, then apply their answer.
67	- Examples: which of two reasonable naming choices; whether to widen scope for an adjacent edge case; whether a near-miss matches the spec's original intent.
68	- Acceptable — fine against the plan. Note and move on.
69
70	If a finding makes a claim about code ("I fixed X", "already handles Y"), have a subagent spot-check before classifying — don't take the implementor's word for it.
71
72	When you make your own code-based claim in the final summary, verify it first:
73
74	- Cite the specific file/function or command output y

People who liked this also viewed

6 picks

Type

review-assumptions

28stars1forks

View on GitHub

How to install review-assumptions?

codagent-ai/agent-skills/review-assumptions

$npx -y skills add Codagent-AI/agent-skills --skill review-assumptions

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Review Assumptions
2
3	The implementor(s) produced session report(s) (via `codagent:session-report`) listing `risky` / `notable` assumptions and context gaps. Assume the implementors did not have the plan's intent; audit the findings against that intent, act on confident fixes, and ask about ambiguous cases.
4
5	## Checklist
6
7	Work through these in order:
8
9	1. Build the report map — identify every session report, its iteration id, and the exact task file it belongs to.
10	2. Extract findings via a subagent — keep extraction noise off your context.
11	3. Create a finding ledger — every extracted finding gets one stable id and one final disposition.
12	4. Classify and act on each finding one at a time.
13	5. Summarize what was fixed, what the user decided, what was accepted as-is, and any remaining context gaps.
14
15	## Report map
16
17	Before extracting findings, map reports to tasks:
18
19	- Use the report filename's iteration marker (for example `implement-tasks_0`) only as an iteration id; do not infer the task name from order or memory.
20	- Cross-reference the matching `step_start` / `iteration_start` metadata when available to recover the `task_file` parameter.
21	- Record each report as `[iteration id \| task file path \| short task name]`.
22	- If a report cannot be mapped to a task, label it `task unknown` and treat that as an ambiguity to surface in the final summary.
23
24	Do not renumber tasks in the final summary. Use the mapped task file path or short task name. This prevents mixing up "task 0" and "task 1" when workflow iteration order differs from human-readable task order.
25
26	## Extracting findings
27
28	Dispatch a subagent with this task:
29
30	- From the session report(s), extract the `## Assumption Audit` (with `### Risky` / `### Notable` subsections) and `## Context Gaps` sections.
31	- Use the report map supplied by the parent agent. Preserve the iteration id and mapped task file for every finding.
32	- Return a compact markdown list: one line per finding with stable id, iteration id, task file, severity, finding title, and a tight verbatim quote or paraphrase of the bullet. No commentary.
33
34	If nothing turns up, report "no findings to review" and stop.
35
36	## Finding ledger
37
38	Create a ledger before acting:
39
40	```markdown
41	\| id \| iteration \| task \| severity \| finding \| disposition \| evidence \| action \|
42	\| --- \| --- \| --- \| --- \| --- \| --- \| --- \| --- \|
43	```
44
45	Allowed dispositions:
46
47	- `fixed` — high-confidence issue fixed in code/docs.
48	- `resolved-with-user` — ambiguous issue answered by the user, then acted on or left as-is.
49	- `accepted` — reviewed and intentionally left unchanged because it matches the plan or risk is acceptable.
50	- `deferred` — real issue or risk remains but is outside this review's authority/scope; include why and who should handle it.
51	- `context-gap` — only for findings originally reported under `## Context Gaps`, or for cases where the report itself cannot be mapped to a task.
52
53	Hard requirements:
54
55	- Every extracted assumption and context gap must appear in the ledger exactly once.
56	- Do not silently drop low-severity, notable, or "acceptable" findings.
57	- Do not reclassify an assumption as a context gap just to avoid fixing or asking about it. If it is acceptable, mark it `accepted`; if it needs product input, mark it ambiguous and ask.
58	- Before the final response, compare the number of extracted findings with the number of ledger rows. If they differ, stop and reconcile the missing item(s).
59
60	## Classifying and acting
61
62	For each finding, pick one bucket and act accordingly:
63
64	- High-confidence fix — a bug, obvious gap, or clear deviation from the plan. Fix it directly: edit (or dispatch an implementor subagent for nontrivial changes), then commit with a message citing the task and assumption. Don't ask permission.
65	- Examples: implementor picked a default that contradicts a spec scenario; implementor skipped an error path the spec required; implementor left a TODO the plan explicitly required finishing.
66	- Ambiguous — product intent, scope, or UX preference only the user can weigh in on. Ask the user, then apply their answer.
67	- Examples: which of two reasonable naming choices; whether to widen scope for an adjacent edge case; whether a near-miss matches the spec's original intent.
68	- Acceptable — fine against the plan. Note and move on.
69
70	If a finding makes a claim about code ("I fixed X", "already handles Y"), have a subagent spot-check before classifying — don't take the implementor's word for it.
71
72	When you make your own code-based claim in the final summary, verify it first:
73
74	- Cite the specific file/function or command output y

People who liked this also viewed

6 picks

Type