New and existing projects
HelmIt uses the same process in both cases. It first prepares the project with
setup, the product spec, architecture, and environment. Each delivery then
moves through a phase spec, implementation, and ship. What changes is where
the initial information comes from: a new project needs to define it, while
an existing project can reveal some of it through its code.
What changes during preparation
Section titled “What changes during preparation”| Step | New project | Existing project |
|---|---|---|
| Setup | Creates the HelmIt kit and installs commit protection. | Does the same and detects existing code without rewriting that code. |
| Product spec | Defines the goal, boundaries, and initial requirements. The roadmap receives the first needed phases. | Records the evolution goal and what is out of scope. Current code is the baseline; the roadmap starts without phases and grows with authorized deliveries. |
| Architecture | Defines necessary technical choices and the test, build, and lint commands. | Examines the repository to record proven technologies, commands, and conventions. It asks only about conflicts, gaps, or desired changes. |
| Environment | Checks that the environment can run the recorded commands. | Performs the same check. |
setup configures HelmIt in the repository once. A new conversation does
not require another setup; use /helmit:next to resume the project’s position.
See Install and get started if you still need to
install the plugin.
In a new project
Section titled “In a new project”Because there is no existing system to inspect, the product spec describes the intended outcome. The agent uses what you have already provided and asks only about choices still needed to define that outcome. A clear request may need no further questions.
For architecture, the agent presents options for relevant technical decisions and records the choices and commands that will verify the work. Component details that are not yet needed remain with the appropriate phase. Once the environment is ready, the delivery lifecycle begins.
In an existing project
Section titled “In an existing project”The current system is the starting point. The initial spec describes what you want to change, without trying to rewrite everything the product already does. No phase is invented to account for past work; a phase enters the roadmap when a new delivery is defined.
For architecture, the agent reads project files such as manifests, scripts, and continuous integration configuration to discover facts and commands. Established facts are recorded directly. If sources disagree, a required command is missing, or you want to change the architecture, the agent presents the choice. Findings outside the request go to the Inbox and do not interrupt preparation on their own.
After preparation
Section titled “After preparation”The path is the same again. A new delivery gets its own spec, is implemented
as tasks, and is completed by /helmit:ship. A localized correction of
something already defined may follow the CHG route outside phases, with
focused verification. An out-of-scope finding is captured in the Inbox for
triage; capture alone does not authorize a correction.
The workflow map shows where preparation ends and the repeating delivery cycle begins.