Specgetty, spg for short, is a text-mode UI for reviewing
OpenSpec changes and specifications.
It is built for speed and focus.
Writing software has moved from typing code to reviewing what a machine proposes. The bottleneck moved with it. There are more specs and more changes to read than there used to be, and they are read in editors built for writing code rather than for reading a behaviour contract.
specgetty is built for that reading, so that you can get through more of it.
OpenSpec is the format it reads: a
project keeps its requirements under openspec/specs/ and its proposed work
under openspec/changes/, as markdown.
- Fast navigation through changes/specs/archive
- Review specs in focussed card view
- Change deltas marked added, modified, removed
- Task checkboxes ticked off in place
- Every openspec project on your machine, searchable
- Archive, discard and export a change
- Shared spec stores followed
- Unreadable specs reported with the reason and the line
With nix, which needs nothing installed first:
nix run github:speclib/specgettyA released binary, from the
latest release. The
archives are named per version and platform, spg_<version>_linux_amd64.tar.gz
and the same for darwin and arm64:
gh release download --repo speclib/specgetty --pattern 'spg_*_linux_amd64.tar.gz'
tar xzf spg_*_linux_amd64.tar.gzWith Go. The command is .../src rather than the repository root, because that
is where the program lives, and it installs a binary named src:
go install github.com/mipmip/specgetty/src@latest
mv "$(go env GOPATH)/bin/src" "$(go env GOPATH)/bin/spg"Copy config.yml to ~/.config/specgetty/config.yml and edit
to your needs. The path follows the XDG Base Directory Specification: with
$XDG_CONFIG_HOME set, the config is read from
$XDG_CONFIG_HOME/specgetty/config.yml.
spgspg opens the OpenSpec project you are standing in. It resolves it from the
working directory and starts immediately, without scanning your disk. If there
is no project there, it offers the project picker.
| Flag | Effect |
|---|---|
--view=single |
Open the project at the working directory (default) |
--view=all |
Open at the project picker |
--path <dir> |
Open that project; implies --view=single |
--change-fields=<a,b> |
Choose the change list columns |
The command line takes no positional arguments. To choose where the picker
looks, edit scandirs.include in the configuration file.
| Page | What is in it |
|---|---|
| Keys | every key, by where the keyboard is |
| Reading specs | the three levels, the vocabulary, the report view |
| Projects | the picker, stores, the cache, the properties tab |
| The change list | searching, columns, grouping, exporting |
| The editor | E, and the environment it reads |
Issues and pull requests are welcome at
github.com/speclib/specgetty. Every push runs the same
gate a change is shipped through, nix flake check, which builds the package,
vets it, runs the suite and enforces a coverage ratchet.
specgetty is itself written with OpenSpec: its behaviour lives in
openspec/specs/, and a change starts as a proposal under openspec/changes/.
The badges above count them.
- OpenSpec, the format specgetty reads
- openspec.nvim, the same specs in neovim, whose keyword vocabulary specgetty follows
- awesome-openspec, what else exists around the format
make lintMIT. See LICENSE.