Fix shell injection in pr-checker.yml + add DSCWoC issue migration script

[Copilot]

Description

pr-checker.yml directly interpolates the PR body into a bash script via "${{ github.event.pull_request.body }}". Backtick-wrapped words in the PR description (e.g. `dscwoc`, `level-1/2/3`) are interpreted as command substitution, causing command not found errors.

Also adds a one-shot migration script for transitioning all 14 open issues from GSSoC/Hacktoberfest to DSCWoC labeling.

Issue Number

Changes Made

• .github/workflows/pr-checker.yml — Move PR body from inline interpolation to env: block (GitHub-recommended practice)

# Before (broken) — bash executes backtick content as commands
run: |
  PR_DESCRIPTION="${{ github.event.pull_request.body }}"

# After (fixed) — passed as plain string via env var
env:
  PR_DESCRIPTION: ${{ github.event.pull_request.body }}
run: |
  if [[ -z "$PR_DESCRIPTION" ]]; then

• scripts/dscwoc-migrate-issues.sh — Idempotent script that creates DSCWoC labels, removes hacktoberfest/gssoc2025 labels, replaces Level 1/2/3 → level-1/2/3, updates all 14 issue descriptions with codebase-aware context, creates 5 new improvement issues, and deletes obsolete labels. Includes gh CLI install/auth pre-checks.

Type Of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Screenshots or Videos

N/A

How Has This Been Tested?

• bash -n scripts/dscwoc-migrate-issues.sh syntax validation
• Verified the CI failure is reproduced by the old interpolation pattern and resolved by the env: approach

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented on my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Additional Information

The migration script is run once by the project admin after authenticating with gh auth login. See script header for full install/auth instructions.

Original prompt

Analyse all the open issue in this repositories and anaylise the entire codebase and based on the entire project first:

• Update the existing issue by removing the remove the hacktoberfest and gssoc label and add the exact labels in the context i'll provide you below okay.
• If needed creat the new issue based on the project improvement regarding this please take the time and don't make any mistake okay.

here is the context:

1. ROLE OF A MENTOR
   MENTORS (PROJECT ADMINS) PLAY A KEY ROLE IN
   DSCWOC BY GUIDING CONTRIBUTORS, MAINTAINING
   PROJECT QUALITY, AND ENSURING A HEALTHY AND
   INCLUSIVE OPEN-SOURCE ENVIRONMENT.

2. RESPONSIBILITIES OF A MENTOR
   DEFINE CLEAR PROJECT GOALS AND CONTRIBUTION
   SCOPE
   MAINTAIN AN UP-TO-DATE AND DETAILED PROJECT
   README
   CREATE AND MANAGE GITHUB ISSUES
   REVIEW PULL REQUESTS REGULARLY
   PROVIDE CONSTRUCTIVE AND RESPECTFUL
   FEEDBACK

3. PROJECT READINESS
   THE REPOSITORY IS PUBLIC
   THE PROJECT ALIGNS WITH DSCWOC DOMAINS
   README INCLUDES:
   PROJECT OVERVIEW
   TECH STACK
   SETUP AND INSTALLATION INSTRUCTIONS
   CONTRIBUTION GUIDELINES
   BEGINNER-FRIENDLY ISSUES ARE CLEARLY LABELED

4. ISSUE MANAGEMENT GUIDELINES
   ASSIGN ISSUES ONLY AFTER A CONTRIBUTOR REQUESTS
   THEM
   DO NOT ASSIGN THE SAME ISSUE TO MULTIPLE
   CONTRIBUTORS
   UNASSIGN ISSUES IF CONTRIBUTORS REMAIN INACTIVE
   FOR LONG PERIODS
   ENSURE ISSUES ARE CLEAR, WELL-DEFINED, AND
   ACHIEVABLE

5. PULL REQUEST REVIEW GUIDELINES
   MENTORS SHOULD:
   VERIFY CORRECTNESS AND RELEVANCE OF THE PR
   ENSURE ORIGINALITY AND ABSENCE OF PLAGIARISM
   CHECK CODE QUALITY AND DOCUMENTATION
   REJECT SPAM, DUPLICATE, OR LOW-EFFORT PRS
   REQUEST CHANGES POLITELY AND CLEARLY

