Github Stars Organizer

GitHub Stars Organizer

Organize a user's GitHub starred repositories by reusing existing lists, creating only a small number of broad missing lists, and adding unlisted repositories to the right places.

This skill is for organizing starred repositories, not for general GitHub account maintenance.

Default stance: be conservative, review-first, and additive. A bad list assignment is worse than leaving a repository unfiled for later review.

Required Tooling

• Preferred browser automation skill: chrome-cdp
• A compatible equivalent is acceptable only if it can:
• control an authenticated local browser session
• read the GitHub Stars page
• inspect repository list membership
• create lists
• add repositories to lists

If chrome-cdp or an equivalent browser automation skill is unavailable, stop and say that authenticated browser automation is required.

Remote Debugging Prerequisite

If Chrome remote debugging is not enabled yet, tell the user to do this first:

1. Open chrome://inspect/#remote-debugging 2. Enable remote debugging / remote target discovery 3. Make sure GitHub is logged in in that Chrome profile 4. Confirm the local debugging endpoint is available, commonly 127.0.0.1:9222 5. Approve any Chrome "Allow debugging" prompt for the GitHub tab if it appears

Do not proceed until browser automation can reach the GitHub tab.

Inputs

The user should provide at least one of:

• GitHub username
• GitHub profile URL
• GitHub Stars URL

Do not hardcode any specific account, repository, or list names.

Default Safety Rules

• Default to additive organization only
• Do not unstar repositories
• Do not remove repositories from lists
• Do not rename or delete lists
• If a repository is already in one or more lists, skip it by default
• Reuse existing lists before creating new ones
• Keep the final list system compact and reusable
• Prefer one primary list per repository
• Add a second list only when it clearly improves retrieval
• Add a third list only for genuine cross-domain repositories
• If confidence is not high, do not guess
• Report ambiguous repositories instead of forcing them into a weak category

If the user explicitly asks for reorganization that would modify existing assignments, ask for confirmation before changing any existing list membership.

Operating Modes

• Default mode: review-first
• analyze lists
• analyze unlisted repositories
• propose taxonomy and assignments
• stop for confirmation before writing if ambiguity is material
• Auto-apply mode
• only use when the user explicitly asks for direct execution
• still stop if ambiguity is high or list count would exceed the cap

If the user did not clearly ask for immediate writes, prefer the default review-first mode.

Primary Workflow

1. Open the target user's Stars page in the authenticated GitHub browser session. 2. Read all existing lists first and build a normalized map of:

• list name
• semantic meaning
• probable duplicates or near-duplicates

3. Read all starred repositories. Important:

• GitHub Stars pagination is cursor-based.
• Follow the Next link/cursor.
• Do not assume page=N is reliable.

4. For each starred repository, inspect its list membership. 5. Split repositories into:

• already listed
• unlisted

6. Only organize the unlisted repositories unless the user explicitly asks for broader reorganization. 7. Build a taxonomy plan:

• strongly prefer existing suitable lists
• create missing lists only when they are broad and reusable
• avoid near-duplicate lists

8. Classify each unlisted repository by primary intent, not by incidental words in the description. 9. Assign a confidence level to each proposed placement:

• high
• medium
• low

10. Keep the total number of lists ideally between 5 and 15. 11. If the plan would require more than 15 total lists, stop and ask the user whether the extra lists may be created. Include:

• the exact proposed new list names
• a short reason for each

12. If ambiguity is material, stop and ask the user before writing. Treat ambiguity as material when:

• more than 10 repositories are medium/low confidence, or
• more than 10% of unlisted repositories are medium/low confidence, or
• many repositories appear to require a new category not yet approved by the user

13. Create any approved missing lists. 14. Add each unlisted repository to the smallest reasonable number of lists. Target:

• usually 1 list
• sometimes 2
• rarely 3

15. Verify every repository after update by re-reading its current list membership. 16. Report:

• lists reused
• lists created
• repositories added
• repositories skipped because they were already organized
• repositories intentionally left unassigned because confidence was too low
• ambiguities or repos that may need user judgment

Taxonomy Rules

