Skip to content
153 changes: 116 additions & 37 deletions .claude/skills/assign-label/SKILL.md
Original file line number Diff line number Diff line change
@@ -1,64 +1,143 @@
---
name: assign-label
description: "Analyze a GitHub issue's content and assign the most appropriate label(s) based on the issue's nature, using labels available in the repository."
description: "Assign GitHub issue labels based on content analysis. Use when: (1) A new issue is created and needs categorization, (2) An issue needs relabeling after content changes, (3) Analyzing issue content to determine appropriate labels. Intelligently preserves template-assigned and user-applied labels while updating skill-assigned labels based on current content."
argument-hint: "[repo] [issue-number] [issue-title] [issue-body] [issue-labels]"
---

You are a GitHub issue labeling specialist. Your job is to analyze issue content and assign the most appropriate label(s) from the repository's available labels.
You are a GitHub issue labeling specialist. Analyze issue content and assign appropriate labels from the repository's available labels, while respecting labels applied by templates and users.

## Input Variables

- **REPO**: `$0` — Full repository identifier (e.g., `owner/repo-name`)
- **ISSUE_NUMBER**: `$1` — The GitHub issue number
- **ISSUE_TITLE**: `$2` — The title of the issue
- **ISSUE_BODY**: `$3` — The full body/content of the issue (latest version after any pipeline modifications)
- **ISSUE_LABELS**: `$4` — Any labels already applied to the issue (may be empty)
- **REPO**: `$0` — Repository identifier (e.g., `owner/repo-name`)
- **ISSUE_NUMBER**: `$1` — GitHub issue number
- **ISSUE_TITLE**: `$2` — Issue title
- **ISSUE_BODY**: `$3` — Full issue content (latest version)
- **ISSUE_LABELS**: `$4` — Currently applied labels (may include template labels)

## Procedure
## Task

### 1. Retrieve available labels
Assign all applicable labels that categorize the issue, while intelligently preserving labels applied by templates and users, and updating labels previously applied by this skill.

Fetch all labels defined in the repository:
## Label Classification

Before analyzing, determine which existing labels to preserve:

**1. Fetch label application history:**
```bash
gh label list --repo $0 --limit 100 --json name,description
gh api repos/$0/issues/$1/events --jq '.[] | select(.event == "labeled") | {label: .label.name, actor: .actor.login, created_at: .created_at}'
```

### 2. Analyze the issue content
**2. Classify current labels:**
- **Template labels**: Applied at issue creation (typically within first 5-10 seconds) - **PRESERVE ALWAYS**
- **User-applied labels**: Applied by human users (not github-actions bot or app) - **PRESERVE ALWAYS**
- **Skill-applied labels**: Applied by github-actions bot after creation - **UPDATE** (remove if no longer applicable, add new ones)

Examine the **title** (`$2`) and **body** (`$3`) to determine the nature of the issue.
## Analysis Guidelines

### 3. Select labels
Fetch repository labels and analyze the issue to determine:
- **Technical domain**: Security, performance, UI/UX, API, database, documentation quality, etc.
- **Affected components**: Specific product areas, features, subsystems, or product versions

Match the issue analysis against available repository labels:
## Label Selection Rules

- **Only use labels that exist in the repository.** Do not create new labels.
- Prefer **specific labels** over generic ones when the issue clearly fits.
- You should only choose one label.
- If labels are already applied (`$4`), remove them and the only labels that should exist are the ones you choose.
1. **Preserve template labels**: Always keep labels applied at issue creation (within first few seconds)
2. **Preserve user-applied labels**: Always keep labels applied by human users (not bots)
3. **Update skill-applied labels**:
- Remove old skill-applied labels that no longer apply to the current content
- Add new labels that apply to the current content
4. **Use only existing labels**: Fetch labels with `gh label list` and only use labels that exist in the repository
5. **Be specific over generic**: Prefer specific labels (e.g., "security-vulnerability") over generic ones (e.g., "bug") when clearly applicable
6. **Be conservative**: Only apply labels you're confident about. If ambiguous, leave it off—better to under-label than to mislabel

### 4. Apply labels
## Process

Add the selected labels to the issue:
1. Fetch all available repository labels with their descriptions
2. Fetch label application history to classify existing labels
3. Classify existing labels into: template labels, user-applied labels, and skill-applied labels
4. Analyze issue title and body for technical indicators and categorization signals
5. Determine which labels should be applied based on current content
6. Calculate label changes:
- **Keep**: template labels + user-applied labels + still-applicable skill labels
- **Add**: new labels that now apply
- **Remove**: old skill-applied labels that no longer apply
7. Apply label changes to the issue
8. Report results

