bparanj

Use this prompt for Claude Code:

You are working on a Go-based security product prototype that will be used to measure real demand before the main product is fully ready.

Goal

Build a small, usable product in several iterations. The product must be easy for early adopters to run in their own environment, especially in CI/CD and AWS environments. The purpose is to learn from real usage and feedback in the same market as Stave.

Core strategy

bparanj

This is a perfect candidate for a Go "Golden File" test runner. The current shell script is a "Swiss Army Knife" of dependencies (jq, rg, sed, grep, sha256sum, find) that makes your CI environment fragile.

In Go, you can use the os/exec package combined with testify/assert or simple comparison logic to create a much more robust runner.

The "Go E2E Runner" Refactor

Create a file at internal/app/e2e_test.go. This approach uses Go's subtests to run every directory in testdata/e2e as an independent test case.

package app_test

bparanj

Yes, converting this to a Go test or a Go-based runner is highly recommended. Using shell scripts to "move folders around" to filter tests is brittle and can leave your testdata in a corrupted state if the script crashes.

In Go, the idiomatic way to solve this is using Subtests and Filtering via go test -run.

The "Go Way" Refactor

Instead of a shell script that moves files, create a Go test file (e.g., internal/core/enginetest/e2e_test.go) that dynamically discovers and filters the test cases.

package enginetest

bparanj

To have Claude Code apply the "Designing Errors out of Existence" philosophy to your Go codebase, you need a prompt that distinguishes between Critical Failures (which should remain errors) and State-based No-ops (which should be designed away).

The Audit & Refactor Prompt

"Audit the Go source code to identify functions that return an error but could be refactored to 'design the error out of existence' based on John Ousterhout’s philosophy. Please generate a report and suggest refactors for the following patterns:

1. Idempotent No-ops: Find functions where an error is returned for a state that already matches the desired outcome (e.g., Delete failing because a file is already gone, or Close failing on an already closed resource). If the post-condition is met, the function should succeed silently.
2. Empty-Set Safety: Find functions that return an error when a slice or map is empty. Refactor these to treat an empty input as a valid 'no-work-to-do' state rather than a

bparanj

This is a high-quality audit. A 2.1 average complexity score is healthy for a security tool, but your "Score 5" items are classic "Technical Debt" in CLI design.

Here is a 3-stage plan to refactor these commands to reveal their intent and simplify the API.

---

Phase 1: High-Impact Splits (The "Swiss Army Knives")

Goal: Decompose the "Score 5" commands into focused sub-commands.

1. Refactor stave snapshot hygiene

bparanj

Evaluate your CLI surface area against the "Simple and Focused" principle, you can use the following prompt. This instructs Claude to look for Flag Bloat, Command Overloading, and Inter-dependency Confusion.

The Evaluation Prompt

"Analyze all Cobra/CLI commands in this project to evaluate their 'Functional Focus' and 'Flag Complexity.' Please provide a report in a Markdown table with the following columns:

Command Name: The full subcommand path (e.g., stave evaluate).

Primary Intent: A one-sentence description of the single job this command performs.

bparanj

Creating a Mock Server for OpenAPI in Go

Prerequisites

• Go installed on your system
• Your OpenAPI specification file (openapi.yaml)

What We'll Use

• github.com/getkin/kin-openapi for parsing OpenAPI specs
• github.com/labstack/echo/v4 as a lightweight web framework
• Standard Go libraries for file handling and HTTP operations

bparanj

#!/bin/bash

# deploy.sh

# Put this script on your production server and make it executable with chmod
# +x. 

# Set the deploy_dir variable to the path on the production server to
# deployment directory. The script assumes the deployment directory is a git
# clone of the codebase from an upstream git repo. This script also assumes

bparanj

#!/usr/bin/env bash

# Configuration
SERVER='10.20.30.40'
DEPLOY_TO='/Users/simon/apps/some_app/staging/'
EXCLUDE='*.sqlite3 *.swp .DS_Store .git/ tmp/ log/ public/uploads/ uploads/'
DRY_RUN=false
DEPLOY_GEM_PATH='/Users/simon/.rvm/gems/ruby-1.9.2-p180'
MYSQL2_BUNDLE='/Users/simon/apps/some_app/staging/vendor/bundle/ruby/1.9.1/gems/mysql2-0.2.13/lib/mysql2/mysql2.bundle'

bparanj

def lookup_hash
  h = {}
  letter = 'a'
  count = 1
  for i in (1..26)
    h[letter] = count
    letter = letter.next
    count += 1
  end
  h