The Sidebar Unification: Links, My Tools, Sidebar Lessons, Cheat Sheets

Claude Rules Workflow

Chapter 6 · The Sidebar Unification: Links, My Tools, Sidebar Lessons, Cheat Sheets

Everything so far in this course has covered rule families that stayed roughly the same shape once written. Sidebar is the opposite kind of example — a real case where the rules system itself got reorganized, twice, in the space of a single day, and the reorganization actually held up once the site's own routing was rebuilt around it. It's the clearest example in this whole course of a rules system being revised, not just extended.

SB1 — Four Content Types, One Folder Tree

"Sidebar" is a top-level content category for everything that doesn't fit the numbered-course model at all — no fixed chapter count, generated one page at a time, on demand. Four genuinely different content types live under it, sharing one content/sidebar/<subject>/ tree:

Links
A curated link collection for one topic — Documentation/Downloads/Free Courses/LinkedIn Learning
My Tools
A self-contained interactive HTML tool, built from a YAML spec file
Sidebar Lessons
A standalone, topical deep-dive — too substantial to skip, too narrow for a full course
Cheat Sheets
A compact, printable, scannable quick-reference page — commands and syntax, not prose

Browsing Sidebar for a given Subject is meant to surface a link collection, a tool, a lesson, and a cheat sheet all in one place — rather than four separate top-level sections a visitor has to already know exist independently.

Links (LN1–LN9) and My Tools (MT1–MT9), Briefly

Links pages follow a real research workflow: check the user's own running scratchpad file first, then search the web section by section (Documentation, Downloads, Free Courses, LinkedIn Learning), never fabricating a URL that hasn't actually been confirmed. My Tools pages work completely differently — the spec is a YAML file, not a web search, describing exactly what the tool should do, and the whole page has to be a self-contained fragment with every CSS rule scoped under its own wrapper class, after a real leak bug (unscoped selectors bleeding into the rest of the page once injected) was found and fixed in an early tool.

SB2 — The Banner Format, Revised In Place

Every Sidebar page originally used the same Course:/Chapter: banner shape as a numbered course — Course: Links, Course: My Tools, Course: Sidebar. It worked, but it was never really true: none of these are courses. SB2 replaced it with a shape that actually describes what the content is:

<!-- ============================================================ Category: Sidebar Subcategory: <Subject, Title Case> Chapter: <Page Title, Title Case> File: <filename>.html Date Created: ... Date Updated: ... ============================================================ -->

Category is always literally "Sidebar." Subcategory is the piece that was missing before entirely — the page's own Subject — even though that Subject already silently determined the file's folder path the whole time.

This change was applied retroactively — a deliberate exception
Most banner-format changes on this site are explicitly not retroactive (P1's own default). This one was different: with only five existing Sidebar pages in scope at the time, every one of them was updated to the new banner in the same session the new format was decided — a real, documented exception made because the cost of updating five files was genuinely small next to the benefit of the whole category being internally consistent from that point on.

Sidebar Lessons (SB3–SB5) and Cheat Sheets (SB6–SB8)

A Sidebar lesson (sidebar: <topic>) is a standalone deep-dive, deliberately required to cross-reference existing courses honestly rather than presenting overlapping material as entirely new. A cheat sheet (cheat sheet <topic>) is a genuinely different shape, not a lesson in miniature — a grid of category cards with dense command — description rows, no prose intro, no closing summary, since the whole page already is the summary. Cheat sheets are deliberately a plain-English prompt rather than a formal skill, since picking which commands actually matter is judgment, not a fixed mechanical pipeline.

SB10 — A Bet That Actually Paid Off

The entire Sidebar reorganization was made on a specific bet: that structuring the on-disk folders by Subject now would let a rebuilt site automatically generate real navigation later, without ever hand-maintaining a table-of-contents page per Subject. SB10 confirms that bet actually paid off — once the site's own routing was rebuilt, content/sidebar/<subject>/ folders started auto-generating a real, working index page listing everything under that Subject, with zero manually-written index file anywhere.

A genuinely verified outcome, not just an assumption written down
It would have been easy for this rule to just assert "the folder structure will pay off later" and leave it there. Instead, once the rebuild actually happened, someone went back and confirmed it directly against the real, live routing behaviour — and only then was SB10 updated to say "confirmed working," not just "expected to work." That's the same evidentiary standard Chapter 1's own R1-deprecation finding and Chapter 5's own broken-back-link finding both apply: a claim about the system gets checked against what's actually true, not left as an assumption.

SB11 — One Shared Tracking File, Not Three

Before the unification, Links, My Tools, and the one-off Sidebar lesson each had their own separate tracking file. SB11 merged all three into one shared sidebar-pages.md, logging every page across all four content types — topic/tool/lesson/cheat-sheet name, Subject, file path, creation date, and every update date — updated in the same step a page is generated, exactly matching P7's own never-deferred discipline from Chapter 3, just applied one level down to a single tracking file instead of the whole completed-courses/bucket-list pair.

Coding Challenges

Challenge 1

Explain why SB2's banner change was applied retroactively to all five existing Sidebar pages, when P1 itself explicitly says banner changes normally aren't retroactive. What made this case different?

📄 View solution
Challenge 2

A user asks for a cheat sheet on a topic. Explain, using SB7, why the resulting page should NOT include a set of Hands-On Exercises or a closing Quick Reference box, even though those are standard parts of a Sidebar lesson.

📄 View solution
Challenge 3

Explain what SB10's own "confirmed working" note is actually claiming, and why that's a stronger, more useful statement than the original folder-structure decision alone would have been.

📄 View solution

Chapter 6 Quick Reference

  • Sidebar unifies four content types — Links, My Tools, Sidebar Lessons, Cheat Sheets — under one content/sidebar/<subject>/ tree
  • Links (LN1–LN9) — real web research, never a fabricated URL
  • My Tools (MT1–MT9) — YAML-spec-driven, every CSS rule scoped to its own wrapper class
  • SB2 — the Category:/Subcategory: banner replaced the old Course:-based one, applied retroactively as a deliberate, documented exception
  • Sidebar Lessons (SB3–SB5) vs. Cheat Sheets (SB6–SB8) — genuinely different shapes, not a lesson in miniature
  • SB10 — the folder-structure-predicts-live-routing bet, later verified true, not just assumed
  • SB11 — one shared sidebar-pages.md tracking file, merged from three, updated in the same step every time
  • Next chapter: the tracking files themselves — completed_courses.md, course_bucket_list.md, and the P7 discipline that keeps them honest