Agent skill · Databases

issue-fields-migration

Bulk-migrate metadata to GitHub issue fields from two sources: repo labels (e.g. priority labels to a Priority field) and Project V2 fields. Use when users say "migrate my labels to issue fields", "migrate project fields to issue fields", "convert labels to issue fields", "copy project field values to issue fields", or ask about adopting issue fields. Issue fields are org-level typed metadata (single select, text, number, date) that replace label-based workarounds with structured, searchable, cross-repo fields.

GitHub68,948★ · +463/wk · 2 repos on radarProfile →
copilotMIT
Install
npx skills add github/awesome-copilot --skill issue-fields-migration --agent copilot

Same command for any agent — swap --agent for claude-code, codex, cursor.

Facts
Files in the skill folder: 4
SKILL.md size: 24 KB
Bundled scripts: none
Path: skills/issue-fields-migration/SKILL.md
Open the folder on GitHub →
Where it comes from
Stars: 37,432 · +281 this week
Language: Python

Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.

Review
written from the skill's own SKILL.md · Aug 5, 2026

What it does

Bulk-migrates metadata to GitHub issue fields from two sources: repo labels and Project V2 fields. It supports converting labels to a single_select issue field, multiple-label to one field, and copying various project field types (text, number, date, iteration) to corresponding org-level issue fields. It guides users through discovery, mapping, pre-flight checks, preview, and execution, with explicit steps and tool usage for each flow.

How it works

  • It describes two flows: Label Migration and Project Field Migration.
  • Label Migration Flow: migrates repo labels into issue fields (single_select). It performs: input collection (org and repos), reading repo labels, listing org issue fields, optional filtering, suggesting mappings using multiple matching strategies, presenting mappings for confirmation, conflict detection, pre-flight checks (repository permissions and issue counts), a dry-run preview, and then execution via the GH API to set issue_field_values and optionally remove migrated labels.
  • Project Field Migration Flow: copies values from Project V2 fields to org issue fields. It performs: input collection (org and project), listing project fields, listing org issue fields, filtering proxy fields, auto-matching field types, presenting proposed mappings for confirmation, an option-mapping phase for single-select fields, pre-flight checks (repo write permissions, repository_id caching), and data scanning/execution guidance with MCP tools and GH API calls. It emphasizes a preview before executing.
  • It provides concrete commands and endpoints for key steps, e.g., gh label list, gh api /orgs/{org}/issue-fields, mcp__github__projects_list, and the issue-field-values write endpoint.
  • It includes detailed phases, example outputs, and a final summary table of results post-migration.

When to use it

  • When users want to migrate labels to issue fields (priority, type, team, etc.).
  • When users want to copy values from a GitHub Project V2 into org-level issue fields.
  • When users are adopting issue fields and wish to replace label-based workarounds with structured, searchable fields.
  • When users want to pre-populate or convert existing project fields to issue fields before deprecating the old project data.

What it can touch

  • Repositories and issues via GitHub API (gh api, gh label/list, issue-list, issue-field-values).
  • Project V2 data via MCP tools (mcp__github__projects_list, list_project_fields, list_project_items).
  • Organization-level issue fields and per-repo issues (via endpoints and RFC-like workflows in the guidance).

Caveats

  • Requires issue fields enabled at the org level and corresponding target issue fields existing.
  • For project-field migration, project fields must have actual options (non-proxy) to map to issue fields.
  • For label migration, labels must exist on target repos, and mappings depend on matching single_select options.
  • User must have write access to repos and, if migrating project fields, the project itself.
  • The workflow relies on interactive confirmation steps, previews, and potential conflict resolution strategies (First match, Skip, Manual).
From the SKILL.md

# Issue Fields Migration [Issue fields](https://github.blog/changelog/2026-03-12-issue-fields-structured-issue-metadata-is-in-public-preview/) are org-level typed metadata (single select, text, number, date) that replace label-based workarounds with structured, searchable, cross-repo fields. Every organization gets `Priority`, `Effort`, `Start date`, and `Target date` preconfigured, with support for up to 25 custom fields. This skill bulk-migrates existing metadata into issue fields from two sources: - **Repo labels**: Convert labels like `p0`, `p1`, `priority/high` into structured issue field values (e.g. the Priority field). Supports migrating multiple labels at once and optionally removing them after migration. - **Project V2 fields**: Copy field values (single select, text, number, date, iteration) from a GitHub Project into the equivalent org-level issue fields. ## When to Use - User added org-level issue fields that overlap with existing project fields - User wants to copy values from project fields to issue fields before deleting the old project fields - User asks about "migrating", "transferring", or "copying" project field data to issue fields - User wants to convert repo

What's inside
Steps it walks through
  1. When to Use
  2. Prerequisites
  3. Available Tools
  4. MCP Tools (read operations)
  5. CLI / REST API
  6. Workflow
  7. Step 0: Migration Source
  8. Label Migration Flow
  9. Project Field Migration Flow
  10. Important Notes
  11. Examples
  12. Example 1: Full Migration
  13. Example 2: Dry-Run Only
  14. Example 3: Multiple Fields
Ships with 3 files
  • references/issue-fields-api.md
  • references/labels-api.md
  • references/projects-api.md
Commands it runs
gh label list -R {owner}/{repo} --limit 1000 --json name,color,description
gh api /orgs/{org}/issue-fields \
gh api /repos/{owner}/{repo} --jq '{full_name, id, permissions: .permissions}'
gh issue list -R {owner}/{repo} --label "{label_name}" --state all \
echo '{"issue_field_values": [{"field_id": FIELD_ID, "value": "OPTION_NAME"}]}' | \
gh api /repositories/{repo_id}/issues/{number}/issue-field-values \
gh api /repos/{owner}/{repo}/issues/{number}/labels/{label_name} -X DELETE
Use MCP tool
gh api /repos/{owner}/{repo} --jq '{full_name, permissions: .permissions}'
gh api /repos/{owner}/{repo} --jq .id
More from awesome-copilot
All skills →
About this skill
What does the issue-fields-migration skill do?

Bulk-migrate metadata to GitHub issue fields from two sources: repo labels (e.g. priority labels to a Priority field) and Project V2 fields. Use when users say "migrate my labels to issue fields", "migrate project fields to issue fields", "convert labels to issue fields", "copy project field values to issue fields", or ask about adopting issue fields. Issue fields are org-level typed metadata (single select, text, number, date) that replace label-based workarounds with structured, searchable, cross-repo fields.

How do I install it?

Run `npx skills add github/awesome-copilot --skill issue-fields-migration --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.

Where does this skill come from?

From github/awesome-copilot, a repository with 37,432 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.

Is a popular skill a good skill?

Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.

Keep going