Uğur Özyılmazel vigo

Disallowing Claude from Reading Secrets

There are files you don't want your agnet to read, especially ones with secrets in them. Here's how you can prevent it:

PreToolUse Hook

In ~/.claude/settings.json (or in the project directory .claude/settings.json)

Let Claude Notify You When It Needs You

Instead of letting claude wait for me patiently, I've created a Notification hook that plays a sound to alter me.

The hook is defined in ~/.claude/settings.json

{
  // ...
 "hooks": {

You MUST NOT try and generate a Rails app from scratch on your own by generating each file. For a NEW app you MUST use rails new first to generate all of the boilerplate files necessary.
Create an app in the current directory with rails new .
Use Tailwind CSS for styling. Use --css tailwind as an option on the rails new call to do this automatically.
Use Ruby 3.2+ and Rails 8.0+ practices.
Use the default Minitest approach for testing, do not use RSpec.
Default to using SQLite in development. rails new will do this automatically but take care if you write any custom SQL that it is SQLite compatible.
An app can be built with a devcontainer such as rails new myapp --devcontainer but only do this if requested directly.
Rails apps have a lot of directories to consider, such as app, config, db, etc.
Adhere to MVC conventions: singular model names (e.g., Product) map to plural tables (products); controllers are plural.
Guard against incapable browsers accessing controllers with `allo

Go - The Ultimate Folder Structure

Organizing your Go (Golang) project's folder structure can help improve code readability, maintainability, and scalability. While there is no one-size-fits-all structure, here's a common folder structure for a Go project:

project-root/
    ├── cmd/
    │   ├── your-app-name/
    │   │   ├── main.go         # Application entry point
    │   │   └── ...             # Other application-specific files

If someone asked me the question "what layout should I use for my Go code repository?", I'd start by asking back "what are you building: an executable, or a library?"

Single executable

Stage 1: single source file

Create a directory named however you want your final executable to be called (e.g. "mycommand"), change into that directory, and create the following files:

	"""
	The most atomic way to train and run inference for a GPT in pure, dependency-free Python.
	This file is the complete algorithm.
	Everything else is just efficiency.

	@karpathy
	"""

	import os # os.path.exists
	import math # math.log, math.exp

	jobs:
	build:
	runs-on: ubuntu-latest
	steps:
	- name: Build Jekyll site
	- name: Generate CSV with MD5 Hashes
	run: \|
	cd build
	find . -type f -exec md5sum {} + \| sed 's/\.\///' \| sort -t $'\t' -k 2 > file_hashes.csv
	working-directory: ${{ github.workspace }}

	#!/bin/bash

	# Colors
	RED='\033[0;31m'
	GREEN='\033[0;32m'
	NO_COLOR='\033[0m'
	BLUE='\033[0;34m'
	YELLOW='\033[0;33m'
	NO_COLOR='\033[0m'

	VERSION = \"1.0.0\"

	PREFIX ?= out
	INCDIR = include
	SRCDIR = src
	LANG = c
	OBJDIR = .obj

	MODULE ?= binary_name
	CC ?= gcc

	-- file: migrations/00001_init_schema.down.sql

	DROP TABLE users;