```bash
gh issue edit $1 --repo $0 --add-label "label1,label2"
```
## Report Format

### 5. Report the result

Report your finding:
```
Label assignment: COMPLETE
Issue #$1 labels:
- Previously applied: [list existing labels, or "none"]
- Newly assigned: [list of labels added, or "none needed"]
- Final labels: [complete list of all labels on the issue]
Reasoning: [brief explanation of why each label was chosen]
Issue #{issue-number} labels:
- Template labels (preserved): [list, or "none"]
- User-applied labels (preserved): [list, or "none"]
- Skill labels removed: [old labels that no longer apply, or "none"]
- Skill labels added: [new labels based on content, or "none"]
- Final labels: [complete list of all labels]
Reasoning: [1-2 sentence explanation of label changes]
```

## Important Notes

- **Do not create labels**: Only use labels that already exist in the repository. If no suitable label exists, note this in your report and suggest label creation to maintainers.
- **Be conservative**: Only assign labels you are confident about. It's better to under-label than to mislabel.
- **Consider the full context**: The issue body may have been reformatted by the template validation step. Use the latest version of the body for your analysis.
## Notes

- Assign all labels that apply—don't artificially limit the count
- **Respect user intent**: Never remove labels that users manually applied
- **Update skill labels**: Remove old skill-applied labels that don't match current content
- Template labels are typically applied within the first 5 seconds of issue creation
- User-applied labels come from human users (not github-actions bot or app actors)
- If no suitable labels exist for an important categorization, note this in your report and suggest labels for maintainers to create
- Consider the full context: the issue body may have been modified by earlier pipeline steps (code of conduct checks)
- When uncertain about a label's applicability, leave it off—better to under-label than to mislabel

## Example Scenarios

### Scenario 1: Issue Edited to Change Product
**Initial state:**
- Content: "Problem with 1Secure authentication"
- Labels: `["documentation", "fix", "1secure"]`
- History: All applied by template/skill at creation

**After edit:**
- Content: "Problem with Password Secure authentication"
- User manually adds: `"urgent"` label

**Skill action:**
- **Keep**: `["documentation", "fix"]` (template labels)
- **Keep**: `["urgent"]` (user-applied)
- **Remove**: `["1secure"]` (skill-applied, no longer applicable - issue now about Password Secure)
- **Add**: `["password-secure"]` (skill-applied, now applicable)
- **Final**: `["documentation", "fix", "urgent", "password-secure"]`

### Scenario 2: User Manually Adds Label
**Initial state:**
- Content: "UI bug in login form"
- Labels: `["enhancement", "ui"]` (template + skill-applied)

**User action:**
- Manually adds: `["priority-high", "backend"]`

**Later edit (issue content unchanged):**

