MakingCode

Auditing 25 GitHub Repositories with Claude

Tue, 04 Aug 2026 00:00:00 GMT

My GitHub account had accumulated 25 repositories over several years. It was a mix of active projects, class assignments from my master’s coursework, half-finished prototypes, and old tutorial stubs like helloGit and HelloNetlify. As part of building out this site and deliberately applying AI tools to real engineering workflows, I wanted to audit and organize the account. But manually clicking through 25 repository settings pages to edit descriptions, topics, and visibilities sounded like tedious administrative overhead.

Instead of spending an afternoon on manual UI navigation, I used Claude in Chrome to audit the entire account and generate a batch action plan.

The tool setup and the exact prompt

Claude didn’t have a direct API connection to my GitHub account. Rather than setting up personal access tokens or custom script integrations for a one-off task, I used Claude’s Chrome browser integration. The extension allows Claude to inspect live browser pages, navigate repository tabs, open directory trees, and read README.md files directly in the browser.

I opened my profile URL (github.com/jdeleon3) in Chrome and ran this prompt:

Hey Claude. I'd like to evaluate the state of my github repositories. I want to figure out which ones I should keep, which to delete, which ones to work on and fix. Help me get things in order. Ask any clarifying questions as you review my github. We are only doing an evaluation at this point. Here's the link: https://github.com/jdeleon3

When Claude asked clarifying questions to weight the recommendations, I specified two constraints: the primary goal was organizing the profile to highlight real engineering work, and the execution should be planned for a single focused session.

Spot-checking and verification

Rather than making blind assumptions from repository names, Claude inspected file structures and surfaced ambiguous cases for human review:

netlify-blog: Claude flagged this as a Next.js/MDX template clone with Bejamas boilerplate and asked whether it was an active blog or an unused clone. I confirmed it was an unused template, moving it straight to the deletion bucket.
aws-rss-reader-ui: Claude noticed aws-rss-reader had a full backend spec, while aws-rss-reader-ui was an untouched Vite template. It asked if the UI was functional or stalled. I confirmed it was scaffolded and stalled, tagging it as a work-in-progress to document alongside the backend.

Having the LLM ask before categorizing prevented deleting repositories that looked like tutorial stubs but contained custom logic.

The audit breakdown

In a single session, Claude categorized all 25 repositories into four action buckets:

Keep (active or portfolio-solid, no action needed): MakingCode.IO.Site, MakingCode.IO.ContentPipeline, RD.Creations.Site, Projects.RealFakeJobPredictor, and ImageProcessing.BackgroundReplace (five repos with recent pushes, real stars, or both).
Delete 9 dead-weight repos: Flagged zero-byte tutorial clones (helloGit, HelloNetlify, HelloPython), netlify-blog (an unused template clone, added to this bucket from the spot-check confirmation above rather than the initial pass), and abandoned stubs (coursera-java-fundamentals, azurestaticwebappwithvue, Graduate.Work, Projects.Infrastructure.ExplainableAnomalyDetection, Projects.ExplainableNetworkMonitoring).
Fix missing metadata on 8 repos: Identified repos with real code but blank descriptions: rag-saas-mvp, Projects.Movies.ReviewSentimentAnalysis, aws-rss-reader, aws-rss-reader-ui (the same stalled scaffold flagged during spot-checking, back again here because a stalled repo still needs an honest description), aws-lambda-siteCrawler, and the three Data Mining repos (Datamining.Classification.TumorType, Datamining.Classification.CustomerSegmentation, Datamining.Clustering.CreditCardDataset). Claude drafted custom one-line descriptions and topic tags based on actual directory contents. The eventual script also touched the four Keep-bucket repos and flipped one to private, covered below.
Consolidate duplicates (2 deletions): Identified three separate stock trading repositories (Stock-Swing-Trader, Projects.Finance.StockSwingTrader, Projects.ExplainableStockPredictions) and recommended merging them into Stock-Swing-Trader, deleting the two redundant stubs.

Five repos landed in Keep, but one of them was a private repository resulting in only four pinned repositories: Projects.RealFakeJobPredictor, ImageProcessing.BackgroundReplace, MakingCode.IO.Site, and RD.Creations.Site. MakingCode.IO.ContentPipeline stayed a Keep without getting pinned.

Generating executable PowerShell scripts

Rather than making manual UI edits, Claude output ready-to-run GitHub CLI (gh) commands.