• Prefer broad, stable themes over tiny one-off buckets
• New lists should usually represent a category that can hold multiple repositories
• Do not create a new list for fewer than 3 repositories unless the user explicitly wants that category
• Prefer single-responsibility list names
• Do not use compound list titles with &, /, or other bundled meanings unless the user explicitly asked for that style
• One list title should represent one retrieval concept
• Avoid trivial distinctions like:
• AI Agents vs Agent Frameworks vs Autonomous Agents
• UI, Frontend, Web UI, Frontend Tools
• Prefer merging into one broad list unless the distinction is genuinely useful for retrieval
• Good list systems usually include a mix of:
• domain buckets
• tooling buckets
• reference/awesome/tutorial buckets
• Avoid creating language-only lists unless the user explicitly wants language-based organization

If the current taxonomy is missing an obvious stable category, create it only when it has a clear long-term use.

Examples of acceptable missing categories:

• Web Tooling
• Build Tooling
• Auth
• Identity
• Browser Automation

Examples of bad categories:

• Random JS
• Stuff To Try
• Interesting Repos
• Tools 2

Better Algorithm

Use a two-pass planner:

1. Reuse-first pass Match every unlisted repository against existing lists before proposing anything new.

2. Gap-creation pass Create new lists only for clusters that:

• do not fit an existing list cleanly
• are broad enough to be useful again
• help retrieve repositories later

This keeps the system stable and prevents uncontrolled list growth.

Also cap per-repository assignment density:

• prefer 1 list
• allow 2 when both are clearly helpful
• allow 3 only when the repository spans multiple major themes

This prevents over-tagging.

Add a confidence gate:

• high confidence:
• repository name, description, and ecosystem all point to the same category
• medium confidence:
• one strong clue exists, but there are plausible alternatives
• low confidence:
• the repository could fit multiple categories equally well, or the description is too vague

Default write policy:

• auto-apply only high-confidence assignments
• ask the user before applying medium-confidence assignments in bulk
• never auto-apply low-confidence assignments

Add a naming gate:

• if a proposed new list name feels like two categories glued together, split it
• prefer Frontend and Design Systems over Frontend & UX
• prefer Backend and Infrastructure over Backend & Infra
• prefer Learning and Reference only if the user wants both as separate retrieval concepts; otherwise pick the one that best matches intent

Classification Rules

Classify by the repository's primary job, not by stray words in its description.

Signal priority:

1. repository name 2. short description / tagline 3. project type and user 4. ecosystem and technology 5. only then secondary keywords

Negative rule:

• a repo is not backend just because it mentions server, node, API, or auth
• a repo is not frontend just because it has a UI or demo
• a repo is not learning/reference just because it has docs or examples
• a repo is not AI coding tooling just because it is used by developers
• a repo is not productivity just because it is an app

Use the category only when the category is the main value proposition.

Category Intent

• Learning
• use only for awesome-lists, tutorials, guides, courses, examples, templates, references, and educational starter material
• do not use for mature runtimes, frameworks, products, or libraries unless their main role is educational

• Frontend
• use for UI frameworks, component libraries, CSS systems, animation libraries, editors, design systems, browser interaction tooling, and clear front-end app frameworks
• do not use for agent systems just because they have a UI

• Backend
• use for APIs, databases, deployment stacks, observability systems, infrastructure platforms, queues, auth servers, server-side platforms, and operations tooling
• do not dump generic developer tooling or web build tooling here by default

• AI Coding Tools
• use for tools whose primary purpose is helping people write, inspect, run, review, or manage code with AI or developer automation
• do not use for ordinary libraries, frameworks, or product apps

• AI Agents
• use for agent runtimes, orchestration systems, agent operating environments, autonomous assistants, and multi-agent control planes
• do not use for prompt collections, awesome-lists, or evaluation content unless the repo itself is an agent system

• AI Skills & Prompts
• use for reusable prompts, skills, instruction packs, subagents, templates, and other composable prompting artifacts

• RAG & Search
• use for retrieval, vector search, memory systems, embedding pipelines, indexing, semantic search, and knowledge retrieval

• Productivity & Personal Tools
• use for end-user note apps, personal systems, automation tools, messaging bridges, utilities, and personal workflow software

Descriptions may be broader than titles, but the title itself should stay single-purpose.