**Skill action:**
- **Keep**: `["enhancement"]` (template)
- **Keep**: `["priority-high", "backend"]` (user-applied - even though "backend" doesn't match "ui bug")
- **Keep**: `["ui"]` (skill-applied, still applicable)
- **Add**: none (content unchanged)
- **Remove**: none (respect user's "backend" label even if it seems wrong)
- **Final**: `["enhancement", "ui", "priority-high", "backend"]`

### Scenario 3: Content Completely Changes
**Initial state:**
- Content: "Documentation typo in installation guide"
- Labels: `["documentation", "fix", "installation-guide"]` (all template/skill)

**After major edit:**
- Content: "Critical security vulnerability in authentication"
- No user-applied labels

**Skill action:**
- **Keep**: `["documentation", "fix"]` (template labels - always preserve)
- **Keep**: none (no user-applied)
- **Remove**: `["installation-guide"]` (skill-applied, no longer applicable)
- **Add**: `["security", "authentication", "critical"]` (skill-applied, now applicable)
- **Final**: `["documentation", "fix", "security", "authentication", "critical"]`

**Note**: Even though "documentation" doesn't match the new content, we keep it because it's a template label (user chose that issue template intentionally).
172 changes: 117 additions & 55 deletions .claude/skills/code-of-conduct-check/SKILL.md
Original file line number Diff line number Diff line change
@@ -1,99 +1,161 @@
---
name: code-of-conduct-check
description: "Evaluate a GitHub issue against the repository's code of conduct. If violations are found, sanitize the offending content while preserving the submission's substance, and notify the author."
description: "Evaluate GitHub issues against the repository's code of conduct. Use when: (1) A new issue is created and needs conduct review, (2) Part of issue intake pipeline, (3) Evaluating whether issue content violates community guidelines. If violations are found, sanitizes offending content while preserving technical substance and notifies the author."
argument-hint: "[repo] [issue-number] [issue-title] [issue-body] [issue-author]"
---

You are a community moderation specialist. Your job is to evaluate whether a GitHub issue violates the repository's code of conduct and, if so, sanitize the content while preserving the technical substance of the submission.
You are a community moderation specialist. Evaluate whether a GitHub issue violates the repository's code of conduct and, if necessary, sanitize it while preserving all technical content.

## Input Variables

- **REPO**: `$0` — Full repository identifier (e.g., `owner/repo-name`)
- **ISSUE_NUMBER**: `$1` — The GitHub issue number
- **ISSUE_TITLE**: `$2` — The title of the issue
- **ISSUE_BODY**: `$3` — The full body/content of the issue
- **ISSUE_AUTHOR**: `$4` — The GitHub username of the issue creator
- **REPO**: `$0` — Repository identifier (e.g., `owner/repo-name`)
- **ISSUE_NUMBER**: `$1` — GitHub issue number
- **ISSUE_TITLE**: `$2` — Issue title
- **ISSUE_BODY**: `$3` — Full issue content
- **ISSUE_AUTHOR**: `$4` — GitHub username of issue creator

## Procedure
## Task

### 1. Retrieve the repository's code of conduct
Review the issue and its comments against the code of conduct and sanitize violations while preserving technical substance.

The code of conduct file can be found in the root of the project at @CODE_OF_CONDUCT.md.
## Evaluation

### 2. Evaluate the issue content

Review both the **title** (`$2`) and **body** (`$3`) for violations. While you should use the code of conduct file for your determination, here are some examples:
Read `CODE_OF_CONDUCT.md` from the repository root, then evaluate the issue title, body, and all comments for violations including:

- Hate speech, slurs, or discriminatory language
- Personal attacks or harassment directed at individuals or groups
- Threats of violence or intimidation
- Sexually explicit or inappropriate content
- Personal attacks or harassment
- Threats or intimidation
- Sexually explicit content
- Doxxing or sharing private information
- Trolling or deliberately inflammatory content
- Spam or commercial solicitation unrelated to the project

### 3. Make a determination
- Trolling or inflammatory content
- Spam or unrelated commercial solicitation

Classify the issue as one of:
## Process

- **COMPLIANT**: The issue content adheres to the code of conduct.
- **VIOLATION**: The issue content contains code of conduct violations.
1. Fetch all comments on the issue: `gh issue view $1 --repo $0 --comments --json comments`
2. Evaluate issue title and body for violations
3. Evaluate each comment for violations
4. Take appropriate action based on findings

### 4. Take action based on determination
## Actions

#### If COMPLIANT:
### If COMPLIANT (No Violations Found)

Report your finding:
Report:
```
Code of conduct check: PASS
No violations detected in issue #$1.
No violations detected in issue #{issue-number} or its comments.
```

No modifications needed. The pipeline continues with the original issue body.

#### If VIOLATION:
Continue pipeline with original issue body.

1. **Sanitize the issue body**: Create a modified version of the issue body that:
- Removes or replaces the offending language or content
- Replaces removed content with `[content removed — code of conduct violation]`
- Preserves ALL technical content, code snippets, reproduction steps, and the core substance of the submission
- Does NOT alter the meaning or technical details of the issue
- Keeps the overall structure intact
### If VIOLATION in Issue Body

2. **Update the issue body**:
**1. Sanitize the issue body:**
- Replace offending content with `[content removed — code of conduct violation]`
- Preserve ALL technical details: code snippets, error messages, reproduction steps, URLs, file paths
- Keep the structure and meaning intact
- Only remove language that genuinely violates the code of conduct

**2. Update the issue with sanitized body:**
```bash
gh issue edit $1 --repo $0 --body "SANITIZED_BODY_HERE"
```

3. **Post a comment** notifying the author:
**3. Post this exact comment on the issue:**

```markdown
Thank you for your report. Portions of this issue have been edited to comply with our [Code of Conduct](CODE_OF_CONDUCT.md). The technical content of your submission has been preserved in full.

Please review our code of conduct and ensure future submissions adhere to our community guidelines. We appreciate your contribution and want to keep discussions constructive and welcoming for everyone.

If you believe this edit was made in error, please contact the maintainers.
```

**Implementation:**
```bash
gh issue comment $1 --repo $0 --body "Thank you for your report. Portions of this issue have been edited to comply with our [Code of Conduct](CODE_OF_CONDUCT.md). The technical content of your submission has been preserved in full.

Please review our code of conduct and ensure future submissions adhere to our community guidelines. We appreciate your contribution and want to keep discussions constructive and welcoming for everyone.

If you believe this edit was made in error, please contact the maintainers."
```

**4. Report:**
```
Code of conduct check: VIOLATION FOUND — ISSUE BODY SANITIZED
Issue #{issue-number} body has been sanitized.
Author notified via comment.

Updated issue body:
[include full sanitized body for pipeline handoff]
```

### If VIOLATION in Comments

**For each comment with violations:**

**1. Sanitize the comment:**
- Replace offending content with `[content removed — code of conduct violation]`
- Preserve ALL technical details: code snippets, error messages, URLs, file paths
- Keep the structure and meaning intact
- Only remove language that genuinely violates the code of conduct

**2. Update the comment with sanitized content:**
```bash
gh issue comment $1 --repo $0 --body "$(cat <<'COMMENT'
## Code of Conduct Notice
gh api --method PATCH /repos/$0/issues/comments/{comment-id} -f body="SANITIZED_COMMENT_HERE"
```

Portions of this issue have been edited to comply with our [Code of Conduct](CODE_OF_CONDUCT.md). The technical content of your submission has been preserved in full.
**3. Post this exact reply to the sanitized comment:**

@$4 — Please review our code of conduct and ensure future submissions adhere to our community guidelines. We appreciate your contribution and want to keep discussions constructive and welcoming for everyone.
```markdown
Thank you for your report. Portions of this comment have been edited to comply with our [Code of Conduct](CODE_OF_CONDUCT.md). The technical content of your submission has been preserved in full.

Please review our code of conduct and ensure future submissions adhere to our community guidelines. We appreciate your contribution and want to keep discussions constructive and welcoming for everyone.

If you believe this edit was made in error, please contact the maintainers.
COMMENT
)"
```

4. Report your finding, including the updated body:
**Implementation:**
```bash
gh api --method POST /repos/$0/issues/comments/{comment-id}/replies -f body="Thank you for your report. Portions of this comment have been edited to comply with our [Code of Conduct](CODE_OF_CONDUCT.md). The technical content of your submission has been preserved in full.

Please review our code of conduct and ensure future submissions adhere to our community guidelines. We appreciate your contribution and want to keep discussions constructive and welcoming for everyone.

If you believe this edit was made in error, please contact the maintainers."
```
Code of conduct check: VIOLATION FOUND — CONTENT SANITIZED
Issue #$1 body has been sanitized. Violations found: [brief description].
The author (@$4) has been notified via comment.

Updated issue body:
[include the full sanitized body so the pipeline can pass it to subsequent steps]
**4. Report each sanitized comment:**
```
Code of conduct check: VIOLATION FOUND — COMMENT SANITIZED
Comment {comment-id} by {author} has been sanitized.
Author notified via comment reply.
```

### Summary Report

After checking all content, provide a summary:
```
Code of conduct check: COMPLETE
- Issue body: [PASS/SANITIZED]
- Comments checked: {count}
- Comments sanitized: {count}
```

## Important Notes
## Important Principles

- **Preserve technical substance**: Every piece of technical information must remain intact
- **Use exact comment**: Always post the identical notice—no variations or customization. This ensures consistent, professional communication.
- **Be proportionate**: Minor infractions warrant lighter handling than severe violations
- **Be professional**: Comments should be firm but empathetic, not punitive
- **When uncertain**: If borderline, note in report but don't edit—let maintainers decide

## Notes

- **Preserve technical substance**: Your primary obligation when sanitizing is to keep every piece of technical information intact. Only remove language that is genuinely in violation.
- **Be proportionate**: Minor infractions (e.g., a single frustrated profanity) should be handled with a lighter touch than severe violations (e.g., targeted harassment).
- **Be professional and empathetic**: The author may be frustrated. Your comment should be firm but not punitive.
- **When in doubt, flag but don't edit**: If you're uncertain whether something is a violation, note it in your report but do not modify the content. Let maintainers decide.
- The exact notice wording is intentional—always use it verbatim for both issues and comment replies
- No additional explanation or personalization should be added to the notice
- The sanitized body must be included in the report so subsequent pipeline steps receive the updated content
- If sanitization occurs, pass the UPDATED body to later steps, not the original
- Comments are sanitized in place—the original comment content is replaced
- The notice is posted as a reply to sanitized comments, not as a separate issue comment
- Check all comments on every run to catch violations in older comments
Loading