In the previous article, I ended with a small naming problem.
workbench/ no longer felt like a workbench.
Originally, it was a place for temporary material:
- investigations,
- prototypes,
- comparisons,
- drafts,
- validation output.
But review feedback changed what I was putting there.
Some findings were valid, but not part of the current work.
I wanted to keep them with enough context to revisit later without turning them into requirements or active tasks.
That meant workbench/ was starting to hold more than temporary material.
It was starting to hold work that had state.
That eventually forced me to rethink two of AIDD Skeleton's top-level areas.
workbench/ was no longer describing what it owned
A deferred review finding is not quite the same thing as a draft.
It may have:
- a reason for not acting now,
- a condition for reconsideration,
- context from the work that discovered it,
- and value across multiple conversations.
That is already much closer to retained work than temporary scratch material.
The distinction mattered because I did not want:
deferred
=
forgotten
but I also did not want:
deferred
=
promised future implementation
The repository needed somewhere to retain work without pretending that the work was currently active.
At that point, calling the area workbench/ started to feel misleading.
plans/ had the opposite problem
The other name that had become inaccurate was plans/.
It originally made sense.
That area contained things such as:
- requirements,
- design,
- testing expectations,
- project state.
But those were not really "plans."
They were the project's adopted definition.
Some described the future.
Some described the present.
Some defined what had to be true regardless of when the work happened.
So I renamed the two areas together:
plans/ → definition/
workbench/ → jobs/
The first step was intentionally just a structural rename.
I did not want a naming change and a lifecycle redesign mixed into the same change.
That separation made the migration easier to review.
PR #37: docs: rename plans and workbench domains
commit 61bc922: docs: rename plans and workbench domains
The names now described the responsibilities more directly:
definition/ adopted project definition
jobs/ retained work and work state
Project state is not the same thing as work state
Renaming the directories exposed another problem.
At the time, AIDD Skeleton still had a centralized CURRENT_STATUS.md.
That file could easily become a mixture of two different things:
What is true about the project?
and:
What are we doing next?
Those are not the same responsibility.
For example:
- "The API supports authentication" is project state.
- "Add browser coverage next" is work state.
- "Deployment has not been verified" is project state.
- "Investigate deployment verification tomorrow" is work state.
So I separated them.
The formal state of the system or application moved into the relevant definition indexes.
Things such as:
- priority,
- next work,
- temporary blockers,
- execution progress
belonged with the work itself.
Project state is not the same thing as work state.
This also meant there was less reason for one global status document to try to describe both.
PR #38: docs: move current state ownership into definition indexes
A job needed a lifecycle, not just a folder
Once jobs/ existed, another question appeared.
How should the repository distinguish:
work that is active now
from:
work worth retaining, but not active now?
I did not want every retained item to look like a current task.
I also did not want inactive work to disappear just because the current conversation had moved on.
So retained jobs gained a small lifecycle marker:
+<purpose> active
_<purpose> inactive but retained
For example:
jobs/
├── +release-validation/
└── _investigate-export-format/
The marker describes current work state.
It does not describe whether the idea is good or bad.
An inactive job is not necessarily rejected.
It is also not automatically the same thing as a deferred review finding.
A job may become inactive because it no longer needs attention now, and become active again later.
That gave the repository a simple way to preserve continuity without treating every retained item as current work.
PR #39: docs: govern Change Units and jobs lifecycle
The repository was starting to track work, not just information
AIDD Skeleton originally focused heavily on information ownership.
The question was:
Where does this information belong?
Then review automation introduced another question:
What is the agent allowed to act on now?
The jobs/ change added a third:
What state is the work itself in?
That was the real reason workbench/ became jobs/.
It was no longer only storing intermediate artifacts.
The repository was beginning to preserve continuity across conversations:
active now
retained for later
reconsidered
reactivated
without turning every retained item into a requirement or permanent commitment.
The rename was small.
The responsibility change behind it was not.
AIDD Skeleton:
https://github.com/joyrswd/AIDDSkeleton
AI disclosure: This article was written with AI assistance based on my development history, repository changes, and design decisions. I reviewed the final structure and technical claims against the AIDD Skeleton repository history.
Top comments (0)