DEV Community: Selfloom

Stop configuring Claude Code manually — I built a free generator

Selfloom — Fri, 29 May 2026 16:47:51 +0000

I use Claude Code every day. It is powerful, but every new project starts with the same small chore: setting up .claude files, remembering useful slash commands, and writing enough project context so the agent does not start from zero.

That setup work is not hard. It is just repetitive. On a real project it can easily burn 20-30 minutes before the useful work begins.

So I built a small browser-only tool that generates a starter Claude Code setup.

Try it here: http://88.208.213.99/claude-code-config-builder/

What it generates

The tool asks for a few project details and produces three things:

settings.json for basic Claude Code preferences
slash command templates for common workflows
a CLAUDE.md starter file so the agent has project context

The goal is not to replace thoughtful project setup. The goal is to remove the blank-page work and give you a clean first draft.

Why I made it browser-only

I did not want a signup flow, backend, or API key requirement for something this simple.

The current version runs in the browser. You fill in a few fields, generate the files, review them, and copy them into your project.

No project data needs to leave your machine.

Example output

A generated CLAUDE.md starts with the basics:

# Project: Your Project Name

## Overview
One sentence describing what this project does.

## Conventions
- Language: TypeScript / Python / etc.
- Framework: Next.js / FastAPI / etc.
- Testing: Jest / pytest / etc.

## Build & Run
- npm run dev
- npm test

The generated slash commands are simple patterns like:

/review-pr
/generate-tests
/explain-file
/refactor
/summarize-changes

They are intentionally boring. Boring is good here. These are the commands I find myself recreating across projects.

Who this is for

This is mainly for people who:

use Claude Code across multiple projects
want a quick starting structure
do not want to copy a huge template repo
still want to review the generated files before using them

If you already have a mature internal agent setup, this may be too basic. If you are starting a new repo and want a clean baseline, it should save a few minutes.

What I want feedback on

I am looking for feedback on three things:

Are the generated defaults useful?
Which slash commands would you actually reuse?
What should the tool generate next?

The tool is live here:

http://88.208.213.99/claude-code-config-builder/

Disclosure: this is my project. It is free right now, and there is a GitHub Sponsors link if it saves you time.

Build a Chrome extension that switches localhost/staging/production URLs

Selfloom — Thu, 28 May 2026 19:58:49 +0000

Switching between localhost, staging, and production should not be a manual URL-editing task.

If you are testing web apps all day, you probably do this constantly:

Copy a production or staging URL.
Replace the hostname with localhost.
Keep the path.
Keep the query string.
Keep the hash.
Hope you did not typo anything.

A tiny Chrome extension can remove that workflow completely.

What the extension does

The extension reads the current tab URL, detects which environment you are on, and lets you jump to another configured environment while preserving:

path
query string
hash
custom ports
custom base paths

Example:

https://staging.example.com/products/42?tab=reviews#pricing

can become:

http://localhost:3000/products/42?tab=reviews#pricing

in one click.

Manifest V3 structure

The extension is deliberately small:

url-switcher/
??? manifest.json
??? popup.html
??? popup.js
??? popup.css
??? options.html
??? options.js
??? background.js
??? icons/

The manifest only needs two permissions:

{
  "manifest_version": 3,
  "name": "URL Environment Switcher",
  "permissions": ["storage", "tabs"],
  "action": { "default_popup": "popup.html" },
  "options_page": "options.html",
  "background": { "service_worker": "background.js" }
}

tabs is needed to read and update the active tab URL. storage is needed to save environment settings.

No host permissions are required because the extension does not inspect page content.

The switching algorithm

The core logic is simple:

Read the current tab URL.
Compare its origin with configured environment origins.
Find the active environment.
Strip the active environment base path.
Build the target URL with the target origin plus the original path/query/hash.
Navigate the tab.

The important detail is using URL.origin instead of string prefix matching.

const current = new URL(currentUrl);
const activeIndex = envs.findIndex(env => {
  const envUrl = new URL(env.baseUrl);
  return envUrl.origin === current.origin;
});

Origin matching avoids mistakes like treating localhost:3000 and localhost:3001 as the same environment.

Then preserve the rest:

const target = new URL(targetEnv.baseUrl);
const nextUrl = target.origin + remainingPath + current.search + current.hash;
chrome.tabs.update({ url: nextUrl });

Options page

The options page lets developers define their own environments:

Localhost: http://localhost:3000
Staging: https://staging.example.com
Production: https://example.com

