Introduce Skeleton-of-Thought (SoT) doctrine across all codices - #6
Conversation
Applies the two-stage SoT doctrine to every character in the Undead Legion and supporting packages. Each upgrade follows the same pattern: - Stage 1: produce a concise skeleton (3-10 points) immediately - Stage 2: expand each independent point in parallel; sequence only dependents Changes by package: BERSERKER (v1.0.0 → v1.1.0) - New SoT skill branch: Battlefield Sketch, Parallel Shard Prep, Time-to-First-Shard - New CHAIN IV: THE BATTLEFIELD SURVEY — SoT pre-investigation before any shard sequence - Documents when SoT applies (independent symptoms) vs. when to stay sequential (state-dependent shards) ARCHITECT (v1.1.0 → v1.2.0) - New SoT Engine skill branch replacing standalone Skeleton-of-Thoughts entry - Phase II (Skeleton Generation) upgraded to full SoT two-stage protocol with dependency map - SoT Task Classification Gate — identifies optimal vs. suboptimal SoT tasks - New THE SKELETON-OF-THOUGHT ENGINE section with parallelization protocol - New CHAIN IV: SKELETON-OF-THOUGHT RAPID SYNTHESIS prompt template HOUND (v1.2.0 → v1.3.0) - New SoT skill branch: Claim Cartography, Parallel Verification, Time-to-First-Label - New THE CLAIM CARTOGRAPHY ENGINE section with two-stage hunt specification - New CHAIN IV: THE SoT RAPID VERIFICATION SCAN — skeleton all claims, verify in parallel WARLOCK (v1.3.0 → v1.4.0) - New SoT skill branch: Branch Skeleton, Parallel Branch Weave, Design-Space Classifier - Branch Generation Protocol upgraded to SoT two-stage with branch skeleton first - New CHAIN IV: THE SKELETON SÉANCE — rapid design space survey before full exploration DRAGON (v1.4.0 → v1.5.0) - New SoT Orchestration skill branch: Mission Skeleton, Parallel Persona Dispatch, Dependency Graph - New THE SoT ORCHESTRATION DOCTRINE section — two-stage Legion deployment spec - Persona task independence classification framework - SoT Mission Skeleton template with speedup estimation - New CHAIN IV: THE SoT RAPID DISPATCH PROTOCOL BARD - New SoT skill branch: Documentation Skeleton, Parallel Chronicle Weave, SoT Release Notes - New workflow: workflow-skeleton-of-thought-chronicle.txt — 5-verse workflow for parallel documentation generation using SoT HEXWEAVER (v1.0.0 → v1.1.0) - New CHAIN IV: THE FIRST SCRYING SKELETON — SoT pre-scrying phase before the Ritual of Resurrection - Two-stage doctrine: corruption skeleton from symptoms → parallel scrying of independent fronts ARCHIVIST (v1.0.0 → v1.1.0) - New Chain IV: THE SKELETON INQUEST — SoT mapping of investigation fronts before any artifact is opened - Integration guide: how Chain IV replaces/enhances Chain I (The Broken Kingdom Dossier) https://claude.ai/code/session_01AL3cSuSU4GMhhkVDR5Di52
📝 WalkthroughRelease Notes
Changes by File
WalkthroughThis pull request introduces a unified Skeleton-of-Thought (SoT) two-stage protocol across nine architectural documentation files spanning multiple persona codices. Stage 1 generates structural skeletons; Stage 2 executes parallel or sequential expansions based on task dependencies. Version increments and methodology updates accompany each integration. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes The changes span nine files with substantial additions (~981 lines), yet constitute homogeneous, consistently-patterned documentation updates introducing the same SoT methodology across multiple persona contexts. The repetitive nature of the Stage 1/Stage 2 framework reduces per-file cognitive load, though the breadth of integration points and version consistency verification warrant moderate review attention. Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@archivist/undead-archivist.md`:
- Around line 737-738: Remove the dangling “, or” at the end of the first bullet
in the two-item list that starts with "Tailor one of the chains specifically to
code review, product design, or TTRPG campaigns," and the following bullet "Turn
the MCP concept into a concrete JSON/OpenAPI-ish tool schema."; specifically
edit the first bullet to drop the trailing ", or" (leaving the list to imply the
alternative) so the list reads cleanly.
- Around line 622-716: The fenced code blocks in the Chain IV section (e.g., the
blocks starting with "Stage 1 — THE INQUEST SKELETON", the "When SoT Applies to
the Inquest" block, "Prompt Template: The Skeleton Inquest", and the "STAGE 2 —
PARALLEL INVESTIGATION" / "Integration with Chain I" examples) lack language
identifiers and surrounding blank lines; update each opening fence to include a
language (use ```text) and ensure there is exactly one blank line immediately
before and after each fenced block, and normalize closing fences to ``` so the
MD031/MD040 lint rules are satisfied.
In `@berserker/Berserker_BERSERKER_CODEX.md`:
- Around line 322-323: Remove the duplicated horizontal rule in the Markdown by
deleting one of the consecutive '---' lines so only a single separator remains;
locate the duplicate in the Berserker_BERSERKER_CODEX.md section where two
consecutive '---' separators appear and remove the extra line to keep a single
horizontal rule for cleaner structure.
- Around line 355-412: The doc describes automatic front labeling/dependency
orchestration that the current MCP tool interfaces (see
Berserker_mcp-server_src_tools_scan.ts and
Berserker_mcp-server_src_tools_analyze.ts around the tool handler functions) do
not support; either implement explicit session/schema fields (e.g., add a
Front[] type with id, description, dependencies, parallelEligible to the tool
contract and wire it through the scan/analyze handlers and their
payload/response types) or revise this CHAIN IV section to state it is an
operator-guided methodology (remove wording implying MCP-native orchestration
and add a short note that tools currently return only raw findings and require
an external orchestrator to label fronts/dependencies).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: dc0b5eb2-33e0-4a75-be02-e4451d2d7073
📒 Files selected for processing (9)
architect/ARCHITECT_CODEX.mdarchivist/undead-archivist.mdbard/BARD_CODEX.mdbard/workflow-skeleton-of-thought-chronicle.txtberserker/Berserker_BERSERKER_CODEX.mddragon/DRAGON_CODEX.mdhexweaver/roles-hexweaver.mdhound/HOUND_CODEX.mdwarlock/WARLOCK_CODEX.md
📜 Review details
🧰 Additional context used
🪛 LanguageTool
hound/HOUND_CODEX.md
[style] ~284-~284: To make your writing clearer, consider a shorter, more direct phrase.
Context: ... VERIFIED first) - Claim B is presented as a consequence of Claim A Two claims are INDEPENDENT...
(AS_A_CONSEQUENCE_OF)
archivist/undead-archivist.md
[style] ~626-~626: Consider a different adjective to strengthen your wording.
Context: ... fronts, one sentence each Rule: No deep analysis. Structure only. Naming only. ...
(DEEP_PROFOUND)
🪛 markdownlint-cli2 (0.22.0)
archivist/undead-archivist.md
[warning] 622-622: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 634-634: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 634-634: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 638-638: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 648-648: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 648-648: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 652-652: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 677-677: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 677-677: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 679-679: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 703-703: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 703-703: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 709-709: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 716-716: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 716-716: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔍 Remote MCP
Based on the search results, the second search returned results about Warhammer 40k game content rather than the LLMRP project. Let me search more specifically for the LLMRP project and the Skeleton-of-Thought methodology application.## Summary of Relevant Context Found
Based on my research, I've identified important context about the Skeleton-of-Thought (SoT) methodology that this PR is implementing across the LLMRP codices:
SoT Methodology Foundation
Skeleton-of-Thought (SoT) is a technique where instead of producing answers sequentially, SoT produces different parts of answers in parallel. Given a question, SoT first prompts the LLM to generate the skeleton, then conducts batched decoding or parallel API calls to expand multiple points in parallel, and finally aggregates the outputs to get the final answer. This methodology was published as a peer-reviewed paper at ICLR 2024.
Key Design Principles for PR Review
The PR's implementation across multiple codices appears to follow the established SoT pattern with important variations:
-
Two-Stage Protocol Structure: SoT currently ignores dependencies between points, but a conceptually better approach is to organize points as Graph-of-Thoughts where edges represent dependencies, and dynamic Graph-of-Thoughts allows the high-level structure to be adjusted dynamically by LLMs themselves, potentially combining the efficiency and global thinking advantages of SoT with the logical reasoning of methods like Chain-of-Thought (CoT).
-
Parallelization with Dependency Management: The PR's emphasis on "independent vs dependent" classification across all codices (Architect's "nexus points," Dragon's "persona tasks," Berserker's "investigation fronts," etc.) aligns with this theoretical evolution toward dependency-aware parallelization rather than naive parallel generation.
-
Applicable Context for Implementation: The ICLR 2024 paper demonstrates that SoT gains strongest benefits for problems with naturally independent decomposable components, while pure sequential approaches may be superior for tightly-coupled reasoning chains.
Key Observations for PR Review Criteria
- Version consistency: The PR implements versioning updates across 7 codices (v1.1.0 through v1.5.0), suggesting incremental, coordinated adoption
- Unified templating: All packages include explicit "Chain IV" workflows with Stage 1 skeleton generation and Stage 2 expansion protocols
- Task classification emphasis: All codices introduce explicit gates/classification rules for determining when SoT is appropriate vs. when sequential/dependent execution should be used instead
[::web_search::]
🔇 Additional comments (9)
hound/HOUND_CODEX.md (1)
258-356: Excellent SoT execution spec: staged, dependency-aware, and operator-friendly.The split between Stage 1 cartography and Stage 2 CoVe expansion is clear, actionable, and well constrained for real verification workflows.
hexweaver/roles-hexweaver.md (1)
975-1079: Strong Chain IV addition with the right sequential fallback semantics.The “independent vs related” handling and explicit “SoT does not apply” gate make this robust instead of blindly parallel.
dragon/DRAGON_CODEX.md (1)
434-496: Well-architected dispatch protocol with crisp Stage 1/Stage 2 boundaries.The sequencing gates and ledger feedback loop are particularly strong additions for repeatable orchestration quality.
warlock/WARLOCK_CODEX.md (1)
244-280: Excellent upgrade to a true two-stage branch protocol.The Stage 1 skeleton contract and Stage 2 dependency-aware expansion are precise and immediately usable for architectural exploration sessions.
architect/ARCHITECT_CODEX.md (1)
411-465: Superb SoT engine formalization with practical applicability boundaries.The “optimal vs suboptimal” task table plus dependency-graph execution protocol turns doctrine into an implementable operating model.
bard/workflow-skeleton-of-thought-chronicle.txt (1)
16-224: Outstanding workflow artifact: concrete, executable, and team-ready.The staged templates, dependency handling, and integration/time-report closure make this immediately operable rather than purely conceptual.
bard/BARD_CODEX.md (1)
170-175: Elegant and precise SoT skill-tree integration for the Bard.The new branch captures the full skeleton-first documentation doctrine in compact, actionable form.
berserker/Berserker_BERSERKER_CODEX.md (2)
102-106: Excellent SoT skill-tree integration.This addition is crisp, internally consistent, and communicates the Stage 1/Stage 2 doctrine clearly in the Berserker voice.
618-619: Version/tagline update is well aligned with the SoT doctrine rollout.
v1.1.0and the new closing line are coherent with the introduced “survey-before-charge” behavior.
| ``` | ||
| Stage 1 — THE INQUEST SKELETON (Archivist delivers immediately): | ||
| Input: Case description only — the observable symptoms of the failing system | ||
| Output: 3–7 investigation fronts, one sentence each | ||
| Rule: No deep analysis. Structure only. Naming only. | ||
| Delivery: The skeleton IS the first output. Delivered before any artifact is opened. | ||
|
|
||
| Stage 2 — PARALLEL INVESTIGATION: | ||
| INDEPENDENT fronts: investigated simultaneously | ||
| DEPENDENT fronts: investigated in declared order only | ||
| Effect: A broken kingdom with 5 independent failure modes is investigated ~2x faster | ||
| than sequential autopsy | ||
| ``` | ||
|
|
||
| ### When SoT Applies to the Inquest | ||
|
|
||
| ``` | ||
| SoT OPTIMAL: | ||
| → A kingdom with multiple distinct failure categories (political, architectural, operational, human) | ||
| → A system with independent subsystems that can fail separately | ||
| → Post-mortems with multiple unrelated contributing factors | ||
|
|
||
| SoT SUBOPTIMAL: | ||
| → A single cascading failure where cause A must be confirmed before cause B can be named | ||
| → A corruption that flows through the system linearly (Stage 2 depends on Stage 1 output) | ||
| → Any investigation where the first finding determines the shape of all subsequent findings | ||
| ``` | ||
|
|
||
| ### Prompt Template: The Skeleton Inquest | ||
|
|
||
| ``` | ||
| Seeker, you have described a broken realm. | ||
| Before the Archivist opens a single scroll, she applies the Skeleton Inquest. | ||
|
|
||
| The case: [DESCRIBE THE FAILING SYSTEM OR PROJECT] | ||
| Observable symptoms: [LIST ALL KNOWN FAILURE SIGNALS] | ||
|
|
||
| STAGE 1 — THE INQUEST SKELETON: | ||
|
|
||
| From the symptoms alone, the Archivist names the investigation fronts: | ||
|
|
||
| FRONT 1: [failure category] — [one-sentence description of likely wound] | ||
| → INDEPENDENT / DEPENDS ON: [Front N] | ||
|
|
||
| FRONT 2: [failure category] — [one-sentence description] | ||
| → INDEPENDENT / DEPENDS ON: [Front N] | ||
|
|
||
| ... | ||
|
|
||
| PARALLEL ELIGIBLE: [list of independent fronts] | ||
| SEQUENTIAL REQUIRED: [ordered pairs where one front depends on another] | ||
|
|
||
| The skeleton is delivered now. The first scroll has not yet been opened. | ||
| Confirm the fronts. Add missing wounds. Remove fronts that do not apply. | ||
| When the map is confirmed, Stage 2 begins. | ||
| ``` | ||
|
|
||
| ``` | ||
| STAGE 2 — PARALLEL INVESTIGATION: | ||
|
|
||
| Skeleton confirmed. Artifacts brought forward. | ||
|
|
||
| For each PARALLEL ELIGIBLE front: | ||
| [PASTE RELEVANT ARTIFACT] | ||
| Apply the standard Archivist autopsy to this front: | ||
| - Structural wounds | ||
| - Operational wounds | ||
| - Human wounds | ||
| - Hidden risks not yet triggered | ||
|
|
||
| These autopsies run in parallel — the Archivist does not wait for | ||
| Front 1’s wounds to be catalogued before beginning Front 2’s dissection, | ||
| when those fronts are independent. | ||
|
|
||
| For SEQUENTIAL pairs: complete front N before beginning front N+1. | ||
| Pass front N’s findings explicitly into front N+1’s context. | ||
|
|
||
| When all fronts are complete: | ||
| → Produce the Rot Map: root causes and all symptoms they spawn | ||
| → Rank root causes by: speed of destruction / total cost / difficulty of reversal | ||
| → Produce 2–3 Restoration Playbooks | ||
| ``` | ||
|
|
||
| ### Integration with Chain I (The Broken Kingdom Dossier) | ||
|
|
||
| The Skeleton Inquest replaces Prompt 1 of Chain I and enhances Prompt 2. | ||
|
|
||
| ``` | ||
| Standard Chain I: Skeleton Inquest Enhancement: | ||
| Prompt 1 — The Summons → ENHANCED: Produce SoT skeleton before any artifact is opened | ||
| Prompt 2 — First Autopsy → ENHANCED: All independent fronts autopsied in parallel | ||
| Prompt 3 — Cross-Contagion → Preserved: Cross-reference across completed autopsies | ||
| Prompt 4 — Ledger of Blame → Preserved: Ranking and cost analysis | ||
| Prompt 5 — Edicts → Preserved: Restoration playbooks | ||
| ``` |
There was a problem hiding this comment.
Resolve markdown fence lint issues in Chain IV blocks.
From Line 622 through Line 716, fenced blocks are missing language identifiers and required blank-line spacing (MD031/MD040). Please normalize these fences to keep docs lint clean.
Proposed pattern to apply across the affected fenced blocks
-```
+```text
Stage 1 — THE INQUEST SKELETON (Archivist delivers immediately):
Input: Case description only — the observable symptoms of the failing system
...
-```
+```Also ensure one blank line before and after each fenced block.
🧰 Tools
🪛 LanguageTool
[style] ~626-~626: Consider a different adjective to strengthen your wording.
Context: ... fronts, one sentence each Rule: No deep analysis. Structure only. Naming only. ...
(DEEP_PROFOUND)
🪛 markdownlint-cli2 (0.22.0)
[warning] 622-622: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 634-634: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 634-634: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 638-638: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 648-648: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 648-648: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 652-652: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 677-677: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 677-677: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 679-679: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 703-703: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 703-703: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 709-709: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 716-716: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 716-716: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@archivist/undead-archivist.md` around lines 622 - 716, The fenced code blocks
in the Chain IV section (e.g., the blocks starting with "Stage 1 — THE INQUEST
SKELETON", the "When SoT Applies to the Inquest" block, "Prompt Template: The
Skeleton Inquest", and the "STAGE 2 — PARALLEL INVESTIGATION" / "Integration
with Chain I" examples) lack language identifiers and surrounding blank lines;
update each opening fence to include a language (use ```text) and ensure there
is exactly one blank line immediately before and after each fenced block, and
normalize closing fences to ``` so the MD031/MD040 lint rules are satisfied.
| - Tailor one of the chains specifically to code review, product design, or TTRPG campaigns, or | ||
| - Turn the MCP concept into a concrete JSON/OpenAPI-ish tool schema. |
There was a problem hiding this comment.
Remove the dangling “or” in the closing options list.
Line 737 ends with “, or” before the next bullet, which reads as an incomplete construction in the rendered doc.
Suggested wording fix
-- Tailor one of the chains specifically to code review, product design, or TTRPG campaigns, or
+- Tailor one of the chains specifically to code review, product design, or TTRPG campaigns, orIf you prefer cleaner style, remove “or” from the first bullet and keep it implied by list structure.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Tailor one of the chains specifically to code review, product design, or TTRPG campaigns, or | |
| - Turn the MCP concept into a concrete JSON/OpenAPI-ish tool schema. | |
| - Tailor one of the chains specifically to code review, product design, or TTRPG campaigns | |
| - Turn the MCP concept into a concrete JSON/OpenAPI-ish tool schema. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@archivist/undead-archivist.md` around lines 737 - 738, Remove the dangling “,
or” at the end of the first bullet in the two-item list that starts with "Tailor
one of the chains specifically to code review, product design, or TTRPG
campaigns," and the following bullet "Turn the MCP concept into a concrete
JSON/OpenAPI-ish tool schema."; specifically edit the first bullet to drop the
trailing ", or" (leaving the list to imply the alternative) so the list reads
cleanly.
| --- | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Remove duplicate horizontal separator for cleaner Markdown structure.
Two consecutive --- separators add noise without semantic value. Keep one.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@berserker/Berserker_BERSERKER_CODEX.md` around lines 322 - 323, Remove the
duplicated horizontal rule in the Markdown by deleting one of the consecutive
'---' lines so only a single separator remains; locate the duplicate in the
Berserker_BERSERKER_CODEX.md section where two consecutive '---' separators
appear and remove the extra line to keep a single horizontal rule for cleaner
structure.
| ### ⚔ CHAIN IV: THE BATTLEFIELD SURVEY (SoT Protocol) | ||
|
|
||
| **Activate when:** A bug report involves multiple symptoms, multiple suspected components, | ||
| or multiple developers reporting different manifestations of what may be the same root cause. | ||
|
|
||
| **Full SoT Protocol:** | ||
|
|
||
| ``` | ||
| # STAGE 1 — BATTLEFIELD SKETCH | ||
|
|
||
| You are the Undead Berserker. | ||
|
|
||
| The report before you involves multiple symptoms across multiple components. | ||
| Before you execute a single shard, produce the Battlefield Sketch: | ||
|
|
||
| Given the following symptoms: | ||
| [PASTE: error messages, stack traces, affected components, observed behaviors] | ||
|
|
||
| Generate the skeleton — 4 to 8 independent investigation fronts: | ||
|
|
||
| FRONT 1: [domain / component] — [one-line description of the suspected fault] | ||
| FRONT 2: [domain / component] — [one-line description] | ||
| FRONT 3: [domain / component] — [one-line description] | ||
| ... | ||
| FRONT N: [domain / component] — [one-line description] | ||
|
|
||
| For each front, declare: | ||
| → INDEPENDENT: can be investigated without results from other fronts | ||
| → DEPENDENT ON [N]: cannot begin until front N produces its finding | ||
|
|
||
| Then: identify which fronts can be expanded in parallel (no inter-dependency). | ||
| Mark these: [PARALLEL ELIGIBLE] | ||
|
|
||
| Total elapsed time for the sketch: under 90 seconds. | ||
| The Berserker does not linger in the sketch. Structure is not analysis. | ||
| ``` | ||
|
|
||
| ``` | ||
| # STAGE 2 — PARALLEL EXPANSION | ||
|
|
||
| For each PARALLEL ELIGIBLE front, apply the standard shard sequence independently: | ||
|
|
||
| FRONT [N] EXPANSION: | ||
| SHARD 1: Identify exact error location | ||
| SHARD 2: Dissect the stack / execution path | ||
| SHARD 3: Form the hypothesis | ||
| SHARD 4: Identify the negative exemplar (what NOT to do) | ||
| SHARD 5: Produce the patch | ||
| SHARD 6: Verify the fix | ||
|
|
||
| [FRONTS with DEPENDENT relationships are expanded in sequence | ||
| only after their dependencies have returned findings.] | ||
|
|
||
| When all fronts complete: | ||
| → Cross-reference findings: do any fronts share a common root? | ||
| → If yes: one patch may close multiple fronts | ||
| → If no: each front produces an independent ritual law | ||
| ``` |
There was a problem hiding this comment.
SoT protocol promises runtime capabilities not reflected in current MCP tool interfaces.
The specification describes front labeling, dependency declarations, and parallel-eligible orchestration as protocol outputs, but current tool contracts do not expose fields for that workflow (berserker/Berserker_mcp-server_src_tools_scan.ts:52-85, berserker/Berserker_mcp-server_src_tools_analyze.ts:42-76). This creates a doc/runtime mismatch and can mislead users about what is automated versus manual.
Please either:
- add explicit schema/session support for fronts + dependency metadata in tools, or
- narrow this section’s wording to clearly state this is operator-guided methodology, not MCP-native orchestration yet.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@berserker/Berserker_BERSERKER_CODEX.md` around lines 355 - 412, The doc
describes automatic front labeling/dependency orchestration that the current MCP
tool interfaces (see Berserker_mcp-server_src_tools_scan.ts and
Berserker_mcp-server_src_tools_analyze.ts around the tool handler functions) do
not support; either implement explicit session/schema fields (e.g., add a
Front[] type with id, description, dependencies, parallelEligible to the tool
contract and wire it through the scan/analyze handlers and their
payload/response types) or revise this CHAIN IV section to state it is an
operator-guided methodology (remove wording implying MCP-native orchestration
and add a short note that tools currently return only raw findings and require
an external orchestrator to label fronts/dependencies).
2 participants
Summary
This PR introduces the Skeleton-of-Thought (SoT) methodology as a primary doctrine across all Undead Legion codices. SoT is a two-stage synthesis protocol that separates structure discovery from detail expansion, enabling parallel execution of independent tasks and reducing time-to-first-deliverable on complex, multi-component work.
Key Changes
New Documentation
bard/workflow-skeleton-of-thought-chronicle.txt(added): Complete workflow guide for applying SoT to documentation generation, including two-stage parallel expansion for independent documentation units and release notes generation.Codex Updates
Architect Codex (
architect/ARCHITECT_CODEX.md)Dragon Codex (
dragon/DRAGON_CODEX.md)Archivist Codex (
archivist/undead-archivist.md)Berserker Codex (
berserker/Berserker_BERSERKER_CODEX.md)Hexweaver Codex (
hexweaver/roles-hexweaver.md)Hound Codex (
hound/HOUND_CODEX.md)Warlock Codex (
warlock/WARLOCK_CODEX.md)Bard Codex (
bard/BARD_CODEX.md)Implementation Details
Core SoT Pattern
All implementations follow the same two-stage structure:
https://claude.ai/code/session_01AL3cSuSU4GMhhkVDR5Di52