If a repository does not fit an existing category cleanly, prefer:

• proposing a new stable list, or
• leaving it unassigned for review

instead of forcing it into the nearest broad bucket.

GitHub-Specific Notes

• Read detailed implementation guidance in references/algorithm.md
• Read conservative classification guidance in references/classification.md
• The core repository membership endpoint is /<owner>/<repo>/lists
• Use that endpoint to detect whether a repository is already organized
• If a repository already has checked lists, skip it by default
• After adding list assignments, re-fetch the same menu and confirm the expected checked state

When to Ask the User

Ask before proceeding only when one of these is true:

• the target account is unclear
• browser automation is unavailable
• Chrome remote debugging is not enabled
• the GitHub session is not authenticated
• more than 15 total lists would be needed
• ambiguity is high enough that bulk writes would likely create bad assignments
• a large number of borderline or duplicate list names already exist and safe reuse is unclear

Critical Prohibitions

• Do not use a specific user's account as a hidden default
• Do not blindly create dozens of lists
• Do not destroy or rewrite existing organization without explicit permission
• Do not rely on page=N for GitHub Stars traversal
• Do not treat a repository as unlisted until its current list membership has been checked
• Do not classify by programming language alone
• Do not use Learning & Reference as a lazy fallback for uncertain repositories
• Do not classify a repository into Backend & Infra or Frontend & UX based on weak incidental keywords

GitHub Stars Organizer Algorithm

This reference documents a safe, repeatable workflow for organizing GitHub starred repositories with browser automation.

Goal

Create or reuse a compact list system so starred repositories become easy to find later.

Default operating mode:

• only organize repositories that are not yet in any list
• preserve all existing organization
• add, do not subtract
• prefer review-first over blind bulk writes

Required Environment

• Authenticated GitHub session in a local browser
• Browser automation via chrome-cdp or equivalent
• Chrome remote debugging enabled

If the browser tool cannot read and interact with the live GitHub session, stop.

Remote Debugging Instructions

For Chrome or Chromium-based browsers:

1. Open chrome://inspect/#remote-debugging 2. Enable remote debugging 3. Confirm the local endpoint is available, typically 127.0.0.1:9222 4. Open GitHub in that same browser profile 5. Approve any one-time Chrome "Allow debugging" prompt for the GitHub tab

Data Collection Order

Always collect data in this order:

1. Existing lists 2. All starred repositories 3. Current list membership for each repository 4. Candidate taxonomy updates 5. New list creation 6. Repository additions 7. Verification

This order matters because existing lists should shape the plan before any new lists are proposed.

Default Execution Policy

Use this policy unless the user explicitly asks for aggressive direct execution:

1. analyze existing lists 2. analyze all unlisted repositories 3. build a proposed mapping 4. identify ambiguous repositories 5. stop for confirmation if ambiguity is material 6. only then write changes

Ambiguity is material when:

• more than 10 repositories are medium/low confidence, or
• more than 10% of unlisted repositories are medium/low confidence, or
• the taxonomy would need several new lists to stay coherent

Existing Lists

Start by reading all current lists and normalize names conceptually.

Look for:

• exact duplicates
• near-duplicates
• singular/plural variants
• wording variants with the same retrieval purpose

Examples of near-duplicates:

• AI Tools and AI Tooling
• Frontend and Frontend & UX
• Learning, Tutorials, Reference

Do not create new lists that overlap heavily with these.

Also infer what each existing list is really meant to contain. Use repository samples from that list, not just the list title.

Traversing Stars

GitHub Stars uses cursor-based pagination.

Do this:

• open the Stars page
• read repository cards on the current page
• follow the Next link href/cursor
• continue until there is no Next

Do not do this:

• do not rely on page=1, page=2, etc.
• do not assume every page URL can be synthesized safely

Repository Membership Check

Each repository has a list-menu endpoint:

/<owner>/<repo>/lists

Use it to determine:

• repository id
• list form action
• CSRF/authenticity token
• current checked list ids

If one or more list checkboxes are already checked:

• treat the repository as already organized
• skip it by default

Only include it in the plan if the user explicitly asked for deeper reorganization.

