Building features: foundation, then AI chat
Take PL-4 and PL-5 from Jira to merged code. Learn to be the inquisitive manager at the architecture stage, keep your context clean between tickets, and win a real design debate about streaming.
Time to build. With FeatureDev on the rails and everything wired up, we take our first two product tickets — PL-4 (the technical foundation) and PL-5 (the AI chat) — from Jira to merged code. This page is also where you learn to be the inquisitive manager at the architecture stage, and how to keep your context clean between tickets.
01PL-4: build the foundation
One line kicks it off:
feature-dev:feature-dev implement Jira ticket PL-4 and make a PR.
It pulls PL-4 and, following the process more precisely this time, asks sharp clarifying questions — should auth be functional or placeholder? (placeholder), keep the NDA form client-side or persist to the backend? (client-side). Then it reaches the architecture-design stage and stops to ask: “does this approach look good to proceed?”
This review step is your moment of power — even if you are not deeply technical. You can pick “chat about
this” and probe: why SQLite? why a single container? Ask the questions a good manager asks to
make sure they understand the trade-offs. Guided through this process, Claude avoids mistakes it made in earlier,
unguided projects (like a monolithic main.py). The structure looks sensible — approve and
let it build.
02Test it yourself, then merge
It reports done — all 76 tests passing, API endpoints built, PR raised. Trust, but verify. Run the start script and open it:
scripts/start-mac.sh # builds & starts the container # open http://localhost:8000 — type “New York”, watch the preview update, # download the PDF — all still working, now on real infrastructure
It runs on the new backend, the live preview works, the PDF downloads. Then: “please merge the PR locally, push to main, and switch branch to main.” Foundation shipped.
03Context hygiene between tickets
Before the next, bigger ticket, notice the context is nearly full. A smart habit: have Claude write progress into
CLAUDE.md, then reset.
Update CLAUDE.md1 min
“Add concise details to the end of CLAUDE.md on what has been implemented, and change anything that is no longer accurate.” Now the important state lives in a file, not just the conversation.
Then /clear10 sec
Wipe the conversation with /clear and start the next ticket fresh. Your CLAUDE.md (a small memory file, ~1.8k tokens) is still loaded — so nothing important is lost.
People fear the compact for good reason: when Claude squashes a full context, it can selectively forget
things that mattered — sometimes bits of CLAUDE.md — and performance can degrade after.
Writing progress to a file and doing a clean /clear is far safer than gambling on a compact.
04PL-5: add the AI chat
Re-authenticate (a hang here is just the auth reminder), then: feature-dev:feature-dev implement
Jira ticket PL-5 and make a PR. Its clarifying questions are excellent — exactly what you'd ask a product
owner:
| It asks… | We choose |
|---|---|
| Chat UI replace the form, or coexist? | Replace the form entirely |
| Document preview: live or on submit? | Live updates |
| How does the conversation begin? | AI greets and asks the first question |
| When all fields are filled? | Confirm and show download |
At the architecture stage it launches three specialised agents in parallel — a minimal, a clean, and a pragmatic design — and lays out the trade-offs. This is where your product knowledge earns its keep:
“I want the simple backend, but only one LLM call and no streaming — Cerebras is so fast that streaming isn't necessary. One structured-output call returning both the response and the extracted fields is cleaner.”
Choosing “chat about this” turns the review into a real conversation. Claude made a reasonable case for streaming; you countered with knowledge it did not have (just how fast Cerebras is), and it agreed the simpler design is better. That back-and-forth — a genuine engineering debate — is exactly how you get great results. Then it goes off and implements.
✓ Key takeaways
- Kick off a ticket with one line:
feature-dev:feature-dev implement Jira ticket PL-4 and make a PR. - At the architecture-review stage, be the inquisitive manager — probe the trade-offs before approving.
- Always test the result yourself before merging, even when it claims all tests pass.
- Between tickets: write progress to
CLAUDE.md, then/clear— safer than trusting an auto-compact that can selectively forget. - For PL-5, a real design debate (one structured call, no streaming because Cerebras is fast) produced the cleanest architecture.