Building with the GitHub Copilot SDK, Part 3 – Tracking Project Progress
In my previous post, we covered how to wire up the @github/copilot-sdk inside an Electron and Angular desktop app. We got authentication working, built streaming into the UI, and kept sessions separated per workspace.
In this post, we are going to use that foundation to do something different. Instead of just chatting with Copilot about code, we are going to use it to help manage project designs. Because we store our project data locally as JSON files, Copilot can read, understand, and modify those files directly.
Why does this matter?
Because knowing whether a project is on track is more than just ticking boxes. It is about understanding whether you are delivering value at the speed you expected. And that is a hard problem to answer without the right data in front of you.
Why Earned Value Matters
Most of us have been on projects where the status was “green” right up until it wasn’t. Simple percent-complete tracking doesn’t tell you much. You need a way to compare where you planned to be against where you actually are.
That is what an Earned Value (EV) chart does. It is one of the most reliable ways to answer the question: “Are we really on schedule?”
We added an Earned Value chart and a new Tracking system to Chad’s Copilot. Together, they take the guesswork out of project status.
How to Read the Chart
The chart shows two lines:
- Projected % — This is where you should be if everything went according to the original plan. Think of it as your baseline, or Planned Value.
- Actual % — This is where you actually are, based on what has been completed.
When the actual line is above the projected line, you are ahead of schedule. When it falls below, you are behind — and you can see by how much.
You should be able to read it at a glance. If you have to dig through spreadsheets or ask three people to figure out whether a project is on track, you have already lost time.
What Is Happening Behind the Scenes
Behind the scenes, the planning engine runs a full Critical Path Method (CPM) calculation. It accounts for holidays, resource limits, and dependencies. Every activity can have its own “business value” if you want to assign one; otherwise, we use duration as the weight. The engine then spreads that value across working days so the curves reflect reality.
What Surprised Me
Here is the part that surprised me.
I told Copilot: “Add a tracking tab where I can mark activities done and pick the completion date. Then use that to feed a real earned-value line on the chart.”
And it did it.
- It added the right fields to the data model (
percentComplete,actualFinishDate, etc.). - It slotted new daily-actuals logic into the existing engine without breaking forward and backward passes.
- It built a responsive
SVGline chart that auto-scales to any project length.
No copy-pasting snippets. No multi-day debugging session. Just a working, integrated feature that already understood the rest of the application’s context. In my first post in this series, I mentioned how the SDK picks up your working directory and uses it to understand your codebase. This is where that pays off. Copilot was not guessing about data structures or naming conventions — it already knew.
This is the thing I keep coming back to with the Copilot SDK. It is not just about writing code faster. It is about having a tool that understands your codebase well enough to build features that fit.
Give It a Try
If you want to experiment with this yourself, the project is open source: Chad’s Copilot on GitHub. Open the Tracking tab, mark a few activities complete, and switch to the EV Chart tab. Watch the lines tell you the story of your project.
If you have questions or want to share your experience, reach me at @chadmichel on X.
