Problem
When a Nous campaign finishes, its knowledge (principles, dead-ends, boundary conditions, untested combinations) lives only in raw ledger.json and principles.json files inside the campaign directory. There's no structured way to:
- Extract what failed and why (dead-ends)
- Identify where knowledge runs out (frontiers)
- Surface untested combinations of confirmed techniques (interactions)
- See the campaign's knowledge as a navigable graph
Users have to manually re-read principles.json (30-55 entries) to remember what a campaign discovered. This makes it hard to build on prior work or share findings.
Desired Outcome
A /post-campaign Claude skill that takes a completed campaign directory, extracts structured knowledge, and produces:
dead-ends.json — self-contained descriptions of what was tried and why it failedfrontiers.json — boundary conditions where knowledge ends and the next experiment beginsinteractions.json — untested combinations of confirmed techniques worth exploringconcepts.json — entity/concept/parameter knowledge graph with principle linkagesummaries.json — per-iteration narrative (what was tried, what was found)summary.md — human-readable campaign summary- An interactive HTML visualization of the campaign's knowledge graph
The skill calls Python scripts for validation and visualization — the LLM handles knowledge extraction, the scripts handle rendering.
Each output entry should be self-contained — readable without opening any other file.
A thin /visualize-campaign skill should also exist for re-rendering the HTML from pre-existing data without re-extracting.
Constraints
- No modifications to existing orchestrator code (campaign.py, ledger.py, cli.py, etc.)
- Idempotent: running twice on the same campaign is a no-op
- All output goes to
~/.nous/wiki/campaigns/<name>/ (user-level, outside any repo)
Context
See Discussion #269 for how this fits into the broader cross-campaign persistence strategy.
Problem
When a Nous campaign finishes, its knowledge (principles, dead-ends, boundary conditions, untested combinations) lives only in raw
ledger.jsonandprinciples.jsonfiles inside the campaign directory. There's no structured way to:Users have to manually re-read
principles.json(30-55 entries) to remember what a campaign discovered. This makes it hard to build on prior work or share findings.Desired Outcome
A
/post-campaignClaude skill that takes a completed campaign directory, extracts structured knowledge, and produces:dead-ends.json— self-contained descriptions of what was tried and why it failedfrontiers.json— boundary conditions where knowledge ends and the next experiment beginsinteractions.json— untested combinations of confirmed techniques worth exploringconcepts.json— entity/concept/parameter knowledge graph with principle linkagesummaries.json— per-iteration narrative (what was tried, what was found)summary.md— human-readable campaign summaryThe skill calls Python scripts for validation and visualization — the LLM handles knowledge extraction, the scripts handle rendering.
Each output entry should be self-contained — readable without opening any other file.
A thin
/visualize-campaignskill should also exist for re-rendering the HTML from pre-existing data without re-extracting.Constraints
~/.nous/wiki/campaigns/<name>/(user-level, outside any repo)Context
See Discussion #269 for how this fits into the broader cross-campaign persistence strategy.