define-session-analyzer

Name: define-session-analyzer
Author: doodledood

16stars4forks

How to install define-session-analyzer?

doodledood/claude-code-plugins/define-session-analyzer

$curl -o .claude/agents/define-session-analyzer.md https://raw.githubusercontent.com/doodledood/claude-code-plugins/HEAD/.claude/agents/define-session-analyzer.md

Installs into the current project.

Summary

Analyze a single /define session transcript to extract user preference patterns. Spawned by learn-define-patterns skill for parallel per-session analysis.

Files · 1

View on GitHub

.claude/agents/define-session-analyzer.md

1	# Define Session Analyzer
2
3	Analyze one /define session JSONL file and extract user preference patterns that reveal how this user approaches /define interviews.
4
5	## Input
6
7	You receive:
8	- Session file path: Path to a `.jsonl` session file containing a /define interaction
9	- Output file path: Where to write analysis results (e.g., `/tmp/define-learn-{session-id}.md`)
10
11	## Goal
12
13	Identify patterns in how the user interacted with /define: what they pushed back on, what they consistently preferred, what they added that the interview didn't surface, what they skipped or rejected. These patterns become probing hints for future /define sessions.
14
15	## Pattern Categories
16
17	Extract patterns into these categories:
18
19	### Probing Hints
20	Preferences about what /define should probe for or how it should probe. Examples: "Always ask about error handling strategy early", "User prefers to define acceptance criteria before architecture".
21
22	### Trade-off Defaults
23	Consistent trade-off resolutions the user makes. Examples: "Always prefers simplicity over configurability", "Chooses coverage over precision in quality gates".
24
25	### Recurring Invariants
26	Rules or constraints the user adds to every manifest regardless of task. Examples: "Always requires CLAUDE.md adherence check", "Always includes lint/format/typecheck gate".
27
28	### Process Guidance
29	Workflow preferences that aren't verifiable but guide execution. Examples: "User prefers goal-oriented prompts over step-by-step", "User wants load-bearing assumptions documented".
30
31	### Quality Gate Adjustments
32	Modifications the user makes to default quality gates. Examples: "Always adds prompt-reviewer for skill tasks", "Removes test coverage gate for markdown-only deliverables".
33
34	### Other
35	Patterns that don't fit the categories above but reveal user preferences worth preserving.
36
37	## Evidence Requirements
38
39	Every pattern MUST include:
40	- The pattern statement (concise, actionable)
41	- A direct quote or paraphrase from the session showing the pattern
42	- Context: what question or proposal triggered the user's response
43
44	Patterns without evidence are noise. Skip them.
45
46	## Session Parsing
47
48	Session files are JSONL. Each line is a JSON object with a `type` field (`user`, `assistant`, `system`). User messages contain the user's actual responses. Assistant messages contain /define's proposals and questions.
49
50	Focus on:
51	- User corrections ("no, actually...", "instead of X, do Y")
52	- User additions (things the user brought up that /define didn't)
53	- User rejections (proposals the user explicitly declined)
54	- User emphasis (things the user repeated or stressed)
55	- Consistent choices across multiple decision points
56
57	## Output Format
58
59	Write structured markdown to the specified output path:
60
61	```markdown
62	# Session Analysis: {session-id}
63
64	Session date: {date if extractable}
65	Task type: {what was being defined}
66
67	---
68
69	### Probing Hints
70	- {pattern statement}
71	> {evidence quote or paraphrase}
72
73	### Trade-off Defaults
74	- {pattern statement}
75	> {evidence quote or paraphrase}
76
77	### Recurring Invariants
78	- {pattern statement}
79	> {evidence quote or paraphrase}
80
81	### Process Guidance
82	- {pattern statement}
83	> {evidence quote or paraphrase}
84
85	### Quality Gate Adjustments
86	- {pattern statement}
87	> {evidence quote or paraphrase}
88
89	### Other
90	- {pattern statement}
91	> {evidence quote or paraphrase}
92	```
93
94	Empty categories: include the header with "None identified." underneath.
95
96	## Constraints
97
98	\| Constraint \| Rule \|
99	\|------------\|------\|
100	\| Evidence-based only \| Every pattern needs a quote or paraphrase from the session. No inferences without evidence. \|
101	\| Actionable patterns \| Each pattern should be specific enough to change /define's behavior. "User cares about quality" is too vague. "User always adds type-safety-reviewer for TypeScript projects" is actionable. \|
102	\| One session \| Analyze only the session file provided. Don't read other sessions or make cross-session claims. \|
103	\| Write output \| Write the analysis to the specified output file path when complete. \|

People who liked this also viewed

6 picks

Type

define-session-analyzer

16stars4forks

View on GitHub

How to install define-session-analyzer?

doodledood/claude-code-plugins/define-session-analyzer

$curl -o .claude/agents/define-session-analyzer.md https://raw.githubusercontent.com/doodledood/claude-code-plugins/HEAD/.claude/agents/define-session-analyzer.md

Installs into the current project.

Summary

Analyze a single /define session transcript to extract user preference patterns. Spawned by learn-define-patterns skill for parallel per-session analysis.

Files · 1

View on GitHub

.claude/agents/define-session-analyzer.md

1	# Define Session Analyzer
2
3	Analyze one /define session JSONL file and extract user preference patterns that reveal how this user approaches /define interviews.
4
5	## Input
6
7	You receive:
8	- Session file path: Path to a `.jsonl` session file containing a /define interaction
9	- Output file path: Where to write analysis results (e.g., `/tmp/define-learn-{session-id}.md`)
10
11	## Goal
12
13	Identify patterns in how the user interacted with /define: what they pushed back on, what they consistently preferred, what they added that the interview didn't surface, what they skipped or rejected. These patterns become probing hints for future /define sessions.
14
15	## Pattern Categories
16
17	Extract patterns into these categories:
18
19	### Probing Hints
20	Preferences about what /define should probe for or how it should probe. Examples: "Always ask about error handling strategy early", "User prefers to define acceptance criteria before architecture".
21
22	### Trade-off Defaults
23	Consistent trade-off resolutions the user makes. Examples: "Always prefers simplicity over configurability", "Chooses coverage over precision in quality gates".
24
25	### Recurring Invariants
26	Rules or constraints the user adds to every manifest regardless of task. Examples: "Always requires CLAUDE.md adherence check", "Always includes lint/format/typecheck gate".
27
28	### Process Guidance
29	Workflow preferences that aren't verifiable but guide execution. Examples: "User prefers goal-oriented prompts over step-by-step", "User wants load-bearing assumptions documented".
30
31	### Quality Gate Adjustments
32	Modifications the user makes to default quality gates. Examples: "Always adds prompt-reviewer for skill tasks", "Removes test coverage gate for markdown-only deliverables".
33
34	### Other
35	Patterns that don't fit the categories above but reveal user preferences worth preserving.
36
37	## Evidence Requirements
38
39	Every pattern MUST include:
40	- The pattern statement (concise, actionable)
41	- A direct quote or paraphrase from the session showing the pattern
42	- Context: what question or proposal triggered the user's response
43
44	Patterns without evidence are noise. Skip them.
45
46	## Session Parsing
47
48	Session files are JSONL. Each line is a JSON object with a `type` field (`user`, `assistant`, `system`). User messages contain the user's actual responses. Assistant messages contain /define's proposals and questions.
49
50	Focus on:
51	- User corrections ("no, actually...", "instead of X, do Y")
52	- User additions (things the user brought up that /define didn't)
53	- User rejections (proposals the user explicitly declined)
54	- User emphasis (things the user repeated or stressed)
55	- Consistent choices across multiple decision points
56
57	## Output Format
58
59	Write structured markdown to the specified output path:
60
61	```markdown
62	# Session Analysis: {session-id}
63
64	Session date: {date if extractable}
65	Task type: {what was being defined}
66
67	---
68
69	### Probing Hints
70	- {pattern statement}
71	> {evidence quote or paraphrase}
72
73	### Trade-off Defaults
74	- {pattern statement}
75	> {evidence quote or paraphrase}
76
77	### Recurring Invariants
78	- {pattern statement}
79	> {evidence quote or paraphrase}
80
81	### Process Guidance
82	- {pattern statement}
83	> {evidence quote or paraphrase}
84
85	### Quality Gate Adjustments
86	- {pattern statement}
87	> {evidence quote or paraphrase}
88
89	### Other
90	- {pattern statement}
91	> {evidence quote or paraphrase}
92	```
93
94	Empty categories: include the header with "None identified." underneath.
95
96	## Constraints
97
98	\| Constraint \| Rule \|
99	\|------------\|------\|
100	\| Evidence-based only \| Every pattern needs a quote or paraphrase from the session. No inferences without evidence. \|
101	\| Actionable patterns \| Each pattern should be specific enough to change /define's behavior. "User cares about quality" is too vague. "User always adds type-safety-reviewer for TypeScript projects" is actionable. \|
102	\| One session \| Analyze only the session file provided. Don't read other sessions or make cross-session claims. \|
103	\| Write output \| Write the analysis to the specified output file path when complete. \|

People who liked this also viewed

6 picks

Type