Learn
Scan the current codebase, compare against existing phucbm/skills knowledge, and suggest new skills to save or existing skills to update. Use when the user says "learn from this repo", "what can I save from here", or "run learn".From its SKILL.md
npx -y skills add phucbm/skills --skill learnAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.4 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it
What this skill does
Reads your existing skills from phucbm/skills README, scans the current codebase, diffs the two, and presents a ranked list of save/update candidates with recommended file paths. You pick which ones to act on.
Steps
Phase 1 — Pull existing skills index (read README only)
gh repo clone phucbm/skills /tmp/phucbm-skills 2>/dev/null || git -C /tmp/phucbm-skills pull
Read /tmp/phucbm-skills/README.md only. Extract:
- Knowledge table: topic names and descriptions (what's already saved)
- Skills table: skill names (operational skills already known)
Phase 2 — Scan current codebase (run in parallel)
Read these in parallel:
package.json/composer.json/pyproject.toml/Cargo.toml/go.mod— deps and scripts- Config files at root:
next.config.*,vite.config.*,drizzle.config.*,biome.jsonc,playwright.config.*,tailwind.config.* .github/workflows/*.yml— CI/CD patternsscripts/directory — custom tooling- Key source entry files:
lib/,src/,app/top-level only (don't recurse deep — read index/entry files) .claude/CLAUDE.mdand.claude/docs/if present — already-documented patterns
Extract topics: libraries used, non-obvious configurations, custom patterns, architectural decisions, CI/CD tricks.
Phase 3 — Diff and rank
Cross-reference found topics against existing README knowledge and skills tables.
Produce two lists with recommended file paths for every item:
NEW — topics found in codebase with no match in existing knowledge/skills:
[N] Topic name — one-line reason it's worth saving
skill: skills/<topic>/SKILL.md
knowledge: knowledge/<category>/<slug>.md
If multiple new topics share knowledge (e.g. rag + pinecone), show the relationship:
[N] RAG pipeline — generic chunk→embed→query pattern, reusable with any vector DB
skill: skills/rag/SKILL.md
knowledge: knowledge/rag/concepts.md
[N+1] Pinecone — vector DB setup, upsert, query, metadata filters
skill: skills/pinecone/SKILL.md
knowledge: knowledge/pinecone/setup.md
note: skills/rag will also reference knowledge/pinecone/setup.md
UPDATE — topics that overlap an existing entry but the codebase shows something new:
[N] update: <existing-topic> — what's new or different
file: knowledge/<category>/<slug>.md
Rank by: reusability across projects × non-obviousness (things you'd have to figure out again from scratch).
Skip topics that are: trivial to look up, fully covered already, or project-specific with no transfer value.
Phase 4 — User picks, then act
Present the full list and ask: "Which ones to save? (e.g. 1, 3, update 4 — or 'all')"
Wait for response. Then for each selected item:
- NEW picks → invoke
add-skillflow: draftskills/<topic>/SKILL.md+knowledge/<category>/<slug>.md, show both, confirm, push - UPDATE picks → invoke
update-skillflow: show diff of proposed changes to existing knowledge file, confirm, push
Each item is confirmed individually. Never batch-push without showing what will change.
After all pushes: confirm final state and remind user to run /plugin marketplace update phucbm in other projects to get the new skills.
Rules
- Phase 1 reads README.md only — no file tree scanning of the skills repo (saves tokens)
- Phase 2 reads breadth-first — top-level files only, don't recurse into deep source dirs
- Always output recommended file paths in Phase 3 — user must confirm names before any files are written
- Skills are flat:
skills/<topic>/SKILL.md— one level only, no bucket subdirectories - Knowledge can be namespaced:
knowledge/<category>/<slug>.md— flag when shared across skills - Never suggest saving secrets, API keys, or project-specific data (user IDs, URLs, credentials)
- Knowledge files are generic — cite specific projects as examples only, never as facts
- Always confirm per-item before pushing
- If nothing new is found, say so clearly rather than inventing suggestions
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most learn study skills give in ~1.0k tokens
Counted across 545 of the 593 authors here whose files we hold, read 2026-09-06
- Treat the current directory as a teaching workspacein 20 of 545, across 17 files
- Teach knowledge first then practice skillsin 19 of 545, across 16 files
- Design lessons which build long-term retentionin 15 of 545, across 12 files
- Save each lesson as a self-contained HTML filein 15 of 545, across 12 files
- Question the user on why they want to learn thisin 15 of 545, across 12 files
- Reuse components from the assets directoryin 14 of 545, across 11 files
- Never trust your parametric knowledgein 13 of 545, across 10 files
- Record user preferences in NOTES.mdin 11 of 545, across 8 files
- Ground all teaching in the MISSION.md documentin 11 of 545, across 8 files
- Save each lesson to the lessons directoryin 8 of 545
- Question the user if the mission is unclearin 7 of 545
- Gather primary sources onlyin 7 of 545, across 4 files
Said here and by no other author read
- Read existing skills from the repository
- Scan the current codebase in parallel
- Diff found topics against existing knowledge
- Present a ranked list of candidates
- Ask the user which items to save
- Confirm each item individually before pushing
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.