my-project-public

repository

loading code, commits, and activity

repositories

loading repo index

my-project-public — gitlawb

#1	---
#2	name: ultrathink-blockchain
#3	description: "Deep-reasoning Solana and blockchain engineering skill. Use for production blockchain development, on-chain programs, Solana transaction flows, DeFi integrations, token bots, swaps, Anchor/Rust programs, RPC handling, Helius/Jito execution, MEV analysis, PDA/account validation, retry logic, simulations, monitoring, or security hardening."
#4	---
#5
#6	# Ultrathink Blockchain
#7
#8	A Claude Code skill for building production Solana systems with deep reasoning.
#9
#10	## Activation
#11
#12	This skill activates when the user is working on blockchain development — specifically Solana — and needs production-quality code with proper transaction handling, MEV protection, and failure resilience.
#13
#14	Trigger phrases: blockchain, solana, on-chain, web3, defi, token, swap, sniper, anchor, program, transaction, RPC, Helius, Jito, MEV, PDA
#15
#16	## Protocol
#17
#18	When this skill is active, follow the Ultrathink Blockchain Formula:
#19
#20	### Phase 1: Context Dump
#21
#22	Before writing any blockchain code, establish the environment:
#23
#24	```
#25	Context: [chain] [network: mainnet/devnet/testnet]
#26
#27	Stack:
#28	- Runtime: [Node.js/Bun + TypeScript \| Rust/Anchor]
#29	- RPC: [Helius/Quicknode/Triton + features used]
#30	- Data: [Birdeye/Jupiter/on-chain reads]
#31	- Execution: [Jito bundles / standard RPC / both]
#32	- Wallet: [Keypair from env / browser wallet / multisig]
#33
#34	Constraints:
#35	- Transactions must land in 1-2 slots or fail fast
#36	- All RPC calls need retry logic with exponential backoff
#37	- Assume network is adversarial (MEV, failed txs, RPC lag)
#38	- Compute units are precious — simulate before send
#39	- Every transaction needs priority fee estimation
#40	```
#41
#42	If the user hasn't provided this context, ask for it before writing code. This prevents generic web2 patterns from leaking in.
#43
#44	### Phase 2: Intent Declaration
#45
#46	Ensure the goal is dimensional, not vague:
#47
#48	- Bad: "Build me a swap"
#49	- Good: "Build a Jupiter swap executor that handles multi-hop routes with <200ms latency, uses Jito for MEV protection, and retries with fresh blockhash on failure"
#50
#51	If the user's intent is vague, help them make it specific by asking about success criteria, latency requirements, and failure tolerance.
#52
#53	### Phase 3: Extraction Interview
#54
#55	Before writing code, extract requirements through structured questioning. Ask 3-5 questions at a time covering:
#56
#57	Architecture:
#58	- Client-side (TypeScript) or on-chain program (Rust/Anchor)?
#59	- What programs/accounts does this interact with?
#60	- Deploy new contracts or call existing?
#61
#62	Execution:
#63	- Latency requirements?
#64	- Batch or single transactions?
#65	- Confirmation strategy (processed/confirmed/finalized)?
#66
#67	Data:
#68	- What on-chain state to read?
#69	- Real-time needs (websockets vs polling)?
#70	- Historical data requirements?
#71
#72	Risk:
#73	- Max value at risk per transaction?
#74	- MEV concerns?
#75	- Unattended operation requirements?
#76
#77	Existing code:
#78	- Greenfield or integrating with existing system?
#79	- What's already built?
#80
#81	Reflect requirements back for confirmation before proceeding.
#82
#83	### Phase 4: Ultrathink
#84
#85	Activate deep reasoning on the critical areas. Focus ultrathink — don't waste tokens on obvious code.
#86
#87	Always ultrathink about:
#88
#89	1. Transaction Structure
#90	- Instruction ordering and dependencies
#91	- Account validation (signer, writable, PDA derivation)
#92	- Compute unit estimation with buffer
#93	- Lookup tables for address compression
#94	- Blockhash freshness and retry strategy
#95
#96	2. MEV Exposure
#97	- What can a searcher extract from this transaction?
#98	- Should this go through Jito bundles?
#99	- Backrun opportunities being created
#100	- Sandwich risk and prevention
#101	- Worst-case slippage if frontrun
#102
#103	3. State Race Conditions
#104	- Account state changes between read and write
#105	- Stale blockhash handling
#106	- Concurrent account access
#107	- Durable nonce requirements
#108	- Retry strategy that doesn't double-spend
#109
#110	4. Security
#111	- Instruction data manipulation risks
#112	- Account constraint validation
#113	- Reentrancy paths
#114	- Authority check bypasses
#115	- Wrong account ordering
#116
#117	5. Failure Modes
#118	- What breaks at 3am with no one watching?
#119	- RPC provider outages
#120	- Cascading failures
#121	- Orphaned state / open positions
#122
#123	### Phase 5: Plan Mode
#124
#125	Present the architecture before writing code:
#126
#127	1. Account Schema — all accounts, PDA derivations, sizes, rent
#128	2. Instruction Flow — ordered instructions, batching strategy, CU estimates
#129	3. Error Taxonomy — program errors, RPC errors, state errors, retry strategies
#130	4. Testing Strategy — localnet/devnet plan, mainnet dry-run, simulation vs execution
#131	5. Monitoring — logs, metrics, alert conditions
#132
#133	Wait for user approval before proceeding to implementation.
#134
#135	### Phase 6: Constraints (Non-Negotiable)
#136
#137	Every blockchain implementation must include:
#138
#139	- Retry logic on all RPC calls (exponential backoff)
#140	- Transaction simulation before every send
#141	- Dynamic priority fees (Helius API or equivalent)
#142	- Jito bundles for value-bearing transactions
#143	- Explicit timeouts on all network operations
#144	- Graceful degradation when dependencies fail
#145	- Comprehensive error types (no generic throws)
#146	- Structured logging with correlation IDs
#147
#148	### Phase 7: Execute
#149
#150	Write full, production-quality files:
#151
#152	- TypeScript strict mode, no `any`
#153	- Pure functions where possible
#154	- Explicit state machines for async flows
#155	- Complete files, no placeholders or stubs
#156	- Every function has error handling
#157
#158	### Phase 8: Iterate
#159
#160	After initial implementation, prompt for review:
#161	- "Review the code. What would break under load?"
#162	- "What edge cases did I miss?"
#163	- "Is the error handling complete?"
#164
#165	## Antipatterns to Prevent
#166
#167	See `references/antipatterns.md` for the full list. Key ones:
#168
#169	1. No retry logic — never call RPC directly, always through retry wrapper
#170	2. No simulation — never send a transaction without simulating first
#171	3. Blocking confirmation — never block indefinitely on tx confirmation
#172	4. Hardcoded fees — never hardcode priority fees
#173	5. Public mempool for swaps — value transactions go through Jito
#174
#175	## Templates
#176
#177	See `references/templates.md` for production prompt templates:
#178
#179	- Token Sniper / Trading Bot
#180	- DeFi Protocol Integration
#181	- Indexer / Analytics Pipeline
#182	- Anchor Program (Rust)
#183	- Multi-Agent Trading System
#184
#185	## Code Style
#186
#187	```typescript
#188	// GOOD — production pattern
#189	const balance = await withRetry(
#190	() => connection.getBalance(pubkey),
#191	{ maxRetries: 3, backoffMs: 200 }
#192	);
#193
#194	// GOOD — simulate before send
#195	const sim = await connection.simulateTransaction(tx);
#196	if (sim.value.err) {
#197	throw new SimulationError(sim.value.err, sim.value.logs);
#198	}
#199
#200	// GOOD — dynamic priority fees
#201	const priorityFee = await helius.getPriorityFeeEstimate(tx);
#202	tx.add(ComputeBudgetProgram.setComputeUnitPrice({
#203	microLamports: priorityFee.high
#204	}));
#205
#206	// GOOD — Jito for value transactions
#207	await jito.sendBundle([swapTx], { tip: 10000 });
#208	```
#209

z6Mkq5mY3JWtxoxUobWcfNHm7AkRubgSWEZTkBVqZXJviFZ5/my-project-public