plugins/teamcraft-glgd/skills/tech-decisions/SKILL.md
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.
npx skillsauth add codingthefuturewithai/claude-code-primitives teamcraft-glgd:tech-decisionsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
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.
Call mcp__google-drive__list_accounts before any other Drive operation:
account_email explicitly on every Drive tool call this session.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 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.
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.
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.
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.
development
Launch (or re-launch) the user's live, multi-project work board. The dashboard is a single HTML file copied to a stable user-side location at ~/.claude/teamcraft-board.html and opened in the user's default browser. It has two views via a header toggle — a drag-and-drop Kanban Board and a live Status tab with analytics (work by status, throughput, cycle time, aging, blocked chains, recomputed on every poll). Each project is added via a header dropdown; the dashboard polls each project's .teamcraft/work directly from the browser and updates in real time. Use when the user says 'show me the kanban', 'work board', 'open the board', 'board view', 'kanban view', 'live dashboard', 'visual dashboard', 'live status dashboard', 'status dashboard', 'project metrics', 'throughput/cycle-time view', 'HTML view of work items', 'drag-and-drop board', or asks to see/move/track work visually.
development
Run a retrospective — AI compiles evidence from recent work, facilitates human reflection, and captures process decisions back into living docs. Use when the user says 'run a retro', 'let's do a retrospective', 'run a retrospective on the last 2 weeks', 'let's reflect on how that feature went', or 'time for a retro'.
development
Re-evaluate what Claude needs to be told about this project as the codebase evolves. Some gotchas become obvious from the code (remove them). New gotchas emerge. Decisions change. Use when the user says 'refresh the rules', 'update Claude's context', 'are the rules still accurate', 'clean up claude rules', or after significant codebase changes.
development
Report project status from work items and git history — either as a quick, interpreted read here in the session, or by pointing the developer to the live Status dashboard (the work board's Status tab). Covers work by status, what's in flight, cycle times, throughput, backlog priorities, aging alerts, blocked chains, and how commit activity lines up with the board. Use when the user says 'project status', 'show me the project status', 'what's the status of the work items', 'how are we doing', 'generate a status report', or asks for a status dashboard.