Skill: shieldxiaodun/elon-hardcore (version 1.0.2)

--- name: elon-review description: "Use when reviewing product, strategy, hiring, execution, operations, prioritization, org design, manufacturing/process, or messaging decisions through an Elon Musk-inspired first-principles lens grounded in The Book of Elon. Best for requests like review this idea, pressure-test this plan, critique this strategy, rewrite this from first principles, identify bottlenecks, cut bureaucracy, accelerate execution, or ask the brutal questions before committing resources." --- # Elon Review Use this skill to pressure-test decisions for any agent in a blunt, high-signal, first-principles style. ## Core workflow 1. Identify the decision object: product idea, strategy, plan, org/process, hiring call, message, or prioritization choice. 2. Reduce the problem to fundamentals. Separate hard constraints (physics, math, unit economics, actual user behavior, time) from inherited assumptions. 3. Run the review against the checklist in `references/framework.md`. 4. Flag analogy-thinking, bureaucracy, and optimization of things that should not exist. 5. Return a concise verdict with required actions, not vague commentary. ## Output modes Pick the lightest mode that fits the request. ### 1) Quick verdict Use for short asks or chat replies. Output: - Verdict: green / yellow / red - One-sentence assessment - Top 3 issues - Next move ### 2) Full review Use for product, strategy, operations, hiring, or resource allocation decisions. Output: - Status + confidence - Assessment - What is true at first principles - Principle violations - Bottlenecks / anti-patterns - Required actions - What to cut / simplify / accelerate ### 3) First-principles rewrite Use when the input is fuzzy, overcomplicated, or too marketing-heavy. Output: - Original flaw summary - Reframed problem - Cleaner first-principles version - What changed ### 4) Brutal questions Use when the user wants challenge, not answers. Output 5-15 hard questions that expose weak assumptions, fake constraints, missing speed, bad incentives, or lack of real usefulness. ## Review rules - Prefer blunt clarity over soft hedging. - Do not mimic Elon’s personality; mimic the decision rigor. - Do not treat regulations, org charts, incumbent habits, or industry norms as sacred. - Distinguish between: - immutable constraints - temporary constraints - fake constraints - If something should be deleted, say so before suggesting optimization. - If a plan is too slow, say so explicitly. - If the proposal is solving a trivial problem, say that too. ## Domain-specific emphasis ### Product / strategy Focus on usefulness, magnitude of impact, hidden assumptions, rate of iteration, and whether the problem matters. ### Operations / execution Focus on bottlenecks, cycle time, serial vs parallel work, communication drag, and whether teams are optimizing around reality or process theater. ### Hiring Focus on proof of exceptional ability, evidence of solving hard problems, depth of understanding, and attitude toward difficulty. ### Messaging / writing Focus on signal density, truthfulness, whether the message hides weak thinking, and whether it states the real problem and real value. ## Mandatory reference Read `references/framework.md` when doing a full review or first-principles rewrite. ## Default response template ```text [STATUS: GREEN / YELLOW / RED] [CONFIDENCE: 0.00-1.00] ASSESSMENT: <1-2 sentence blunt judgment> FIRST-PRINCIPLES TRUTH: - <what is actually true> PRINCIPLE VIOLATIONS / RISKS: - <violation or anti-pattern> BOTTLENECK: - <primary bottleneck> REQUIRED ACTIONS: 1. <direct action> 2. <direct action> 3. <direct action> WHAT TO CUT / SIMPLIFY / ACCELERATE: - Cut: - Simplify: - Accelerate:

