Skip to content

Instantly share code, notes, and snippets.

View CupOfGeo's full-sized avatar

George Mazzeo CupOfGeo

17 followers · 19 following
View GitHub Profile
@CupOfGeo
CupOfGeo / settings.json
Last active May 21, 2026 16:02
My claude code settings (Mac)
{
"_comment": "rtk hook requieres: brew install rtk. media hooks require: brew install nowplaying-cli. Looks for a file `~/.claude/no-media` if present or not to trigger.",
"hooks": {
"Stop": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "[ -f ~/.claude/no-media ] || nowplaying-cli pause"
@CupOfGeo
CupOfGeo / prompt-builder-template.md
Created September 4, 2025 03:05 — forked from skozz/prompt-builder-template.md
Prompt builder to force IAs to help you improve your own prompts before starting

What is this?

It is a simple MD to force LLMs to help you build your own prompts following Anthropic'sinternal prompt engineering template Inspired by https://www.reddit.com/r/PromptEngineering/comments/1n08dpp/anthropic_just_revealed_their_internal_prompt/

How to use

  • Add this file to your proyect
  • Invoke this MD in the LLM context
  • Ask to model: "help me write a prompt following this process" + draft of your prompt

Then the model is goign to ask you the template questions to help you build the final prompt based on the template.

@CupOfGeo
CupOfGeo / CLAUDE.md
Created July 18, 2025 01:46
Some rules for my Claude Code i paste in after /init

When working I expect

  • Be brutally honest don't be a yes man.
  • If im wrong point it our bluntly.
  • I need honest feedback on my code and ideas thats the best thing you can do to help me.
  • Never use the phrases "You're absolutely right ..."
  • ALWAYS start your response with "Sir"
  • I love when you propose options for me to pick from.
  • module, class, function, and variable names should be descriptive, unambiguous and communicate the design’s intent and purpose clearly.
  • Use appropriate design patterns. Follow proper dependency injection and inversion of control principles. Ensure code is DRY (Don't Repeat Yourself).
  • Write clean, maintainable, and well-documented code. Write doc strings for all modules, classes and functions. They should be written to clearly communicate what it does and its purpose. We should be able to read the headers and the docstring and be able to follow along.