| name | new-resource-list |
| description | Use when the user wants to scaffold a new PUBLIC GitHub resource list (Awesome-style index of third-party repos). Triggers — "create a resource list for X", "new awesome list", "let's build a list of Y tools/repos". Produces the canonical README shape (alphabetical sections, project/description/stars table, scope block, CC0). Public repo on GitHub. For private lists use `new-private-resource-list`. |
New Resource List (Public)
Scaffold a new public GitHub resource list following Daniel's standard shape.
Inputs to gather (silently infer where possible)
- Topic / scope — what the list catalogues (e.g. "AI evaluation tools", "Israeli civic-tech repos").
- Repo name — Train-Case, prefixed
Awesome- if it fits the genre. Examples: Awesome-AI-Evaluations-Tools, LLM-Memory-Layers-Index. Confirm with the user only if ambiguous.
- Initial entries — URLs the user dropped. May be zero (scope-only scaffold).
- Section scheme — either user-provided or AI-proposed from the entries. If proposing, list the sections back to the user before writing.
Standard shape (the default)
Everything below is the default — only deviate if the user explicitly asks.
-
Filename: README.md at repo root.
-
Awesome badge at the top.
-
Short scope block: In Scope / Out Of Scope bullets.
-
Sources Used block when the user supplied GitHub topic URLs or other discovery sources. Placement: 1–3 sources render inline near the top, immediately under the scope block. 4+ sources render in a ## Sources Used section at the bottom (just above List Authorship) so they don't crowd out the recommendations.
-
Contents TOC linking to each section.
-
Sections in alphabetical order. Within each section, rows alphabetical by display name.
-
Each section is a 4-column table — Stars and Last Updated are mandatory, never dropped:
| Project | Description | Stars | Last Updated |
|---|---|---|---|
| [Display Name](https://github.com/OWNER/REPO) | One-sentence description (≤22 words). |  |  |
-
Display name = human-readable (DeepEval, not deepeval). Description from gh repo view OWNER/REPO --json description -q .description, trimmed to ≤22 words. No marketing tone.
-
Footer: List Authorship with author block + CC0 license badge.
Procedure
- Resolve repo path. Default to
~/repos/github/my-repos/<RepoName> (Daniel's convention). Honour RESOURCE_LIST_PUBLIC_BASE env var if set.
- Resolve template. If
RESOURCE_LIST_TEMPLATE_PATH is set and points to a readable file, use it as the base instead of the built-in template below; still apply alphabetical ordering.
- Fetch metadata for every supplied URL in parallel:
gh repo view OWNER/REPO --json description,stargazerCount,pushedAt (Bash, batched). Skip dead/missing repos and report them. (Stars and last-updated are mandatory columns; both badges render off OWNER/REPO, so the live values come from shields.io — but capture pushedAt and stargazerCount for the release-resource-list CSV export.)
- Categorise. If the user gave sections, use them verbatim. Otherwise propose a section list (alphabetical) covering the entries, and confirm with the user only if the entries span clearly different sub-domains. If the user dropped a flat list and asked for help organising, do the categorisation work — that is the value-add of this skill.
- Write README.md using the shape above. Alphabetise sections. Alphabetise rows within each section.
- Initial commit + create GitHub repo.
git init if not already.git add -A && git commit -m "Initial commit: <topic> resource list"gh repo create danielrosehill/<RepoName> --public --source=. --description "<one-line>" --push- Creating a public repo requires explicit user authorisation — confirm before running
gh repo create --public.
- Optional index registration. If
RESOURCE_LIST_PUBLIC_INDEX is set (e.g. Resources-Lists-Index), offer to add a pointer there using its existing format. Do not auto-edit without confirmation.
- Report. Repo URL, entry count, sections used, anything skipped.
Built-in README template
# <Title> [](https://awesome.re)
[](https://github.com/danielrosehill/<RepoName>)
<One-paragraph description of the list and its scope.>
## Scope
### In Scope
- ...
### Out Of Scope
- ...
{If 1–3 GitHub topic URLs / discovery sources were supplied, render here as a single line:
**Sources Used:** [topic-slug](https://github.com/topics/topic-slug) · [topic-slug](https://github.com/topics/topic-slug)
If 4+ sources, omit here and render the `## Sources Used` section near the bottom instead (template at end of this file).}
---
## Contents
- [<Section A>](#section-a)
- [<Section B>](#section-b)
---
## <Section A>
| Project | Description | Stars | Last Updated |
|---|---|---|---|
| [Project Name](https://github.com/OWNER/REPO) | Description ≤22 words. |  |  |
##
| Project | Description | Stars | Last Updated |
|---|---|---|---|
---
{If 4+ GitHub topic URLs were supplied as sources, render the section below; otherwise omit.}
This list was assembled by surveying the following GitHub topic pages and awesome lists:
[]()
...
---
Curated by []().
Contributions, corrections, and PRs welcome.
[]()]()
To the extent possible under law, the author has dedicated all copyright and related and neighboring rights to this list to the public domain worldwide under [](). Linked projects retain their own licenses.
Edge cases
- No entries supplied — write a scope-only scaffold with empty section tables. Still create the repo.
- Mixed Git hosts — only GitHub repos get the star badge. For GitLab/Codeberg/etc., omit the badge cell or render
—.
- Org URLs — list each notable repo separately rather than the org root.
- Existing repo at the target path — stop and report; do not overwrite.
