diff --git a/.github/ISSUE_TEMPLATE/rule_request.md b/.github/ISSUE_TEMPLATE/rule_request.md
new file mode 100644
index 0000000..c1653f6
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/rule_request.md
@@ -0,0 +1,50 @@
+---
+name: Rules database entry
+about: Tell us about a cache or artifact directory Diskern doesn't know yet
+labels: rules, enhancement
+---
+
+<!-- Diskern only knows what its rules tell it. If you know where an app
+     on your platform keeps its regenerable files, that's a rule nobody
+     else can write as well as you — and it needs no Rust.
+     Format and reasoning: docs/RULES.md -->
+
+**Which application, and on which OS?**
+
+<!-- e.g. "VS Code on macOS", "Docker on Linux" -->
+
+
+**Where does it keep the files?**
+
+<!-- The full path, with the user-specific parts marked:
+     ~/Library/Application Support/Code/CachedData
+     C:\Users\<user>\AppData\Local\<app>\Cache -->
+
+
+**What's in there, and what happens after it's removed?**
+
+<!-- What regenerates it, and what the user loses in the meantime —
+     "rebuilt on next launch, first launch is slower" is exactly right. -->
+
+
+**Proposed verdict**
+
+<!-- safe = regenerable, removal affects nothing
+     review = probably reclaimable, but the user should look first
+     Prefer review when unsure. A wrong `safe` offers to move real data. -->
+
+- [ ] `safe`
+- [ ] `review`
+- [ ] not sure
+
+**Is there anything nearby that must NOT match?**
+
+<!-- The trap this database exists to avoid: a Firefox profile holds
+     cache2/ next to logins.json and cookies.sqlite, so the rule has to
+     name the cache directory, not the profile. Anything similar here? -->
+
+
+**Would you like to open the PR yourself?**
+
+<!-- Happy either way. The rules are JSON in
+     crates/diskern-core/rules/base.json and adding one is a few lines. -->
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0254564..8ce65bb 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -46,13 +46,36 @@ verdict levels and the safety reasoning are in
 [`crates/diskern-core/rules/base.json`](crates/diskern-core/rules/base.json),
 and adding one needs no Rust.
 
-**Issues labelled `good first issue`** are scoped to a single file with
-the reasoning already worked out.
-
 **Documentation.** If something here or in `docs/` was wrong or missing
 when you followed it, that is a bug report worth filing even if you
 don't fix it.
 
+### Picking an issue
+
+Open issues carry a difficulty label, so you can choose by how much of
+the codebase you need to hold in your head at once:
+
+| Label | What it means |
+| --- | --- |
+| [`level: beginner`](https://github.com/Coding-Moves/diskern/issues?q=is%3Aopen+label%3A%22level%3A+beginner%22) | Scoped to one file, with the reasoning already worked out — a rule, a flag, a formatting fix. |
+| [`level: intermediate`](https://github.com/Coding-Moves/diskern/issues?q=is%3Aopen+label%3A%22level%3A+intermediate%22) | Sits inside one crate and has to be tested against it — a stage in the report pipeline, a test harness. |
+| [`level: advanced`](https://github.com/Coding-Moves/diskern/issues?q=is%3Aopen+label%3A%22level%3A+advanced%22) | Cross-cutting, or lands on a safety guarantee. Say what you're planning on the issue before you start. |
+
+Most `level: beginner` issues are also labelled
+[`good first issue`](https://github.com/Coding-Moves/diskern/labels/good%20first%20issue);
+[`help wanted`](https://github.com/Coding-Moves/diskern/labels/help%20wanted)
+means we'd particularly like someone to take it.
+
+The rest of the labels say where a change lands rather than how hard it
+is. `engine`, `cli` and `app` name the crate; `backend` and `frontend`
+are the same split in broader terms; `rules`, `safety`, `ui/ux`, `ci`,
+`testing`, `performance` and `documentation` name the concern.
+`priority: high` means correctness or safety, not a deadline.
+
+Comment on the issue before you start, so two people don't write the
+same patch. If nothing fits, opening an issue to describe what you want
+to change is a fine first contribution on its own.
+
 ## The loop
 
 1. Fork, and branch from `main`. Branch names follow the commit prefixes
diff --git a/README.md b/README.md
index 64be34b..e855541 100644
--- a/README.md
+++ b/README.md
@@ -66,6 +66,12 @@ Contributions are welcome — see [CONTRIBUTING.md](CONTRIBUTING.md) for
 setup and guidelines, and [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md)
 for how the pieces fit together.
 
+Looking for somewhere to start? Issues are labelled by difficulty:
+[`level: beginner`](https://github.com/Coding-Moves/diskern/issues?q=is%3Aopen+label%3A%22level%3A+beginner%22)
+is scoped to a single file with the reasoning worked out, and teaching
+Diskern about a cache on your platform is a
+[rules change](docs/RULES.md) that needs no Rust at all.
+
 ## License
 
 [MIT](LICENSE). Unless you explicitly state otherwise, any contribution
diff --git a/docs/RULES.md b/docs/RULES.md
index 153143b..50e1949 100644
--- a/docs/RULES.md
+++ b/docs/RULES.md
@@ -95,3 +95,8 @@ rules PRs are very welcome. Guidelines:
    not), what happens after removal.
 4. Add a test in [`rules.rs`](../crates/diskern-core/src/rules.rs) if the
    rule protects something critical.
+
+Don't want to write the JSON? Filing a
+[rules database entry](https://github.com/Coding-Moves/diskern/issues/new?template=rule_request.md)
+with the path and what regenerates it is just as useful — someone else
+can turn it into a rule from there.