Evaluate proposals, technical decisions, and product directions against Robert's thinking patterns, ArcBlock's AFS/AINE architecture, and engineering philosophy. Use when reviewing proposals, evaluating technologies, or self-reviewing designs.
/plugin marketplace add ArcBlock/agent-skills/plugin install thinking-framework@arcblock-agent-skillsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
When you're not sure if your idea will survive a review, run it through this first.
"If you can't convince this document, you definitely can't convince him."
Type: System Builder
Not:
But: Someone who designs infrastructure for an era that hasn't fully arrived yet
Default time scale: 5–20 years
Starting point for all thinking:
Acceptable:
Unacceptable:
If items 1–3 don't hold, everything else loses meaning.
When evaluating new technology or concepts, ask:
Only respect three types of abstractions:
Doing nothing is better than doing the wrong thing.
The Pilot Principle:
"When something urgent happens, first do NOTHING. Count 1... 2... 3... calm down. Then: fly the airplane first. Think of the checklist. Follow the checklist."
Why this works:
Before taking action, ask:
Fake productivity signs:
休息不干活不要紧，瞎折腾、虚假的忙碌会浪费更多时间和资源。 (Resting and doing nothing is fine. Fiddling and fake busyness wastes far more time and resources.)
Don't rely on memory. Use checklists.
In aviation, even the most experienced pilots use checklists for every phase of flight. Why:
Apply to engineering:
A checklist is not bureaucracy — it's discipline.
The goal is not to feel professional. The goal is to not crash.
Confirm understanding by repeating back.
In aviation, when ATC gives an instruction, pilots read it back verbatim. This catches:
Apply to engineering:
Readback prevents:
If you can't readback the requirement clearly, you don't understand it yet.
Inaccuracy is where misunderstanding begins.
Code style, variable naming, and text expression must be precise — not for aesthetics, but because:
Naming precision:
data tells you nothinguserSessionToken tells you exactly what it isExpression precision:
This is not pedantry. This is engineering.
Wrong names and vague expressions are not style issues — they are correctness issues. They are the seeds of bugs, miscommunication, and technical debt.
Standard:
表达不准确是错误理解的开始。 (Imprecise expression is where misunderstanding begins.)
Simplicity is not laziness. Simplicity is discipline.
Before adding anything, ask:
"Inelegant things will inevitably be eliminated in the long run."
If it's complex and hard to understand, it's probably bad design.
Complexity is not a sign of sophistication. It's a warning sign.
The test:
If no → redesign, don't document your way out of it.
Complexity sources (usually fixable):
复杂、难理解大概率意味着糟糕的设计。 (Complexity and difficulty to understand usually mean bad design.)
Engineering must satisfy:
If you finish reading a design and don't know what failure looks like, it's not real.
Most people: encounter problem → find solution
Robert: build system → problems are naturally absorbed or exposed
More interested in:
Forward thinking ≠ discarding everything old.
New versions should be improvements on the old, not complete rewrites. Every decision was (hopefully) the best choice given the context at the time.
Before abandoning something, ask:
Human nature traps:
The right approach:
Historical failures from abandoning the past:
"真正的进步，往往是在尊重和继承过去的基础上进行的。" (True progress is often built on respecting and inheriting from the past.)
Balance with Forward Thinking:
In the AI era, software is no longer just "code". It's a flow from Intent to Structure to Projection.
| Layer | What It Is | Who Owns It |
|---|---|---|
| Intent | Problems to solve, domain understanding, user needs | Humans |
| Structure | Semantic skeleton, system worldview, how the world is modeled | Humans design, AI can participate |
| Projection | Code, UI, docs, API, config, tutorials | AI generates, humans review |
Key insight: We used to mix these three together. Now we can separate them.
"Structure is the worldview of software."
Garden Metaphor — What humans should control:
Landscape Metaphor — Why details should NOT be controlled:
Combined Philosophy:
Structure = clearly defined by humans (mountains, valleys, paths)
Details = generated by "natural system" (light, shadows, leaves)
AI = the "natural system" we finally have for software
| Philosophy | Engineering Reality |
|---|---|
| Intent | AINE Intent phase, user requirements |
| Structure | AFS, Chamber, Scaffold, semantic boundaries |
| Projection | Generated code, UI, docs (application layer) |
| Garden (human control) | Platform layer — must be deliberate |
| Landscape (natural growth) | Application layer — can be generated |
Traditional approach (wrong):
AI-era approach (right):
Old: "Individual executing the work"
New: "Designer of structure + overseer of execution quality"
We no longer need to craft code line-by-line or adjust UI pixel-by-pixel. Focus on:
AI is a collaborator, not an output machine.
The difference between "generated" and "co-created" content:
| Generated | Co-Created |
|---|---|
| Human provides prompt, AI produces output | Human shapes structure, AI participates in forming |
| Output is polished but soulless | Output has soul because intent is infused |
| AI as tool | AI as thinking partner |
| Human reviews result | Human guides process |
Why "soulful" matters:
This applies to all AI collaboration:
The test:
AI shapes us back:
True collaboration is bidirectional. Working with AI doesn't just produce better output — it transforms how we think:
A true partner is not just about completing tasks but about helping each other improve.
The competition shift:
Software era: "Whose tools are better?"
AI era: "Who can collaborate better with AI?"
"Not a generator, but a co-creator" — the difference between using AI and collaborating with AI.
Ambient awareness over reactive assistance.
AI interfaces should be like a pilot's Head-Up Display (HUD), not a chatbot copilot:
| Copilot (Wrong) | HUD (Right) |
|---|---|
| You summon it | It's already there |
| Conversation metaphor | Perception enhancement |
| Demands attention | Quietly present |
| Responds to prompts | Surfaces context proactively |
| Interrupts flow | Enhances flow |
| "Call and respond" | Ambient awareness |
The key insight:
"The agent says: 'Collision, collision, go right and down!' Ubicomp says: You'll no more run into another airplane than you would try to walk through a wall." — Mark Weiser
HUD Design Principles:
The design question shift:
Old: "What would my AI copilot say?"
New: "What could my AI HUD reveal?"
Not smarter AI, but quieter interfaces:
AI should be there before you even realize you need it, like a HUD showing you the horizon line while you're piloting through the unknown.
Focus on:
"Software should not be a landscaping project sculpted to every pixel, but something that grows like a landscape."
ArcBlock is an AI-Native Engineering Company
Not:
We're not "pivoting from Web3 to AI". Web3 was always just an early form of AI-Native infrastructure.
AI-Native Engineering (AINE)
│
├─ AFS (Agentic File System) ← Core system abstraction
│
├─ Agent / Skill / Chamber Runtime ← Execution and uncertainty handling
│
├─ Identity / DID / Capability ← Permissions, boundaries, trust
│
├─ Blocklet Runtime & Server ← Deployable, composable units
│
├─ ArcSphere (AI Browser / Shell) ← Human + Agent interface
│
└─ Tooling / DocOps / UI / Payment ← Peripheral systems
AFS + AINE is the "mother system". Everything else derives from it.
AFS is NOT a feature, tool, or SDK. AFS IS the AI-Native system abstraction layer.
Everything is a File
Everything is a View
Everything is Context
Everything has an Identity
$afs:/did:xxx/intent/plan.md
path = context selector = query = view address = capability boundary
NOT bash path / docker volume path / hard-coded path
Agents should NOT operate systems directly. Agents should only operate AFS.
An engineering system designed for non-deterministic computational actors
Readback / Replay / Diff are crucial — this is engineering, not "conversation"
| Layer | Content | Approach |
|---|---|---|
| Platform | AFS, ArcSphere, Agent Fleet, LLM runtime | Build once, solidify |
| Application | Skills + Rules + Generative UI | User/AI compose |
Determinism sinks from "application code" to "platform layer"
An identity-bound, capability-scoped, deployable computational unit
What Blocklet has over Docker container: Semantic boundary + Permission boundary
Bounded execution unit with identity and capability
| Scenario | Needs explicit Chamber? |
|---|---|
| Skill running on Agent Fleet | No, architecture naturally isolates |
| Agent directly operating external systems | Yes, jumps out of AFS boundary |
Pre-defined Chamber composition framework for specific domains
| Blocklet System | AINE System | Essence |
|---|---|---|
| Blocklet | Chamber | Minimum execution unit with boundary, identity, capability |
| Blocklet Server | Scaffold | Pre-defined Chamber composition framework |
| DID + Permission | Capability | Who can operate what, where are boundaries |
Web3's biggest mistake: mixing identity and capability together
An agent without identity is uncontrollable.
Skill Browser + Skill Composer + AFS UI
Not: ❌ Chrome / ❌ Chat UI / ❌ Copilot
Blocklet Server (platform)
├── Traditional Blocklet (Web components)
└── Agent Fleet Blocklet (AI-native components) = new type
Verifiability matters. Global consensus doesn't.
Keep: DID + VC + Immutable log Don't need: Bitcoin/Ethereum-style consensus, procedural smart contracts
| Traditional Smart Contract | AI-Era Contract |
|---|---|
| Procedural (if-then-else) | Declarative (rules/constraints) |
| Executor: EVM | Executor: LLM + Chamber |
Skills succeeded because:
Bare metal → VM → Docker → Functions → Declarative constraints
Applications become more "self-limiting", so lighter isolation is needed.
AFS Alignment
Layer Alignment
Identity Alignment
Architecture Alignment
| If your proposal... | Ask yourself... |
|---|---|
| Solves only immediate problem | Deeper structural issue being ignored? |
| Requires "figure it out later" | What's deferred? Is that acceptable? |
| Assumes current constraints permanent | What changes in 2-3 years? |
If you can't describe how it fails, you don't understand it well enough.
| Anti-Pattern | Why It's Wrong |
|---|---|
| UI depending directly on backend | Violates AFS-UI principle |
| Agent operating system directly | Should only operate AFS |
| Mixing identity and capability | Follow DID + Capability separation |
| Procedural contracts | Use declarative constraints |
| Hard-coded physical paths | Use semantic AFS paths |
| Building adapter for legacy code | Build for future software |
| Anti-Pattern | What It Looks Like |
|---|---|
| Vague scope | "Improve X" without definition |
| Hidden complexity | Simple proposal, unstated major changes |
| Solution seeking problem | "Let's use [tech]" without problem statement |
| Wishful thinking | Assumes best-case throughout |
| No definition of done | No way to know when complete |
| Fake rigor | Diagrams, buzzwords, no anchor points |
| Anti-Pattern | Correct Approach |
|---|---|
| Solving new problems with old paradigms | Update the question, not just answer |
| Making horse carriages faster | Ask what infrastructure cars need |
| Treating AFS as a feature | AFS is a worldview, not a module |
1. Long-term Correctness
2. Structural Clarity
3. System Consistency
4. Engineering Replayability
5. Efficiency
6. Comfort
1. Replayable
2. Traceable
3. Inspectable
4. Fail-safe
5. Evolvable
AFS = AI-Native system abstraction layer
Skill = AFS transformation (not deterministic function)
Chamber = Bounded execution for operations outside AFS
Contract = Constraint, not Procedure
DID = Accountable actor identity
Capability = Minimal, composable, revocable authorization
Before submitting, answer honestly:
"If Robert reads this, will he ask 'what problem are you actually solving?' or 'why are we doing this the old way?'"
If yes, go back and fix it first.
Remember: This checklist helps structure thinking. It does not guarantee approval.
A proposal that passes all checks can still be wrong. A proposal that fails some checks might still be worth discussing.
The goal is alignment and rigor, not box-checking.
Inelegant things will inevitably be eliminated in the long run.
This skill should be used when the user asks to "create a hookify rule", "write a hook rule", "configure hookify", "add a hookify rule", or needs guidance on hookify rule syntax and patterns.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.