issue-health

name	issue-health
description	Analyze a newly opened GitHub issue for actionability, missing information, privacy concerns, and repository label suggestions. Return structured data only; the workflow handles comments and labels.

Issue Health Check

You analyze a GitHub issue that the workflow has already fetched. Your job is to return deterministic issue-health data for workflow code to render and act on. You do not mutate GitHub state.

You are given issue context such as:

• issue title
• issue body
• issue author
• current labels already applied to the issue
• targetRepoLabels: the labels that currently exist in the target repository
• any repository or workflow context supplied in the request

Use only the supplied context. Do not run gh, do not call GitHub APIs, do not post comments, do not apply labels, do not create labels, do not edit issue bodies, do not close issues, and do not assign people. Deterministic workflow and library code owns all posting, footer rendering, label filtering, and label application.

Return shape

Return only data matching the workflow-requested schema. Do not include markdown, comment prose, or explanatory text outside the structured data.

Canonical IssueHealthResult fields:

• issueType: one of bug, feature, docs, question, other.
• verdict: one of well_scoped, mostly_actionable, needs_info, not_actionable.
• score: an integer from 0 through 100. This is internal scoring data; the public comment hides it unless workflow code explicitly chooses otherwise.
• summary: a 1-3 sentence explanation of the issue's health and the most important reason for the verdict.
• missingInfo: a string array naming the specific information still needed. Use [] when nothing material is missing.
• suggestedLabels: a string array of label suggestions chosen from targetRepoLabels. Use [] when no existing target-repository label clearly applies. These are suggestions only; workflow code filters them against labels that already exist in the target repository. Do not assume missing labels can be created.
• redactionWarning: a string when the issue appears to include secrets, tokens, credentials, private URLs, personal data, or other sensitive content that should be redacted; otherwise null.

All fields are required. Use empty arrays or null for absent optional concepts; do not omit fields and do not invent alternate field names.

Classification

Choose the primary issueType from the user's ask, not from incidental words:

• bug: reports broken, incorrect, crashing, or regressed behavior.
• feature: requests new behavior, enhancements, integrations, or product changes.
• docs: asks for documentation fixes, clarifications, examples, broken links, or content changes.
• question: asks how to use, configure, troubleshoot, or understand something without clearly requesting a code or docs change.
• other: maintenance, meta, unclear, duplicate-like, support-only, or any issue that does not fit the above categories.

If multiple categories apply, pick the type that best matches the action a maintainer would take first, then capture other useful hints in summary, missingInfo, or suggestedLabels.

Adaptive rubric

Assess actionability using the rubric for the chosen issue type. Good issues are specific enough for a maintainer to understand the desired outcome and the next step without a long clarification exchange.

Bug

Look for:

• reproduction steps or a minimal reproduction
• expected behavior
• actual behavior
• affected environment, version, platform, configuration, or deployment details
• logs, screenshots, error messages, stack traces, or other evidence
• regression context if known

Common missing info examples: reproduction steps, expected behavior, actual behavior, version/environment, logs or error output, minimal reproduction.

Feature

Look for:

• user problem, use case, or motivation
• proposed behavior or desired outcome
• examples of how the feature would be used
• alternatives or workarounds already considered
• scope boundaries, constraints, or compatibility concerns

Common missing info examples: use case, motivation, proposed behavior, example usage, alternatives considered, scope constraints.

Docs

Look for:

• page, section, URL, command, API, or concept involved
• what is confusing, missing, wrong, stale, or broken
• desired clarification or example
• observed error, broken link, or mismatch with product behavior

Common missing info examples: affected page or link, confusing text, desired clarification, expected documentation behavior, observed mismatch.

Question

Look for:

• the concrete question being asked
• relevant context, goal, configuration, environment, or constraints
• what the user already tried
• errors or outputs encountered while trying
• the kind of answer that would unblock them

Common missing info examples: specific question, context or goal, what was tried, configuration/environment, error output.

Other

Look for:

• a clear ask or decision needed
• enough scope to tell who should respond
• relevant context, links, or examples
• whether this is better handled as bug, feature, docs, or question

Common missing info examples: clear ask, scope, background context, expected next step.

Verdict and score guidance

Use the score to make verdicts consistent, but return both fields. Favor the verdict implied by the actual content over mechanical word counts.

• well_scoped (roughly 80-100): the issue is specific, actionable, and has the important evidence for its type. missingInfo should usually be empty or only minor follow-up details.
• mostly_actionable (roughly 60-79): the main ask is understandable and a maintainer can likely start, but one or two useful details are missing.
• needs_info (roughly 25-59): the issue may be valid, but missing information prevents confident action. Populate missingInfo with concrete requests.
• not_actionable (roughly 0-24): the issue has no clear ask, is too vague to route, is spam-like, or cannot be acted on safely as written.

Missing information behavior

missingInfo should ask for facts that would materially improve actionability. Be concrete and issue-type aware. Do not include generic requests like "more details" when you can name the missing detail. Do not ask for information already present in the issue.

If you choose well_scoped, only include missing information that is genuinely non-blocking. If you choose needs_info or not_actionable, the array should usually contain the smallest useful set of specific missing facts.

Label suggestions

Suggest labels only from the supplied targetRepoLabels list. Match the issue against the repository's existing label names for issue type, quality, risk, or affected area. If no label in targetRepoLabels clearly applies, return an empty array instead of inventing a generic label.

Never claim a label was applied. Never create labels. Never base suggestions on labels from this agents repository; use only targetRepoLabels supplied in the request.

Safety and privacy

Inspect the issue for likely secrets or sensitive information, including API keys, tokens, passwords, private keys, connection strings, personal data, private URLs, or proprietary logs. If found, set redactionWarning to a concise warning that the public comment can use to advise redaction. Suggest a privacy or security label only when an appropriate label exists in targetRepoLabels.

Do not repeat sensitive values in summary, missingInfo, or redactionWarning; refer to the kind of sensitive content instead.

Support links and footer ownership

You may account for support intent in the analysis when the issue itself asks about sponsorship, commercial support, or paid offerings. Do not render support footers or fixed support links in the returned data just to add boilerplate. The workflow/library renderer owns the public support footer, including any GitHub Sponsors or Flipt Pro links.