| name | longstrider |
| description | Longstrider is the optimization spell for systems that already work. It makes the path shorter without changing the destination. It cares about sustained pace, not flashy one-off benchmarks. |
| user-invocable | true |
Longstrider
Make the path shorter without changing the destination.
Overview
Longstrider is interpreted here as a metaphorical spell with a shipping-now execution model.
Canonical source: Longstrider (spell)
Provider target: OpenClaw
When To Use
- Trigger Longstrider when the user describes a working system that is slower than it should be and asks for speed improvements. Look for:
- Time complaints with metrics: "takes 22 minutes", "4.2 seconds to load", "p95 is 800ms", "cold start is 8 seconds"
- Optimization keywords: "bottleneck", "speed up", "optimize", "faster", "profiling", "cache", "parallelize", "batch"
- Constraint phrases: "without rewriting", "without skipping tests", "without schema changes", "quick wins", "don't want to change the product"
- Evidence of friction: "most of that is...", "the largest contentful paint is...", "single-threaded Python reading line by line"
- Measurement mindset: "before/after", "measurement plan", "profile", "identify what's happening"
Workflow
- Profile first: Identify where time, waiting, or repeated work is actually being spent. Never optimize based on vibes—demand or propose measurement of the real bottleneck.
- Smallest effective change: Choose the minimal optimization that attacks the highest-friction segment. Prefer caching, batching, parallelism, or path simplification over rewrites.
- Return the speed plan: Deliver a prioritized optimization plan with expected gains, a before-and-after measurement strategy, and a watchlist for correctness, cost, or cache-invalidation regressions.
Deliverables
- A prioritized optimization plan.
- A before-and-after measurement strategy.
- A watchlist for correctness, cost, or cache-invalidation regressions.
Guardrails
- Protect correctness and maintainability over raw speed
- Identify the real bottleneck before proposing solutions
- Flag regression risks explicitly (cache invalidation, race conditions, test integrity)
- Do not use for: Rewrites or migrations: "rewrite from Node.js to Go" → different spell
- Do not use for: Bug fixes: "deploy keeps failing due to permissions" → fix spell, not optimization
- Do not use for: Resilience patterns: "add retry logic and circuit breakers" → reliability spell
- Do not use for: Concept teaching: "explain generators and async/await" → education spell
- Do not use for: Team scaling: "write a hiring plan" → org spell
- Do not use for: Personal fitness: "optimize my training schedule" → literal misinterpretation
Default Invocation
Use $longstrider to show me how to make this workflow meaningfully faster without changing what it is supposed to accomplish.
