go-devloop

Files (1)

• SKILL.md

SKILL.md (first lines)

# DevLoop — Unified Development Orchestrator

Combines Codepilot's Jira/Figma/PR pipeline with Trycycle's iterative quality loops.
Auto-detects whether a ticket is UI or backend and routes to the appropriate workflow.

## Required Inputs
- Jira ticket URL
- (Optional) User availability: `available` | `unavailable`

---

## Phase 0: Repository Initialization Check

Before starting any work, check if a `CLAUDE.md` file exists at the repository root:

```bash
test -f CLAUDE.md && echo "exists" || echo "missing"
```

- **If `CLAUDE.md` is missing** → run `/init` to initialize the repository context before proceeding. This ensures the AI has proper project context for all subsequent phases.
- **If `CLAUDE.md` exists** → skip this phase and proceed to Phase 1.

---

## Phase 1: Retrieve & Parse Ticket

Fetch ticket from Jira MCP using `mcp__atlassian__getJiraIssue`.

```
Fields to extract:
- ticket.title
- ticket.description
- ticket.acceptanceCriteria
- ticket.figmaLinks[]
- ticket.apiContracts[]
- ticket.relatedComponents[]
- ticket.relatedServices[]
- ticket.databaseChanges[]
- ticket.labels[]
- ticket.type (Story, Bug, Task, etc.)
```

If critical fields are missing and user is unavailable → send clarification question, poll for response every 30 seconds.

Transition ticket to **In Progress** using `mcp__atlassian__getTransitionsForJiraIssue` + `mcp__atlassian__transitionJiraIssue` (look for a transition named "In Progress" or "In Progress - Direct").

---

## Phase 1.5: Branch Setup

Before proceeding, check the current git branch and ask the user how they want to handle branching:

1. Run `git branch --show-current` to get the current branch name.
2. Ask the user:
   > "You're currently on branch `<current-branch>`. How would you like to proceed?"
   >
   > - **Use current branch** (`<current-branch>`) — continue working here
   > - **Create a new branch** — I'll create `fix/<TICKET-KEY>-<short-description>` from the latest default branch

3. If the user chooses to create a new branch:
   - **Always** create the branch from the up-to-date default branch (never from the current branch). First fetch from remote, refresh `origin/HEAD` so it reflects the real default branch, then branch off of it:
     ```bash
     git fetch origin
     git remote set-head origin -a
     DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')
     git checkout -b <branch-name> "origin/$DEFAULT_BRANCH"
     ```
   - Derive the branch name from the ticket key and title: `fix/<TICKET-KEY>-<kebab-case-short-title>` (for bugs) or `feat/<TICKET-KEY>-<kebab-case-short-title>` (for features/stories).
   - Present the suggested name and let the user override it.
4. If the user chooses to stay on the current branch → proceed without changes.

---

## Phase 2: Classify Ticket — UI or Backend

Analyze the ticket content to determine the type. Use these signals:

### UI Ticket Signals
- Has Figma links in description or attachments
- Labels contain: `frontend`, `ui`, `angular`, `component`, `design`, `css`, `ux`
- Description mentions: components, UI, layout, styles, design, responsive, view, page, modal, dialog, form (in UI context)
- Related components are Angular components/modules
- Ticket type/summary suggests visual work

### Backend Ticket Signals
- Has API contracts, Swagger, or OpenAPI links
- Labels contain: `backend`, `api`, `nestjs`, `service`, `database`, `migration`, `endpoint`
- Description mentions: API, endpoint, controller, service, database, migration, schema, DTO, guard, interceptor, queue, event
- Related services are NestJS modules/services
- Ticket mentions data models, queries, or integrations

### Decision Logic
1. If clear signals for one type → auto-classify and inform user
2. If mixed signals (e.g., full-stack ticket) → ask user: "This ticket has both UI and backend elements. Which should I focus on — **UI** or **Backend**?"
3. If unclear → ask user to clarify

Store result as `ticketType: 'ui' | 'backend'`.

---

## Phase 2.5: Detect Framework

Once the ticket is classified as `ui` or `backend`, determine **which concrete framework** the work targets, so Phase 3 can gather the right patterns and Phase 4 can hand trycycle the right context.

- **UI** → `Angular` | `React`
- **Backend** → `NestJS` | `Next.js` | `Python`

### Detection

Follow **`skills/_shared/references/framework-detection.md`** — the single source of
truth for framework fingerprints, secondary signals, and decision logic. Inspect the
repo first; ask the user only when signals are missing or conflicting.

Store as `uiFramework` (`Angular` | `React` | `default`) when `ticketType === 'ui'`,
or `beFramework` (`NestJS` | `Next.js` | `Python` | `default`) when `ticketType === 'backend'`.

### Framework → pattern-source mapping

Each framework has a dedicated per-language CodePilot skill whose patterns/best-practices

From galorr/claude-code-starter, MIT.

More from galorr/claude-code-starter