Introduction
At Kerno, we are building a deeply technical product with many moving parts, requiring a lot of coordination and brainstorming. Keeping everybody in-sync means there is a greater emphasis on tracking progress, PRD quality and ticket hygiene.
When writing a ticket, it requires the engineer or the product owner to understand the intent, feature, dependencies, the broader company vision and a lot more context to make that ticket accurate and relatable. The problem is that we all have a limit to what we can retain in our heads.
For that reason discussing and defining tickets takes time and it can lead to having a bunch of tickets that are one-liners that don’t really cover the entire implementation of the feature. Besides that, not everyone is always thinking about all the edge cases and scenarios that can branch from this implementation. Suddenly, tickets become todos, versus actual tickets.
This issue was causing a lot of delays, confusion and scope creep, so I decided to build a skill that has helped our engineers.
What is a Skill?
In Claude Code and Cursor, skills are reusable instruction sets that shape how the AI behaves for a specific type of task. Instead of pasting the same system prompt into every conversation, you define it once in a SKILL.md file, and the AI picks it up automatically when you ask for a specific task to the agent.
Think of it as teaching the AI to wear a specific hat, for a specific job.
My skill makes the agent wear a Product Manager hat.
Skills are becoming fundamental to the AI-DLC, with tools like Linear and Miro becoming essential in the earlier processes.
The Problem with "Just Writing a Ticket"
When you ask an AI to "create a ticket for X", it will. It will write something coherent, probably title, description, acceptance criteria. But it'll skip all the steps that make a ticket actually useful:
- It won't ask why you're building X
- It won't push back if X is too vague or too large
- It won't check whether a similar thing already exists
- It won't think about which team owns what, or what needs to happen first
- It won’t be sure it has all the context necessary
A ticket without discovery is just a guess written down. It’s even worse than a one liner, believe me, I tried it and some descriptions were not even related to what we needed.
The Skill: A Five-Phase PM Workflow
My project-planner skill runs through five structured phases before it creates a single ticket:
- Phase 1 - Discovery: I write a first prompt defining the core idea, then the AI asks clarifying questions until both of us agree on the problem, the desired outcome, the scope, and any dependencies. It challenges vague requirements ("What does 'improve' mean specifically?") and flags if the scope is too large for one project.
- Phase 2 - Problem Framing: It drafts a structured project description using a fixed template, which includes problem statement, core idea, why we should address it, desired outcome, technical approach (if known), and explicit out-of-bounds. It presents this to me for approval before moving on.
- Phase 3 - Technical Validation: Before breaking anything into tickets, the skill explores the actual codebase. It identifies which services are affected, finds existing patterns to follow, spots potential conflicts with in-progress work, and surfaces risks. If the technical findings change the plan, it loops back to Phase 2.
- Phase 4 - Ticket Breakdown: Only after the plan is validated it writes a ticket. Each one has a clear title, description, context, acceptance criteria, technical notes and explicit out-of-scope. Tickets are right-sized (scoped to be small and quick to review), ordered by dependency, and assigned to the correct team. The skill presents a dependency graph alongside the list and it hard-stops there, waiting for my approval before creating anything.
- Phase 5 - Linear Creation: After I review and approve the plan, it creates the project and all tickets in Linear (using Linear MCP), with proper labels, states, dependencies, and links to initiatives.
Why This Works
The skill isn't doing anything that anyone couldn't do manually. The difference is consistency and friction, the context that the AI has about the product and the code base is almost unique compared to anyone else. Without the skill, it's tempting to skip straight to ticket creation, especially for small features. The skill helps to deep-dive into why you want to do a feature and really make you think before creating anything.
A few things it enforces that I used to skip:
- "Out of bounds": Every project description and ticket has an explicit exclusions section. Writing "we are NOT adding X" is often more valuable than writing what you are adding. It helps to keep the scope of the feature clear.
- Dependency order: The skill specifies not just what tickets block each other, but which branch to create from. If ticket B depends on ticket A's API, ticket B's branch should be cut from A's branch, not from main.
- Technical notes: Every ticket includes specific files and patterns to follow. Not "follow the service pattern" but "follow EventsService in apps/bff/src/app/events/". An engineer picking up a ticket shouldn't have to reverse-engineer where to start.
The Outcome
The difference in ticket quality is noticeable. Before, tickets were vague, missing context, often missing the point. Now, engineers or even other AIs pick up a ticket and know exactly what to build, what files to touch, what patterns to follow, and what's explicitly not their problem.
The planning conversation itself is also more useful. Having the AI challenge scope, flag dependencies, and surface "there's already something like this in the codebase" catches things I'd miss in a 5 minute sync.
If you work on a product with an established architecture and a project tracker, this pattern is worth trying. Start with your most painful planning bottleneck, the type of ticket that always needs two rounds of back-and-forth before an engineer can actually start and teach the AI how you'd do it.