teamcraft-glgd:tech-decisions

---
name: teamcraft-glgd:tech-decisions
description: Capture the technology stack and key decisions for this project. Reads the PRD from Google Drive, surfaces matching team conventions as context, and records what the team has decided to use and why. Simple format — what was decided and why, not a full ADR ceremony.
argument-hint: "[PRD Drive URL or file ID — optional]"
disable-model-invocation: true
user-invocable: true
allowed-tools:
  - mcp__google-drive__list_accounts
  - mcp__google-drive__search_files
  - mcp__google-drive__download_file
  - mcp__google-drive__create_file
  - mcp__google-drive__update_file
---

## Hard Constraints

- 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.

## Goal

Produce a clear record of what technologies this project uses and the key decisions that shaped its technical direction. Format: what was decided, why, and any caveats. This becomes the single source of truth that sprint planning and issue creation reference throughout the project.

## The Decisions Boundary

This skill captures what the team chose and why — not requirements (that is capture-requirements' domain) and not how to implement with the chosen stack (that belongs in code, comments, or the conventions knowledge base). If a conversation drifts into feature requirements or implementation how-tos, note it and redirect.

## 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.

## Load Context

Load the PRD — it provides the requirements and constraints that technology decisions must satisfy. If a Drive URL or file ID was passed as an argument, use it directly. Otherwise, ask the user if they can point at the PRD in Drive before searching. Only search Drive if they cannot point at it directly.

Also ask the user if they can point at any team convention documents — documents that describe how this team builds software. If they can, load them directly. If they cannot, ask whether to search Drive for them. Convention documents might be named by team, client, technology, or practice area.

Conventions are context, not constraints — the user decides whether this project follows them. If a convention clearly answers a technology question, skip asking it, but capture any deviations and the reasons for them.

## Capture Decisions

Have a focused conversation about the key technical decisions for this project. Focus on decisions that shape implementation — things an engineer picking up an issue needs to know. Cover what's genuinely relevant; not every area applies to every project.

Areas to consider: language and versions, frameworks, data persistence, caching and queues, infrastructure and deployment, architectural approach, key dependencies, authentication — and anything else that materially shapes the codebase.

See `references/example-tech-decisions.md` for what a well-formed decisions document looks like.

## Review and Store

Show the complete document for review. Do not store until the user confirms. Ask the user where in Google Drive to store it — which folder. Never save to the Drive root. Do not search Drive for a location; ask the user directly. If they have a PRD in Drive already, suggest the same folder as a natural default but let them decide. Record the URL.

## Done

Share the Drive URL. Pass this URL to your developer — they will record it in the project manifest alongside the PRD URL and GitLab project details. With requirements and technology decisions settled, the natural next step is sprint planning — taking the PRD and tech decisions into GitLab and creating the first milestone and issues.