Delegating Work Made Me Need a Dashboard
A dashboard that grew out of PetV3 is becoming a project of its own. The current work is to fix a redesign regression while preserving the features I already use.
Following the work
Running several AI tasks in parallel on PetV3 made me consider how to extend the workflow. I could open each conversation to see what had finished and where a decision was needed. But moving between windows and reconstructing the relationships between tasks was tedious. Bringing that information together seemed like a way to increase the amount of work without increasing the effort of checking it to the same degree.
The requirements grew through use. Beyond a task list, I wanted to see the responsible session, changed files, and commit range. Related tasks needed a graph, and selecting a task should lead to its details and conversation. I approached this as a practical experiment in reducing repeated steps and making information easier to inspect, rather than as a demonstration of design expertise. I also wanted to extend the system to other projects.
To write this account, I asked the AI to review my earlier prompts and conversation records and summarize how the dashboard requirements developed. Its summary brought back the early requests and revisions described below. I used those records to put the original intentions alongside my current reflections.
Aug 30 — Navigation
The review of earlier conversations showed that reuse was already part of the idea. I asked for features tested in PetV3 to be incorporated into a shared dashboard skill. Supporting other projects is not a new ambition; PetV3 was where I discovered most of the requirements, so the implementation grew alongside it.
Once the interactive screen began working, I wanted navigation. Clicking a recent commit should open its message and details, with a way back to the previous screen. Git status should lead to remote information, and the work queue should lead to task details. The numbered menus needed to be usable entry points, not just labels.
I also requested several work-intensity settings, a custom option, and an ASCII gauge resembling a speedometer. I wanted to recognize the current setting quickly rather than read through a list of numbers. The dashboard was starting to become a tool for choosing and inspecting, rather than simply printing status.
Sep 1 — Live status
The summary also surfaced a request to show changes close to real time, with ASCII animation or loading indicators for active ChatGPT and Claude sessions. I wanted some visual character, but also a quicker way to notice which work was moving.
That introduced a distinction: a recently updated record does not prove that a process is still running. The implementation notes describe retaining question marks for inferred activity and separating animation updates from expensive data collection. A moving indicator should not imply more certainty than the underlying evidence supports.
There was already a UI regression that day. The main screen became excessively long, and clicks no longer lined up properly. I reported those problems directly. Adding information had made basic interaction harder. I then asked for the lessons from repairing the dashboard to be reflected in both the Codex and Claude skills, so the same problems would not recur in another project.
Sep 1–2 — Controls
My attention moved from watching work to adjusting it. I asked for a dashboard option that would stop work when the usage budget was exhausted, with stopping enabled by default and a way for me to adjust the intensity when needed.
A later exchange records me asking whether it had noticed the mode I had just changed in the dashboard. Changing a button or gauge on screen did not establish that the AI had read the setting or applied it to subsequent work. The selection, its delivery, and its effect on execution were separate things to check.
That experience helped define the direction of the dashboard. An interactive control also needed to show how far a request had reached. The same distinction matters for conversation links: delivery confirmation is not confirmation that the requested work is complete. Having a connection module does not establish that communication with existing Codex and Claude conversations has been verified.
Sep 3 — Graphs and identity
As the task list grew, I wanted to understand relationships rather than read more rows. My requests at the time included opening a task's details, zooming the graph with the mouse wheel, dragging to move around it, and updating project phases when the underlying work records changed.
I also asked for overlapping menu functions to be consolidated without losing their capabilities, while keeping detailed views available separately. A larger graph was not the objective. I wanted it to be easier to see which tasks depended on one another and where to look next.
The request for project-specific ASCII art, inspired by neofetch, was already present at this point. I wanted it to fit the overall design rather than appear as an unrelated decoration. The current request for different sizes and preservation of existing animation continues that direction: a recognizable interface whose artwork does not get in the way of the work.
My role
I described missing features and awkward behavior in prompts, inspected the results, and adjusted the next request. I did not personally design every implementation detail or choose the entire technology stack. My focus was whether the interface helped me understand the work and decide what to do next.
I have also been trying different models. I am now continuing with Astra, watching how well requirements survive through implementation and whether the changes work in practice. A model change alone is not evidence of improvement. The features I already rely on need to keep working too.
Sep 4–5 — Astra rework
The latest revision made that issue clear. I wanted to preserve the menus, layout, and animations while improving the graph, dragging, and click behavior. Instead, the graph became the dominant screen and existing features became harder to find. At narrower widths, the detail panel disappeared as well, leaving what looked like a graph-only dashboard.
I had asked for added functionality and bug fixes. Replacing the familiar dashboard with a simpler, different interface was not the result I wanted. I asked for the existing design and numbered menus to be retained, with the new features integrated into them. I also clarified that dragging, selection, and resizing needed to be checked together.
That rework is currently in progress. I cannot yet say the original experience has been restored or all the interactions verified. I intend to use the next revision before accepting it.
Preserving what works
This was a reminder that an improvement request needs to describe what must remain as well as what should change. Accessible menus, familiar placement, and existing animations were part of the requirements. Adding a feature does not make the result better if it makes an established task harder.
Code checks and execution tests matter, but some differences become obvious only when using a familiar interface. I delegate implementation while continuing to identify and explain those differences. The dashboard needs to be both visually clear and useful for managing the project.
Beyond one repository
Eventually, I would like someone else to install the tool and run it in their own project. It could read commits, task documents, and connected issues, then present information appropriate to that repository. I am considering a skill for initial analysis and setup, with the dashboard itself remaining a program that follows the actual state.
Commit history cannot reveal every future task or dependency. Relationships inferred by AI need to be distinguished from information established in the records. Adapting to a project means deciding which sources to use, not filling gaps with invented certainty.
Sharing the progress
For now, I want to share the process of using and improving the dashboard within PetV3. Before distributing it as an independent product, I need to resolve the current regression and see whether another project can use it through configuration without changes to the main program. That will give me a better basis for deciding when to separate the repository.
The next useful evidence is not a longer feature list. It is whether the new functionality works while preserving what was already useful, and whether that experience carries over to another project. Today, I am working through those requirements with Astra.