A running log of substantive Claude Code turns in this
repository, per §12 of CLAUDE.md — kept here instead of on
the index page because it only grows. Newest first.
Move the growing session-log Artifact out of
index.html onto its own page in the same domain, linked
from the index, and evaluate a left sidebar nav for the site's
pages.
Split the log out to this file, cl-log.html,
published at the site root alongside index.html and
linked from it. It's the actual §12 Artifact mirror — self-contained
(inline styles, no shared stylesheet) because a claude.ai Artifact
can't consume an external CSS file or keep a `<head>` of its
own, so byte-identical parity between the published Artifact and
this file only works if the file has no outside dependencies.
site/build.py now copies it into dist/
unmodified, and the deploy workflow's trigger paths include it.
The old inline demo entry on the index page (a synthetic "how do I
open a session" example) moved here instead, as the log's founding
reference entry, since it was never a real conversation turn.
On the sidebar: recommended against one for now — two pages don't justify a persistent rail, and it would immediately eat back into the horizontal room a previous turn widened the layout to get. A lightweight top nav (a couple of text links near the masthead) fits a small, growing-by-pages-not-by-count site better; revisit a sidebar if the page count grows meaningfully.
Add an instruction that commit messages should follow the Conventional Commits convention, per a linked gist.
Added to CLAUDE.md §11: the
<type>(scope)!: description format, the type
enum (feat/fix/refactor/perf/style/test/docs/build/ops/chore),
the rule against issue IDs as scopes, imperative-present /
no-capital / no-period description rules, and the
! + BREAKING CHANGE: footer for breaking
changes — with a carve-out to use exact user-supplied message text
verbatim rather than reformatting it.
The "Setting up a new project" intro paragraph doesn't fit the page width, and the repo link above it is barely visible — fix both.
The faint link was a real bug: the decorative grid's fade-out
was implemented as a mask-image on the whole
header.masthead element, which masks everything
painted inside it, not just its own background — so real content
lower in the header (the repo link) was fading out along with the
grid pattern, which was only ever meant to fade. Moved the grid
and its mask onto a ::before pseudo-element behind
the content, so only the decoration fades and the content stays
fully opaque. The intro paragraph had a leftover
max-width: 38ch from before the page was widened;
removed it so it inherits the section's 42rem measure like every
other paragraph.
Consider adding a light/dark theme toggle button, and consider giving the page more horizontal room — the margins feel too big.
Widened the page column from 42rem to 52rem, and capped body
prose (paragraphs, list items, log-card answers) at 42rem
separately, so line length stays readable while code blocks and
cards get to use the extra width. Added a small fixed circular
button (☾/☀, top-right) that overrides the OS-driven theme via a
data-theme attribute on <html>,
persisted in localStorage — the token system already
supported both themes from the start, so this only needed the
actual switch.
The deployed site's intro paragraph looks faded and hard to read, and the inline code chips are barely readable — fix.
The intro paragraph (.dek) used the same muted
--ink-soft tone as footer/meta text, at a size where
that read as washed out; switched to full --ink. The
inline code chips used --accent-soft as background,
which in dark mode is barely lighter than the page background
itself — good text-to-chip contrast, but almost no chip-to-page
separation, so the chip read as a blur even though the text
inside it was legible on its own. Restyled inline code to match
the already-legible pre block treatment:
--paper-raised background, a visible
--rule border, full-strength text.
Rewrite the README so users can deliberately decide public vs. private, document how to set up the Pages automation (prompting Claude counts as valid instructions here, since this is an AI-assisted template), and call out the free-tier limitation of a public Pages site on a private repo.
Step 6 now frames public/private as a real decision: default
private, treat flipping to public later as effectively one-way
(anything ever pushed public may already be mirrored), and
cross-references step 7's caveat before deciding. Step 7 rewritten
to document the actual Actions-based pattern from this repo as a
reference implementation, gives a copy-pasteable prompt for
delegating the setup to Claude Code in a new project rather than
only listing raw commands, and leads with the limitation that
Pages sites are always public on personal GitHub accounts
regardless of the source repo's visibility. Rebuilding surfaced a
second Python-Markdown quirk: fenced code blocks nested inside a
list item get mis-parsed as one inline <code>
span, because the two triple-backtick fences get read as matching
inline-code delimiters once list-continuation indentation defeats
the fenced-code extension — restructured that list so the
commands sit outside it, rather than working around the parser.
Configure GitHub Actions so the docs site
updates automatically whenever a relevant file changes on
main.
Two design choices settled the shape: native GitHub Actions
Pages deployment (build_type: workflow) instead of
committing built output to the gh-pages branch, and
generating the setup steps straight from README.md's
markdown rather than hand-styled callouts, so there's nothing to
keep in sync by hand. Moved the site source onto
main: site/template.html (shell) +
site/build.py (renders README.md's
## steps into the shell via Python-Markdown) +
.github/workflows/pages.yml (push-to-main trigger,
path-filtered, deploys via
actions/configure-pages +
actions/upload-pages-artifact +
actions/deploy-pages). Found and fixed a real bug
while verifying the build: Python-Markdown, unlike GitHub's own
renderer, won't parse a bullet list that immediately follows a
paragraph without a blank line between them — fixed the
formatting inconsistency directly in README.md rather
than working around it in the build script. Switched the repo's
Pages source to build_type=workflow via the API,
pushed, first workflow run succeeded.
Follow README step 7 to publish a browsable GitHub Pages site for this repo, and generate a template Artifact page per §12 to show on it.
Steps 1–6 were already done (repo public, gh
authenticated), clearing step 7's only guardrail. Built a
self-contained index.html in a documentation
register — system serif/sans/mono type trio, muted pine-green
accent, hairline rules, a graph-paper masthead nodding at
"scaffold" — rendering the README's setup steps plus a §12-format
example log entry. Deployed via an orphan gh-pages
branch pushed through a throwaway git worktree, so
main stayed untouched throughout; enabled Pages via
gh api and set the repo homepage. First version went
live at
ntorresd.github.io/cl-project-template.
Once a project has a CLAUDE.md
in place, how do I actually start a Claude Code session against
it?
VS Code extension. Open the project folder in
VS Code, then either install "Claude Code" from the Extensions
Marketplace directly, or run claude in VS Code's
integrated terminal — it offers to install the companion
extension automatically. Once installed, the extension reads
CLAUDE.md from the project root as context for every
session opened against that folder; no separate loading step is
needed.
JetBrains plugin. The same "Claude Code" plugin is published to the JetBrains Marketplace for IntelliJ-family IDEs, with the same CLAUDE.md-on-open behavior.
CLI. Run claude from a terminal
inside the project directory — editor-independent, and what the
IDE extensions wrap under the hood.
Desktop or web app. The desktop app (Mac/ Windows) and the web app at claude.ai/code cover the same workflow for projects pushed to a connected GitHub repository.