EthosPowerAIReference design · Automation
Phased Software Build for an Engineering Team
- GSD Core
- Claude Code
- Sandboxed container
- Git
- GitHub Actions
- Python
The problem
An integrator's engineers can now get a coding agent to write a commissioning-report tool in an afternoon. What they get is a script with no plan, no record of which limits it checks and no test anyone walked through.
What I would build
GSD Core turns a spec for the commissioning-report tool into requirements, a roadmap and phases in the repository. For each phase the engineer answers the gray-area questions from the firm's own acceptance limits and report template, the plans are checked before execution, executors commit each task atomically, and a verifier plus the engineer's acceptance test decide whether it ships. The agent runs in a sandboxed container with its permission prompts on, the GSD Core version is pinned, and CI runs on the pull request before merge.
The logic flow
Click any node for what it does, what it hands on, and where a person is required.
What it returns
I use GSD Core inside Claude Code when a build is too complex to plan in one conversation but does not warrant my IWO agentic workflow: GSD helps Claude research the problem, write the plan and carry it out phase by phase. I built the most significant phases of my Second Brain system this way, over several long programmes that moved it forward in large steps, and the loop has not once failed me. The Second Brain runs in production, and it is the evidence. This page is still a reference design for a client's build, so the figures I would watch there are cost per phase and how many verify-work failures each phase produces; GSD itself publishes no benchmark for its context claim.
Why it fits
A battery-storage integrator's commissioning engineer can now ask a coding assistant to write a script that reads her test CSVs and checks them against limits, and she will have something running by lunch. The small internal tool used to be a job she put out to a software contractor, or waited a quarter for, and now she can produce a version of it herself. A firm that answers this by letting each engineer 'vibe' a tool in one long chat session gets a folder of scripts nobody planned, nobody tested against the firm's own limits, and nobody can extend once the session that wrote them is gone.
So I would run the build as a sequence of phases, each with a written plan, a record of the decisions an engineer made, and a verification step a person walks through before anything ships. GSD Core gives that loop its shape: a roadmap and requirements in the repository, a discussion phase where the engineer answers the gray-area questions, plans checked before execution, atomic commits per task and a verifier at the end. I use GSD's loop in my own sessions. The design adds what a firm needs on top of it: the agent runs in a sandboxed container with its permission prompts kept, the GSD Core version is pinned because releases arrive roughly weekly, the firm's acceptance limits and report template sit in the repository as the source for every discussion answer, and continuous integration runs on the shipped pull request before anyone merges it.
One five-year strategy it could serve, offered as an illustration rather than a plan: treat the planning record as the asset, and the code as its by-product. An integrator whose commissioning tool carries its requirements, its decisions and its verification reports beside the code can hand a client the reason each limit sits where it does, and can rebuild the tool when the standard changes rather than reverse-engineer it. The script is cheap now. The record of why it is right is not.
See it run
Want one of these?
Every part of it is open source and self-hostable. What I bring is the build, the checks around the project's gaps, and the judgement about where your gates should sit.