This is non-negotiable in additive mode.

Planning Rules

For unlisted repositories:

1. Try to map them into existing lists first. 2. Group the leftovers into broad reusable clusters. 3. Create new lists only for those clusters.

Before assigning a repository, determine its:

• primary job
• likely future retrieval need
• confidence level

If the category fit is weak, leave it unassigned for review.

Good new lists:

• broad enough to be reused
• distinct from current lists
• useful as search buckets later
• likely to hold at least 3 repositories now or soon
• named around one clear concept

Bad new lists:

• one-off lists for a single repository
• overly narrow technology splits
• lists that repeat the meaning of an existing list
• vague catch-all lists
• compound names that bundle multiple retrieval concepts together

List Count Guardrail

Target total list count:

• ideal: 5 to 15

Rules:

• if the current system is already within that range, prefer reuse over creation
• if new list creation would push the total over 15, stop and ask the user

When asking the user, present:

• proposed new list names
• why each is needed
• how many repositories each would likely contain

Naming Guardrail

Prefer single-purpose list titles.

Good:

• Frontend
• Backend
• Infrastructure
• Learning
• Reference
• Browser Automation
• Build Tooling

Bad:

• Frontend & UX
• Backend & Infra
• Learning & Reference
• Tools / Utilities

If a name needs & to make sense, it is usually hiding two categories.

Assignment Density

Per repository:

• prefer 1 list
• allow 2 if both are clearly useful
• allow 3 only for genuine cross-category repositories

Avoid tagging a repository into many lists. The goal is retrieval, not exhaustive ontology.

Default tagging policy:

• one list when possible
• two only when both materially improve retrieval
• three only for truly cross-domain repositories
• zero is acceptable when confidence is too low

Safe Update Pattern

When adding a repository to lists:

1. Read the repository's current list form from /<owner>/<repo>/lists 2. Compute desired list ids 3. Submit the update 4. Re-fetch /<owner>/<repo>/lists 5. Verify checked ids match expectation

If operating in default additive mode, desired list ids are just the new target lists because the repo started unlisted.

If later extending this skill for editing already-listed repos, preserve the existing checked ids unless the user explicitly approved reassignment.

Conservative Classification

Read references/classification.md before applying assignments.

Mandatory rules:

• classify by primary intent, not incidental keywords
• do not classify by implementation language
• do not dump vague repos into Learning & Reference
• do not treat general web tooling as Backend & Infra by default
• do not treat every repo with a UI as Frontend & UX

Use high confidence only when the name, description, and repo type all point to the same category.

Suggested Default Taxonomy

Do not hardcode this taxonomy, but it is a useful baseline when the account has no lists yet:

• AI Agents
• AI Coding Tools
• AI Skills & Prompts
• AI Safety & Evals
• RAG & Search
• Frontend & UX
• Backend & Infra
• Productivity & Personal Tools
• Learning & Reference

This is a strong default because it is:

• broad
• stable
• discoverable
• well under the 15-list cap

But it is still only a baseline.

If a repository cluster clearly does not fit these buckets, propose a better reusable list instead of forcing the fit.

Example:

• webpack, vite, bundler plugins, and web build analyzers may justify Build Tooling or Web Tooling

Reporting

Final report should include:

• total starred repositories processed
• existing lists reused
• new lists created
• repositories added
• repositories skipped because they already had lists
• repositories withheld because confidence was too low
• any ambiguous cases

If there were no changes, say why:

• no unlisted repositories
• all unlisted repos already fit existing lists after inspection plan
• user did not approve exceeding the list cap

Failure Cases

Stop and explain the blocker if:

• browser automation cannot attach to the GitHub tab
• the user is not logged into GitHub
• GitHub returns list menu pages that cannot be parsed
• Chrome remote debugging is disabled
• the required tool is missing

Do not guess around these failures.

Conservative Classification Rules

This reference exists to prevent low-quality list assignments.

The previous common failure mode was simple keyword matching that pushed repositories into broad buckets such as Frontend & UX, Backend & Infra, or Learning & Reference for weak reasons.

Core Principle

Classify the repository by its primary retrieval value:

• why the user would want to find it later
• what job the repository mainly does
• what kind of thing it fundamentally is