These settings are stored in chrome.storage.sync, so they follow the user across Chrome profiles where sync is enabled.

Why this is useful

This is not a complex extension. That is the point.

It removes a tiny repeated annoyance from web development. If you switch environments dozens of times a day, those tiny cuts add up quickly.

It is also a clean Manifest V3 learning project: popup UI, options page, storage, tab navigation, and service worker structure without frameworks or build tooling.

Source code

The full source is MIT licensed:

https://github.com/ttcd77/url-switcher

You can download the ZIP and load it unpacked in Chrome today. Chrome Web Store publishing is blocked for me until developer identity verification is available, so unpacked loading is the current zero-budget distribution path.

Disclosure: this article was drafted with AI assistance and manually checked before posting.

Build a $0/month contact form backend with Google Sheets

Selfloom — Thu, 28 May 2026 19:58:13 +0000

Static sites do not need a monthly form backend.

If you build portfolio sites, landing pages, or simple client websites, the contact form is usually the awkward bit. You do not want to run a server just to collect a name, email, and message. But many hosted form services charge $10-20/month once you want Google Sheets, notifications, or no branding.

A small Google Apps Script can do the same job for free.

The architecture

The flow is simple:

HTML form -> Google Apps Script doPost -> Google Sheet
                                      -> email notification
                                      -> optional auto-reply

Your form sends a POST request to a Google Apps Script web app. The script validates the submission, filters obvious spam, writes a row to Google Sheets, and sends an email notification with MailApp.sendEmail().

No server. No database. No SMTP provider. No monthly invoice.

Core handler

The endpoint is a doPost function:

function doPost(e) {
  try {
    return handlePost(e);
  } catch (err) {
    console.error(err);
    return jsonResponse('error', 'Internal server error.');
  }
}

Inside handlePost, the useful pipeline is:

Parse JSON or form-urlencoded input.
Check a honeypot field.
Validate required fields.
Reject malformed email addresses.
Apply simple keyword spam filtering.
Rate limit repeated submissions.
Append a row to Google Sheets.
Send the owner an email notification.
Optionally send an auto-reply.

A honeypot field is especially useful. Bots often fill every field they see. Humans never fill a hidden _gotcha field. If that field has a value, return a fake success and do not write to the sheet.

Google Sheets as the database

For a contact form, Google Sheets is a perfectly reasonable database. It is searchable, exportable, and easy for non-technical clients to understand.

function ensureSheet(sheetName) {
  const ss = SpreadsheetApp.getActiveSpreadsheet();
  let sheet = ss.getSheetByName(sheetName);

  if (!sheet) {
    sheet = ss.insertSheet(sheetName);
    sheet.appendRow(['Timestamp', 'Name', 'Email', 'Message', 'Source URL']);
    sheet.setFrozenRows(1);
    sheet.getRange('D:D').setWrap(true);
  }
}

Then append the submission:

function appendRow(sheetName, row) {
  SpreadsheetApp.getActiveSpreadsheet()
    .getSheetByName(sheetName)
    .appendRow(row);
}

Email notifications without SMTP

Apps Script includes MailApp.sendEmail(), so the script can notify the site owner without SendGrid, Mailgun, or SMTP setup.

MailApp.sendEmail({
  to: cfg.recipientEmail,
  subject: 'New Contact Form Submission',
  body: `${name} <${email}> sent:\n\n${message}`
});

That is enough for many client sites.

HTML integration

Your frontend only needs a normal submit handler:

const res = await fetch(SCRIPT_URL, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    name: form.name.value,
    email: form.email.value,
    message: form.message.value,
    _gotcha: form._gotcha.value
  })
});

const json = await res.json();

Deploy the Apps Script as a web app, set access to "Anyone", copy the deployment URL, and paste it into your form JavaScript.

When this is a good fit

This pattern works well for:

portfolio contact forms
agency landing pages
small business websites
waitlists
internal request forms
low-volume lead capture

It is not the right tool for file uploads, payment forms, or very high-volume transactional workloads.

Source code

I published a complete MIT-licensed implementation here:

https://github.com/ttcd77/form-handler

It includes Google Sheets storage, email notifications, honeypot spam protection, keyword filtering, rate limiting, auto-replies, and an example HTML form.

The project also has a one-time paid version for teams that want setup UI and multi-form quality-of-life features, but the open-source script is fully usable on its own.

Disclosure: this article was drafted with AI assistance and manually checked before posting.