session-report

Name: session-report
Author: Codagent-AI

28stars1forks

How to install session-report?

codagent-ai/agent-skills/session-report

$npx -y skills add Codagent-AI/agent-skills --skill session-report

Installs into the current project.

Summary

Audits your session for assumptions and context gaps — things only a human can act on. Use when the user says "session report", "review assumptions", "what did you struggle with", "audit your session", or wants a retrospective on execution quality.

Files · 1

View on GitHub

SKILL.md

1	# Session Report
2
3	Audit your own session against the task file(s) you were given. Surface assumptions you made and context gaps that caused struggles. These are observations for the human — not things you can fix after the fact.
4
5	## Review Process
6
7	Work through each dimension in order. For every finding, cite specific evidence.
8
9	### Dimension 1: Assumption Audit
10
11	Identify every place you made a decision that was not dictated by the task file or spec. For each assumption:
12
13	- Ambiguity — what the spec didn't say
14	- Choice — what you decided and why (the reasoning, not just the outcome)
15	- Risk — what could go wrong if this choice is wrong. Be specific: name the scenario, the affected code path, and what would break. "Could surprise future workflows" is not specific enough — say which workflow shape triggers it and what the symptom would be.
16	- Impact classification:
17	- `benign` — reasonable default, no real consequence (do not report)
18	- `notable` — meaningful choice that could have gone differently
19	- `risky` — could cause problems, warrants review
20	- Recommendation — what the reviewer should do: verify behavior, add a test, clarify the spec, or approve as-is with rationale.
21
22	Report only `risky` and `notable` assumptions. Drop `benign` entirely — they dilute the signal. Sort `risky` first, then `notable`.
23
24	### Dimension 2: Context Gaps
25
26	A context gap is a major, avoidable hole in the task file or project context that sent you down a fundamentally wrong path, caused you to build the wrong thing, or wasted significant effort that better upfront information would have prevented entirely.
27
28	The bar is high. Most sessions have zero context gaps. Fixing a linter warning is not a context gap. Searching for a convention is not a context gap. Iterating on validator feedback is not a context gap — it is the normal development loop.
29
30	Examples of real context gaps:
31	- The task said to extend module X, but module X was deleted last week and replaced by module Y — you built against a nonexistent target
32	- The task required integrating with service A but didn't mention that service A requires an auth token from a separate provisioning step — you couldn't have known this without tribal knowledge
33	- The task file pointed you to the wrong directory or package, wasting significant effort before you found the right one
34
35	Things that are NOT context gaps (do not report these):
36	- Anything the validator caught (lint, security, permissions, test failures) — the validator's entire purpose is to catch what the task doesn't enumerate
37	- Quick searches for conventions, patterns, or existing code — that is normal development
38	- Iterative fix cycles of any kind — fixing things the first pass missed is expected, not a gap
39	- Learning something new about the codebase during implementation
40
41	For each genuine context gap:
42	- What happened — the concrete wasted effort or wrong direction
43	- What was missing — the specific information that, if present, would have prevented it entirely
44
45	## Output Format
46
47	```markdown
48	## Assumption Audit
49
50	### Risky
51
52	1. [What the spec didn't say]
53	- Choice: [What you decided and why]
54	- Risk: [Specific scenario that breaks — name the code path, workflow shape, and symptom]
55	- Recommendation: [What the reviewer should do]
56
57	### Notable
58
59	1. [What the spec didn't say]
60	- Choice: [What you decided and why]
61	- Risk: [Specific scenario that breaks — name the code path, workflow shape, and symptom]
62	- Recommendation: [What the reviewer should do]
63
64	## Context Gaps
65
66	- [What happened] — Missing context: [what was needed]
67	```
68
69	Omit any section (`Risky`, `Notable`) that has zero items. Do not include a `Benign` section.
70
71	## Guardrails
72
73	- Do not suggest fixes for context gaps. Report what needs attention; leave solutions to the human.
74	- Do not conflate code quality issues with assumptions. An assumption is a decision you made where the spec was silent — not a code style choice.

