I think that it would be useful to have an ArcanistStatusWorkflow class which provides an arc status command. This command would show information about the current differential.
Example output
**NEEDS REVISION** D1234: Create an `arc status` workflow. Commit message here. **Reviewers** @epriestley requested revision. **Lint:** OKAY **Unit:** OKAY
To summarize discussion from elsewhere: it isn't clear to me when this is better than other tools -- including arc browse D123, which already exists.
One use case that was floated elsewhere was "follow up with reviewers about the status of a change", but you can already use arc list or arc branch to see that changes need review, and arc browse to open the page for the revision (and arc browse will get easier after T10895).
If you want to check which reviewers you need to follow up with and then follow up with them, you presumably need to open the browser to do step (2) anyway most of the time (e.g., leave a comment on the revision like "Hey, review this thx"). Reviewer status is prominent on the page at the top, so I think the workflow today is something like this:
It seems like arc status just adds an additional, redundant step between (1) and (2) on this workflow.
Even if you strongly prefer working on the CLI to working in the browser, it doesn't seem like this lets you shift the workflow to the CLI.
I'd like a better sense of use cases for this before building it, since without use cases I worry we're just building arc chrome-browser-cli-emulator <uri> and we might be better off supporting the CLI browser UAs like links explicitly.
T5088 is a possible use case (report if the current revision needs an update), although I feel like it's a bit flimsy.
I think this has failed to collect any compelling use cases in several years and don't plan to pursue it.
Today, experimental and wilds can open the current revision corresponding to the working copy state when "arc browse" is run.