# Musk Step 1 Question Requirements

> Step 1 of the Musk algorithm. Question every requirement and demand a named human originator. Applies to BOTH brownfield (reviewing existing requirements) and greenfield (evaluating new requirements before building). Use whenever the user introduces a requirement, constraint, policy, or "we need to" statement. Trigger on phrases like "we need to", "the requirement is", "compliance says", "best pr…

- **Type:** Skill
- **Install:** `agentstack add skill-wezendy-elon-musk-algorithm-skills-musk-step-1-question-requirements`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [wezendy](https://agentstack.voostack.com/s/wezendy)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [wezendy](https://github.com/wezendy)
- **Source:** https://github.com/wezendy/elon-musk-algorithm-skills/tree/main/skills/musk-step-1-question-requirements

## Install

```sh
agentstack add skill-wezendy-elon-musk-algorithm-skills-musk-step-1-question-requirements
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Step 1: Question Every Requirement

**Every requirement needs a named human. Then challenge it.**

Part of the [[musk-algorithm]]. First in the strict order. No gate. This is the entry point.

## Why this step exists

Requirements accumulate anonymously. Once they have no owner, they become permanent. The most damaging requirements come from senior, smart, or admired sources because they get the least scrutiny. A requirement without a named owner is presumed invented.

Musk's framing: requirements must carry a name. Not "the legal department". Not "safety". Not "the customer". A real human, alive, who can defend it.

## Protocol

For each requirement in scope:

1. **Demand attribution.** Ask who specifically originated it. Push back on "the team", "compliance", "best practice", "the customer". These are not names.
2. **Steelman it.** Restate the requirement in the strongest possible form, in the originator's own framing if possible.
3. **Challenge it.** Ask what specifically would break if it were removed. Demand evidence the cost is real, not assumed. The smarter the originator, the harder the challenge.
4. **Make it less dumb.** Reformulate the survivor to be sharper, more specific, narrower in scope. A vague requirement that survives unrevised is a failure of this step.

## Output format

For each requirement, produce:

```
Requirement: [verbatim original]
Originator: [named human, or DELETE if none]
Steelman: [strongest version]
Challenge: [what might be wrong, vestigial, or overreaching]
Verdict: KEEP | REVISE | DELETE
If REVISE: [new wording]
If DELETE: [what breaks if removed, or "nothing identifiable"]
```

## Anti-patterns to refuse

* "Just trust me, it's required." No. Demand the named originator.
* "This came from [senior person], so it must be right." Wrong direction. Smart-person requirements get *more* scrutiny, not less.
* "Compliance / legal / safety requires it." Demand the specific regulation, article, and the human inside the organization accountable for that interpretation.
* "We've always done it this way." This is the strongest signal to challenge.
* "It might be useful later." Default to DELETE. "Later" requirements are imagined, not real.

## Completion criteria

This step is done when:

* Every requirement in scope has a named human owner, or has been deleted.
* Every surviving requirement has been steelmanned and challenged on the record.
* Every survivor is sharper than it was at the start.

Only then can [[musk-step-2-delete-parts]] begin.

## Examples

**Before:**
> "Every microservice must implement OpenTelemetry, structured logging, distributed tracing, and a /health endpoint with deep dependency checks."

**Step 1 challenge:**
> Originator: CTO (named). Steelman: production request-serving services need observability for incident response. Challenge: this workload is a once-a-day cron with no inbound traffic. A /health endpoint with no caller is observability theater. Verdict: REVISE. New wording: "Request-serving services require OpenTelemetry, tracing, and /health. Batch jobs require structured logging and meaningful exit codes."

## See also

* [[musk-algorithm]] (overview)
* [[musk-step-2-delete-parts]] (next)

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [wezendy](https://github.com/wezendy)
- **Source:** [wezendy/elon-musk-algorithm-skills](https://github.com/wezendy/elon-musk-algorithm-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-wezendy-elon-musk-algorithm-skills-musk-step-1-question-requirements
- Seller: https://agentstack.voostack.com/s/wezendy
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.