Unlearn Skills
Seventeen Claude Code skills for product work: specs, branch review, a pre-commit check and cleanup of leftovers.
- 106 ★ on the repository
- Last commit
Minimal access
Why this level
- The skills read the project and the git index and produce reports, and only checklists and specs are written as files.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/unlearn-skillsDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewMinimal accessThe tool runs nothing and makes no network calls.
- The skills read the project and the git index and produce reports, and only checklists and specs are written as files.
This is third-party code. Review the repository files before installing.
What it does
Unlearn Skills is a collection of 17 Claude Code skills for product development workflows from the studio unlearn.dev. The skills are grouped by stage. `spec-generator` turns a vague idea into a detailed specification and `feature-generator` expands it into a feature list ordered by dependencies. For review there are `code-review`, `review-order`, `first-five`, `triage` with risk tiers and `judge-arch`, which checks a branch against decisions in `DECISIONS.md`. Before release there are `ship-gate`, which returns PASS or BLOCK for the staged diff, `preflight` with a post-merge to-do list and `qa-checklist` for manual testing. Another group cleans up agent traces: `cruft-hunt`, `is-it-dead`, `zombies` and `leftovers` find duplicates, unused packages and extra abstractions. The skills only read the project and produce a report.
Who it is for. Developers and tech leads who work with Claude Code and want branches checked the same way before review and release.
Good fit when
- A vague idea must become a specification and a feature list to implement.
- Before a commit the staged diff must be checked for keys, debug code and stray large files.
- The branch is large and a reviewer needs a change map with risk tiers.
- After a long agent session the code holds duplicates and unused abstractions.
Not a fit when
- You work in Cursor or Codex: the set is written for Claude Code.
- You want automatic fixes: the skills report candidates and change nothing themselves.
- The project has no `DECISIONS.md`: `judge-arch` has nothing to check against.
Example request
/ship-gate — check what is staged before I commit.Limitations
The set is built for Claude Code and installs into the project's `.claude/skills/` through skills.sh. The skills read the project and produce reports, so the result depends on code quality and branch history. `ship-gate` works on staged changes only, and `cruft-hunt` first runs the stack's dead-code tool without adding it to the project. The repository has no license file. The last commit in the repository was made in November 2026.
How to disable. Delete the needed folders from the project's `.claude/skills/`. Report and checklist files the skills created are removed by hand.
FAQ
How do I install every skill?
Run `npx skills add unlearndev/skills`. The skills land in the project's `.claude/skills/` and the agent picks them up on demand.
How do I install just one skill?
Add the `--skill` flag, for example `npx skills add unlearndev/skills --skill spec-generator`.
What does ship-gate check?
Secrets and keys, debug code such as `console.log`, large commented-out blocks and accidentally added large or binary files. The verdict is a single PASS or BLOCK.
Does cruft-hunt change code?
No. It only ranks deletion candidates with evidence and flags in a Check first section anything that might be reached another way.
How is is-it-dead different?
It proves or disproves that one file, function, route or package is dead through the DEAD checks and runs deletion one commit at a time.
Discussion
No questions or reviews yet.
Related
Skills14 skills that find the gaps in a task before the code: interviews, plans, assumption tests and proof that a bug fix works
22 skills for the full Claude Code project lifecycle: setup and task scope, code review, pre-push checks and session notes.
Nine personal engineering skills: an idea-to-PR chain, standards search, a sandboxed review loop and wizard pages for changes
lencx skills
lencx-skills
Two skills for Claude Code and Codex: keel works through architecture questions, coding-protocol keeps code edits inside the task
A set of Claude Code utilities: background skills, expert agents, slash commands and prompt templates for development
A CLI that scaffolds Claude skills, validates their size and structure, packages them for Claude.ai and adds activation hooks
README in short
The repository has 17 folders with `SKILL.md` under `skills/`: each skill comes with a description, sample prompts and the output form. Installing through skills.sh sets up all skills at once or one by one.
README badge
Original SKILL.md
--- name: spec-generator description: Generate a detailed product specification document from a vague idea, rough description, or supporting materials (UI sketches, screenshots, notes, existing docs). Use this skill whenever the user wants to turn a rough concept into a structured spec — even if they say things like "write up a spec for...", "turn this idea into a requirements doc", "I have this rough idea for a product", "help me spec this out", "create a PRD for...", or uploads images/files and wants a spec written from them. Covers all product types including internal tools. Trigger this skill even if the request seems simple — a vague one-liner idea deserves a proper spec just as much as a detailed brief. --- # Spec Generator Skill Turn a vague product idea — possibly supported by sketches, screenshots, notes, or other documents — into a clear, well-structured product specification document that a development team can act on. This always produces a **product spec**. That covers customer-facing products, internal tools, and staff-facing systems — they're all products. Never produce a feature spec, API spec, or integration spec. ## What "good" looks like A good output spec should: - Be concise but complete — no padding, no gaps - Use plain language, not corporate jargon - Be opinionated where needed (e.g. suggest a sensible default stack or behaviour) while flagging where the team still needs to decide - Surface implicit assumptions and make them explicit - Feel like it was written by a thoughtful senior PM or tech lead who has thought through the edges --- ## Process ### Step 1: Gather and understand inputs Take stock of everything the user has provided: - **Verbal description** — even one sentence is enough to start - **Uploaded files** — read all of them: notes, existing docs, data models, wireframes, screenshots, mockups - **Images** — examine carefully; extract implied features, flows, and constraints Before drafting, review everything the user has provided and identify any gaps that would meaningfully affect the spec. Always ask about the intended technical stack if it hasn't been provided — this can influence the direction of the project and its features. Ask any other questions that cannot be reasonably inferred from the available inputs — don't ask about things that are already clear or can be decided with a sensible default. Keep the questions concise and grouped in one go, not spread across multiple turns. ### Step 2: Draft the spec Use the template below. Adapt sections as needed — not every section is required for every spec. Use your judgment. Omit sections that don't apply rather than filling them with placeholder text. --- ## Spec Template ```markdown # [Product Name] — Specification > **Context:** [1–2 sentences on why this is being built and what informed this spec — e.g. team discussions, user research, a UI sketch.]