Chaining Claude Code Skills for Web Design: 3 Runs Compared

I’ve redesigned the blog and checked it in screenshots at 1440px and 390px, in light and dark mode: home, article, category, Books, About and 404. hugo -D builds with no errors or warnings. Nothing is committed.

The live site was still using the old compiled assets/css/index.css. The SCSS added in the last commit (“Time in the margin”) was never connected to the templates. I replaced that SCSS and pointed the templates at it, so styles now compile from assets/scss/main.scss.

The idea. Your About page says you started out building a pseudo-graphics GUI for Clarion in C and Assembler. So code blocks now look like old text-mode editor windows: a deep blue background, a double line across the top, the language name set into that line like a window title, and [ Copy ] at the right. That’s the one bold element. The rest is a white page with one blue for links, code and the footer. Amber appears only on blue surfaces and in text selection.

• Type: Atkinson Hyperlegible Next for text and headings, Atkinson Hyperlegible Mono for code. It’s built to keep look-alike characters like l 1 I and 0 O apart, which suits a site with this much code. The zero has a slash, so dates show it too.
• Home: the newest post is first, set large with its description and cover. Older posts are plain rows with title, category, date and description. The white cards with share toggles are gone.
• Article: large title, cover, text kept to about 68 characters per line. Code and images can run wider than the text. On wide screens the table of contents stays fixed on the right and highlights the section you’re reading. On phones it’s a collapsed box above the text.
• Right column (labels, GitHub, gists, codepens): all kept, set small in dark text so it doesn’t compete with the post.
• Dark mode follows the reader’s system setting.

Brand changes#

• I kept the {D:S} mark but set it in the mono font with blue braces.
• I dropped the copper. #D48166 on white is 2.9:1 contrast, which is too low for link text. Copper on a light page is also the most common look on generated sites right now.
• The navigation is sentence case now, not uppercase Oswald, so it fits on a phone without the menu button.

Other changes#

• In config.toml I set markup.highlight.noClasses = false, so the code colours come from my SCSS. The old github-dark inline colours no longer apply.
• I added three bits of text: a “Books” heading on the Books page, a “Share” label next to the share icons, and “N posts” under the title on category and tag pages. The /categories/ and /tags/ pages used to show “Taxonomy terms” as placeholder text. They now list every term with its post count.
• I left assets/css/index.css and assets/css/syntax.css in place. Nothing uses them now, so you can delete them.

The redesign is done for all five page types: home, article, category/tag listing, About and Books. The 404 page and footer got the same treatment. I checked every page at 1440px and 390px in screenshots, and hugo -D builds without errors. Nothing is committed.

What changed#

• Home: the newest post is the one focal point. Its title, date, description and cover are all on the first screen, and the next post’s title shows above the fold on a 1440×900 screen. Older posts are plain text rows (title, date, category, description). The old cards with big screenshot thumbnails are gone.
• Article: no white card around it. Big headline, meta line, then the cover. Prose is set at about 70 characters per line, and code blocks and images use the full column width. The table of contents sits in a sticky right column on wide screens and highlights the section you’re reading. On phones it becomes a collapsed “Contents” box.
• Right column (Labels, GitHub, gists, codepens, Contacts, Reading shelf): all kept, but small and muted so it doesn’t compete with the article. On phones it moves below the content.
• Type: Instrument Sans for headings and UI, Source Serif 4 for body text, IBM Plex Mono for code only. Sizes come from one scale: 14/16/18/21/24/36/48px.
• Colours: white page, charcoal text. The header, footer and code blocks share the brand charcoal, so code reads as part of the brand. Code keeps the GitHub-dark syntax colours, with a copper left edge on each block.
• Dark mode follows the visitor’s system setting. It’s an addition you didn’t ask for, and easy to remove if you don’t want it.

Brand changes, and why#

• Logo: {D:S} and the Oswald name are unchanged.
• Links on white use a deeper copper, #A14E31. Your #D48166 on white is 2.9:1 contrast, which fails accessibility guidelines for text. It’s 5.75:1 for the deeper shade. #D48166 is still used on dark surfaces: logo braces, the active-nav bar, the code edge, the cookie button.
• Navigation is sentence case instead of Oswald capitals. It fits on a phone without the burger menu, so the burger is gone.
• Removed (chrome, not content): the share widget and “comments” link on every card in the list. Share links and comments are still on each article.

