Conversation
…ect management - Remove scripts/sync-github-project.mjs and its workflow - Remove TODO.md and PLAN.md (replaced by GitHub Issues/Projects) - Remove sync:github-project npm script - Add issue templates (bug, feature, task) with structured forms - Add PR template with checklist - Add auto-label workflow using actions/labeler with path-based rules - Add close-legacy-issues workflow to close all 29 existing issues - Add stale issue/PR management workflow - Update copilot-instructions.md, README.md, DESIGN.md, docs/development.md Co-authored-by: devlux76 <86517969+devlux76@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR removes the markdown-driven TODO/PLAN → GitHub sync pipeline and replaces it with GitHub-native project management primitives (issue forms, PR template, auto-labeling, and stale automation), updating docs accordingly.
Changes:
- Removed
TODO.md/PLAN.mdand thesync-github-project.mjsscript + workflow that attempted to mirror them into GitHub Issues/Milestones/Labels. - Added GitHub-native automation: issue forms, PR template, auto-label workflow + labeler config, stale workflow, and a one-shot legacy issue cleanup workflow.
- Updated developer docs and Copilot instructions to direct task tracking into GitHub Issues/Projects instead of repo markdown files.
Reviewed changes
Copilot reviewed 18 out of 18 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| scripts/sync-github-project.mjs | Removed the TODO/PLAN parsing + GitHub API sync script. |
| .github/workflows/sync-github-project.yml | Removed the workflow that ran the sync script on pushes / dispatch. |
| package.json | Removed the sync:github-project npm script entry. |
| TODO.md | Removed markdown task tracker (replaced by GitHub Issues/Projects). |
| PLAN.md | Removed markdown implementation plan tracker (replaced by GitHub Issues/Projects). |
| docs/development.md | Updated “documentation maintenance” workflow to reference DESIGN/README/api docs + GitHub Issues. |
| README.md | Added “Project Management” section pointing to Issues/Projects/Milestones/Labels/gh CLI. |
| DESIGN.md | Removed TODO.md-specific reference while keeping the guard note generic. |
| .github/workflows/stale.yml | Added weekly stale management for issues/PRs with exemptions. |
| .github/workflows/auto-label.yml | Added PR auto-labeling via actions/labeler. |
| .github/labeler.yml | Added path→label mappings for the CORTEX layer labels. |
| .github/copilot-instructions.md | Updated instructions to use GitHub-native project management instead of markdown tracking. |
| .github/PULL_REQUEST_TEMPLATE.md | Added PR checklist (lint/typecheck/tests/guard/docs). |
| .github/workflows/close-legacy-issues.yml | Added a manually-triggered workflow intended to close legacy sync-created issues. |
| .github/ISSUE_TEMPLATE/* | Added YAML issue forms for task/feature/bug plus template config. |
| // Paginate through all open issues | ||
| let page = 1; | ||
| let closed = 0; | ||
| while (true) { | ||
| const { data: issues } = await github.rest.issues.listForRepo({ | ||
| owner, repo, | ||
| state: "open", | ||
| per_page: 100, | ||
| page, | ||
| }); | ||
| if (issues.length === 0) break; | ||
|
|
||
| for (const issue of issues) { | ||
| // Skip pull requests (they appear in the issues API) | ||
| if (issue.pull_request) continue; | ||
|
|
||
| await github.rest.issues.addLabels({ | ||
| owner, repo, | ||
| issue_number: issue.number, | ||
| labels: ["wontfix"], | ||
| }); | ||
| await github.rest.issues.update({ | ||
| owner, repo, | ||
| issue_number: issue.number, | ||
| state: "closed", | ||
| state_reason: "not_planned", | ||
| }); |
There was a problem hiding this comment.
@copilot we may need to do this in steps. Removing the PLAN and TODO at this stage is not as important as simply closing the issues right now.
If possible the best path is to close the issues while keeping the files temporarily while we figure out what to do with them.
We need issues, just not these issues in this form.
At core we need all PRs to speak to actual issues, tasks and subtasks.
To do that, we need those need to be organized hierarchically from the top down.
Can we look to Projects, Milestones and other canonical GitHub project management structures, get those in place before we delete the docs which were quite frankly a lot of effort and expense to get this far?
There was a problem hiding this comment.
Restored TODO.md and PLAN.md in 49ea771. The close-legacy-issues workflow now targets only the 29 specific issue numbers ([21, 23–42, 56–63]) created by the old sync script, so it won't affect any new issues created afterward. The broken sync-github-project.mjs script and its workflow are still removed, and all the new GitHub-native automation (issue templates, PR template, auto-labeling, stale management) is in place ready to go alongside the existing docs.
…list - Restore TODO.md and PLAN.md (keep existing docs while GitHub-native project management is set up) - Rewrite close-legacy-issues.yml to only close the 29 specific issues created by the old sync script, not all future issues - Restore PLAN.md/TODO.md rows in README.md and copilot-instructions.md Co-authored-by: devlux76 <86517969+devlux76@users.noreply.github.com>
The
sync-github-project.mjsscript and its markdown-driven issue management created 29 issues with overlapping structure (22! combinatorial complexity) and no hierarchy. Agents now have directghCLI access, making the intermediary script unnecessary.Removed
scripts/sync-github-project.mjs(496 lines), its workflow, and npm scriptKept (temporarily)
TODO.mdandPLAN.mdare retained as reference documentation while GitHub Projects, Milestones, and hierarchical issue structures are establishedAdded: GitHub-native automation
.github/ISSUE_TEMPLATE/) — structured YAML forms for bugs, features, and implementation tasks with priority/layer dropdownsactions/labelerwith.github/labeler.ymlmapping file paths to all 10 CORTEX layer labelsactions/staleweekly sweep (60d stale, 14d close, P0/pinned exempt)close-legacy-issues.ymlworkflow (manually triggered) targeting only the 29 specific legacy issue numbers created by the old sync scriptUpdated docs
copilot-instructions.md— new "Project Management" section directing agents to useghCLI and GitHub IssuesREADME.md,DESIGN.md,docs/development.md— updated references to reflect current project management approachPost-merge
Trigger Actions → "Close Legacy Issues" to close the 29 legacy sync-generated issues, then delete that workflow file.
Original prompt
Here is some advice from CoPilot. We need to implement this advice and take it to the limit to maximize automation and minimize human friction.
Plan it all out in full, then implement it please. Keep in mind we have a broken TODO-to-issue manager that probably just needs to be removed since all agents now have full access to gh command line directly.
The combinatorics on the current issues is basically 22 factoral so structuring them hierarchically is probably not the most direct path on them.
Might be faster and easier to close all open issues as won't fix and drive issue formation and management from a different layer of GitHub itself so the subtask structure is correctly computed and preserved.
From CoPilot:
It sounds like you've built an excellent foundation of organization using markdown files (
DESIGN.md,PLAN.md,TODO.md), but you could possibly streamline your workflow by using GitHub's built-in features. Let’s explore some improvements based on your points:1. Overlapping Issues and Merge Conflicts
Challenge:
Solution: Organize Projects and Issues Effectively
Use Issue Hierarchies: Convert overarching tasks like "Task 1" into an Epic Issue. Within it, detail the smaller actionable tasks (Tasks 2–10) as checklist items in the description. For long-term organization:
Breaking Branches Properly: Divide work into feature-specific branches (e.g.,
feature/task-2) rather than having overlapping branches. During Conflict Fixing, consider rebasing branches regularly to avoid growing divergence.Relevant GitHub Features:
2. Markdown Files vs GitHub Collaboration Tools
Challenge:
DESIGN.md,PLAN.md, andTODO.mdduplicate project management features..mdfiles may fall out of sync or clutter the repo, making accountability difficult.Solution: Replace Markdown Files with Centralized Features
PLAN.mdandTODO.mdwith GitHub Projects:DESIGN.mdas Proper Documentation:README.mdor GitHub Wiki.Relevant GitHub Features:
.mdfiles with GitHub Issues for collaborative and accountable task-tracking.bug,enhancement,priority: high).3. Scalability and Feature Overlap
Challenge:
Solution: Adopt GitHub Automation Where Possible
Relevant GitHub Features:
Summary of Suggestions
High-Level Focus Areas:
.mdfiles for project management (e.g.,PLAN.md,TODO.md) with GitHub Issues and Projects.In addition to anything else CoPilot said, just try to derive the most automated system for agentic driven development with accountability that you can. You have all of GitHub's features at your disposal. Configure the repo and its supporting tools with that in mind.
Thanks so much!
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.