One immediate gotcha: Claude formatted multiline commands using Bash line continuation backslashes (\). PowerShell has no line-continuation meaning for \ at all (only the backtick does), so a trailing backslash doesn’t continue the command onto the next line. It just ends the line early, and PowerShell parses whatever comes next as a separate, malformed statement.

The next attempt was PowerShell’s actual line-continuation character, the backtick. That didn’t hold up either: a single invisible trailing space after a backtick silently breaks the continuation. PowerShell doesn’t throw a syntax error; it just stops treating the next line as part of the same command, and the failure shows up downstream as a confusing, unrelated-looking error instead of pointing at the real cause. After tripping over that once, I stopped fighting line continuation entirely and had every gh repo edit and gh repo delete command flattened to a single line. That’s what’s actually in all three .ps1 scripts below.

I split the commands into three scripts in my workspace:

delete_stale_repos.ps1 (deleting 9 dead-weight repos):

gh repo delete jdeleon3/helloGit --yes
gh repo delete jdeleon3/HelloNetlify --yes
gh repo delete jdeleon3/HelloPython --yes
gh repo delete jdeleon3/coursera-java-fundamentals --yes
gh repo delete jdeleon3/azurestaticwebappwithvue --yes
gh repo delete jdeleon3/Graduate.Work --yes
gh repo delete jdeleon3/Projects.Infrastructure.ExplainableAnomalyDetection --yes
gh repo delete jdeleon3/Projects.ExplainableNetworkMonitoring --yes
gh repo delete jdeleon3/netlify-blog --yes

consolidate_stock_repos.ps1 (deleting 2 redundant duplicate stubs):

gh repo delete jdeleon3/Projects.Finance.StockSwingTrader --yes
gh repo delete jdeleon3/Projects.ExplainableStockPredictions --yes

add_descriptions.ps1 ended up covering more than just the 8 Fix-bucket repos: I also used it to refresh descriptions and topics on the 4 pinned Keep-bucket repos, and to flip RD.Creations.Site to private in the same pass. One inconsistency worth flagging: rag-saas-mvp’s description below says “Production-ready”, whereas the audit table called the same repo stalled at 5 commits. That’s the line that actually shipped; I’m not rewriting it for this post. One more note: the visibility change for RD.Creations.Site ran as part of this script, but the profile and repo-list screenshots later in this post were captured before that line executed, so they still show it public (a timing artifact, not a contradiction):

# --- Descriptions + topics: pinned / Keep repos ---
gh repo edit jdeleon3/MakingCode.IO.Site --description "Content/blog site for the MakingCode.IO brand - Astro on Cloudflare Workers, paired with an AI-assisted content pipeline" --add-topic astro --add-topic cloudflare-workers --add-topic blog

gh repo edit jdeleon3/Projects.RealFakeJobPredictor --description "Full-stack app with an ML core detecting fraudulent job postings - Python/ML backend, AWS CDK infrastructure, and frontend" --add-topic machine-learning --add-topic fraud-detection --add-topic aws-cdk

gh repo edit jdeleon3/ImageProcessing.BackgroundReplace --description "Computer vision app for removing/replacing image backgrounds (color-based and transparency methods) with a UI - CS 6322 grad term project" --add-topic computer-vision --add-topic image-processing --add-topic python

gh repo edit jdeleon3/RD.Creations.Site --description "Order intake site and mini-CRM for RD Creations, a Valley Mills, TX bakery - Astro + Tailwind + Supabase, deployable to Cloudflare Pages or Vercel" --add-topic astro --add-topic supabase --add-topic tailwindcss

gh repo edit jdeleon3/RD.Creations.Site --visibility private

# --- Descriptions + topics: Fix repos ---
gh repo edit jdeleon3/Projects.Movies.ReviewSentimentAnalysis --description "Full-stack movie review sentiment analysis app - Python backend, frontend, and AWS CDK infrastructure" --add-topic sentiment-analysis --add-topic aws-cdk --add-topic nlp

gh repo edit jdeleon3/Datamining.Classification.TumorType --description "Classification pipeline predicting tumor type from clinical data - preprocessing, model training, and visualization" --add-topic classification --add-topic machine-learning --add-topic scikit-learn

gh repo edit jdeleon3/Datamining.Classification.CustomerSegmentation --description "Classification pipeline segmenting customers by behavioral and demographic features" --add-topic classification --add-topic machine-learning