Copy: no new text. The only wording changes: list descriptions are cut at about 240 characters, and the tag page heading is the tag name (#Next.js). It had no heading before.

Things to know#

• I replaced the files in assets/scss/. They were a cobalt/yellow attempt that nothing loaded. The site now compiles scss/main.scss. The old assets/css/index.css and _design/ are unused but still on disk, so delete them when you’re happy with this.
• assets/js/site.js (contents scroll-highlight, copy button on code blocks, back-to-top) was also unused. It’s loaded now.
• content/_index.md has draft = true, so the home page only exists when you build with -D. Your npm scripts already pass -D, but plain hugo server shows a 404 on the home page.
• The puppetry image in the GitHub list showed as broken in my test browser. That looked like a network limit in my sandbox, not the page, but check it on the live site.

Claude: First question: the last time you read one of your own posts on the live site, what was the first thing that felt off, if anything?

Me: I realized that the overall visual design probably didn’t look as professional as I wanted it to.

Claude: “Not professional” can mean a few things. My guess is that it’s the parts that date the site: white boxed cards on a grey page, bordered copper chips, all-caps condensed nav, and a sidebar full of widgets. Together those read like a 2015 blog theme, not like the work of someone with 27 years in the field. Correct me if it’s something else.

Is there a developer blog or site you’ve read recently that felt professional to you, and what about it gave you that impression?

Me: I like the overall look and feel of Medium publications, as well as sites like Smashing Magazine, Cloudflare Blog, Martin Fowler and DEV Community.

What I appreciate about them is their clean, professional presentation, strong typography, clear content hierarchy and focus on readability. They make technical content feel approachable without being visually boring or overly decorative.

I particularly like the editorial feel of Medium, the polished presentation of Cloudflare’s blog and the technical depth and straightforward structure of Martin Fowler’s site.

Claude: Why the redesign: The site works, but it doesn’t look as professional as you’d like. “Professional” for you is the feel of Medium, Smashing, Cloudflare’s blog, Martin Fowler and DEV: clean presentation, strong typography, clear hierarchy, readability first. Technical content should feel approachable, and the site shouldn’t turn plain or decorative to get there.

What those sites have in common (my reading, not something you said):

• On article pages there’s no sidebar, or one so quiet you stop noticing it. Medium, Cloudflare and Fowler all run a single centred column of about 680–740px.
• Body text is near-black at 18–21px. None of them use grey body copy.
• Chrome is minimal. Hairline rules replace boxes and borders, and the article title is the biggest thing on the page.
• Listing pages split into two camps. Cloudflare and DEV use image-led cards. Fowler and Medium use text-led lists where the title and summary do the work.

Three different pulls (also my reading). Medium is editorial, with a serif body and lots of air. Cloudflare is polished product-blog: a sans-serif, crisp and image-heavy. Fowler is a working document: dense, structured, text-first. I think these are the raw material for genuinely different directions, not one template with tweaks.

What this implies for your site (my guess): the white cards, the bordered chips and the widget sidebar are what work against “professional”. Copper and the dark header aren’t the problem.

What’s wrong or missing in that?

Me: I totally agree with your assessment.

Claude: Good, so the boxes, chips and widgets are what we’re fixing. Copper and the dark header stay.

When someone finishes one of your articles, what would you like them to do next?

Me: I’d like them to continue reading by going to a related article in the same series or on a closely related topic. Ideally, the site should make the next relevant article obvious and encourage readers to explore more of the content rather than just reaching the end of the page and leaving.

Claude: Got it. One thing I checked: no post carries series metadata. Four old Drupal/realtime posts link to related articles by hand in their body text, and that’s all. So “the next relevant article” would come from Hugo’s built-in related-content feature, matching on tags and categories. It’s a template change only, with no content edits and no new dependency.

How do you feel about the cover images on your posts: are they part of what makes a post yours, or decoration you could live without on the listing pages?

Me: I’m a bit undecided about this. Personally, I find cover images useful because they attract attention and give readers a visual impression of an article before they start reading. However, I’m not a designer or artist, so most of my current cover images are AI-generated. I’m concerned that this might actually put some readers off or make the blog look less professional.

Claude: This might be easier if I show you. Want me to open a browser tab with some mockups?

Me: Sure!

Claude: The mockup screen is up (a local browser tab). It shows your four latest posts, with real titles, descriptions and covers, in three treatments. Only the image handling changes between them:

• A. Image-led: a big cover on the latest post, then an image grid. This is how Cloudflare and DEV do it.
• B. Thumbnail: text leads and the cover is a small picture on the right. This is the Medium approach.
• C. Text only: no images on listing pages, like Martin Fowler’s site. Covers appear only on the article page and in social previews.

One data point: 56 of your 93 covers are credited to an AI generator (DALL·E, Gemini, ChatGPT or Grok). Another 19 have an empty credit field.

Take a look, and click one if it helps. Which of these treatments feels closest to how you want the blog to come across?

Me: I’ll go with C. Text only. I’m concerned that the AI-generated cover images might put some readers off rather than attract them. I’d prefer a clean, typography-driven presentation where the article titles and descriptions do the work of attracting attention.

Claude: The three directions are on the same tab, so just refresh it. Each one shows the home page and an article, using your real posts. All three keep {D:S}, the charcoal header, copper, text-only listings, and no sidebar on article pages.

• Editorial (Medium, Smashing). Serif body at about 20px, one centred column on every page, lots of white space. The header is a slim band, and copper shows up only on category links and the active nav item. It’s the calmest and most bookish of the three.
• Index (Martin Fowler). Sans body at 18px, with monospace for dates, categories and nav, which picks up the code-brace look of {D:S}. Home is a dense dated index. Articles get a sticky “Contents” rail on the left, which pays off on your long posts (one has 22 sections). It fits the most information on a screen and has the least decoration.
• Masthead (Cloudflare blog). The charcoal header grows into a band that carries the newest post on home and the title on article pages, with a copper category label above it. Everything below is a crisp white page in a modern sans. The rest of the home page is a two-column grid of text tiles. It has the strongest brand presence.

I’m not ranking them yet. Judging the directions is the taste step, and I’ll do that once you’ve reacted.

Which one feels most like your blog, and is there anything you’d pull across from the others?

Me: I choose 3. Masthead

Claude: Grilling round 1. These are the decisions I can put to you now. Each one has my recommendation, and “yes” accepts it. Where I think you’re wrong, I’ve said so.

❓ Q1 - Masthead on the home page vs. “no hero”: You asked that nothing push the latest article down. A dark band holding the newest post is fine on desktop, because the article itself is the content there. At 390px, though, a band with title, description and meta fills most of the first screen, so the second post drops below the fold. I’d accept that, but only if the band stays tight. On home it gets the category, the title, the description clamped to 3 lines and the meta, with no extra padding. Pages 2+ of the pagination get a slim header with no masthead.

➡️ Yes: tight masthead on page 1 only, description clamped to 3 lines. At 1440px the first row of tiles must be visible without scrolling.

❓ Q2 - “Don’t invent copy” vs. a related-articles block: You want readers to see the next relevant article. That block needs a label, and that runs into your no-new-headings rule. The way out: the phrase “Related articles” already appears in the content of four of your posts. I’d reuse it, and not write anything like “You might also like”.

➡️ Yes: label the block “Related articles”. It shows 3 posts picked by Hugo’s built-in related-content feature (matching tags and categories), placed after the article body and before Previous/Next and comments.

❓ Q3 - Where the sidebar content goes: Removing sidebars shouldn’t delete anything. Here’s what lives in them today and where I’d put it:

• Labels (category chips, on home, listings and 404): a plain list in the footer, not chips.
• Contents (TOC on articles): see Q4.
• My github / My gists / CodePen (home, listings, Books): moved to the bottom of About.
• Contacts + My Reading Shelf (About): they stay on About, as a second column on desktop and below the CV on mobile.

➡️ Yes to all four moves.

❓ Q4 - Contents on long articles: Cloudflare has no TOC. Your posts run to 22 sections, though, and the current site shows “Contents” in the sidebar. I’d keep it in two forms. At widths of 1200px and up, it’s a sticky list in the left margin beside the body: small grey text that stays quiet. Below 1200px, it’s a collapsed “Contents” disclosure above the first paragraph. Either way it only appears when the post has headings, which is the current rule.

➡️ Yes: margin TOC on wide screens, collapsed disclosure on narrow ones.

❓ Q5 - Copper contrast (a brand change, here’s the reason): Your copper #D48166 reaches only 2.9:1 on white and 3.9:1 on charcoal. That fails WCAG AA for normal-size text in both places, so it can’t stay as the link and label colour. I’d split it into three tones that read as one family:

• Logo stays #D48166. A logo is exempt from contrast rules.
• Bright copper on charcoal for the masthead kicker and the active nav item, lightened until it reaches at least 4.5:1.
• Deep copper on white for links and tile kickers, darkened until it reaches at least 4.5:1, aiming for about 5.5.

➡️ Yes: three copper tones, with exact values and ratios in the spec.

❓ Q6 - Typefaces: The mockup used Figtree. My recommendation is Figtree for headings and body, IBM Plex Mono for code, and Oswald kept only for the {D:S} logo. Oswald + Open Sans + Lora go away, so the font payload drops. Fonts keep coming from Google Fonts the way they do now, so there’s no new dependency. Body text would be 18px with 1.7 line height, a measure of about 68 characters, and near-black on white.

➡️ Yes to Figtree + Plex Mono + Oswald for the logo only.

❓ Q7 - Cover image on the article page: Here I’m pushing back on the choice you made. You dropped covers from listings because AI art might put readers off. On the article page the cover is the first thing a reader sees after the title, so the same worry applies there, just one click later. Removing covers counts as a content change, which you ruled out. So I’d keep them, sized to the text column (not full width), and keep the “Image generated by…” credit as it is today.

➡️ Yes: keep covers at column width, with the credit.

❓ Q8 - Tile descriptions on home: Your descriptions run from one line to about 320 characters. In a two-column grid that makes the rows ragged. I’d clamp tile descriptions to 3 lines with CSS. The full text stays in the HTML for SEO, and nothing is rewritten.

➡️ Yes: 3-line clamp on tiles. One column below 700px.

❓ Q9 - Tag and category pages: Today, categories show Items in category <b>name</b> and tags show no heading at all. In the masthead style, the term name becomes the title. For the kicker I’d use the single words “Category” or “Tag” plus the post count. These are labels, not new copy, and “Items in category” goes away.

➡️ Yes: kicker “Category” or “Tag” plus the count, term name as the masthead title, then the same tile grid.

❓ Q10 - Out of scope: To keep this pass focused, I’d leave out dark mode (the site doesn’t have one today), search and comments, and the behaviour of the cookie bar. The cookie bar gets restyled to match and made more compact, but its logic in enhancement.js doesn’t change.

➡️ Yes: all four stay out of scope, apart from restyling the cookie bar.

Me: Yes, proceed with this recommendation.

Claude: All ten are settled. Round 2 covers the decisions those answers opened up.

❓ Q11 - Footer: The footer keeps all its current content: “Who’s the dude?” with your photo and line, “Elsewhere”, “Credits” and the copyright row. Per Q3 it also gains the Labels list. I’d make it the same charcoal as the masthead so the page has a dark band at the top and the bottom. Small 15px text, deep layout grid on desktop, stacked on mobile.

➡️ Yes: charcoal footer, same content plus Labels.

❓ Q12 - About and Books get the slim header, not a masthead: The masthead works where a page has a natural title: an article, the newest post, a category. About already opens with “Dmitry Sheiko / Senior Full-Stack Web Developer” inside the content. Books has no title at all, and its focal point is the three real book covers, which aren’t AI art. A masthead there would mean inventing a heading or repeating the first one. So those two pages get the slim charcoal header, and the content starts on white. On Books, each book is a row with the cover on the left and the text on the right, stacking on mobile.

➡️ Yes: slim header on About and Books, book rows on Books.

❓ Q13 - Code blocks: Code is all over your posts. I’d set code-block backgrounds to the masthead charcoal and keep your existing github-dark syntax colours from config.toml. Code would be 15px Plex Mono with horizontal scroll and no wrapping, and inline code gets a light warm grey chip. The dark blocks then rhyme with the masthead and don’t look like a foreign widget.

➡️ Yes.

❓ Q14 - Mobile nav: Today, phones get a burger menu (a checkbox hack) for just three links plus RSS. At 390px, “Blog Books About me” and the RSS icon fit on one line next to {D:S}. I’d drop the burger so every link is one tap away and visible.

➡️ Yes: no burger, inline nav at every width.

❓ Q15 - Order of the article footer: After the body I’d use this order: the share links (as today), then Related articles (3 posts), then Previous / Next, then comments (giscus). Related articles comes before Previous / Next because it’s the thing you said you want readers to take.

➡️ Yes to that order.

❓ Q16 - Repo cleanup: The new styles go in assets/scss/ and are compiled with Hugo toCSS, which replaces the unwired “Time in the margin” SCSS that’s in there now. header.html stops loading assets/css/index.css, and I’d delete that file. I’d also delete the orphan partials from that earlier attempt (article-lead, post-list, term-page, cover, icon, image-credit) if nothing references them after the build. The README’s styling paragraph gets corrected. _design/ stays untouched, because it still builds static/build/enhancement.js, which handles lazy-load, zoom and the cookie bar.

➡️ Yes: replace and delete as described, and leave _design/ alone.

Me: Yes, proceed with this recommendation.

Claude: I read taste-skill (design-taste-frontend 2.5.1). It’s built for company landing pages: a hero alone on the first screen, one section per screen, photographs, motion “moments”, shader effects, and copying its starter kit into the project. A lot of that directly contradicts your brief (content first, no hero, no invented copy, no new dependencies). It also says “deal, never choose by taste”, which would have its scripts override the direction you picked. I’m applying only the parts that work as review criteria: whether it looks made for this client or from a template, one consistent system, equal edges, contrast, focus and tap sizes, and the “no caption under images” rule. Its kit and scripts stay out of the repo.

Judging the three directions#

• Strongest identity: 2, Index. Monospace dates and categories echo the {D:S} braces. A dated index suits 93 posts spanning 2003–2026, and the contents rail fits how you actually write: long, sectioned posts. It reads as one specific engineer’s site.
• Strongest brand presence: 3, Masthead, your pick. The charcoal band is earned, because it turns your existing header into structure rather than adding decoration. But two parts are generic:
  • The tiles. An uppercase letter-spaced kicker over a 3px top rule is the stock tech-blog tile. You see it on half the corporate engineering blogs out there.
  • Figtree. It’s pleasant but it’s the 2024 default sans. Nothing about it says “you”.
• Most generic: 1, Editorial. A serif body in a centred column on warm white is what every Ghost or Medium-style theme ships. It’s calm, and nobody would remember it.

What the judge would change in Masthead#

1. Monospace for meta. Kickers, dates and reading time go in IBM Plex Mono, which you’re already loading for code, set in sentence case rather than spaced-out capitals. That’s Index’s best trait at no extra cost.
2. A headline face with more character. Schibsted Grotesk is a grotesk drawn for a newspaper group, which suits a masthead. It would cover headings and body, with Figtree dropped.
3. Move the “Image generated by…” credit. Taste-skill says credits don’t sit under pictures. For you there’s a sharper reason: a line announcing “DALL·E” right under the title amplifies exactly the AI-art worry you raised. The text stays, word for word, in the article footer next to the share links.
4. Equal edges. On article pages, the masthead title starts on the same left edge as the body column, not the page edge. On home, it starts on the tile grid’s edge.

Points 1 and 2 are visual, so I’ll put them side by side on the companion tab for you to compare.

The layout and colours are identical on both sides. Only the faces and the meta styling differ:

• Left (A): Figtree throughout, as mocked, with uppercase letter-spaced kickers.
• Right (B): the judge’s version. Schibsted Grotesk for headings and body. Kickers, dates and reading time are in Plex Mono, in sentence case. Dates switch to ISO format (2026-07-02), which suits monospace. That date format is a visible change, so it’s part of what you’re approving.

Both sides use a 1px tile rule instead of the 3px bar. The 3px bar was part of what read as stock, and I’d drop it whichever face you choose.

Do you take B, together with moving the image credit into the article footer and aligning the masthead to the column edges?

Me: I choose Left (A)

Claude: The taste pass on the spec found four things, all now fixed in the draft:

• Two button styles, shared by the cookie bar and the 404 page. Before, each had its own.
• Tap targets. Small links (kickers, tags, footer, TOC) get at least 24 by 24 px. Nav and buttons get 44 px.
• Heading outline. Home gets a visually hidden h1 using your existing site title, and Books gets a hidden “Books” h1. No heading level is skipped on any page.
• Button labels keep the sentence case they’re written in (“Go to the blog”), with no forced capitals.

Claude: The design spec is ready for your approval: docs/superpowers/specs/2026-11-13-masthead-redesign-design.md. It covers the concept, the type scale, the palette with contrast ratios, spacing, the pattern for each page, and the responsive rules. I haven’t committed it.

The Related articles block now always shows 3 posts, as you chose. These are the calls I made that you didn’t, so check them while reading:

• Taste changes, section 12 A–C:
  • The “Image generated by…” credit moves from under the cover to the article footer, same wording.
  • The masthead text lines up with the content edge below it.
  • Tiles use a 1px top rule instead of a 3px bar.
• Copper: #D48166 stays on the logo only. Text uses #E3977A on charcoal (6.0:1) and #A14B2B on white (5.9:1). The header charcoal goes from #373A36 to #2B2C2A.
• Home page 1: the masthead post plus 11 tiles, so the pagination URLs stay the same. The last row has one tile.
• No duplicate “Related articles”: five older posts already have a hand-written “Related articles:” line, and they skip the automatic block.
• /weblog/ gets the same treatment as home. _default/single.html (currently a stub) becomes the article template.
• Heading outline: a visually hidden h1 on home (your existing site title) and on Books (“Books”).
• Buttons and tap targets: one shared pair of button styles for the cookie bar and the 404 page. Small links get at least 24px tap targets, nav and buttons 44px.
• Ported styles: before index.css is deleted, the styles your content and enhancement.js depend on are carried over with the same class names.
• Fonts: Oswald 400 is added so the “DMITRY” line in the logo doesn’t change.

How taste-skill was used, for the log: it isn’t registered in this session, so I applied its SKILL.md as a review rubric only. Its kit, scripts and landing-page rules (hero screen, photos, motion “moments”, picking a design by script) don’t fit this brief, and I kept them out.

Do you approve the spec? Once you do, I’ll go straight to step 4 (build) and skip the writing-plans handoff, as you asked.

Me: I approve. Please proceed.

What changed#

• Look: a charcoal masthead carries the newest post on home, the title on articles, and the term on category and tag pages. Listings are text-only tiles, with no cover images. Type is Figtree, Plex Mono for code, and Oswald for the {D:S} logo only.
• Copper: it now passes AA. The logo keeps #D48166, and text uses a lighter copper on charcoal and a darker one on white.
• Sidebars are gone. Their content moved to the footer (Labels) and the bottom of About (GitHub, Gists, CodePens).
• Articles: they get a Contents rail on wide screens and a collapsible Contents on narrow ones. They end with “Related articles”, which always shows three posts.
• Styles now live in assets/scss/ and are compiled by Hugo toCSS. The old index.css, the unwired SCSS and 13 orphan partials are deleted. The README is corrected.

Testing#

• I checked 10 page types at 1440, 768 and 390: no horizontal overflow, focus is visible on every stop, the skip link works, and there’s one h1 per page with no skipped heading levels.
• On the first screen, the newest post and the first row of tiles are visible at 1440, and the second post starts within the first screen at 390.
• Compared with a build of the previous commit, the new build produces the same 254 URLs. RSS, sitemap and robots.txt are byte-identical, and meta tags and JSON-LD match on every page. There are no broken internal links or assets.
• I couldn’t verify three external resources: giscus, Google Analytics and the GitHub-hosted puppetry image. The sandbox blocks their HTTPS. Check them in a normal browser.

Left as found#

• The Books copy repeats id="description".
• The React patterns post has its own “Contents” heading, so its rail shows “Contents” twice.
• Three partials that were already unused before this work are still there.

On the skills#

• taste-skill was installed but never registered in this session. I read its SKILL.md and used it as a review rubric only. Its landing-page rules (hero screen, photos, motion, picking a design by script) didn’t fit your brief and weren’t applied.
• I skipped the writing-plans handoff, as you asked.