plugins/teamcraft-glgd/skills/create-issue/SKILL.md
Create a single well-formed GitLab issue at any time — bugs found in production, features requested by stakeholders, technical debt noticed during development, chores that need doing. Follows the same issue standards as plan-sprint, always. Works in Claude Cowork and Claude Code.
npx skillsauth add codingthefuturewithai/claude-code-primitives teamcraft-glgd:create-issueInstall 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.
Create one well-formed GitLab issue that gives a developer everything they need to pick it up cold. The same standards apply regardless of when or why the issue is created. One issue. Explicit confirmation. No exceptions.
Use mcp__gitlab__list_projects to see what is visible, surface the results, and ask the user which project this issue belongs to. Never ask the user to supply a namespace string. Confirm once identified.
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.
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.
Ask the user if they can point at the tech decisions and conventions documents in Google Drive. If they can, use mcp__google-drive__download_file to load them directly. If they cannot, ask whether to search Drive. These documents inform the technical guidance section of the issue. If nothing is available, proceed without — the user's description carries sufficient context.
Use $ARGUMENTS as the starting point if provided. Determine issue type — feature, bug, or chore. Ask if not clear from the description.
Before drafting, read the reference file matching the issue type — references/example-feature-issue.md, references/example-bug-issue.md, or references/example-chore-issue.md. These define the required structure. Every issue must include all sections from the reference: Background & Goal, Acceptance Criteria, Technical Guidance, and Testing Requirements (for features and bugs) or Verification (for chores). An issue missing any of these sections is incomplete.
Show the draft. Get explicit confirmation before creating. Never create without approval.
Create the issue in GitLab. If open milestones exist, offer to assign it to one. Report the IID and URL.
After creating the issue, assess whether it represents a capability or requirement not currently reflected in the PRD. If it does — a new feature, a constraint discovered in implementation, a stakeholder request that extends original scope — flag it explicitly:
"This issue adds capability X that is not in the current PRD. If this reflects a real change in scope, the PRD should be updated so all agents and team members work from accurate requirements. Would you like to update it now?"
If the user says yes, ask them to point at the PRD in Drive and update the relevant section. One atomic action — the issue and the PRD stay in sync at the moment scope changes, not weeks later.
tools
Capture feedback about Teamcraft itself and turn it into a well-structured GitHub issue on the plugin's repo. Vets whether the problem is really a Teamcraft skill defect (vs. misuse, the harness, or the user's own project) by root-causing against the actual skill source, then helps the developer decide whether to file and publishes via the GitHub CLI. Use when the user says 'improve teamcraft', 'a teamcraft skill did the wrong thing', 'file feedback on teamcraft', 'report a teamcraft bug', 'I have an idea to make teamcraft better', or when a Teamcraft skill clearly misbehaved and the user wants that captured upstream.
tools
Learn the Teamcraft plugin itself — how its workflow, skills, and artifacts fit together. A guided overview for a human getting started, or a system map for Claude orienting itself to how Teamcraft works before working in a Teamcraft repo. Teaching only; needs no project or environment access. Use when someone wants to understand Teamcraft (the tool, not their specific project), asks "how does Teamcraft work", "explain the workflow", "which skill do I use for X", or when Claude needs the big picture of how the skills hook together.
tools
--- name: teamcraft:work-board description: 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 (analytics: work by status, throughput, cycle time, aging, blocked chains, recomputed on every poll). Each project is added via a header dropdown; the
development
Run pre-PR reviews (code health, security, acceptance criteria), address findings, and submit the PR for review. Ends when the PR is ready and CI has passed. Use when implementation is done and ready for review, or when the user says "I'm done coding", "validate this", "ready for review", "submit this for review", "run the pre-PR reviews", or "prepare this for review".