Teach issue agents and skills to reuse existing labels and issue types

[coisa]

Objective

Update the issue-related agents and skills so they classify issue scope with the repository's existing issue types and labels instead of publishing issues without metadata discipline.

Current Limitation

The current issue-drafting and issue-publication flow does not reliably enforce metadata selection based on scope. That creates two risks:

• issues may be created without the most appropriate existing type or label;
• future automation could drift into inventing new labels, issue types, milestones, project assignments, or project-field values instead of reusing the repository metadata that already exists.

For this repository, issue creation should stay aligned with the existing issue types (Task, Bug, Feature) and the existing labels that are already available in GitHub. The same principle should apply to project assignment, project status, project priority, project size, and milestones whenever those surfaces are in use.

Proposed Work

Refine the issue-oriented skills and agents so they:

• infer the most appropriate existing issue type from the request scope;
• add existing labels only when they materially improve categorization;
• never propose or create new labels or issue types on the fly;
• validate requested metadata against the repository's current GitHub configuration before issue creation or update;
• validate requested project assignment against repository or organization projects that already exist when the available GitHub token supports project access;
• infer the most appropriate existing project status, priority, and estimated size when the selected project exposes those fields;
• validate requested milestone assignment against milestones that already exist in the target repository;
• check whether the new issue appears related to another open issue and add the appropriate relationship when that connection is materially useful;
• populate as much existing issue and project metadata as can be inferred safely instead of leaving supported fields blank by default.

Scope

• Update the github-issues skill guidance so issue drafting and publication explicitly select from existing issue types and labels.
• Update any issue-oriented project agents or prompts that create or refine issues so they follow the same metadata rules.
• Add repository-aware guidance for when to omit labels instead of forcing weak or noisy categorization.
• Add repository-aware guidance for when to omit project assignment because no existing project fits or project access is unavailable.
• Add repository-aware guidance for when to omit project-field assignment because the selected project does not expose a matching field or the appropriate value cannot be inferred safely.
• Add repository-aware guidance for when to omit milestone assignment because no existing milestone fits or no milestones are available in the repository.
• Add repository-aware guidance for when to relate a newly created issue to an existing open issue and when to leave issues unlinked.
• Ensure the workflow remains explicit about the chosen type, labels, project assignment, project field values, milestone assignment, and issue relationships when mutating GitHub.

Non-goals

• Creating new repository labels or issue types.
• Creating new GitHub Projects as part of normal issue drafting or publication.
• Creating new project status, priority, size, or milestone values as part of normal issue drafting or publication.
• Linking issues together speculatively when the relationship is weak or unclear.
• Redesigning the overall issue templates beyond what is needed to support metadata discipline.
• Forcing every issue to carry a label when the existing label set does not materially improve categorization.
• Forcing uncertain metadata just to maximize field count when the project or repository context does not support a confident choice.

Acceptance Criteria

Delivery Criteria

• The github-issues skill explicitly requires selecting an issue type from the repository's existing issue types instead of inventing new values.
• The issue-oriented agents and prompts explicitly require choosing labels only from labels that already exist in the target repository.
• The issue-oriented flow explicitly forbids creating new labels or issue types as part of normal drafting or publication.
• The issue-oriented flow explains when no label should be added because the existing labels do not fit the issue scope.
• When project assignment is in scope and the available token can inspect projects, the issue-oriented flow chooses only from projects that already exist in the target repository or organization.
• When a selected project exposes fields such as status, priority, or size, the issue-oriented flow attempts to choose the most appropriate existing values instead of leaving those fields unmanaged by default.
• The issue-oriented flow aims to fill the maximum useful metadata across the issue and project surfaces when that metadata can be inferred safely from the scope and repository context.
• The issue-oriented flow does not attempt to create new projects or new project-field options as part of normal issue drafting or publication.
• When milestone assignment is in scope and the repository has milestones available, the issue-oriented flow chooses only from milestones that already exist in the target repository.
• The issue-oriented flow does not attempt to create new milestones as part of normal issue drafting or publication.
• When a newly created issue clearly overlaps with or depends on an existing open issue, the issue-oriented flow checks for that relationship and records it explicitly instead of leaving the issues disconnected.
• The issue-oriented flow avoids creating speculative or noisy issue links when no meaningful open-issue relationship exists.
• Issue creation and update steps remain explicit about which type, labels, project assignment, project field values, milestone assignment, and issue relationships were chosen for the mutation.
• Any affected skills, prompts, or docs are updated consistently.

Architectural / Isolation Criteria

• MUST: The affected documentation or content MUST follow the repository's existing information architecture and naming conventions.
• MUST: Related navigation, cross-links, or synchronized outputs MUST be updated when the change affects them.
• MUST: Examples, commands, and file paths MUST remain accurate for the current repository behavior.
• MUST: The update MUST avoid duplicating content that should live in a single canonical location.