Not:

• a random word in the description
• the implementation language
• the fact that it contains docs, demos, or examples
• the fact that developers might use it

Confidence Model

Every proposed assignment should carry a confidence level.

High Confidence

Use high confidence only when most signals align:

• repository name strongly indicates category
• description strongly indicates category
• repository type matches category
• no strong competing category exists

Example:

• awesome-webauthn -> Learning & Reference
• agent-orchestrator -> AI Agents
• react-draft-wysiwyg -> Frontend & UX

Medium Confidence

Use medium confidence when:

• one or two signals suggest a category
• but another category is also plausible

Medium-confidence repos should usually be shown to the user before bulk apply unless the user explicitly wants aggressive automation.

Low Confidence

Use low confidence when:

• the repo description is vague
• multiple categories are plausible
• the repo is a mixed product
• the category fit depends on assumptions

Low-confidence repos should not be auto-assigned.

Anti-Randomness Rules

Keep List Names Single-Purpose

Do not hide uncertainty inside compound list titles.

Bad:

• Frontend & UX
• Backend & Infra
• Learning & Reference

Better:

• Frontend
• UX
• Backend
• Infrastructure
• Learning
• Reference

If the category still feels ambiguous after splitting the name, the repository likely needs human review or a different taxonomy.

Do Not Use Language as a Category Proxy

Bad:

• TypeScript -> Frontend & UX
• Python -> Backend & Infra
• Shell -> Learning & Reference

Language is almost never enough.

Do Not Use Docs Presence as a Reference Signal

A runtime, framework, or product often has:

• docs
• examples
• demos

That does not make it Learning & Reference.

Do Not Use Vague Infra Words

Words like these are weak on their own:

• server
• node
• API
• platform
• tooling
• system

Use Backend & Infra only when the repo is clearly an infrastructure or backend platform.

Do Not Use Vague Frontend Words

Words like these are weak on their own:

• dashboard
• app
• design
• visual
• browser

Use Frontend & UX only when the repo is clearly about UI, web interaction, browser UX, front-end frameworks, or front-end components.

Category Boundaries

Learning & Reference

Use when the repo is mainly:

• an awesome-list
• a guide
• a tutorial
• a course
• a reference
• a starter meant primarily for learning
• an examples collection

Do not use when the repo is mainly:

• a production framework
• a runtime
• a real product
• a standalone app
• a utility library

Frontend & UX

Use when the repo is mainly:

• a UI framework
• a component library
• a design system
• a browser-side interaction library
• an animation library
• a front-end editor
• CSS or layout tooling

Do not use when the repo is mainly:

• an agent platform with a UI
• a build system that is not specifically front-end oriented
• a general productivity app

Backend & Infra

Use when the repo is mainly:

• a backend framework
• a database
• an auth server
• deployment infrastructure
• observability
• orchestration infrastructure
• queues, workers, storage, infra services

Do not use when the repo is mainly:

• front-end tooling
• a developer utility
• a reference list
• an app with a backend

AI Coding Tools

Use when the repo is mainly:

• a coding assistant tool
• code review / code generation tooling
• an IDE or CLI companion for coding
• a code intelligence tool
• a build/run/test developer tool tightly tied to coding workflows

Do not use when the repo is mainly:

• a general library
• a front-end framework
• a backend platform
• an end-user app

AI Agents

Use when the repo is mainly:

• an agent runtime
• an orchestrator
• an assistant platform
• a multi-agent system
• an autonomous task execution environment

Do not use when the repo is mainly:

• an awesome-list of agents
• prompts/skills only
• evaluation rules

When to Propose a New List

If many repositories do not fit existing categories cleanly, propose a new list instead of forcing them into the wrong one.

Examples of legitimate new lists:

• Web Tooling
• Build Tooling
• Auth
• Identity
• Browser Automation

Only propose a new list when:

• at least 3 repositories would fit it now, or
• it is obviously a durable recurring category

Ambiguity Escalation

Stop and ask the user if:

• a cluster of repos does not fit current lists cleanly
• many repos are medium/low confidence
• a new category is clearly needed but not yet approved

It is better to leave a repo unassigned than to poison the taxonomy.