6. COMMUNICATION GUIDELINES
   MAINTAIN PROFESSIONAL AND RESPECTFUL
   COMMUNICATION
   ENCOURAGE BEGINNERS AND FIRST-TIME
   CONTRIBUTORS
   AVOID UNNECESSARY DELAYS IN RESPONSES
   HANDLE CONFLICTS CALMLY AND FAIRLY

DSC WINTER OF CODE — PROJECT ADMIN MANUAL
The DSCWoC scoring system is quality-focused, transparent, and
beginner-friendly. Points are awarded only for meaningful, reviewed, and
merged contributions. Project Admins and Mentors are responsible for
maintaining fairness and consistency.

1. PR ELIGIBILITY FOR SCORING (ADMIN RESPONSIBILITY):-
   REQUIREMENT:
   • Program Label: The PR must include the label “dscwoc”
   • Difficulty Label: The PR must include exactly one difficulty label (level-1,
   level-2, or level-3)
   • Merge Status: The PR must be reviewed and merged by a mentor
   or project admin
   NOTES:
   📌 Points are awarded only after the PR is merged.
   📌 If a PR is not merged or is missing required labels, it receives 0 points.
2. ISSUE DIFFICULTY LEVELS & BASE POINTS (ADMIN ASSIGNMENT):-
   ADMIN RULES
   Do not change difficulty after work has started unless absolutely necessary
   If difficulty is changed, clearly inform the contributor Avoid overusing
   level-3; reserve it for genuinely complex work
   Difficulty Description Points
   Level-1 Beginner-friendly tasks 10
   Level-2 Moderate complexity 20
   Level-3

Advanced or complex
work

30

7. SCORING, ISSUES &
   LEADERBOARD SYSTEM

8. Task-Based Issue Labels (Mandatory) :-
   In addition to difficulty levels, every issue must include at least one task-based label
   to describe the nature of work. ️ Standard Task Labels(When to use)
   4.Beginner-Friendly Issue Labels (Strongly Recommended):- Admins are expected to actively support new contributors by tagging suitable issues. Admin Guidance:-
   Ideal first contribution
   limited scope and clear steps
   Suitable for contributors new to the project
   ⭐Best Practices
   Ensure clear problem statements and acceptance criteria Do not tag complex issues
   as beginner-friendly Maintain a healthy mix of beginner and intermediate issues

9. Bonus Points
   Consistent weekly contributions: +10
   Exceptional contribution (mentor-approved): +10
   Helping others (verified): +5
   6.Manual Point Override:-In exceptional cases, Project Admins or Lead Mentors may
   override the calculated score.
   Override Rules
   Must include a clear justification
   Must be logged for transparency
   Overrides are final
   Label When to Use
   bug Incorrect behavior, crashes, or logical errors
   feature New functionality being added
   ui/ux Interface or user experience improvements
   enhancement Improving or extending existing functionality
   documentation README updates, guides, or written explanations
   refactor Code restructuring without behavior change
   testing Adding or improving automated tests

7.MENTOR REVIEW POLICY:-
ALL PRS MUST BE REVIEWED FOR:
CODE QUALITY
BEST PRACTICES
ORIGINALITY
LOW-EFFORT, SPAM, OR COPIED PRS MUST BE REJECTED
8.LEADERBOARD SYSTEM
THE LEADERBOARD REFLECTS VERIFIED CONTRIBUTOR PROGRESS THROUGHOUT
THE PROGRAM.
CONTRIBUTORS ARE RANKED BASED ON:

1. TOTAL POINTS EARNED
2. NUMBER OF MERGED PRS
3. HIGHER DIFFICULTY CONTRIBUTIONS (LEVEL-2 AND LEVEL-3)
4. EARLIER PR SUBMISSION (TIE-BREAKER)
   LEADERBOARD UPDATES

9.ISSUE CREATION RULES
ISSUES ARE CREATED BY PROJECT ADMINS
NEW ISSUES MAY BE ADDED DURING THE PROGRAM
CONTRIBUTORS SHOULD NOT OPEN ISSUES UNLESS INSTRUCTED
CONTRIBUTORS MUST WORK ONLY ON MENTOR-ASSIGNED OR APPROVED
ISSUES
...

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
flash-fathom-ai	Ready	Preview, Comment	Feb 8, 2026 4:03pm