People who liked this also viewed

6 picks

Type

session-report

28stars1forks

View on GitHub

How to install session-report?

codagent-ai/agent-skills/session-report

$npx -y skills add Codagent-AI/agent-skills --skill session-report

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Session Report
2
3	Audit your own session against the task file(s) you were given. Surface assumptions you made and context gaps that caused struggles. These are observations for the human — not things you can fix after the fact.
4
5	## Review Process
6
7	Work through each dimension in order. For every finding, cite specific evidence.
8
9	### Dimension 1: Assumption Audit
10
11	Identify every place you made a decision that was not dictated by the task file or spec. For each assumption:
12
13	- Ambiguity — what the spec didn't say
14	- Choice — what you decided and why (the reasoning, not just the outcome)
15	- Risk — what could go wrong if this choice is wrong. Be specific: name the scenario, the affected code path, and what would break. "Could surprise future workflows" is not specific enough — say which workflow shape triggers it and what the symptom would be.
16	- Impact classification:
17	- `benign` — reasonable default, no real consequence (do not report)
18	- `notable` — meaningful choice that could have gone differently
19	- `risky` — could cause problems, warrants review
20	- Recommendation — what the reviewer should do: verify behavior, add a test, clarify the spec, or approve as-is with rationale.
21
22	Report only `risky` and `notable` assumptions. Drop `benign` entirely — they dilute the signal. Sort `risky` first, then `notable`.
23
24	### Dimension 2: Context Gaps
25
26	A context gap is a major, avoidable hole in the task file or project context that sent you down a fundamentally wrong path, caused you to build the wrong thing, or wasted significant effort that better upfront information would have prevented entirely.
27
28	The bar is high. Most sessions have zero context gaps. Fixing a linter warning is not a context gap. Searching for a convention is not a context gap. Iterating on validator feedback is not a context gap — it is the normal development loop.
29
30	Examples of real context gaps:
31	- The task said to extend module X, but module X was deleted last week and replaced by module Y — you built against a nonexistent target
32	- The task required integrating with service A but didn't mention that service A requires an auth token from a separate provisioning step — you couldn't have known this without tribal knowledge
33	- The task file pointed you to the wrong directory or package, wasting significant effort before you found the right one
34
35	Things that are NOT context gaps (do not report these):
36	- Anything the validator caught (lint, security, permissions, test failures) — the validator's entire purpose is to catch what the task doesn't enumerate
37	- Quick searches for conventions, patterns, or existing code — that is normal development
38	- Iterative fix cycles of any kind — fixing things the first pass missed is expected, not a gap
39	- Learning something new about the codebase during implementation
40
41	For each genuine context gap:
42	- What happened — the concrete wasted effort or wrong direction
43	- What was missing — the specific information that, if present, would have prevented it entirely
44
45	## Output Format
46
47	```markdown
48	## Assumption Audit
49
50	### Risky
51
52	1. [What the spec didn't say]
53	- Choice: [What you decided and why]
54	- Risk: [Specific scenario that breaks — name the code path, workflow shape, and symptom]
55	- Recommendation: [What the reviewer should do]
56
57	### Notable
58
59	1. [What the spec didn't say]
60	- Choice: [What you decided and why]
61	- Risk: [Specific scenario that breaks — name the code path, workflow shape, and symptom]
62	- Recommendation: [What the reviewer should do]
63
64	## Context Gaps
65
66	- [What happened] — Missing context: [what was needed]
67	```
68
69	Omit any section (`Risky`, `Notable`) that has zero items. Do not include a `Benign` section.
70
71	## Guardrails
72
73	- Do not suggest fixes for context gaps. Report what needs attention; leave solutions to the human.
74	- Do not conflate code quality issues with assumptions. An assumption is a decision you made where the spec was silent — not a code style choice.

People who liked this also viewed

6 picks

Type