13. From two SKILL.md files to a live landing page in one session

This is a case study, not a tutorial. It documents an actual Claude Code session — the decisions made, the things that broke, the things that worked — using two skills from this library back-to-back on a real project.

The project: repo-publisher-toolkit — a repo containing two Claude Code skills (repo-publisher and scsiwyg) that we wanted to share publicly with a resource site explaining what they do.

The skills used: /landing-page then /deploy

Time: One session, same conversation thread.

What we started with

A directory containing exactly this:

repo-publisher-toolkit/
├── repo-publisher/
│   ├── SKILL.md
│   └── references/
│       ├── config-schema.md
│       ├── decision-engine.md
│       ├── media-pipeline.md
│       ├── state-schema.md
│       └── story-templates.md
└── scsiwyg/
    ├── SKILL.md
    └── references/
        ├── blogs.md
        └── claude-skills-conventions.md

No README. No package.json. No screenshots. Just the skills themselves.

The directive was minimal: "we need a landing page for this that provides a what is this by showing how it works."

Running /landing-page

The /landing-page skill runs an 8-phase pipeline coordinating specialist agents: App Auditor → Screenshot Analyst → Strategy Architect → Design Director → Copywriter → Page Builder → Rationale → Growth Advisor.

With no screenshots available and no existing docs directory, the pipeline adapted: skip Phase 2, lean harder on the App Auditor to surface marketable intelligence from the SKILL.md files themselves.

What the App Auditor found

Reading the SKILL.md files through a marketing lens rather than a technical one surfaced the actual story:

• Hero feature: repo-publisher turns git history into published blog content — automatically
• Key differentiator: a decision engine that scores story candidates (significance × novelty × timeliness × audience-fit) — not every commit becomes a post
• Second differentiator: stateful — it remembers what's been published, maintains an editorial calendar
• The platform: scsiwyg is entirely controlled from Claude Code via MCP tools; no web editor exists

The audience wasn't generic "developers" — it was specifically Claude Code users who ship code regularly and have thought "I should write about this" but never do.

The design direction

No screenshots meant leaning into code as the visual. The Design Director chose a dark terminal aesthetic: near-black background (#0d0d0d), Playfair Display for headlines (authority, editorial weight), JetBrains Mono for code blocks, amber accent (#e8a045). Think developer docs meets literary magazine.

The hero headline: "Your repo already has a story."

The first version had a problem

The Page Builder generated this in the hero:

// install
$ claude skill install repo-publisher
$ claude skill install scsiwyg

That command doesn't exist. claude skill install isn't a real CLI feature — skills are just directories you copy to ~/.claude/commands/. Publishing aspirational CLI syntax that doesn't work would immediately erode trust with the exact developer audience we were targeting.

What we replaced it with

Two download cards — one per skill — showing the exact file tree inside each zip before you download it:

repo-publisher + scsiwyg          ↓ .zip
├ repo-publisher/SKILL.md
├ repo-publisher/references/ (5 files)
├ scsiwyg/SKILL.md
└ scsiwyg/references/ (2 files)
Copy folders to ~/.claude/commands/

scsiwyg only                      ↓ .zip
├ SKILL.md
├ references/blogs.md
└ references/claude-skills-conventions.md
Manual blog management · scsiwyg.com →

The transparency is intentional. A developer seeing "here's exactly what's in this zip, 8 markdown files" downloads with confidence. A vague download button gets ignored.

Bundling decision

During this process we also decided: should scsiwyg stay separate or get bundled into the repo-publisher download?

The answer: both. repo-publisher.zip bundles both skills (the 90% case — full automated workflow). scsiwyg.zip stays available standalone for manual blog management. One download for the complete workflow, one for the platform skill alone.

Pipeline output

landing-page-output/
├── index.html                   (1,463 lines, standalone)
├── spec/
│   ├── 01-app-audit.md
│   ├── 03-marketing-strategy.md
│   ├── 04-design-brief.md
│   ├── 05-copy-deck.md
│   └── 06-rationale.md
├── recommendations/
│   ├── promotion-plan.md
│   ├── enhancements.md
│   └── course-corrections.md
└── assets/
    ├── repo-publisher.zip
    └── scsiwyg.zip

The page has 9 sections: Nav → Hero (with download cards) → The Problem → How It Works (6-phase pipeline diagram in CSS/SVG) → Decision Engine (mock terminal with scored story candidates) → scsiwyg Platform → Code Deep-Dive → CTA Banner → Footer.

Running /deploy

The /deploy skill ran into one real obstacle: Netlify CLI v24 fails silently in non-TTY environments. Interactive prompts don't surface an error — they just exit 1 with no output.

The fix was running commands as background tasks rather than foreground commands. That's the only change needed. netlify sites:list worked in background and confirmed the account slug (worksona). The deploy worked the same way.

Two deploys: draft first (preview URL to review), then production.

netlify deploy --dir=. --create-site worksona-repo-publisher-toolkit --no-build
netlify deploy --dir=. --no-build --prod

Total Netlify interaction: under 2 minutes.

What's live

worksona-repo-publisher-toolkit.netlify.app

The page explains what the toolkit is, shows how repo-publisher works (the 6-phase pipeline as a visual diagram), introduces the decision engine, covers the scsiwyg platform, and offers direct zip downloads with full file listings.

Both skill downloads are served from assets/ alongside the page — no external dependency, no GitHub redirect, no "go find the files yourself."

What this session demonstrates

Skills chain. /landing-page produced landing-page-output/. /deploy deployed it. The output directory of one skill was the input of the next. No intermediate steps, no manual file wrangling.

The pipeline is audit-ready. Every decision is documented in spec/. The App Auditor found the real story. The Strategy Architect chose the right audience. The Design Director made defensible choices. All of it is readable in the spec files if you want to understand or challenge any decision.

The real work is in the decisions, not the generation. The Page Builder produced a hero with fake CLI commands. A human caught it and changed it. The bundling question (one zip vs two) required judgment. The Netlify TTY issue required diagnosis. The skills handle the production volume; the session handles the judgment calls.

Skills used

• /landing-page — 8-phase landing page pipeline
• /deploy — Vercel / Netlify deployment
• scsiwyg — publishing this post