Chapter 44
44 / 50

GitHub Issue Analysis

⏱️ 15 min

Why Analyze Issues?

Jumping straight into code from a vague issue almost always leads to rework. Systematic analysis forces you to nail down every detail before writing a single line.

Template Sections

Break down the issue into these 10 sections:

1. Issue Summary

A brief overview of the issue:

## Issue Summary

Add OAuth2 login support for Google accounts to allow users
to sign in without creating a new password.

2. Problem Statement

Define the problem clearly:

## Problem Statement

Currently, users must create an account with email/password
to access the platform. This creates friction in the onboarding
process and reduces conversion rates.

3. Technical Approach

High-level solution and architecture decisions:

## Technical Approach

-   Use Passport.js with Google OAuth2 strategy
-   Store OAuth tokens in existing User model
-   Create new AuthProvider enum for multi-provider support
-   Implement JWT token refresh for session management

4. Implementation Plan

Step-by-step implementation tasks:

## Implementation Plan

1. Add Google OAuth credentials to environment config
2. Create OAuth callback route and controller
3. Extend User model with provider fields
4. Implement token storage and refresh logic
5. Add "Sign in with Google" button to login page
6. Handle account linking for existing users

5. Test Plan

Testing strategy and test cases:

## Test Plan

-   Unit tests for OAuth token validation
-   Integration tests for callback handling
-   E2E tests for complete login flow
-   Edge case: existing email, new OAuth provider
-   Error handling: expired tokens, revoked access

6. Files to Modify

List of existing files that need changes:

## Files to Modify

-   src/auth/auth.module.ts - Add OAuth strategy
-   src/auth/auth.controller.ts - Add OAuth routes
-   src/user/user.schema.ts - Add provider fields
-   src/config/auth.config.ts - Add OAuth config
-   frontend/pages/login.tsx - Add OAuth button

7. Files to Create

New files that need to be created:

## Files to Create

-   src/auth/strategies/google.strategy.ts
-   src/auth/dto/oauth-callback.dto.ts
-   src/auth/guards/oauth.guard.ts
-   tests/auth/oauth.e2e-spec.ts

8. Existing Utilities to Leverage

Project utilities and helpers you can reuse:

## Existing Utilities to Leverage

-   src/common/guards/jwt.guard.ts - Base guard pattern
-   src/common/decorators/user.decorator.ts - User extraction
-   src/config/config.service.ts - Environment config access

9. Success Criteria

Measurable completion criteria:

## Success Criteria

-   [ ] User can click "Sign in with Google" button
-   [ ] OAuth flow redirects and returns correctly
-   [ ] User profile is created/updated from Google data
-   [ ] JWT token is issued after successful OAuth
-   [ ] Existing users can link Google account
-   [ ] All tests pass
-   [ ] No security vulnerabilities introduced

10. Out of Scope

What's explicitly NOT part of this work:

## Out of Scope

-   Apple Sign In (future issue)
-   Facebook Login (future issue)
-   Account unlinking
-   Multiple Google accounts per user

Process

The workflow for analyzing an issue:

  1. Fetch issue details using gh issue view <issue_number>

    • Get the full issue content
  2. Review related code and project structure

    • Understand the relevant code and project layout
  3. Analyze requirements thoroughly

    • Dig deep into the requirements
  4. Create detailed technical specification

    • Write up a detailed tech spec
  5. Follow strict TDD principles, KISS approach

    • Stick to TDD and keep it simple
  6. Enforce 300-line file limit where applicable

    • Keep files under 300 lines
  7. Output the full technical specification for review

    • Ship the complete spec for team review

Full Template

# Technical Specification: [Issue Title]

Issue: #[number]
Author: [name]
Date: [date]

## 1. Issue Summary

[Brief overview]

## 2. Problem Statement

[Clear definition of what needs to be solved]

## 3. Technical Approach

[High-level solution and architecture decisions]

## 4. Implementation Plan

1. [Step 1]
2. [Step 2]
3. [Step 3]
   ...

## 5. Test Plan

-   [Test case 1]
-   [Test case 2]
    ...

## 6. Files to Modify

-   [file1.ts] - [reason]
-   [file2.ts] - [reason]

## 7. Files to Create

-   [newfile1.ts] - [purpose]
-   [newfile2.ts] - [purpose]

## 8. Existing Utilities to Leverage

-   [utility1] - [usage]
-   [utility2] - [usage]

## 9. Success Criteria

-   [ ] [Criterion 1]
-   [ ] [Criterion 2]
-   [ ] [Criterion 3]

## 10. Out of Scope

-   [Item 1]
-   [Item 2]

---

Ready for Implementation: Yes/No
Blockers: [if any]

Using AI to Help Analyze

You can have AI help analyze a GitHub issue:

Analyze this GitHub issue and generate a technical implementation spec:

[Paste issue content]

Include:
1. Problem statement
2. Technical approach
3. Implementation steps
4. Test plan
5. File change list
6. Success criteria

Summary

Systematic issue analysis:

  • Reduces rework during development
  • Clarifies scope and boundaries
  • Provides clear acceptance criteria
  • Makes team review and collaboration smoother

This is the critical step that turns vague requirements into executable code.

📚 Related resources

Common questions

Open a question to review the practical answer.

Why not just read the issue and start coding?

Diving into a vague issue usually triggers rework — undefined scope, missed dependencies, unanticipated edge cases that force architectural changes mid-implementation. The chapter's methodology decomposes the issue into 10 spec sections (Problem / Approach / Steps / Tests / Files / Reuse / Success Criteria / Out of Scope), so 30 minutes of upfront analysis saves days of churn later.

What are the 10 sections of the technical spec?

(1) Issue Summary; (2) Problem Statement; (3) Technical Approach; (4) Implementation Plan (numbered steps); (5) Test Plan (with edge cases); (6) Files to Modify (with reason); (7) Files to Create (with purpose); (8) Existing Utilities to Leverage (avoid reinventing); (9) Success Criteria (checkable boxes); (10) Out of Scope. Add one closing line: Ready for Implementation: Yes/No + Blockers.

Is the Out of Scope section actually necessary?

Yes. The chapter's OAuth example lists Out of Scope items: Apple Sign In / Facebook Login / Account unlinking / multiple Google accounts per user — extensions reviewers naturally ask "why not throw that in too". Listing them explicitly prevents scope creep (PRs ballooning) and lets reviewers see the boundary at a glance, saving three rounds of back-and-forth versus mentioning it verbally.

Why does Existing Utilities to Leverage get its own section?

It forces the developer to scan existing code before writing anything, preventing reinvented wheels. The chapter's OAuth example lists src/common/guards/jwt.guard.ts (base guard pattern) / src/common/decorators/user.decorator.ts (user extraction) / src/config/config.service.ts (env config). Writing a fresh guard adds about 200 LOC and one more maintenance surface compared with reusing — listing them explicitly is what saves that cost.

After gh issue view pulls the issue, how do I move into the spec?

The chapter's 6+ step flow: (1) gh issue view <num> for full content; (2) walk through related code and project structure; (3) deeply analyze requirements; (4) draft the detailed spec; (5) hold strict TDD + KISS; (6) keep files under 300 LOC; (7) output the full spec for review. Steps 1-3 take roughly 60% of the time — without genuine context understanding the spec is an AI hallucination of requirements, it must anchor to the issue's real content.