gh repo edit jdeleon3/Datamining.Clustering.CreditCardDataset --description "Clustering analysis on credit card transaction data to identify spending/behavior segments" --add-topic clustering --add-topic unsupervised-learning --add-topic machine-learning

gh repo edit jdeleon3/aws-rss-reader --description "AWS CDK (TypeScript) backend for an RSS aggregator - categorized feeds with on-demand AI summaries" --add-topic aws-cdk --add-topic typescript --add-topic serverless

gh repo edit jdeleon3/aws-rss-reader-ui --description "Vue 3 + Vite frontend for the AWS RSS Reader project (WIP, paired with aws-rss-reader backend)" --add-topic vue --add-topic frontend

gh repo edit jdeleon3/aws-lambda-siteCrawler --description "Java AWS Lambda function for crawling websites, with CI configured via GitHub Actions" --add-topic aws-lambda --add-topic java --add-topic serverless

gh repo edit jdeleon3/rag-saas-mvp --description "Production-ready RAG SaaS MVP - FastAPI + pgvector backend, React frontend, Ollama LLM inference, Docker Compose" --add-topic rag --add-topic fastapi --add-topic llm --add-topic docker

Human review & CLI permissions

Generating the audit and scripts took roughly 20 minutes. But reviewing the .ps1 files in VS Code before hitting enter was essential because gh repo delete doesn’t ask twice, and delete_stale_repos.ps1 had nine specific repo names on it that I needed to personally confirm before the terminal ever saw them. Generating CLI scripts takes seconds; running gh repo delete without checking the target list first is how you delete a repository you actually needed.

During the first run of delete_stale_repos.ps1, the GitHub CLI came back with a 403 because the authenticated gh session didn’t carry the OAuth scope needed to delete repositories.

Standard gh CLI credentials omit deletion privileges by default. Requesting the explicit delete_repo OAuth scope resolved it:

gh auth refresh -h github.com -s delete_repo

Once re-authenticated, executing delete_stale_repos.ps1 and consolidate_stock_repos.ps1 deleted all 11 targeted repositories in seconds:

The final result: Reconciling the count

Deleting 9 dead-weight repositories plus 2 redundant stock trading stubs removed 11 repositories total. The account dropped from 25 repositories down to exactly 14 active, clean projects.

The repository list now features single-sentence descriptions and topic tags across all remaining codebases:

Next steps

The audit and batch cleanup cleared out the profile noise, but a few follow-up tasks remain on the backlog:

Full README Write-Ups: Draft documentation for Projects.Movies.ReviewSentimentAnalysis and aws-lambda-siteCrawler, which both contain substantial code but zero documentation.
rag-saas-mvp Direction: Decide whether to continue active development on the RAG SaaS MVP (FastAPI + pgvector + Docker) or publish it publicly with an explicit status note indicating it is a completed MVP snapshot.
Coursework Consolidation: Bundle the three separate Data Mining repositories (Datamining.Classification.TumorType, Datamining.Classification.CustomerSegmentation, Datamining.Clustering.CreditCardDataset) into a single ML-Coursework repository with a unified README summarizing each dataset and technique.

If you’ve run a similar cleanup pass on your own GitHub account, reply and tell me what your audit turned up.

Securing a Contact Pipeline: Astro, Cloudflare Pages Functions, Turnstile, and n8n

Wed, 08 Jul 2026 00:00:00 GMT

A mailto: link is not a contact pipeline — it’s a hope that the visitor’s OS has a mail client configured. Replacing it meant building something with an actual trust boundary: verify the submitter is human, authenticate the request before it touches internal infrastructure, and never let the browser talk to the automation server directly. Here’s how that pipeline is put together.

The shape of the problem

The site is static (Astro, output: 'static'), and the destination is a self-hosted n8n instance on a Hetzner VPC. Those two facts rule out the naive approach — a <form> posting straight to the n8n webhook URL — for two reasons: the webhook URL becomes public the moment it’s in client-side JS, and there’s nothing stopping a script from hammering it with junk submissions.

The fix is a broker in the middle: a Cloudflare Pages Function sitting at the edge, doing three things in strict order before anything reaches n8n.

