From Unclear Ticket to Aligned Spec: A Before/After Walkthrough

Most vague tickets aren't the PM's fault. They're just under-scoped.

And AI won't fix that by guessing. It needs context — ideally before you ask for code.

The common pattern: developers take tickets like "Build a login form with 2FA" and immediately drop them into Claude or Copilot, asking for implementation. The output? A mess of HTML, conditional logic, and edge cases nobody asked for. More time spent rewriting than building manually.

The problem isn't the AI tool — it's the approach. Most developers treat Claude like a code generator instead of a thinking partner.

The insight: vague tickets need clarification before implementation, whether you're using AI or not. But Claude can systematically surface those questions faster than thinking through them manually.

Principle Applied: Frame First, Then Build

Instead of jumping into implementation, the better approach starts every feature with a clarification prompt. Not for code — for questions.

Here's the before/after:

❌ Before Prompt:

"Build a login form with 2FA."

✅ After Prompt (Revised):

"You are a senior frontend engineer reviewing a feature request. Your goal is to identify ambiguities and potential risks before development begins.

I'm building a login form with email + password authentication, plus optional 2FA via TOTP.

**Context:**
- Product: B2B SaaS with potential compliance requirements (e.g., SOC 2).
- Tech Stack: React, TypeScript.
- Design System: Mobile-first, with a focus on accessible error handling.
- Future Scope: We will need to handle corporate SSO (SAML/OIDC) integration in a future iteration.

Before I start coding, generate a list of clarifying questions. Focus on edge cases, user experience flows, and technical assumptions that could cause rework.

**Format your response as a markdown checklist, grouping questions by category.**"

Claude 3.5 Sonnet returned a more actionable spec

In under two minutes, this approach produces a spec that covers edge cases, UX flows, and backend assumptions — far beyond what the raw ticket provides.

Here is a checklist of clarifying questions to ensure alignment before development:

### Authentication Flow

[ ] Failed Attempts: How many failed password attempts should we allow before locking an account or triggering a CAPTCHA? What is the rate-limiting strategy?

[ ] Password Reset: Is the recovery flow self-serve via email, or is it an admin-initiated process?

[ ] Session Management: What is the session duration for a standard login? Do we need a "Remember me for 30 days" option?

### 2FA Implementation

[ ] Enrollment: Is 2FA mandatory for all users, or is it an opt-in feature? Can admins enforce it by user role?

[ ] Recovery: Will we provide single-use backup codes during the 2FA setup process?

[ ] Device Trust: Should we include a "Trust this device" option to bypass 2FA for a set period?

### UX & Accessibility

[ ] Error Messaging: Should we use a generic "Invalid credentials" message or provide specific feedback for each field (e.g., "This email address was not found")?

[ ] Loading States: What is the desired experience for loading states during authentication requests (e.g., button spinner, full-screen overlay)?

[ ] Mobile Experience: Should we consider native biometric options (Face ID/Touch ID) as a fallback or alternative to passwords on mobile?

### Technical & Architectural Assumptions

[ ] API Contract: Are the backend endpoints for authentication, 2FA validation, and session creation already defined, or do they need to be built?

[ ] Token Storage: What is the required security posture for token storage? Are we using localStorage, sessionStorage, or secure, httpOnly cookies?

[ ] SSO Prep: What specific UI elements (e.g., "Sign in with Google" button) should we placeholder now to simplify future SSO integration?

The immediate benefit

Catching requirements like SSO integration early. Without that clarification, teams build standard forms that need significant rework later. Sometimes this still requires PM clarification. But starting with Claude sharpens thinking and surfaces the right questions to ask.

Tool Setup

• Model: Claude 3.5 Sonnet (consistently excels at systematic question generation and structured thinking for this use case).

• Method: Thread-based conversation for iterative refinement.

• Template: Saved as a reusable “feature framing” template in Notion. This is a key step for scaling the practice. By creating a shared team template, you codify this "Frame First" step into your development process, ensuring every engineer starts from the same high-quality baseline and reducing variability between tickets.

Why This Works

This isn't about AI magic — it's about forcing systematic thinking before implementation. The ticket "Build a login form with 2FA" has at least 12 decision points that affect the code structure. Addressing them upfront prevents the refactor cycle where you build something, realize it doesn't handle an edge case, and rebuild with a different approach.

What's Next

Once you have clear requirements, the implementation prompts become much more targeted and useful. Instead of "build a login form," you can prompt: "build a login form that handles rate limiting after 3 attempts, includes ARIA labels for screen readers, and has placeholder space for SSO buttons."

This upgrade comes from Stage 1: Frame the Feature of Prompt-to-Production → Read the full 6-stage system