journal

Name: journal
Author: Rune-kit

80stars21forks

How to install journal?

rune-kit/rune/journal

$npx -y skills add Rune-kit/rune --skill journal

Installs into the current project.

Summary

Persistent state tracking and Architecture Decision Records across sessions. Use when recording a decision, ADR, or progress that must survive session boundaries. Manages progress state, module health, dependency graphs, and ADRs for any workflow.

Files · 1

View on GitHub

SKILL.md

1	# journal
2
3	## Purpose
4
5	Persistent state tracking and Architecture Decision Records across sessions. Journal manages the state files that allow any workflow to span multiple sessions without losing progress — rescue operations, feature development, deploy decisions, or audit findings. Separate from session-bridge which handles general context injection — journal writes durable, human-readable state that survives compaction.
6
7	## Triggers
8
9	- Called by any skill needing decision persistence or progress tracking
10	- Auto-trigger: after surgeon completes a module, after deploy, after audit phases
11
12	## Calls (outbound)
13
14	None — pure L3 state management utility.
15
16	## Called By (inbound)
17
18	- `surgeon` (L2): update progress after each surgery session
19	- `rescue` (L1): read state for rescue dashboard
20	- `autopsy` (L2): save initial health assessment
21	- `cook` (L1): record key architectural decisions made during feature development
22	- `deploy` (L2): record deploy decision, rollback plan, and post-deploy status
23	- `audit` (L2): save AUDIT-REPORT.md and record health trend entry
24	- `incident` (L2): record incident timeline and postmortem
25	- `skill-forge` (L2): record skill creation decisions and rationale
26	- `graft` (L2): auto-log graft operations — source URL, mode, challenge score, files changed
27	- `retro` (L2): record retrospective insights and decisions
28	- `improve-architecture` (L2): record an ADR when the user rejects a deepening candidate with a load-bearing reason
29
30	## Files Managed
31
32	```
33	.rune/RESCUE-STATE.md — Human-readable rescue progress (loaded into context)
34	.rune/module-status.json — Machine-readable module states
35	.rune/dependency-graph.mmd — Mermaid diagram, color-coded by health
36	.rune/adr/ — Architecture Decision Records (one per decision)
37	.rune/risks/ — Risk Register entries (one per identified risk)
38	```
39
40	## Execution
41
42	### Step 1 — Load state
43
44	Use `Read` to load current rescue state:
45
46	```
47	Read: .rune/RESCUE-STATE.md
48	Read: .rune/module-status.json
49	```
50
51	If either file does not exist, initialize it with an empty template:
52
53	- `RESCUE-STATE.md`: create with header `# Rescue State\n\nStarted: [date]\nPhase: 1\n`
54	- `module-status.json`: create with `{ "modules": [], "lastUpdated": "[iso-date]" }`
55
56	Parse `module-status.json` to extract current module states and health scores.
57
58	### Step 2 — Update progress
59
60	For each module that was completed during this session:
61
62	1. Locate the module entry in the parsed `module-status.json`
63	2. Update its fields:
64	- `status`: set to `"complete"` (or `"in-progress"` / `"blocked"` as appropriate)
65	- `healthScore`: set to the post-surgery score (0-100)
66	- `completedAt`: set to current ISO timestamp
67	3. Mark the active module pointer in `RESCUE-STATE.md` — update the `Current Module` line to the next pending module
68
69	Use `Write` to save the updated `module-status.json`.
70
71	Use `Edit` to update the relevant lines in `RESCUE-STATE.md` (current phase, current module, counts of completed vs pending).
72
73	### Step 3 — Record decisions (gated by 3-criteria scoring)
74
75	For each architectural decision or trade-off made during this session (applies to any workflow — feature development, deploy, rescue, audit):
76
77	#### Step 3.0 — Score the decision
78
79	Compute three numeric scores (1–5 each) before opening any ADR file. See [references/adr-criteria.md](references/adr-criteria.md) for full rubric.
80
81	\| Axis \| What it measures \|
82	\|------\|------------------\|
83	\| `reversibility` \| 1 = next-sprint reversible; 5 = practically irreversible \|
84	\| `surprisingness` \| 1 = obvious to any reader; 5 = future engineer would "fix" without context \|
85	\| `tradeoff_strength` \| 1 = no real alternative; 5 = genuinely difficult choice \|
86
87	```
88	score = reversibility + surprisingness + tradeoff_strength # range 3–15
89	open_adr = (score >= 11) AND (each axis >= 3)
90	```
91
92	#### Step 3.1 — Counter-test (anti-fake)
93
94	Before writing the ADR, fill in at least one rejected alternative + why. If no credible alternative was actually considered, the decision wasn't a real tradeoff — re-classify as a convention (record in CLAUDE.md or comment, not in `.rune/adr/`) and skip ADR creation.
95
96	#### Step 3.2 — Open the ADR (if gate passed)
97
98	1. Generate filename including the score: `.rune/adr/ADR-[NNN]-[slug]-s[score].md` where NNN is sequential and `score` is the 3–15 sum (e.g., `ADR-007-postgres-write-model-s13.md`)
99	2. Use `Write` to create the ADR file with this format:
100
101	```markdown
102	# ADR-[NNN]: [Decision Title]
103
104	Date: [YYYY-MM-DD]
105	Status: Accepted
106	Workflow: [rescue \| co

People who liked this also viewed

6 picks

Type

journal

80stars21forks

View on GitHub

How to install journal?

rune-kit/rune/journal

$npx -y skills add Rune-kit/rune --skill journal

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# journal
2
3	## Purpose
4
5	Persistent state tracking and Architecture Decision Records across sessions. Journal manages the state files that allow any workflow to span multiple sessions without losing progress — rescue operations, feature development, deploy decisions, or audit findings. Separate from session-bridge which handles general context injection — journal writes durable, human-readable state that survives compaction.
6
7	## Triggers
8
9	- Called by any skill needing decision persistence or progress tracking
10	- Auto-trigger: after surgeon completes a module, after deploy, after audit phases
11
12	## Calls (outbound)
13
14	None — pure L3 state management utility.
15
16	## Called By (inbound)
17
18	- `surgeon` (L2): update progress after each surgery session
19	- `rescue` (L1): read state for rescue dashboard
20	- `autopsy` (L2): save initial health assessment
21	- `cook` (L1): record key architectural decisions made during feature development
22	- `deploy` (L2): record deploy decision, rollback plan, and post-deploy status
23	- `audit` (L2): save AUDIT-REPORT.md and record health trend entry
24	- `incident` (L2): record incident timeline and postmortem
25	- `skill-forge` (L2): record skill creation decisions and rationale
26	- `graft` (L2): auto-log graft operations — source URL, mode, challenge score, files changed
27	- `retro` (L2): record retrospective insights and decisions
28	- `improve-architecture` (L2): record an ADR when the user rejects a deepening candidate with a load-bearing reason
29
30	## Files Managed
31
32	```
33	.rune/RESCUE-STATE.md — Human-readable rescue progress (loaded into context)
34	.rune/module-status.json — Machine-readable module states
35	.rune/dependency-graph.mmd — Mermaid diagram, color-coded by health
36	.rune/adr/ — Architecture Decision Records (one per decision)
37	.rune/risks/ — Risk Register entries (one per identified risk)
38	```
39
40	## Execution
41
42	### Step 1 — Load state
43
44	Use `Read` to load current rescue state:
45
46	```
47	Read: .rune/RESCUE-STATE.md
48	Read: .rune/module-status.json
49	```
50
51	If either file does not exist, initialize it with an empty template:
52
53	- `RESCUE-STATE.md`: create with header `# Rescue State\n\nStarted: [date]\nPhase: 1\n`
54	- `module-status.json`: create with `{ "modules": [], "lastUpdated": "[iso-date]" }`
55
56	Parse `module-status.json` to extract current module states and health scores.
57
58	### Step 2 — Update progress
59
60	For each module that was completed during this session:
61
62	1. Locate the module entry in the parsed `module-status.json`
63	2. Update its fields:
64	- `status`: set to `"complete"` (or `"in-progress"` / `"blocked"` as appropriate)
65	- `healthScore`: set to the post-surgery score (0-100)
66	- `completedAt`: set to current ISO timestamp
67	3. Mark the active module pointer in `RESCUE-STATE.md` — update the `Current Module` line to the next pending module
68
69	Use `Write` to save the updated `module-status.json`.
70
71	Use `Edit` to update the relevant lines in `RESCUE-STATE.md` (current phase, current module, counts of completed vs pending).
72
73	### Step 3 — Record decisions (gated by 3-criteria scoring)
74
75	For each architectural decision or trade-off made during this session (applies to any workflow — feature development, deploy, rescue, audit):
76
77	#### Step 3.0 — Score the decision
78
79	Compute three numeric scores (1–5 each) before opening any ADR file. See [references/adr-criteria.md](references/adr-criteria.md) for full rubric.
80
81	\| Axis \| What it measures \|
82	\|------\|------------------\|
83	\| `reversibility` \| 1 = next-sprint reversible; 5 = practically irreversible \|
84	\| `surprisingness` \| 1 = obvious to any reader; 5 = future engineer would "fix" without context \|
85	\| `tradeoff_strength` \| 1 = no real alternative; 5 = genuinely difficult choice \|
86
87	```
88	score = reversibility + surprisingness + tradeoff_strength # range 3–15
89	open_adr = (score >= 11) AND (each axis >= 3)
90	```
91
92	#### Step 3.1 — Counter-test (anti-fake)
93
94	Before writing the ADR, fill in at least one rejected alternative + why. If no credible alternative was actually considered, the decision wasn't a real tradeoff — re-classify as a convention (record in CLAUDE.md or comment, not in `.rune/adr/`) and skip ADR creation.
95
96	#### Step 3.2 — Open the ADR (if gate passed)
97
98	1. Generate filename including the score: `.rune/adr/ADR-[NNN]-[slug]-s[score].md` where NNN is sequential and `score` is the 3–15 sum (e.g., `ADR-007-postgres-write-model-s13.md`)
99	2. Use `Write` to create the ADR file with this format:
100
101	```markdown
102	# ADR-[NNN]: [Decision Title]
103
104	Date: [YYYY-MM-DD]
105	Status: Accepted
106	Workflow: [rescue \| co

People who liked this also viewed

6 picks

Type