Key Takeaways
- We tried Notion, then Linear, then deleted both. Our project management now lives inside Claude Code: no UI, no app, just a
sprint.mdfile and a few skills. - The reason was friction. We were the bridge, hand-carrying context from Linear into Claude, then carrying updates back out. Cutting the tool cut the bridge.
- Three skills run the loop:
sprint-planning,daily-update(auto-logs what you shipped from your git commits, runs at 6pm), and a retro that scores each goal and coaches each person. The actual prompts are below, copy them. - It saved us about 20 minutes of standups a day, and the whole team was on it in around 10 days.
- It is not magic. Anything that never hits GitHub (video, Webflow) is invisible to it, there is no board, and teammates fall out of sync. We cover where it breaks.
Introduction
This is issue #002 of How We Grow, our weekly log of what we are actually doing to grow Kai. We are in closed beta now, onboarding our first users, with the public launch a few weeks out at the end of June.
This week is mostly one decision: we deleted Linear and Notion and moved our entire project-management system inside Claude Code. Jim built it, the team has run it for about three months, and it has changed how we work more than any tool switch we have made. Below is exactly how it works, the actual skill prompts so you can copy them, and the parts that still break. Then a shorter second half on the closed beta we just opened.
Prefer to watch or listen? Here's the full episode
The tools kept getting in the way
We started in Notion, like everyone. In February we moved to Linear, which is a much better project manager. Six weeks in, Jim told the team we were switching again, and this time not to another tool.
The problem was never Linear. It was that all our context lived in Linear while all our work happened in Claude Code. We would scope a task in Linear, the bullets, the files, the deadline, then copy or import that card into Claude and tell it to go build. Jim was spending his day as a bridge between the place a task was described and the place it got done.
Three frictions pushed the switch:
- The bridge. Every task meant hand-carrying context out of Linear into Claude, then carrying the result back. Pure overhead in the middle.
- The weekly updates. Every Monday we wrote project updates by pulling progress out of Claude, writing it up, and pasting it back into Linear. The same round trip, in reverse.
- The standup amnesia. You finish a packed 24 hours, it is your turn to talk, and you cannot remember what you actually did. Claude had every prompt and every commit. We were describing work to each other that the tool could already see.
What we built instead: sprints inside Claude
To be clear, we did not build an app. There is no UI and no landing page. It is a context layer: a shared sprints repo, separate from our product repos, with one file per sprint and a handful of skills around it. Jim set it up in a couple of hours, and anyone could.
The center of it is a sprint.md. Every two weeks we create one, and it is the North Star for the sprint: team goals at the top, then a section per product (Kai and Morgen), then the tasks, each with an owner and a path pointer to where the work happens. We scope tasks in plain text now, the same way we used to fill a Linear card. Three skills do the rest.
Planning the sprint
/sprint-planning starts a strategic conversation, not a form. It reads the last sprint, pulls every unfinished task, and asks me to keep, drop, or rephrase each one. Then it works through the goals with me against our growth roadmap, and writes the new sprint.md with accurate context pointers. My job goes from creating the sprint to fine-tuning it.
The /sprint-planning prompt (copy it)
Create a new two-week sprint for the team.
1. Read current/sprint.md. Pull every unfinished task (- [ ] not started,
- [~] in progress) and ask: keep, drop, or rephrase each one. Skip tasks
marked - [→] (already deferred to the backlog).
2. Ask for the goals per product (Kai, Morgen) and any team-level goals,
deadlines, and anything to explicitly exclude. Keep it conversational.
3. Read each repo's CLAUDE.md to find accurate context pointers for the tasks.
4. Write sprint.md: Team Goals (the "why") + Tasks (the "what + how + where").
Each task gets a specific title, an owner, and a file-path context pointer
(this is how /daily-update later matches commits to tasks). Under 200 lines.
5. Number the sprint, create the folder + one <name>-daily.md per member,
repoint the `current` symlink, commit, and push.
Never write secrets or personal data into sprint files.
The daily update that writes itself
This is the one that replaced the standup. Each day we run one command, /daily-update lambert, and Claude scans every commit, prompt, and bit of progress across all our repos, matches it against the sprint tasks, and writes the log for me. It reports at the topic level, not the commit level, and updates the task statuses in sprint.md on its own. Mine runs on an automation at 6pm, so most days I do not even type it.
The /daily-update prompt (copy it)
Generate a daily standup entry from git, for one person.
1. Find the sprint repo, read repos.json, and scan commits across every project
repo since this person's last log entry. Re-scan the boundary day and dedupe
on commit hash, so a late-afternoon commit never lands in a blind spot and
nothing double-posts.
2. Report at the TOPIC level ("what did I move forward?"), not the commit level.
Many commits collapse into one bullet. Keep commit hashes as HTML comments
for traceability.
3. Cross-reference the commits against the sprint tasks and update each task's
status in sprint.md automatically.
4. Show the draft, confirm, then isolated-push to the sprint repo
(fetch → temp branch from origin/main → commit → push → rebase local).
The daily log is a standup, not a changelog.
The retrospective that coaches you
At the end of each sprint, /sprint-retro reads every commit across every repo inside the sprint window, scores each goal against what actually shipped, and writes a per-person review: what you contributed, your strengths, and one concrete growth area. Because it reads what you actually did, the feedback is specific. In Sprint 4 it flagged that I, Jim, was shipping features without tests. I am a growth marketer, I do not always know what good test coverage looks like, but an agent reading my code does. I made tests a priority the next sprint, and now everything ships behind them.
The /sprint-retro prompt (copy it)
Generate an end-of-sprint retrospective across every project repo.
1. Read sprint.md: sprint number, start/end dates, the team members (from the
task owners), and the goals.
2. Read repos.json, fetch every repo, and scan all commits inside the sprint
window.
3. Score each sprint goal hit / partial / missed against what actually shipped.
4. Per person: contributions, strengths, and one concrete growth area, backed
by the commits, not vibes.
5. Write retro.md (narrative) + retro.json (a metrics snapshot) to the sprint
folder.
What it changed
The numbers are small but they compound. We cut roughly 20 minutes of daily standups, and we spend that time on strategy instead. The team was comfortable on the new system in about 10 days, and it took less work from everyone, not more. And we stopped losing things: before, small tasks that never made it into a Linear card would quietly vanish from the weekly review. Now anything we push to GitHub is in the log automatically.
Where it breaks
In the spirit of the series, the honest part. This system is not for everyone, and it is not finished:
- Anything that never touches GitHub is invisible. When I spend four hours editing a build-in-public video, or change something in Webflow on the Morgen site, there is no commit, so I log it by hand. The auto-magic only covers work that lands in git.
- It is text only, with no UI. There is no board to glance at and see, at once, which tasks are stuck. You can ask Claude to check the last few days, but you lose the at-a-glance view a real tool gives you.
- Teammates fall out of sync. It is files in a GitHub repo, so if Jim updates his log and I have not pulled, I am reading a stale version. The skills pull before they write, but it is not real-time.
- We are not sure it scales to ten people. It is great for a team of two. At ten, the sync and the missing UI would need real work. We think it is solvable, but we have not solved it.
We also opened the doors: the closed beta
The other thing that happened this week: we crossed 1,070 on the waitlist and started letting a small group into the product, before we feel ready. That is the point. No one should wait until they feel ready to launch. The earlier you get feedback, the better.
The format is a 25-minute call. Five minutes to understand who they are and where their pain is, then we hand over the product and sit silently in the background while they onboard, taking notes on every place they hesitate or something breaks. The last ten minutes are questions about how it actually felt. The loop after is fast: Kai transcribes the onboarding call itself, the notes go to the roadmap, the dev team drops the bullet points into Claude, and the fix often ships within the hour.
On growth, two things moved the waitlist more in 24 hours than the previous six days combined: Lambert launched his free Chrome extension on Product Hunt, and we ran an A/B/C/D email test to past Morgen users, who already care about productivity. Now that we have two proven paths, we lean on them into launch.
What's next
- Launch at the end of June. We do not have billing in yet, so the product is free for now, which is not where we want to be while we are testing monetization. End of June is the target.
- A content lead. We are hiring someone to own content. If that is you, the job description is linked below.
- A research layer for the sprint system. Six months in we will have a lot of sprints and tasks. The next thing to build is a semantic layer to fetch across them without burning a million tokens. A problem for later, but a real one.
If you want the system, the three prompts are above, copy them. The whole series lives at How We Grow, and signing up for early access puts each issue in your inbox.
FAQ
Should you really delete Linear or Notion to run sprints in Claude Code?
For a small AI-native team that already works inside Claude Code, it removed real friction for us. The win is that the context lives where the work happens, so there is no bridge to maintain. If your work does not mostly happen inside an agent, or you are more than a few people who need a visual board, keep the tool. This is not a universal "delete your PM tool" take, it is what fit a team of two who already lived in Claude Code.
How does Claude know what you did each day?
It reads your git commits across every repo, matches them against the sprint tasks, and writes the standup at the topic level. Work that never reaches git, like video editing or a change in a CMS such as Webflow, it cannot see, so you log that by hand.
Do you need to build an app for this?
No. There is no UI and no app. It is a separate sprints repo with one sprint.md per sprint and a few Claude skills around it. Jim set the whole thing up in a couple of hours.
What did you lose by dropping a real project-management tool?
The at-a-glance board, real-time sync between teammates, and a setup that obviously scales past a handful of people. We traded those for zero context-switching between where work is described and where it gets done. For two people, that is a clear win. At ten, we would have to rethink it.
