Analyze GitHub Issue
Given a GitHub issue URL, perform a thorough analysis and produce a complete, actionable plan.
Repository: xrutayisire/react-js-cron
Issue URL: $ARGUMENTS
Phase 1 — Gather context
1.1 Read the issue
Use the GitHub CLI to extract everything about the issue:
# Extract the issue number from the URL
gh issue view <number> --repo xrutayisire/react-js-cron --json title,body,state,labels,assignees,milestone,createdAt,updatedAt,author,closedAt
# Read every comment with author and timestamp
gh issue view <number> --repo xrutayisire/react-js-cron --comments
Record:
- Title and full description
- Every comment (author, date, content)
- Labels, state, milestone, assignees
- Timeline of events (opened, labeled, referenced, closed)
- Any linked pull requests or related issues
1.2 Identify the reporter's intent
From the description and comments, determine:
- What is the reporter asking for?
- What behavior did they expect?
- What behavior did they observe?
- Did they provide a reproduction (code snippet, cron expression, screenshot)?
- Did they specify a version?
Phase 2 — Classify the issue
Assign exactly one primary classification:
| Classification | Criteria |
|---|---|
| Bug | The library behaves differently from what the documentation or API contract promises. Something that worked before is now broken, or a specific input produces an incorrect output. |
| Feature request | A new capability that does not exist today. The current behavior is correct but the reporter wants more. |
| Enhancement | An improvement to existing behavior (better UX, performance, accessibility) without adding a new feature. |
| Question / Support | The reporter is asking how to use something. The library may already support what they need. |
| Not actionable | Insufficient information, cannot reproduce, outside the scope of this library, or a duplicate. |
Explain the classification with evidence from the issue text. If the issue is ambiguous, state the ambiguity and provide the most likely classification.
Phase 3 — Analyze the codebase
3.1 Locate relevant code
Based on the issue content, search the codebase to find every file that is related:
- Components (
src/Cron.tsx,src/fields/*.tsx,src/components/*.tsx) - Types and interfaces (
src/types.ts) - Conversion logic (
src/converter.ts) - Utilities (
src/utils.ts) - Locale definitions (
src/locale.ts) - Styles (
src/styles.css) - Stories and tests (
src/stories/,src/tests/)
Read the relevant sections. Understand the current behavior and why it works the way it does.
3.2 Trace the code path
For bugs or enhancements, trace the exact code path involved:
- Identify which props, state variables, and callbacks are involved.
- Follow the data flow from user interaction to rendered output.
- Identify where the current behavior diverges from the expected behavior.
- Note any edge cases or related logic that could be affected by a change.
3.3 Check existing tests
# Run the test suite to see current state
yarn test --run
Review test files in src/tests/ to understand what is already covered and what gaps exist relative to this issue.
Phase 4 — Reproduce (if bug)
If the issue is classified as a bug:
4.1 Write a failing test
If possible, write a minimal test case that demonstrates the bug. Do not commit it yet — just confirm the reproduction.
4.2 Reproduce visually
If the bug is visual or interaction-based:
- Start local Storybook (
yarn storybookon port 9009) if not already running. - Navigate to the relevant story using Playwright MCP.
- Reproduce the exact steps described in the issue.
- Take screenshots documenting the current (broken) behavior.
- Compare with production (
https://xrutayisire.github.io/react-js-cron/) if the bug is a regression.
Phase 5 — Assess impact
5.1 Breaking-change analysis
Evaluate whether fixing or implementing this would break existing users:
| Impact level | Definition |
|---|---|
| None | Internal refactor, new additive prop, or bug fix that restores documented behavior. No user code changes needed. |
| Minor | Default behavior changes slightly but the previous behavior is available via a new prop or option. Migration is trivial. |
| Breaking | Existing user code would produce different results or fail to compile. Requires a semver major bump. |
For each impact level, explain specifically what would change for a user upgrading.
5.2 User experience assessment
Consider both:
- Existing users: Will their current cron expressions, configurations, or UIs change?
- New users: Will the change make the library easier to adopt, harder, or neutral?
5.3 Scope of code changes
List every file that would need to change, and estimate the complexity (trivial / moderate / significant).
Phase 6 — Produce the plan
6.1 Recommendation
State one of:
- Do nothing — Explain why (not a bug, out of scope, already works as intended, duplicate).
- Respond to the issue — If it is a question, draft a helpful reply.
- Implement — Proceed with the plan below.
6.2 Implementation plan
If the recommendation is to implement, provide:
Summary
One paragraph describing what will be done and why.
Steps
A numbered list of concrete steps. Each step should specify:
- The file to modify
- What to change (add, modify, or remove)
- Why this change is needed
- Any edge cases to handle
Props / API changes
If new props or API surface is added:
- Prop name and type
- Default value (must preserve backward compatibility)
- Description
- Example usage
Tests to add
List specific test cases that should be written:
- What input
- What expected output
- What edge cases
Stories to add or update
If the change affects the UI, specify which Storybook stories need updating or adding.
Visual verification
Describe how to visually verify the change using /visual-test to confirm no regressions.
6.3 Breaking-change justification (if applicable)
If the plan involves a breaking change, provide:
- What breaks — Exact behavior that changes.
- Who is affected — What user configurations would see different behavior.
- Why it is necessary — Why a non-breaking alternative is not feasible.
- Migration path — Step-by-step guide for users to update their code.
- Semver impact — This requires a major version bump.
Phase 7 — Draft the response
Draft a comment to post on the GitHub issue that:
- Thanks the reporter.
- Confirms or corrects the classification.
- Summarizes the findings (bug confirmed/not confirmed, feature feasibility).
- Outlines the plan at a high level (without internal implementation details).
- Sets expectations (timeline, next steps, whether a PR will follow).
Do not post the comment. Present it for review.
Output format
Present the full analysis as a structured report with these sections:
## Issue analysis: #<number> — <title>
### Classification: <Bug | Feature request | Enhancement | Question | Not actionable>
<Evidence and reasoning>
### Reproduction
<Steps taken, whether reproduced, screenshots if applicable>
### Impact assessment
<Breaking-change level, user experience impact, scope of changes>
### Recommendation: <Do nothing | Respond | Implement>
<Reasoning>
### Implementation plan
<Full plan as described in Phase 6.2, or "N/A" if not implementing>
### Suggested GitHub response
<Draft comment for the issue>
Source: xrutayisire/react-js-cron — distributed by TomeVault.