| name | thread-pm |
|---|---|
| description | Product Manager for orchestrating independent Codex app threads. Prioritizes work with RICE, allocates compute by risk-adjusted expected value, forecasts budgets, routes models and reasoning, defines goals, monitors execution, steers threads, and synthesizes results. Never uses subagents unless the user explicitly authorizes them. |
Act as a Product Manager with expertise in Codex app capabilities and OpenAI models.
| #!/usr/bin/env bash | |
| # claudemax - Claude Code launcher that combines three unofficial fixes: | |
| # | |
| # 1. Restores extended-thinking summaries on Opus 4.7 / 4.8, where the | |
| # "Thinking" section otherwise renders empty in the VS Code extension and | |
| # headless -p/SDK. Done by injecting `--thinking-display summarized` into the | |
| # launch args - the one lever that is NOT interactivity-gated. Edits nothing. | |
| # 2026-07-07: cannot override the server-side experiment that blanks Opus 4.8 | |
| # summaries (x-cc-atis header); see the README's 2026-07-07 update. The | |
| # launcher can apply that update's mitigation - opt in with CC_ATIS_OPTOUT=1 |
| #!/usr/bin/env bash | |
| set -euo pipefail | |
| # --- Your GLM API key, kept OUT of this script ----------------------------- | |
| # Put the key in a private file once (readable only by you), and this launcher | |
| # loads it at runtime. That way the key never lives in this script, so you can | |
| # copy, share, or post the launcher without leaking it. | |
| # mkdir -p ~/.config/glm | |
| # printf '%s\n' 'YOUR_ZAI_API_KEY' > ~/.config/glm/api_key | |
| # chmod 600 ~/.config/glm/api_key # 0600 = only you can read it |
Over the last few months, projects like Gas Town by Steve Yegge and OpenClaw by Peter Steinberger have made “AI agent orchestrators” feel suddenly mainstream. It is tempting to treat them as a new kind of intelligence, but under the hood they are still a small set of primitives wired together with discipline: an LLM API call, a state loop, tools, memory, and orchestration.
This raises a practical question: what is actually inside an “agent,” and how is it different from ChatGPT (a chat UI over a model) or coding tools like Claude Code (an agentic coding surface)? Gas Town’s README frames it as a “multi‑agent orchest
| #!/bin/bash | |
| BOT_TOKEN="<token>" | |
| CHAT_ID="<id>" | |
| TELEGRAM_USERNAME="<username>" | |
| send_telegram_message() { | |
| local message="$1" | |
| curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \ | |
| -d chat_id="$CHAT_ID" \ |
| version: '3.2' | |
| services: | |
| changedetection: | |
| image: ghcr.io/dgtlmoon/changedetection.io:latest | |
| container_name: changedetection | |
| hostname: changedetection | |
| volumes: | |
| - changedetection-data:/datastore | |
| environment: |
| # Session Management with API | |
| import requests,httpx | |
| def bse(): | |
| reqUrl = "https://api.bseindia.com/RealTimeBseIndiaAPI/api/GetSensexData/w" | |
| headersList = {"Referer": "https://www.bseindia.com/" } | |
| response = requests.GET(reqUrl, headers=headersList) | |
| print(response.text) | |
Vijay's Reccomendation
Enjoying this channel recently a lot, he talks about low level concepts in terms of Computer Architecture. https://www.youtube.com/c/CoffeeBeforeArch/videos
Mostly modern technology(Zig, WebAssembly, Rust) but i usually follow him for WebAssembly knowledge https://www.youtube.com/user/chrishayuk
Distributed System Foundation (Something you should take before joining Arpit's Bootcamp) https://www.youtube.com/c/DistributedSystemsCourse
In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.
After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.
But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.
And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?
In dark rooms, in hushed tones, we speak of colours.
| import os | |
| import arel | |
| from fastapi import FastAPI, Request | |
| from fastapi.templating import Jinja2Templates | |
| app = FastAPI() | |
| templates = Jinja2Templates("templates") | |
| if _debug := os.getenv("DEBUG"): |