Browser (Turnstile widget + form)
  → POST /api/submit-contact          (Cloudflare Pages Function)
      1. verify Turnstile token
      2. sign a short-lived JWT
      3. forward payload + JWT to n8n
  → n8n Webhook node (Hetzner VPC)     (JWT Auth credential checks the signature)

The browser never sees the n8n URL, never sees a credential, and can’t reach the webhook without first clearing a human check.

Turnstile as the gate, not the lock

The form embeds Cloudflare Turnstile as a widget scoped to the ContactForm.astro component rather than loaded globally, so pages without the form don’t pay for it:

<div class="cf-turnstile" data-sitekey={turnstileSiteKey} data-theme="dark"></div>
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>

Because the widget lives inside a <form>, Turnstile auto-injects its response token into a hidden cf-turnstile-response field — no manual callback wiring needed. The client-side script just reads it out of FormData on submit and ships it alongside the form fields as JSON.

The verification itself happens server-side, in the Pages Function, against Cloudflare’s siteverify endpoint:

async function verifyTurnstile(token: string, secret: string, remoteIp: string | null): Promise<boolean> {
  const body = new URLSearchParams({ secret, response: token });
  if (remoteIp) body.set('remoteip', remoteIp);

  const response = await fetch('https://challenges.cloudflare.com/turnstile/v0/siteverify', {
    method: 'POST',
    headers: { 'content-type': 'application/x-www-form-urlencoded' },
    body,
  });

  if (!response.ok) return false;
  const result = (await response.json()) as { success?: boolean };
  return result.success === true;
}

A client-side token is a hint, not proof — trusting the widget without this round trip would mean trusting whatever JavaScript happened to run in the visitor’s browser.

From OAuth to a self-signed JWT

The first cut of this pipeline authenticated to n8n with an OAuth 2.0 client-credentials grant: the Pages Function would exchange a client ID and secret at a token endpoint for a bearer token, then attach that token to the n8n request. It worked, but it bought more than the problem needed — a second network hop, a second point of failure, and an external token endpoint to keep alive, all to protect a single internal webhook that only one caller (this function) ever hits.

I replaced it with a self-signed HS256 JWT, minted inline using the Workers-native SubtleCrypto API — no token endpoint, no extra dependency, no extra round trip:

async function signContactJwt(secret: string): Promise<string> {
  const now = Math.floor(Date.now() / 1000);
  const header = { alg: 'HS256', typ: 'JWT' };
  const payload = {
    iss: 'makingcode-contact-form',
    sub: 'contact-submission',
    iat: now,
    exp: now + 60, // single-use, short-lived
  };

  const signingInput = `${base64UrlEncode(JSON.stringify(header))}.${base64UrlEncode(JSON.stringify(payload))}`;

  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign'],
  );
  const signature = await crypto.subtle.sign('HMAC', key, new TextEncoder().encode(signingInput));

  return `${signingInput}.${base64UrlEncode(signature)}`;
}

n8n’s Webhook node verifies it on the way in with its built-in JWT Auth credential, checked against the same shared secret. The token is deliberately short-lived (60 seconds) and single-purpose — it exists only to prove “this request came from the contact function,” not to carry a session or identity. That’s a better fit for a single machine-to-machine hop than a full OAuth grant, and it removes an entire external dependency from the request path.

Isolating two type universes

Adding @cloudflare/workers-types to get proper typing for the Pages Function (PagesFunction<Env>, the crypto.subtle global, etc.) initially broke an unrelated file. The cause: a /// <reference types="@cloudflare/workers-types" /> directive doesn’t scope itself to the file it’s written in — it pulls the whole package into the global TypeScript program. Workers-types declares its own global Element interface (for HTMLRewriter), and its append() signature collided with the DOM lib’s Element.append(), breaking type-checking in a component that had nothing to do with the contact form.

The fix was to stop merging the two globally. functions/ got its own tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ES2022",
    "moduleResolution": "Bundler",
    "lib": ["ES2022"],
    "types": ["@cloudflare/workers-types"],
    "strict": true,
    "skipLibCheck": true,
    "noEmit": true
  },
  "include": ["**/*.ts"]
}

…excluded from the root tsconfig.json ("exclude": ["dist", "functions"]), and checked as a separate step in the build:

"build": "astro check && tsc --noEmit -p functions/tsconfig.json && astro build"

Astro’s browser-facing code keeps the DOM lib it needs; the edge function keeps the Workers runtime types it needs. Neither program sees the other’s globals.

