git-workflow

Name: git-workflow
Author: elb-pr

126stars7forks

How to install git-workflow?

elb-pr/claudikins-kernel/git-workflow

$npx -y skills add elb-pr/claudikins-kernel --skill git-workflow

Installs into the current project.

Summary

Use when running claudikins-kernel:execute, decomposing plans into tasks, setting up two-stage review, deciding batch sizes, or handling stuck agents — enforces isolation, verification, and human checkpoints; prevents runaway parallelization and context death

Files · 1

View on GitHub

SKILL.md

1	# Git Workflow Methodology
2
3	## When to use this skill
4
5	Use this skill when you need to:
6
7	- Run the `claudikins-kernel:execute` command
8	- Decompose plans into executable tasks
9	- Set up two-stage code review
10	- Decide batch sizes and checkpoints
11	- Handle stuck agents or failed tasks
12
13	## Core Philosophy
14
15	> "I'd use 5-7 agents per SESSION, not 30 per batch." - Boris
16
17	Execution is about isolation, verification, and human checkpoints. Not speed.
18
19	### The Six Principles
20
21	1. One task = one branch - Isolation prevents pollution
22	2. Fresh context per task - `context: fork` gives a clean slate
23	3. Two-stage review - Spec compliance first, then code quality
24	4. Human checkpoints between batches - Not between individual tasks
25	5. Commands own git - Agents never checkout/merge/push
26	6. Features are the unit - Batch at feature level, not task level
27
28	### Batch Size Guidance (GOSPEL)
29
30	Wrong: 30 agents for 10 tasks (3 per task micro-management)
31	Right: 5-7 agents total (feature-level batches)
32
33	\| Scenario \| Wrong \| Right \|
34	\| -------------------- \| -------------------------- \| ------------------ \|
35	\| 10 tasks, 5 features \| 30 micro-task agents \| 5-7 feature agents \|
36	\| Simple refactor \| 10 agents for tiny changes \| 1-2 feature agents \|
37
38	Default `--batch 1` is correct. Features are the unit of work.
39
40	## Task Decomposition
41
42	From a plan, extract tasks that are:
43
44	\| Quality \| Definition \| Example \|
45	\| --------------- \| ---------------------------------------------- \| --------------------------------------------- \|
46	\| Atomic \| Completable in one agent session \| "Add auth middleware" not "Build auth system" \|
47	\| Testable \| Has measurable acceptance criteria \| "Returns 401 for invalid token" \|
48	\| Independent \| Minimal dependencies on other tasks \| Can be reviewed in isolation \|
49	\| Right-sized \| Not too small (noise) or large (context death) \| 50-200 lines of changes \|
50
51	See [task-decomposition.md](references/task-decomposition.md) for patterns.
52
53	## Review Stages
54
55	Two reviewers with different jobs. Never skip either.
56
57	### Stage 1: Spec Compliance (spec-reviewer, opus)
58
59	Question: "Did it do what was asked?"
60
61	Checks:
62
63	- All acceptance criteria addressed?
64	- Any scope creep (features not in spec)?
65	- Any missing requirements?
66
67	Output: `PASS` or `FAIL` with line references.
68
69	### Stage 2: Code Quality (code-reviewer, opus)
70
71	Question: "Is it well-written?"
72
73	Checks:
74
75	- Consistency with codebase style
76	- Error handling
77	- Edge cases
78	- Naming clarity
79	- Unnecessary complexity
80
81	Output: `PASS` or `CONCERNS` with confidence scores.
82
83	See [review-criteria.md](references/review-criteria.md) for detailed checklists.
84
85	## Review Enforcement (MANDATORY)
86
87	This is non-negotiable. Violations here break the entire workflow.
88
89	### The Iron Rule
90
91	After EVERY task completes, you MUST spawn BOTH reviewer agents:
92
93	1. spec-reviewer - Spawned via `Task(spec-reviewer, {...})`
94	2. code-reviewer - Spawned via `Task(code-reviewer, {...})` (if spec passes)
95
96	### What "MUST spawn" Means
97
98	\| Allowed \| NOT Allowed \|
99	\|---------\|-------------\|
100	\| `Task(spec-reviewer, { prompt: "...", context: "fork" })` \| Inline spec check by orchestrator \|
101	\| `Task(code-reviewer, { prompt: "...", context: "fork" })` \| "I'll just verify the code looks good" \|
102	\| Waiting for agent output JSON \| Making your own compliance table \|
103	\| Reading from `.claude/reviews/spec/` \| Skipping because "it's a simple task" \|
104
105	### Inline Reviews Are VIOLATIONS
106
107	If you find yourself doing ANY of these, you are VIOLATING the methodology:
108
109	- Creating a "Spec Compliance Check" table yourself
110	- Writing "Verdict: PASS" without spawning an agent
111	- Saying "Let me verify the implementation meets criteria"
112	- Checking acceptance criteria in a loop instead of delegating
113
114	The orchestrator does NOT review. The orchestrator SPAWNS reviewers.
115
116	### Pre-Merge Checklist (HARD GATE)
117
118	Before ANY merge decision can be offered to the user:
119
120	```
121	□ .claude/reviews/spec/{task_id}.json EXISTS for each task
122	□ .claude/reviews/code/{task_id}.json EXISTS for each task
123	□ Both files contain valid JSON with "verdict" field
124	□ spec-reviewer verdict is PASS (or user override d

People who liked this also viewed

6 picks

Type

git-workflow

126stars7forks

View on GitHub

How to install git-workflow?

elb-pr/claudikins-kernel/git-workflow

$npx -y skills add elb-pr/claudikins-kernel --skill git-workflow

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Git Workflow Methodology
2
3	## When to use this skill
4
5	Use this skill when you need to:
6
7	- Run the `claudikins-kernel:execute` command
8	- Decompose plans into executable tasks
9	- Set up two-stage code review
10	- Decide batch sizes and checkpoints
11	- Handle stuck agents or failed tasks
12
13	## Core Philosophy
14
15	> "I'd use 5-7 agents per SESSION, not 30 per batch." - Boris
16
17	Execution is about isolation, verification, and human checkpoints. Not speed.
18
19	### The Six Principles
20
21	1. One task = one branch - Isolation prevents pollution
22	2. Fresh context per task - `context: fork` gives a clean slate
23	3. Two-stage review - Spec compliance first, then code quality
24	4. Human checkpoints between batches - Not between individual tasks
25	5. Commands own git - Agents never checkout/merge/push
26	6. Features are the unit - Batch at feature level, not task level
27
28	### Batch Size Guidance (GOSPEL)
29
30	Wrong: 30 agents for 10 tasks (3 per task micro-management)
31	Right: 5-7 agents total (feature-level batches)
32
33	\| Scenario \| Wrong \| Right \|
34	\| -------------------- \| -------------------------- \| ------------------ \|
35	\| 10 tasks, 5 features \| 30 micro-task agents \| 5-7 feature agents \|
36	\| Simple refactor \| 10 agents for tiny changes \| 1-2 feature agents \|
37
38	Default `--batch 1` is correct. Features are the unit of work.
39
40	## Task Decomposition
41
42	From a plan, extract tasks that are:
43
44	\| Quality \| Definition \| Example \|
45	\| --------------- \| ---------------------------------------------- \| --------------------------------------------- \|
46	\| Atomic \| Completable in one agent session \| "Add auth middleware" not "Build auth system" \|
47	\| Testable \| Has measurable acceptance criteria \| "Returns 401 for invalid token" \|
48	\| Independent \| Minimal dependencies on other tasks \| Can be reviewed in isolation \|
49	\| Right-sized \| Not too small (noise) or large (context death) \| 50-200 lines of changes \|
50
51	See [task-decomposition.md](references/task-decomposition.md) for patterns.
52
53	## Review Stages
54
55	Two reviewers with different jobs. Never skip either.
56
57	### Stage 1: Spec Compliance (spec-reviewer, opus)
58
59	Question: "Did it do what was asked?"
60
61	Checks:
62
63	- All acceptance criteria addressed?
64	- Any scope creep (features not in spec)?
65	- Any missing requirements?
66
67	Output: `PASS` or `FAIL` with line references.
68
69	### Stage 2: Code Quality (code-reviewer, opus)
70
71	Question: "Is it well-written?"
72
73	Checks:
74
75	- Consistency with codebase style
76	- Error handling
77	- Edge cases
78	- Naming clarity
79	- Unnecessary complexity
80
81	Output: `PASS` or `CONCERNS` with confidence scores.
82
83	See [review-criteria.md](references/review-criteria.md) for detailed checklists.
84
85	## Review Enforcement (MANDATORY)
86
87	This is non-negotiable. Violations here break the entire workflow.
88
89	### The Iron Rule
90
91	After EVERY task completes, you MUST spawn BOTH reviewer agents:
92
93	1. spec-reviewer - Spawned via `Task(spec-reviewer, {...})`
94	2. code-reviewer - Spawned via `Task(code-reviewer, {...})` (if spec passes)
95
96	### What "MUST spawn" Means
97
98	\| Allowed \| NOT Allowed \|
99	\|---------\|-------------\|
100	\| `Task(spec-reviewer, { prompt: "...", context: "fork" })` \| Inline spec check by orchestrator \|
101	\| `Task(code-reviewer, { prompt: "...", context: "fork" })` \| "I'll just verify the code looks good" \|
102	\| Waiting for agent output JSON \| Making your own compliance table \|
103	\| Reading from `.claude/reviews/spec/` \| Skipping because "it's a simple task" \|
104
105	### Inline Reviews Are VIOLATIONS
106
107	If you find yourself doing ANY of these, you are VIOLATING the methodology:
108
109	- Creating a "Spec Compliance Check" table yourself
110	- Writing "Verdict: PASS" without spawning an agent
111	- Saying "Let me verify the implementation meets criteria"
112	- Checking acceptance criteria in a loop instead of delegating
113
114	The orchestrator does NOT review. The orchestrator SPAWNS reviewers.
115
116	### Pre-Merge Checklist (HARD GATE)
117
118	Before ANY merge decision can be offered to the user:
119
120	```
121	□ .claude/reviews/spec/{task_id}.json EXISTS for each task
122	□ .claude/reviews/code/{task_id}.json EXISTS for each task
123	□ Both files contain valid JSON with "verdict" field
124	□ spec-reviewer verdict is PASS (or user override d

People who liked this also viewed

6 picks

Type