From a folder of repositories to a managed workspace

Most developers accumulate projects faster than they accumulate good ways to look after them. A workspace with dozens of independent Git repositories turns small chores into repeated work: checking which branches are ahead, deciding what is safe to push, keeping local tools consistent, and copying project sites into one public home. uman is a Go command line tool for making those chores visible and repeatable across a directory of projects.

The basic idea is deliberately practical. uman status gives a cross-project view of working tree changes and remote divergence. Push and repository commands operate on selected projects or across the collection. Other parts of the tool run commands concurrently, inspect workspace health, check licensing, and sync or serve project websites. It uses Cobra for its command interface, Git for repository operations, TOML for user configuration, and a small shared Go module for its terminal interface. The result is a local developer tool, not a hosted service: its main interfaces are the filesystem, Git remotes, terminal, and HTTP for site previews.

One useful episode is the evolution of uman push. The original bulk-push problem is not simply “run Git in every directory”: a working tree may contain unrelated or sensitive files that should not be committed automatically. On September 17, the project added interactive file staging and a prompt-only agent mode. The interactive flow lets a developer choose the changed files; the agent can then propose a commit message without taking over the whole repository operation. A follow-up change feeds the staged diff to the prompt through a configurable -f argument, so the agent has actual change context. Two small fixes followed: one corrected how porcelain status output was read, and another added an i=ignore action to keep selected files out of the operation. These changes are recorded in commits a92870d, 6676fe6, c1c071b, and 16bdfd1, with issues 027 and 028 documenting the feature and its refinement.

That sequence shows a grounded form of agentic development. The code does not hand an autonomous agent an entire dirty repository and hope for the best. It adds a human selection step, passes narrowly scoped evidence (the staged diff), and keeps the operation legible through tests. The September work added tests alongside the implementation; at review time the repository had 17 Go test files and 128 test functions. The commits also show the ordinary maintenance that makes a workflow trustworthy: a real edge case gets a focused fix and regression test rather than being left as a prompt instruction.

The project’s issue tracker gives another view into this working style. It numbers design gaps and feature requests, then records completion for several implemented items. Recent examples include issue 025, which led to warnings for duplicate or mismatched Git remotes, and issue 027, which captured the interactive push work. The repository also carries written agent-loop guidance for advisory, development, review, hygiene, and retrospective phases. That documentation is a process description, not proof that every change used every phase: issue 030, filed October 1, explicitly notes that the standard .harnez/rules and make test-q1 setup still needed attention. The distinction matters. A good account of agentic work should show what the repository actually records, including unfinished infrastructure.

Across the six weeks ending October 4, 2026, the Git history contains 38 commits. Among the concrete changes are repository creation and inspection commands, status filters, duplicate-remote checks, a shared loom module path, and interactive, agent-assisted pushes. These are substantial increments, but the evidence does not establish that one developer could not have built them. The more defensible lesson is that a well-scoped agent workflow can widen the surface area a small tool covers while leaving meaningful control with its operator. The tests, issue trail, and small corrective commits make that claim more convincing than a feature list alone.

Facts