The local-dev trap: `astro dev` doesn’t run Pages Functions

The first local test of the finished form failed with a 404 on /api/submit-contact — not a bug in the function, but a gap in how it was being served. astro dev is a plain Vite dev server; it only knows about routes under src/pages/. It has no concept of a functions/ directory, so any request to /api/* simply has nowhere to go.

Cloudflare Pages Functions only run under Wrangler’s Pages emulator (or in production, on Cloudflare itself). The fix was a dedicated script that builds the static site and serves it through that emulator instead:

"pages:dev": "astro build && wrangler pages dev dist --env-file .env --compatibility-date=2026-07-07"

wrangler pages dev reads secrets straight from .env, wires up functions/ alongside the static output, and serves both from one local server — the same shape the request will take in production. Plain npm run dev is still the right tool for fast UI iteration; it just can’t be used to test the submission path itself.

What’s left on n8n’s side

Everything up to the webhook is done and verified locally: Turnstile blocks non-human submissions, the Pages Function signs a short-lived JWT per request, and the request reaches n8n with that token in the Authorization header. The remaining piece is entirely on the n8n workflow — the Webhook node’s JWT Auth credential needs the same HS256 secret configured, and whatever runs after it (CRM write, notification, whatever the workflow does with a new lead) is a normal n8n build from there.

Architecting Idempotent Webhook Pipelines

Mon, 18 May 2026 00:00:00 GMT

Most CRM and payment providers guarantee at-least-once webhook delivery, not exactly-once. If your system assumes every webhook arrives exactly one time, you will eventually double-book an appointment, double-charge a client, or double-notify an agent. This is the architectural trade-off at the center of every serious automation build: correctness under retries costs a little extra state, but the alternative costs trust.

The trade-off

There are three common strategies, in increasing order of robustness and cost:

Do nothing — cheapest, breaks in production the first time a provider retries after a slow 200.
Timestamp/window de-duplication — cheap, but fragile around clock skew and burst retries.
Idempotency-key ledger — a small persisted table keyed on the provider’s event ID, checked before any side effect runs.

For anything touching money, scheduling, or client communication, option 3 is the only defensible choice.

Implementation: the idempotency-key middleware

import type { Request, Response, NextFunction } from 'express';
import { Pool } from 'pg';

interface WebhookEvent {
  id: string;
  type: string;
  payload: unknown;
}

export function idempotencyGuard(pool: Pool) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const event = req.body as WebhookEvent;

    const { rowCount } = await pool.query(
      `INSERT INTO webhook_events (event_id, event_type, received_at)
       VALUES ($1, $2, now())
       ON CONFLICT (event_id) DO NOTHING`,
      [event.id, event.type],
    );

    if (rowCount === 0) {
      // Already processed this exact event ID — ack without re-running side effects.
      res.status(200).json({ status: 'duplicate_ignored' });
      return;
    }

    next();
  };
}

The ON CONFLICT DO NOTHING clause is doing the real work here: the uniqueness constraint on event_id turns a race between two concurrent retries into a no-op for the loser, with no explicit locking required.

Queueing the guarded events

Once an event passes the guard, it’s handed to a durable queue rather than processed inline — so a downstream failure (CRM API timeout, rate limit) doesn’t force the webhook endpoint itself to block or fail:

# consumer-config.yaml
queue:
  name: webhook-events
  visibility_timeout_seconds: 30
  max_receive_count: 5
  dead_letter_queue: webhook-events-dlq

consumer:
  concurrency: 10
  backoff:
    strategy: exponential
    base_ms: 500
    max_ms: 30000

Verifying the fix

Replaying a captured webhook payload against a local instance confirms the guard behaves correctly under a simulated retry:

# First delivery — should process normally
curl -X POST http://localhost:8787/webhooks/crm \
  -H "Content-Type: application/json" \
  -d '{"id":"evt_9f8a1c","type":"lead.created","payload":{}}'

# Simulated retry of the same event — should be ignored, not reprocessed
curl -X POST http://localhost:8787/webhooks/crm \
  -H "Content-Type: application/json" \
  -d '{"id":"evt_9f8a1c","type":"lead.created","payload":{}}'

If the second call returns duplicate_ignored and no second side effect fires, the ledger is doing its job. This same pattern — a small keyed table in front of anything with a side effect — is the one I reach for by default now, regardless of which CRM or messaging provider sits on the other end.