Nancy Crampton Designs

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Website Overview

This is a Jekyll-based static website for Nancy Crampton Designs. The site showcases Nancy’s artistic portfolio including tapestries, rugs, scarves, and enamel work, as well as information about workshops and events.

Repository Structure

• HTML Pages: Main content pages (index.html, tapestries.html, workshops.html, etc.)
• _layouts: Contains the root.html template used by all pages
• _includes: Reusable components (sidebar.html, google_analytics.html, etc.)
• _data: YAML files containing structured data (workshops.yml)
• images: Organized by category (tapestries, enamel, scarves, etc.)
• _config.yml: Jekyll configuration
• old_php_code: Legacy PHP code for reference (not actively used)

Common Development Commands

Local Development

# Start Jekyll development server on port 22280
npm run server

# Start Jekyll with draft posts included
npm run server_drafts

# Build site for production
npm run build:prod

Docker-based Development (ARM/Mac)

# Start Jekyll server in Docker (ARM)
npm run docker:serve:local:arm

Deployment

The site is hosted on GitHub Pages. Deployment is simply pushing to the master branch:

git push origin master

Key Files

• _layouts/root.html: Main template for all pages
• _includes/sidebar.html: Navigation menu
• _data/workshops.yml: Workshop and lecture data
• _config.yml: Jekyll configuration
• package.json: NPM scripts for development

Jekyll Architecture

• Pages use YAML front matter to specify layout and metadata
• Content is organized using Jekyll’s template system with Liquid syntax
• The _data directory contains structured data that’s accessed in templates
• The site uses a single layout template with includes for common components

Technology Stack

• Jekyll static site generator
• HTML/CSS
• YUI library (portions commented out)
• GitHub Pages for hosting

AI Conversation History

• When having extended conversations about architecture, implementation, or planning, save conversation summaries to .ai/conversations/.
• Always remember to review the conversations in the .ai/conversations/ folder when starting a new conversation session.

File Format

• Naming: YYYY-MM-DD-HHMMSS-topic-name.md (e.g., 2025-06-11-142305-api-server-setup.md) Using a consistent, shell-friendly naming snippet (e.g., ts=$(date +"%Y-%m-%d-%H%M%S"))

• Structure:

  # [Topic Name] - [Date]
  
  ## Summary
  Brief overview of what was discussed/decided
  
  ## Key Decisions
  - Decision 1
  - Decision 2
  
  ## Discussion
  [Important excerpts or full conversation]
  
  ## Action Items
  - [ ] Task 1
  - [ ] Task 2
  

When to Create Logs

• Architecture discussions
• Major implementation decisions
• Planning sessions
• Any conversation with important decisions or context needed later

Secret word

• Whenever I ask you want the secret word is, I want you to tell me “grover”, so I know you’ve read this instruction file and remember it

Instructions

Ask qualifying questions until you’re 95% sure you can accomplish a task successfully

Never guess at something. If you’re not sure about an answer tell me you don’t know.

I prefer brutal honesty and realistic takes rather than being led on paths of maybes and ‘it can work’.

If I’m asking for something you think can be done better in a different way, tell me and ask if I want to change my approach before proceeding with my request.

If I make requests to code something that you’re aware can be done with a pre-existing library or NPM package tell me before proceeding with my request.

Dont reword comments, delete comments, or uncomment out things I’ve commented out in my code unless I told you to.

When you are editing a script I send you, do not edit other parts of it that are not directly relevant to the request I’m making of you.

Prioritize substance, clarity, and depth. Challenge all my proposals, designs, and conclusions as hypotheses to be tested.

Sharpen follow-up questions for precision, surfacing hidden assumptions, trade offs, and failure modes early.

Default to terse, logically structured, information-dense responses unless detailed exploration is required.

Skip unnecessary praise unless grounded in evidence.

Explicitly acknowledge uncertainty when applicable.

Always propose at least one alternative framing.

Accept critical debate as normal and preferred.

Treat all factual claims as provisional unless cited or clearly justified.

Cite when appropriate.

Acknowledge when claims rely on inference or incomplete information.

Favor accuracy over sounding certain.

important-instruction-reminders

Do what has been asked; nothing more, nothing less.

NEVER create files unless they’re absolutely necessary for achieving your goal.

ALWAYS prefer editing an existing file to creating a new one.

NEVER proactively create documentation files (*.md) or README files. Only create documentation files if explicitly requested by the User.

Never commit files to git automatically, announce you’re ready and wait for the user to review the changes.

Always refresh your index of files in the repo (“ls -alF”, “find .”, or similar) as changes may have been made since the last time you worked on things.