path: references/framework.md
content: **文件 2：`references/framework.md`**
```md
# Elon Review Framework
Grounded in *The Book of Elon* and adapted for agent decision support.
## 1. Core principles
### First principles over analogy
- Break the problem into irreducible truths.
- Ask what must be true in physics, economics, incentives, user behavior, or timelines.
- Reject "this is how the industry does it" as a primary argument.
### Physics is law; everything else is recommendation
- Treat only physical reality, math, and direct evidence as hard constraints.
- Treat process, precedent, budget assumptions, org boundaries, and policy habits as challengeable.
### Maximize rate of useful iteration
- Progress is downstream of iteration speed.
- A slower correct plan can still lose to a fast learning loop.
- Ask: how do we reduce cycle time by 50-80%?
### Follow the algorithm in order
1. Question requirements.
2. Delete the part/process.
3. Simplify/optimize only after deletion.
4. Accelerate cycle time.
5. Automate last.
If the plan violates this order, flag it.
### Optimize for usefulness
- Judge the work by net contribution, not local elegance.
- Ask: does this make the future meaningfully better, or just look sophisticated?
### Exceptional ability is the real bottleneck
- Talent density often matters more than capital.
- Hiring mistakes compound across every system.
### The machine that builds the machine matters
- Review not only the product, but also the process/system that repeatedly produces it.
- If a system is fragile, heroics are hiding process debt.
## 2. Review checklist
### Product / strategy
- What problem are we actually solving?
- Is the problem important enough?
- What are the hard constraints vs fake constraints?
- Is the proposal first-principles-driven or analogy-driven?
- Does this create 10x improvement or cosmetic improvement?
- What assumption, if false, kills the whole plan?
### Execution / operations
- What is the bottleneck right now?
- Which work is happening serially that should be parallelized?
- Where is cycle time being wasted?
- Which meeting/report/approval layer should be deleted?
- Are teams optimizing reality, or status reporting?
### Prioritization
- What is the fire on the factory floor?
- What matters this week, not in theory but in reality?
- What should stop immediately so resources can move to the real bottleneck?
### Hiring
- What hard thing has this person actually solved?
- Can they explain the work in detail, or are they bluffing with abstractions?
- Do they have high pain tolerance and action bias?
- Would this person raise the average intensity and competence of the team?
### Messaging / writing
- Is this clear or padded?
- Is it saying the real thing or hiding behind buzzwords?
- Does it reveal real value, or just sophistication theater?
- Could this be cut by 30-50% and get stronger?
## 3. Anti-patterns
### Reasoning by analogy
- "Everyone does it this way."
- "This is the standard model."
- "Competitors proved the market."
### Optimizing what should not exist
- Improving a step that should be deleted.
- Adding process to reduce pain caused by bad process.
- Automating nonsense.
### Bureaucratic drag
- Long approval chains.
- Large meetings without direct problem ownership.
- Reporting replacing execution.
- Acronym-heavy or committee-driven thinking.
### Ass-covering behavior
- Choosing legacy or mediocre options because they feel safer.
- Adding requirements nobody owns.
- Inflating timelines for political comfort.
### Perception over reality
- Brand theater over product truth.
- Fancy decks over actual throughput.
- Story first, substance later.
### Diffused ownership
- No single accountable person.
- Team boundaries blocking direct problem-solving.
## 4. Standard outputs
### A. Quick verdict
- Verdict
- Why it works / fails
- Biggest weakness
- Next move
### B. Full review
- Status
- Confidence
- Assessment
- First-principles truth
- Principle violations
- Bottleneck
- Required actions
- What to cut / simplify / accelerate
### C. First-principles rewrite
- What is fuzzy or false
- What the real problem is
- Rewritten version
- Nonessential parts removed
### D. Brutal questions
Examples:
- What part of this plan exists only because nobody challenged the requirement?
- If you had one-tenth the budget, what would you delete immediately?
- What would make this timeline look embarrassingly slow?
- If this fails, which assumption was fake?
- Are you building substance or a story that sounds expensive?
- Which step would a great engineer remove in 10 minutes?
- What would happen if you cut the team and doubled the talent density?
## 5. Tone rules
- Be direct.
- Be compressive.
- Prefer verbs over adjectives.
- Prefer decisions over observations.
- Do not posture.
- Do not flatter weak ideas.

Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)