codingthefuturewithai/teamcraft-glgd:fast-path

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 GitLab 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 MR in GitLab. Urgency makes visibility more important, not less.
• All GitLab interactions go through the MCP server only. Never use curl, REST calls, GraphQL, or the GitLab CLI. If an operation cannot be done via the MCP tools listed above, tell the developer what to do manually.
• 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 MR ready. Use the Task tool to invoke teamcraft-glgd:code-health-reviewer and teamcraft-glgd:security-reviewer in parallel.
• Lint and format modified files using the project's configured tooling before each commit.
• If a Drive file operation fails with a path error, read the error message to identify a valid accessible host path and retry with it.

What Is Removed

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

Resolve Drive Account

Call mcp__google-drive__list_accounts before any other Drive operation:

• No accounts — Drive is not configured for this user. Tell them and skip Drive operations.
• One account — Use it. Pass account_email explicitly on every Drive tool call this session.
• Multiple accounts — Present the list, ask which account to use for this session. Pass that account_email on every Drive tool call.

If any Drive call returns a permission error, surface it: the active account may not have access to that file or folder. Offer to try another account if one is available.

Phase 1 — Identify the Project and Draft the Issue

Find the GitLab project from .teamcraft/project.md if it exists, then from git remote context. If neither resolves it, use mcp__gitlab__list_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 GitLab.

Create the issue. Record the IID. Apply the appropriate label — bug, feature, or chore. If a critical or urgent label exists in the project (check with mcp__gitlab__list_labels), apply it.

---

Phase 2 — Analyze and Plan

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 IID: bug/IID-slug, feature/IID-slug, or chore/IID-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 issue IID. 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 MR:

• Title: Draft: [issue title]
• Use the draft: true parameter
• Include Closes #[IID] in the description
• Set remove_source_branch: true
• Target branch: the project's default branch
• No milestone required

---

Phase 4 — Pre-MR Review and Ready for Review

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

• Invoke teamcraft-glgd:code-health-reviewer — code quality findings, test coverage gaps, patterns that deviate from the codebase
• Invoke teamcraft-glgd: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 MR ready. For findings the developer chooses to defer, note them explicitly in the MR description as known items.

When the developer approves the state of the implementation and the review findings have been addressed:

• Update the MR: remove Draft status
• Update the issue label to reflect it is in review

Report: issue IID + title + GitLab URL, MR IID + title + GitLab URL, commits made, tests passing, any deferred findings from the pre-MR review.