Why I stopped writing issues — Mustafa Çongara

The title sounds like I’ve been slacking. I haven’t. I’m a PM at ikas — a fast-moving SaaS company — and over the past two months, I haven’t written a single issue from scratch. Here’s why that’s actually a good thing, and how I built the system that made it possible.

The problem

We try to follow a Design → Backend → Frontend workflow. In practice, it rarely stayed that clean.

No standard. Every issue looked different. Some were too short, some too long, some missing critical context entirely.
The flow broke constantly. After design was done, backend logic would change. Once the API was finalized, we’d need to revisit the design. Every reversal made handoffs painful and error-prone.
Too many meetings. Backend → frontend technical handoffs could take hours. Context was passed verbally every single time.
PM bottleneck. We have 3 PMs, each writing in different formats and levels of detail. The inconsistency had been building up and slowing everything down.

The problem wasn’t our tooling. It was how we defined work.

Where the idea came from

A video* I watched at the end of 2025 framed something clearly for me: the quality of AI output depends entirely on the quality of your input. AI isn’t just a chat interface — it’s a function. Better input, better output.

At the same time, the team had decided to enter 2026 working more effectively. These two things collided and I had a thought: we already want to write better issues. So let’s build guides and templates for that. The team reads them, and AI uses the same structure to speed up the process.

The initial plan was simple: a one-time read, manual fill, AI as a helper.

Then it went a bit further.

Stack and folder structure

The tools I use:

Claude Code — AI agent running in the terminal. One command to start.
Figma MCP — Claude reads Figma designs directly.
Linear MCP — Claude sends issues directly to Linear.
A folder — templates, guides, outputs. Everything lives here.

The folder looks like this:

pm-workspace/
├── CLAUDE.md
├── feature-be-template.md
├── feature-be-guide.md
├── feature-fe-template.md
├── feature-fe-guide.md
├── bug-be-template.md
├── bug-be-guide.md
├── bug-fe-template.md
├── bug-fe-guide.md
├── design-new-template.md
├── design-addition-template.md
├── design-redesign-template.md
├── design-guide.md
├── sources/
│   ├── api-docs-inventory.md
│   └── ...
├── output/
│   ├── modal-contract-content.md
│   └── ...
└── tasks/
    ├── feature-be-affiliate-commission.md
    ├── feature-fe-order-list.md
    └── ...

Each issue type has two files: a template and a guide.

template → the skeleton to fill. Placeholders in brackets.
guide → explains how to fill it. Good/bad examples, tips, what to watch out for in each section.

sources/ holds external materials — API docs, meeting notes, content from another team. output/ is for intermediate deliverables: modal copy, email content, anything that’s part of the process but doesn’t go directly to Linear.

There are 7 issue types in total: Backend Feature, Frontend Feature, Backend Bug, Frontend Bug, Design (New), Design (Addition), Design (Redesign).

One more thing that’s not directly part of my system but contributes a lot: the Frontend Doc. When a backend developer makes API changes, they use a team-specific skill to prepare a structured doc and attach it to their own issue. When I start a Frontend issue, I feed that doc to Claude — so Claude has the design, the API, and the gap between them all at once.

The brain of the system: CLAUDE.md

Inside the folder, there’s a file called CLAUDE.md. This file tells Claude:

What this folder is for and how it works
The language and tone to write issues in
Which sections are required vs. optional for each template type
What to ask when a section is incomplete
Which issue type maps to which team and label in Linear — IDs included

So when I say “write a Backend Feature,” Claude already knows: this goes to the Development team, with the Feature label, following the Backend Feature template. I don’t need to say anything else.

AI guides you, not the other way around

I launch Claude from inside the folder, then start explaining the work.

Claude walks through the template section by section. It asks me about each one. It shows what it wrote and asks “does this look right?” If I’m missing something the guide covers, it redirects me with examples.

I don’t guide the AI — the AI guides me.

The more context I give upfront, the fewer questions I get. Less context, more questions. Either way, the output is always structured and complete.

When Figma MCP + Frontend Doc are both in play, things get interesting. For a Frontend issue, I give Claude the Figma link and the Frontend Doc. Claude reads both and cross-references them. It might say:

“The API has a boolean shouldRestock field but it’s not visible in the design. Should it default to true, or does the design need to be updated?”

I didn’t tell it to look for that. Claude read the doc and the design, found the inconsistency, and asked instead of assuming. If the answer is “update the design,” we can spin up a Design issue right then.

From file to Linear

When an issue is done, it saves as a .md file in the tasks/ folder.

tasks/feature-fe-inventory-management.md

Instead of copying it manually to Linear, I type one word: send

Claude reads the file and creates the issue via Linear MCP — correct team, correct label, Backlog status. Properly formatted markdown description.

From there, I take over inside Linear: I read the final issue, assign it to the right person, add it to the right cycle. I don’t want to automate this part. Who gets what and when is a decision that stays with me.

Concrete results

Speed. What used to take half a day — getting context from a backend developer, writing the issue, explaining it to frontend — now takes 10–15 minutes.

Consistency. Every issue follows the same structure.

Blind spots surface. When I describe a feature, edge cases I hadn’t thought of come up through Claude’s questions.

Less PM bottleneck. Fewer meetings, less verbal handoff, less “can you walk me through that again?”

To wrap up

The whole product team is using AI actively — each person in their own domain, for their own needs. We’re shipping faster, with fewer errors along the way, and with less time spent in alignment meetings.

Building this system took time. But what I got wasn’t just speed — it was clarity and consistency. I keep refining it as I run into new situations. I haven’t written an issue by hand in two months, but these have been the best two months of issue quality we’ve had.

*Chat is overrated. Here are 4 innovative AI product interfaces