"3 step" + a link to a paper/article/report is standing shorthand for: read the full source (not just abstract or preview), then write one continuous summary in three layers of increasing length. Layer 1 is one paragraph: the whole piece at maximum compression, a complete stopping point on its own. Layer 2 is two paragraphs that continue from Layer 1 without restating it, adding the next tier of detail (mechanism, key evidence, how the result was produced). Layer 3 is three paragraphs that continue from Layer 2 (methodology specifics, numbers, context, limitations, implications). Every prefix (1, 1+2, 1+2+3) must read as a self-contained summary at its depth. Mark the three layers visibly so the reader can stop at a boundary: a short bold label on its own line before each layer ("Layer 1", "Layer 2", "Layer 3"). No other headers or formatting inside the layers. Nothing is repeated across layers; each only adds. Compression is the point; analysis serves it. Write in plain, direct sentences for a smart reader o
You are auditing the complete online presence of one person: [NAME]. Not just their website — everything a search engine, an AI assistant, or a stranger doing due diligence would find. Your deliverable is an honest, evidence-backed report with a prioritized action plan. You change nothing; you only measure, diagnose, and recommend.
This prompt is self-contained, but if you are a Claude Code-style agent with shell access, first install the open-source claude-seo skill (MIT) for deeper site tooling — it is optional, not required:
git clone --depth 1 https://github.com/AgriciDaniel/claude-seo.git && bash claude-seo/install.shAnthropic's Claude Code CLI source code leaked onto GitHub recently. All of it. About 1,900 files and a lot of TypeScript.
I read through the key modules. What follows is a breakdown of the surprising parts: how the system actually works, where Anthropic made clever engineering choices, and where their approach diverges from OpenAI's Codex in ways you wouldn't guess from using either tool.
Here's what happens when you type a message into Claude Code:
I expected the differences between AI coding agents to be in how they call the LLM. They're not. The API call is trivial -- a streaming HTTP request with a JSON payload. Every agent does it essentially the same way.
What makes these tools different -- what makes them products -- is everything wrapped around that API call: the 40 tools that give the AI hands, the permission systems that keep it from breaking things, the compaction strategies that prevent it from forgetting what it's doing, and the prompt engineering that shapes how it thinks.
I cloned the source code for all four major AI coding agents -- Claude Code (from a leaked copy of Anthropic's proprietary source), OpenAI's Codex CLI, Cline (the popular VS Code extension), and OpenCode (an open-source Go CLI) -- and read through their internals. What I found reveals four competing philosophies about a fundamental question: **how much should you trust an AI with your c
| interface Lender { | |
| function goWild() external; | |
| } | |
| contract FlashERC20 is ERC20 { | |
| using SafeMath for uint256; | |
| function flash(uint256 amount) external { | |
| balances[msg.sender] = balances[msg.sender].add(amount); | |
| Lender(msg.sender).goWild(); |
| // From: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp | |
| vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd | |
| vSeeds.emplace_back("dnsseed.bluematt.me"); // Matt Corallo, only supports x9 | |
| vSeeds.emplace_back("dnsseed.bitcoin.dashjr.org"); // Luke Dashjr | |
| vSeeds.emplace_back("seed.bitcoinstats.com"); // Christian Decker, supports x1 - xf | |
| vSeeds.emplace_back("seed.bitcoin.jonasschnelli.ch"); // Jonas Schnelli, only supports x1, x5, x9, and xd | |
| vSeeds.emplace_back("seed.btc.petertodd.org"); // Peter Todd, only supports x1, x5, x9, and xd | |
| vSeeds.emplace_back("seed.bitcoin.sprovoost.nl"); // Sjors Provoost | |
| vSeeds.emplace_back("dnsseed.emzy.de"); // Stephan Oeste |
- Ethereum 2.0 spec pre-release
- Released yesterday!
- Proof of stake and sharding have been part of the ETH roadmap since 2014
- Started with Slasher in 2014, which is totally broken
- But since then have made a lot of progress
- Casper FFG devised and formally verified
- Sharding is now better specified
- How can we do computing on distributed ledgers?
- Many existing systems for smart contract execution
- Ethereum, Tezos, EOS, etc.
- They all work through re-computation—every party redundantly performs the computations to agree on state
- This comes with scalability tradeoffs
- Recomputing all of these programs is costly
- Many existing systems for smart contract execution
- Weakest computers (e.g. cell phones) can't keep up recomputing all transactions
- What is formal verification?
- Process of specifying and verifying the behavior of programs
- Specification: mathematical description of intended program behavior
- Verification: operational semantics of a language -> spec -> proof
- There are 4 different "flavors" of assurances that formal verification can provide
-
- Smart contract bytecode verification - "Full description of EVM behavior"
-
- What can happen over the course of one transaction?