Agentic Coding #4 — GTD-Based Project Management

From Ideas to Projects and Actions

Project management in the Zettelkasten is oriented toward GTD. A project is defined as anything that requires multiple work steps. An action is one such individual work step.

Everything starts with ideas. These are Obsidian documents of type Idea — short notes that arise when something occurs to you spontaneously. This happens very often during source code development with Claude Code: You are sitting there, working on the project, and something comes to mind. It gets captured as an idea immediately. One could also call these issues, but here they are called ideas.

Alongside ideas, there are also use cases as a separate document type. This comes from use-case-driven development — you simply describe what you want to be able to do, what workflow you envision. Taken together, ideas and use cases constitute the requirements.

These requirements are then translated into actions or projects. When an idea already describes a larger feature, or a use case outlines a more extensive workflow, a project is created from it. Smaller, directly implementable things become individual actions.

Projects and Their Structure

Every project is characterized by having a goal. The goal is an inline field and describes a desired state — the state in which the world, or an aspect of this world, finds itself after the project has been completed. It is the end result, not the path to get there.

A project then necessarily consists of multiple work steps, the actions. Each action is its own Obsidian document and has an inline field called "project" that references the project it belongs to. The individual actions thus know their project. Conversely, at the end of every project, there is a Dataview query that automatically lists all actions in which this project is referenced. This way, for every project you can see which actions belong to it, and for every action you can see which project it belongs to.

Projects can be structured as trees. A project can have subprojects, and those can in turn have subprojects. The actions are ultimately the leaves of this tree. So you have a graph — a root as the main project, which consists of subprojects, and at some point the leaves begin: These are the actions that belong to some project, which itself may belong to yet another project.

In this way, you have individual implementation steps — the actions — that relate to a feature. If the feature is somewhat more complex or consists of multiple parts, it becomes a project itself and is realized through multiple actions.