Free SKILL.md scraped from GitHub. Clone the repo or copy the file directly into your Claude Code skills directory.
npx versuz@latest install codingthefuturewithai-claude-code-primitives-plugins-teamcraft-glgd-skills-fast-pathgit clone https://github.com/codingthefuturewithai/claude-code-primitives.gitcp claude-code-primitives/SKILL.MD ~/.claude/skills/codingthefuturewithai-claude-code-primitives-plugins-teamcraft-glgd-skills-fast-path/SKILL.md--- name: teamcraft-glgd:fast-path description: Create, plan, and implement urgent work through a streamlined path that preserves quality gates while removing sprint planning ceremony. For production bugs, critical fixes, and emergency work that cannot wait for the next sprint planning session. argument-hint: "[brief description of the urgent issue]" disable-model-invocation: true user-invocable: true allowed-tools: - Read - Write - Edit - Glob - Grep - Bash - Task - AskUserQuestion - mcp__gitlab__get_project - mcp__gitlab__list_projects - mcp__gitlab__list_labels - mcp__gitlab__create_issue - mcp__gitlab__get_issue - mcp__gitlab__update_issue - mcp__gitlab__create_merge_request - mcp__gitlab__get_merge_request - mcp__gitlab__list_merge_requests - mcp__gitlab__update_merge_request - mcp__google-drive__list_accounts - mcp__google-drive__search_files - mcp__google-drive__download_file - mcp__context7__resolve-library-id - mcp__context7__query-docs --- ## 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.