teamcraft-jcg:fast-path

What this skill does

## Goal

Move from urgent problem to reviewed, committed implementation as fast as possible — without skipping the quality gates that prevent urgent fixes from creating new emergencies.

`$ARGUMENTS` is the starting description of the problem. Use it. Do not ask the developer to repeat what they already told you.

## Hard Constraints

- This skill runs in Claude Code only. It requires codebase access, local filesystem, and git.
- **Never use Claude Code's built-in plan mode.** Do not call EnterPlanMode or ExitPlanMode. This skill runs in normal conversational context throughout.
- Never create the Jira issue without showing the draft and getting explicit approval. Urgency does not override issue review.
- Never begin implementation without showing the plan and getting explicit approval. A plan approved at speed is still an approved plan. "Approval" means the developer says yes in the conversation — not plan mode.
- Never commit directly to the default branch. The issue branch is the only target.
- TDD is the default. Follow the test framework and patterns already in the repo.
- Code coverage is the default. Set up stack-appropriate coverage tooling if not already configured. Recommended threshold: 80% line coverage. Respect any existing coverage configuration or developer override.
- Follow existing code patterns: imports, error handling, logging, module structure. Do not introduce changes beyond the scope of the fix.
- Context7 research is mandatory before planning — same as the standard build loop. Urgency does not exempt this.
- After the first commit, create a Draft PR on GitHub. Urgency makes visibility more important, not less.
- **All Jira interactions go through the Atlassian MCP only.** Never use curl, REST calls, or GraphQL directly against Jira. If an operation cannot be done via the MCP tools listed above, tell the developer what to do manually.
- **All GitHub interactions go through the gh CLI only.** All PR operations run via Bash (`gh pr create`, `gh pr view`, `gh pr list`, `gh pr edit`, `gh pr ready`).
- **Git push is the only git CLI operation that touches the remote.** If `git push` fails due to auth, follow the guidance in `references/git-push-guidance.md` exactly — detect, stop, guide the developer, and wait.
- Run the code health and security review agents before marking the PR ready. Use the Task tool to invoke `teamcraft-jcg:code-health-reviewer` and `teamcraft-jcg:security-reviewer` in parallel.
- Lint and format modified files using the project's configured tooling before each commit.

## What Is Removed

Sprint assignment is not required. No sprint planning session needed. Deviation review can be deferred if the situation is genuinely urgent. Everything else remains.

## Phase 1 — Identify the Project and Draft the Issue

Find the Jira project from `.teamcraft/project.md` if it exists, then from git remote context to derive the GitHub repo. If neither resolves the Jira project, use `mcp__sooperset-mcp-atlassian__jira_get_all_projects` to see what is visible, surface the results, and ask the developer to confirm which project. Never assume. Confirm the project before proceeding.

Using `$ARGUMENTS` as the starting point, draft the issue. Read the reference file matching the issue type before drafting — `references/example-bug-issue.md` for bugs, `references/example-feature-issue.md` for features. These define the required structure. Every issue must include all sections from the reference. An issue missing Technical Guidance or Testing Requirements is incomplete — a developer cannot pick it up cold without them.

Gather any missing context by asking targeted questions — reproduction steps, environment, error output. A bug without reproduction steps is not actionable. Ask until the issue is complete enough to hand to another developer cold.

Present the full draft. Get explicit confirmation before creating it in Jira.

Create the issue with `mcp__sooperset-mcp-atlassian__jira_create_issue`, specifying the issue type (usually "Bug" for urgent fixes). Standard types are Story, Bug, Task, Epic, Subtask. Record the Jira issue key (e.g., PROJ-42). Set priority to "Critical" or "Urgent" if the situation warrants it — pass it via the `additional_fields` parameter (e.g., `{"priority": {"name": "Critical"}}`).

---

## Phase 2 — Analyze and Plan

Load context from Confluence (tech decisions, conventions) using `mcp__sooperset-mcp-atlassian__confluence_search` to find the relevant pages, then `mcp__sooperset-mcp-atlassian__confluence_get_page` to read them. Read the codebase to understand what is relevant to this issue: what exists, what patterns are established in this area, what files will be touched, and what is the minimal scope of the fix. CLAUDE.md and `.claude/rules/` contain project-specific conventions — read them.

Use Context7 to research any libraries, frameworks, or APIs involved in the fix:
- Use `mcp__context7__resolve-library-id` to identify the relevant library
- Use `mcp__context7__query-docs` to pull current documentation

This is not optional. The correct fix for an urgent bug is still a correct fix — a solution that works against outdated API understanding creates another urgent bug.

Draft an implementation plan covering:
- What the fix does and why
- Files to be changed
- Testing approach (TDD: failing tests first)
- Commit strategy — one logical unit per commit

See `references/example-plan.md` for the target quality and depth of a plan.

Present the plan to the developer. Get explicit confirmation before writing a single line of code.

---

## Phase 3 — Implement

Create the branch. The naming convention follows the issue type and key: `bug/PROJ-42-slug`, `feature/PROJ-42-slug`, or `chore/PROJ-42-slug`. If team conventions captured in the tech decisions or conventions documents establish different naming, follow those instead.

Work through the plan one commit at a time. Apply TDD: write the failing tests first, implement until they pass, then refactor. Run the full test suite after each implementation to confirm nothing regressed. Apply formatting and linting to modified files before each commit. Commit with a message that references the Jira issue key. After each commit, present a summary of what was built, which tests pass, and overall progress — then pause and wait for the developer's response before proceeding to the next unit.

After the first commit, create a Draft PR via `gh pr create --draft` via Bash:
- Title: `Draft: [issue title]`
- Include the Jira issue key and URL in the description for traceability — note that this does NOT auto-close the Jira issue on merge; post-merge must handle that explicitly
- Target branch: the project's default branch
- No sprint assignment required

---

## Phase 4 — Pre-PR Review and Ready for Review

When all units are complete, run the pre-PR reviews in parallel using the Task tool:

- Invoke `teamcraft-jcg:code-health-reviewer` — code quality findings, test coverage gaps, patterns that deviate from the codebase
- Invoke `teamcraft-jcg:security-reviewer` — security vulnerabilities, secrets exposure, unsafe patterns

Pass the diff, the issue context, and the relevant code areas in the task prompts. Both agents review in parallel.

Present the findings to the developer. For any issue either agent raises that requires a fix, address it before marking the PR ready. For findings the developer chooses to defer, note them explicitly in the PR description as known items.

When the developer approves the state of the implementation and the review findings have been addressed:
- Mark the PR ready: `gh pr ready [PR-number]` via Bash
- Transition the Jira issue to "In Review" using `mcp__sooperset-mcp-atlassian__jira_get_transitions` then `mcp__sooperset-mcp-atlassian__jira_transition_issue`. Never assume transition names — fetch them first.

Report: Jira issue key + title + URL, PR number + title + GitHub URL, commits made, tests passing, any deferred findings from the pre-PR