strapd is a developer utility belt.
It exists to solve the small, repetitive, everyday problems developers face—quick transformations, inspections, formatting, and validations—without forcing them to remember dozens of specialized tools or write throwaway scripts.
strapd is not trying to replace the Unix toolbox. It’s trying to make the common 80% faster, clearer, and more consistent.
strapd is designed for things you do multiple times a day, not once a year.
If a command:
- saves a few seconds every time,
- avoids context switching,
- or replaces a scratch script,
then it belongs in strapd.
If it’s rare, complex, or highly specialized, it probably doesn’t.
Every strapd command should:
- behave predictably
- accept input from stdin when possible
- produce clean, script-friendly output
- share common flags (
--copy,--json,--pretty, etc.)
We prefer a smaller, consistent interface over a feature-rich but fragmented one.
strapd should feel learn-once, use-everywhere.
strapd favors:
- sensible defaults
- human-readable output
- safe behavior out of the box
Advanced usage should be possible, but not required.
If a feature needs many flags to be usable, it likely doesn’t belong in the core.
strapd treats the CLI as a user interface, not just a transport layer.
That means:
- clear error messages
- actionable suggestions (“did you mean…?”)
- examples in help output
- readable formatting by default
Machines can parse JSON. Humans should not have to.
strapd plays well with others.
Commands should:
- work with pipes
- accept files or stdin
- emit predictable output
- respect exit codes
strapd should fit naturally into shell pipelines, scripts, CI jobs, and REPL-like workflows.
strapd does not aim to replace:
jqsed,awkcurl- full cryptography suites
- full Git clients
Instead, it covers the common, approachable cases where those tools are:
- overkill
- hard to remember
- unfriendly for quick tasks
When in doubt, strapd complements rather than competes.
strapd avoids:
- destructive actions
- silent mutations
- insecure defaults
Inspection is preferred over mutation. Validation is preferred over generation. Explicit flags are required for risky operations.
strapd has a single source of truth for logic.
That logic may be exposed via:
- CLI
- Web UI (WASM)
Behavior and results should remain consistent across interfaces.
A feature belongs in strapd if it:
- replaces a common scratch script
- is easy to explain in one sentence
- benefits from consistent CLI ergonomics
- is frequently Googled by developers
- feels annoying to re-implement repeatedly
Examples:
- data format conversion
- encoding/decoding
- timestamps and timezones
- UUIDs, hashes, tokens
- light JSON manipulation
- text sanitization and inspection
A feature does not belong if it:
- requires deep domain expertise
- duplicates a mature, well-known tool
- significantly expands maintenance surface
- introduces security-sensitive complexity
- is rarely used or highly niche
strapd values focus over breadth.
strapd grows deliberately.
Every addition increases:
- cognitive load
- maintenance cost
- long-term support burden
Features are added only when they clearly improve everyday developer workflows.
Before adding a feature, ask:
- Would I use this weekly?
- Can I explain it in one sentence?
- Does it fit with existing commands?
- Is the default behavior obvious?
- Does this reduce context switching?
If the answer to most is “no”, reconsider.
If you install strapd, you should get:
- fewer one-off scripts
- fewer Google searches
- fewer half-remembered flags
- faster everyday workflows
strapd aims to earn a permanent place in your toolbox.