Uui Github Issue Workflow

GitHub Issue Workflow

When the user provides a GitHub issue URL or asks to plan work from an issue, follow this two-phase workflow. Always run Phase 1 first; only proceed to Phase 2 after the user confirms.

Trigger

Apply this skill when the user:

• Pastes a GitHub issue URL (e.g. https://github.com/epam/UUI/issues/123)
• Asks to "plan", "implement", or "fix" an issue by link
• References an issue with a github.com/.../issues/N or .../pull/N URL

Phase 1: Analysis (always run first)

Run Phase 1 to analyze scope before implementation. Do not implement yet. Limit exploration; produce a short analysis and stop.

1. Parse the URL

Extract from the URL:

• owner — e.g. epam from github.com/epam/UUI/issues/123
• repo — e.g. UUI
• issue_number — e.g. 123

Supported patterns:

• https://github.com/{owner}/{repo}/issues/{number}
• https://github.com/{owner}/{repo}/pull/{number} (PRs are issues; use issue_number from URL)

If the URL is invalid or cannot be parsed, ask the user to provide a valid github.com/.../issues/N URL.

2. Fetch Issue Content (Dual Path)

Always try GitHub MCP first. Only fall back to WebFetch if MCP is unavailable.

Step 1: Check for GitHub MCP server

Browse the MCP tool descriptors folder to find a GitHub MCP server. Look for server folders that contain GitHub-related tools (e.g. get_issue, issue_read, get-issue). Common server names: github, github-mcp, github-mcp-server.

If a GitHub MCP server is found, read its tool descriptor to get the exact tool name and parameters, then call it:

CallMcpTool
  server: <discovered GitHub MCP server name>
  toolName: <issue read tool from descriptor>
  arguments: { owner, repo, issue_number }

• MCP returns structured JSON with title, body, labels, state, etc.
• If the call succeeds, use the response directly.

Step 2: Fall back to WebFetch (only if MCP is not available or fails)

If no GitHub MCP server is configured, or the MCP call fails:

• Use WebFetch with the full issue URL
• Parse the returned content (markdown/HTML) to extract:
  • Issue title (from page heading or title element)
  • Issue description/body
  • Labels or type indicators if visible

3. Produce Short Analysis (Phase 1 only)

Based on the issue content, produce a concise analysis:

4. Stop and Ask for Confirmation

Do not create a full implementation plan or make any code changes.

Present the analysis and ask:

"Here's my analysis. Proceed with full implementation? Any changes to scope or approach?"

Wait for the user to confirm or request changes. Only after explicit confirmation (e.g. "yes", "proceed", "go ahead") move to Phase 2.

Phase 2: Implementation (only after user confirms)

Run Phase 2 only when the user has approved the analysis or provided adjustments.

1. Create Full Implementation Plan

Produce a structured plan with these sections:

2. Output Format (Phase 2)

Use this template:

## Implementation Plan: #[issue_number] [Title]

### Summary
- **Type:** [bug|feature|refactor|docs]
- **Key points:** [bullet points from description]

### Branch
`fix/123-description` / `feature/456-description`

### Affected Areas
- Package: ...
- Files: ...

### Steps
1. ...
2. ...

### Testing
- Unit: ...
- E2E: (if UI changes)

### Documentation
- (if API changes)

### Checklist
- [ ] yarn test
- [ ] yarn test-update (if UI)
- [ ] yarn test-e2e (if UI)
- [ ] yarn eslint, yarn stylelint
- [ ] yarn track-bundle-size
- [ ] changelog.md

3. Execute Implementation

After presenting the plan, proceed with implementation steps as approved by the user.

Edge Cases

References

• Branch naming, checklist: pr-contributing
• Component patterns: components
• Doc examples, Property Explorer: documentation
• Unit tests: unit-testing
• E2E/screenshot tests: e2e-testing