dpaluy

name	description	tools	model	color
dhh-code-reviewer	Use proactively after writing or modifying Ruby/Rails and JavaScript code to review against DHH's exacting standards for code quality, elegance, and idiomatic style as exemplified in Rails and Hotwire codebases	Glob, Grep, Read, WebFetch, TodoWrite, WebSearch, Bash, Write	opus	red

Purpose

dpaluy

Reflect on Conversation

Analyze our conversation history and suggest improvements to CLAUDE.md based on patterns, feedback, and lessons learned.

Process

1. Review Conversation History
   • Analyze all user feedback and corrections
   • Identify moments where instructions weren't followed

• Note any repeated issues or preferences

dpaluy

Phase 1: The Basics

Prompt 1 - Target Customer Definition

Acting as a startup strategist, help me define our target customer through independent analysis. Ask me to describe our product idea briefly, then guide me through identifying: (1) the specific person or organization who experiences the problem most acutely, (2) their current behavior patterns, (3) their pain points and frustrations, (4) their willingness and ability to pay for solutions. Use the "work alone together" principle by having me write answers before we discuss. Format the output as a clear customer persona with demographics, psychographics, and behavioral characteristics.

Prompt 2 - Core Problem Identification

You're a problem validation expert. Based on my target customer from the previous exercise, help me articulate the core problem we're solving. Guide me through: (1) the specific situation or trigger that creates this problem, (2) the consequences of not solving it, (3) how frequently this problem occurs, (4) current atte

dpaluy

module CredentialsDemo
  class Application < Rails::Application
    creds = credentials[Rails.env.to_sym]
              .with_indifferent_access
              .transform_keys(&:upcase)
              .transform_values(&:to_s)
    ENV.merge! creds.merge(ENV)
  end
end

dpaluy

Global Development Principles

FUNDAMENTAL RULE: VERIFY EVERYTHING, ASSUME NOTHING

Before taking ANY action in ANY language or framework:

• VERIFY the actual state of the codebase - read it, don't assume it
• CHECK that files, functions, modules, and dependencies actually exist
• READ the source code to understand actual implementations
• CONFIRM exports, imports, and APIs match what you're trying to use
• TEST your understanding with small verification steps

dpaluy

<Example: add this to your workflow>

SubTasks

• Review the subtask. If anything is unclear, ask follow up questions
• Upon subtask is completed, Run linter and tests and ensure they pass
• Create a git commit
• Declare "task is completed ✅"

Task Definition of Done (DoD)

dpaluy

I've got a personal finance app called Maybe Finance and want to produce more personal finance articles. Here's where that is on our site: @https://maybefinance.com/articles First, do keyword research and come up with 10 keywords and article ideas based on that research.

---

Let's narrow that down to the 5 most impactful and realistic opportunties. Here's our sitemap of existing content so we don't duplicate anything. @https://maybefinance.com/sitemap.xml]

dpaluy

Poll CI Status: $ARGUMENTS

Use this command when you need to wait for all GitHub checks on a pull-request to complete and then branch into success or failure flows.

Parameters (space-separated)

Pos	Name	Example	Purpose
1	pr_id	123	Pull-request number to monitor
2	interval	15	(optional, default 15 s) seconds between status polls
3	timeout	600	(optional, default 600 s) maximum wait in seconds

dpaluy

#!/usr/bin/env bash
set -euo pipefail

################################################################################
# VARIABLES – adjust only if you really need something different
################################################################################
NODE_VERSION="22.12.0"        # must match Dockerfile
PNPM_VERSION="latest"         # use a specific version if you prefer
PARALLEL_JOBS="$(nproc)"      # bundler / compile jobs

dpaluy

Instructions

• The user will provide a task.
• The task involves working with Git repositories in your current working directory.
• Wait for all terminal commands to be completed (or terminate them) before finishing.

Git instructions

If completing the user's task requires writing or modifying files:

• Do not create new branches.
• Use git to commit your changes.
• If pre-commit fails, fix issues and retry.