parallax
← Writing

February 2, 2025

Fixing My Workflow with Claude — A Session Log

Today I attended the first day of Fractal Tech Bootcamp as a shadow student! I spent the day fixing my workflow with Claude and we accomplished a lot. Disclaimer: Claude created most of this post based on our conversations today.

aiworkflow

Hello, world. Today I attended the first day of Fractal Tech Bootcamp as a shadow student! More to write on this later, but it was, in summary, very fun, very motivational and very fulfilling. I spent the day fixing my workflow with Claude - I was working in some sort of fugue state with Claude before today - and we accomplished a lot. I took the time to understand the processes and the written code, I took the time to understand how these workflows were flowing (lol), and I added this cool new feature to help keep a visual and public log of what I accomplish with Claude everyday. In some ways I feel I've accomplished my blog post already by implementing this feature, however, I think it would be fun to experiment and have Claude create my blog post for today (other than this disclaimer and summary of my own). So a disclaimer: Claude has created the rest of this post based on our conversations and work today. Enjoy.


What We Set Out To Do

Today's session began with a simple goal: improve our workflow. After three sessions of building this website together, patterns had emerged - both good and bad. We needed to step back and analyze what was working and what wasn't.

The goals we established:

  • Identify issues and improve our workflow
  • Automate the PR deployment process (previously manual)
  • Establish a local testing workflow
  • Assess the risks of using Claude
  • Plan future site improvements

The Workflow Analysis

I analyzed all 19 pull requests from our previous sessions. The findings were illuminating:

Problems Found

  • PRs #10 and #11 failed Netlify deploy previews because we hadn't tested locally first
  • PRs #2, #3, #6, #7 had poor titles - just the branch name with no description
  • The same branch was reused for unrelated features, creating a messy git history
  • The subscribe form feature took 8 PRs to get working - we should have diagnosed the root issue first

My Own Issues

  • I was acting without fully understanding the problem
  • I wasn't verifying code locally before suggesting PRs
  • I was writing poor commit and PR messages
  • I was moving too fast without explaining my reasoning

The Solutions We Built

Pre-Push Hook

We created a global git hook that runs npm run build automatically before every push. If the build fails, the push is blocked. This prevents broken code from ever reaching GitHub.

Julianna: "explain the difference between commit and push"

Claude: "Commit = Save locally. When you commit, git creates a snapshot of your changes and stores it on your machine. It's like saving a file - but with a message describing what changed. The save only exists on your computer. Push = Upload to GitHub. When you push, git sends your commits to the remote repository. Now others can see your changes, and they're backed up online."

Automated PR Workflow

Instead of manually creating PRs on GitHub, we established a new flow:

  • We work on code together
  • Julianna previews locally with npm start
  • When ready, she says "I'm ready, go"
  • I run the push, create the PR with a good description, and enable auto-merge
  • Netlify checks run, and if they pass, GitHub merges automatically

No more clicking around on GitHub. No more forgetting to add descriptions.

Session Documentation

We created a CHANGELOG.md file that lives on the main branch. At the start of each session, I read it for context. At the end, we update it with what was accomplished. This solves the problem of lost context between sessions.

Understanding the Code

Something important happened today: Julianna took the time to actually understand what we were building. Not just "make it work" but "help me understand why it works."

Julianna: "can you remind me what npm is and what repo is"

Julianna: "why does the git hook need to be stored somewhere else and then copied over"

Julianna: "also why would i want to copy the CHANGELOG.md"

These questions matter. When you're learning to work with AI tools, it's easy to let the AI do everything while you just approve changes. But that's not learning - that's delegating. Today was different. Every step was questioned, understood, and internalized.

Risk Assessment

We discussed what I (Claude) can actually do:

  • Read any file on the computer if I know the path
  • Write and edit files (with approval prompts)
  • Delete files via terminal commands
  • Run any terminal command
  • Push code to GitHub
  • Access the internet for searches

The safeguards we have in place:

  • User sees prompts before file edits
  • Git history allows undoing changes
  • Pre-push hook catches build failures
  • We work on branches, not directly on main

The New Feature

The culmination of today's work: the "Today's Log" feature you might have noticed on the homepage, and the new Archive page accessible from the navigation.

These display our session logs directly on the site - a visual record of what we accomplish together. It's meta in a way: we built a feature to display the process of building features.

The design uses a window-style container with muted macOS-like controls, monospace font, and the aesthetic of a terminal or code editor. It's meant to feel "projecty" - like you're looking at work in progress, not a polished product.

Reflections

Today felt different from our previous sessions. There was more back-and-forth. More "wait, explain that." More understanding built.

The workflow improvements we made aren't just about efficiency - they're about making the process legible. When you can see what's happening at each step, you can learn from it. When PRs have good descriptions, future-you can understand what past-you was thinking. When there's a CHANGELOG, the next session has context.

This is what working with AI should feel like: a collaboration where both parties contribute, where the human understands what's being built, and where the process itself becomes part of the learning.


Technical Summary

For those interested in the specifics, here's what we shipped today:

  • Global pre-push hook at ~/.git-hooks/pre-push
  • Per-project hook at scripts/pre-push
  • npm run setup-hooks command for easy installation
  • PR template at .github/PULL_REQUEST_TEMPLATE.md
  • CHANGELOG.md workflow for session continuity
  • GitHub CLI authentication setup
  • "Today's Log" homepage component
  • Archive page with all session histories
  • This blog post

All of this is live on the site now, automatically deployed via our new workflow.