Micheál Looney looneym

Prompt Sharing

When El Presidente wants to share specific prompting approaches or guidelines with others, I should create shareable gists containing the prompt content.

Types of Prompts to Share

Configuration sections: Portions of this CLAUDE.md file that others might find useful (like the Session Journaling guidelines)
Ephemeral prompts: Prompting techniques or frameworks we develop during a session that could benefit other teams
Workflow instructions: Step-by-step processes we've refined for specific tasks
Best practices: Guidelines we've discovered for working with Claude effectively

Session Journaling

When El Presidente asks me to "journal" about a working session, I should create a written summary that captures the engineering discussion and can be shared with the team.

Journaling Style and Structure

Tone: Casual but professional - write as an engineer summarizing a working session with El Presidente
Perspective: Third person, factual account of what we tried and learned
Length: Keep it concise - aim for 3-4 paragraphs total
No structured headings: Use flowing narrative paragraphs, not bullet points or formal sections

El Presidente and I had a working session to design a feature flag system for nexus-go to support gradual infrastructure rollouts, specifically migrating from Redis to Valkey. The challenge is that this application handles about 20M events in 10-second windows across 150 production hosts, so performance is absolutely critical.

Initially we took the obvious approach - on-demand DynamoDB lookups with local caching. Each feature flag check would hit the local cache first, then fall back to DynamoDB on a cache miss. This seemed reasonable until we did the math on the scale. At 2M events per second, even with 1-minute caching, cache misses for new features could generate millions of simultaneous DynamoDB calls. We briefly considered switching from app_id-based flags to app_stage-based flags (using the MUSTER_PROFILE env var) to reduce the lookup space, but we realized we'd still have the same rate limiting issues - every single event would still need to check the feature flag, just with a different key. We actual

	module IntercomUtil
	require 'intercom'

	TOKEN = ENV["INTERCOM_PAT"]

	@intercom = Intercom::Client.new(token: TOKEN)

	def self.get_all_conversations
	open_convos = @intercom.conversations.find_all(open: true)
	closed_convos = @intercom.conversations.find_all(open: false)

	<details>
	<summary>Summary Goes Here</summary>

	```
	lol
	```

	</details>

	original = raw_input("Enter a word")

	if len(original) >= 0 and original.isalpha():
	print original
	else:
	print "empty"

	import requests
	import os
	import json

	TOKEN = os.environ['GH']
	NEW_BRANCH_NAME = ''
	HASH = ''
	AUTHOR= ''
	REPO = ''

	import sys
	from twisted.web.static import File
	from twisted.python import log
	from twisted.web.server import Site
	from twisted.internet import reactor

	from autobahn.twisted.websocket import WebSocketServerFactory, \
	WebSocketServerProtocol

	from autobahn.twisted.resource import WebSocketResource

	helloworld:
	image: ubuntu:14.04
	command: /bin/echo 'Hello world'