wp-readme-optimizer

Name: wp-readme-optimizer
Author: jdevalk

85stars9forks

How to install wp-readme-optimizer?

jdevalk/skills/wp-readme-optimizer

$npx -y skills add jdevalk/skills --skill wp-readme-optimizer

Installs into the current project.

Summary

Reviews and rewrites WordPress.org plugin readme.txt files for maximum quality. Use this skill whenever a user pastes, uploads, or references a WordPress plugin readme.txt, or asks to improve, audit, review, score, or optimize a plugin's WordPress.org listing page. Also trigger w

Files · 1

View on GitHub

SKILL.md

1	# WordPress Plugin readme.txt Optimizer
2
3	This skill reviews a WordPress.org plugin readme.txt file with a structured audit, scores each section, and then produces a fully rewritten version. The goal is higher visibility in the WordPress.org plugin directory, better conversion of visitors to installs, and a more trustworthy plugin page.
4
5	Rewrite recipes live in `AGENTS.md` — read it when producing the rewritten readme.
6
7	## Workflow
8
9	1. Read the readme.txt — If a file is attached, read it. If the user pasted content, use that. If neither, ask the user to provide the readme.txt content.
10	2. Infer the target keyword — Before scoring, identify what keyword(s) this plugin should rank for. This anchors the entire audit.
11	3. Run the audit — Score each section and write specific, actionable findings.
12	4. Produce the rewrite — Deliver a drop-in replacement readme.txt, incorporating all audit findings. Follow the recipes in `AGENTS.md`.
13
14	---
15
16	## Phase 0: Keyword Inference
17
18	Before scoring, output: Primary keyword (the 2-3 word phrase most likely to drive installs), Secondary keywords (3-4 supporting terms), Inferred from (plugin name / tags / description), Confidence (high / medium / low).
19
20	Infer by asking: "If a WordPress site owner needed this plugin, what would they type into the search bar?" Look at the plugin name, tags, and the first paragraph. If confidence is low, add `<!-- Couldn't confidently infer primary keyword -->` and proceed with your best guess.
21
22	All scoring in Phase 1 is evaluated against this inferred keyword.
23
24	---
25
26	## Phase 1: Audit
27
28	### Scoring
29
30	Score each of the 8 sections below out of 10 (total /80). Show a summary table at the top of the audit. Score ranges: 65-80 strong (polish only), 45-64 solid with gaps, 25-44 significant problems, 0-24 bare minimum.
31
32	For each section, write 2-5 specific findings. A finding should name the problem, explain why it matters, and suggest a fix. Never be generic -- always refer to the actual content.
33
34	### What to evaluate per section
35
36	#### Plugin Name & Tags
37
38	- Is the name descriptive of what the plugin does, not just a brand name?
39	- Does it include the primary keyword users would search for?
40	- Are up to 5 tags used? Are they the right ones -- high-volume, specific to the plugin's function?
41	- Would a stranger immediately understand what the plugin does from the name alone?
42
43	#### Short Description (<=150 chars)
44
45	- Does it lead with the user's problem or benefit, not the plugin's name?
46	- Is it under 150 characters (hard limit -- truncation kills CTR)?
47	- Does it contain the primary keyword naturally?
48	- Is it specific (avoid vague claims like "powerful", "easy", "best")?
49	- Does it end before 150 chars -- not mid-sentence?
50
51	#### Long Description
52
53	- Does the first paragraph act as a strong hook -- benefit-led, not feature-led?
54	- Is the primary keyword used in the first 150 words?
55	- Are there H2/H3 headings to break up the text (using `== Heading ==` syntax)?
56	- Are features presented as user benefits, not just a bullet dump?
57	- Is there social proof -- active installs, ratings, notable users?
58	- Is there a clear call to action (e.g. link to Pro, docs, or demo)?
59	- Does it include FAQ-style content or video embeds for richness?
60	- Are secondary/long-tail keywords naturally woven in?
61
62	#### Installation
63
64	- Are the steps numbered and complete?
65	- Does it cover both manual (FTP) and automatic (dashboard) methods?
66	- Are there any post-activation steps mentioned?
67
68	#### FAQ
69
70	- Are the questions things real users actually ask (check support forum topics if possible)?
71	- Do the answers contain keywords naturally?
72	- Is there at least one question that surfaces a common objection or concern?
73	- Are questions phrased the way a user would type them, not how a developer would write them?
74
75	#### Screenshots
76
77	- Is there a `== Screenshots ==` section?
78	- Does each screenshot have a caption (captions are indexed by the search engine)?
79	- Do captions describe what the user sees AND include relevant keywords?
80	- Are there enough screenshots to cover the key UI flows?
81
82	#### Changelog
83
84	- Is the changelog up to date?
85	- Does it follow the format `= X.X.X =` with bullet points underneath?
86	- Does the most recent entry communicate user-facing value, not just `"bug fixes"`?
87	- Is there a reasonable update cadence visible (signals active maintenance)?
88
89	#### Stable Tag & Plugin

People who liked this also viewed

6 picks

Type

wp-readme-optimizer

85stars9forks

View on GitHub

How to install wp-readme-optimizer?

jdevalk/skills/wp-readme-optimizer

$npx -y skills add jdevalk/skills --skill wp-readme-optimizer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# WordPress Plugin readme.txt Optimizer
2
3	This skill reviews a WordPress.org plugin readme.txt file with a structured audit, scores each section, and then produces a fully rewritten version. The goal is higher visibility in the WordPress.org plugin directory, better conversion of visitors to installs, and a more trustworthy plugin page.
4
5	Rewrite recipes live in `AGENTS.md` — read it when producing the rewritten readme.
6
7	## Workflow
8
9	1. Read the readme.txt — If a file is attached, read it. If the user pasted content, use that. If neither, ask the user to provide the readme.txt content.
10	2. Infer the target keyword — Before scoring, identify what keyword(s) this plugin should rank for. This anchors the entire audit.
11	3. Run the audit — Score each section and write specific, actionable findings.
12	4. Produce the rewrite — Deliver a drop-in replacement readme.txt, incorporating all audit findings. Follow the recipes in `AGENTS.md`.
13
14	---
15
16	## Phase 0: Keyword Inference
17
18	Before scoring, output: Primary keyword (the 2-3 word phrase most likely to drive installs), Secondary keywords (3-4 supporting terms), Inferred from (plugin name / tags / description), Confidence (high / medium / low).
19
20	Infer by asking: "If a WordPress site owner needed this plugin, what would they type into the search bar?" Look at the plugin name, tags, and the first paragraph. If confidence is low, add `<!-- Couldn't confidently infer primary keyword -->` and proceed with your best guess.
21
22	All scoring in Phase 1 is evaluated against this inferred keyword.
23
24	---
25
26	## Phase 1: Audit
27
28	### Scoring
29
30	Score each of the 8 sections below out of 10 (total /80). Show a summary table at the top of the audit. Score ranges: 65-80 strong (polish only), 45-64 solid with gaps, 25-44 significant problems, 0-24 bare minimum.
31
32	For each section, write 2-5 specific findings. A finding should name the problem, explain why it matters, and suggest a fix. Never be generic -- always refer to the actual content.
33
34	### What to evaluate per section
35
36	#### Plugin Name & Tags
37
38	- Is the name descriptive of what the plugin does, not just a brand name?
39	- Does it include the primary keyword users would search for?
40	- Are up to 5 tags used? Are they the right ones -- high-volume, specific to the plugin's function?
41	- Would a stranger immediately understand what the plugin does from the name alone?
42
43	#### Short Description (<=150 chars)
44
45	- Does it lead with the user's problem or benefit, not the plugin's name?
46	- Is it under 150 characters (hard limit -- truncation kills CTR)?
47	- Does it contain the primary keyword naturally?
48	- Is it specific (avoid vague claims like "powerful", "easy", "best")?
49	- Does it end before 150 chars -- not mid-sentence?
50
51	#### Long Description
52
53	- Does the first paragraph act as a strong hook -- benefit-led, not feature-led?
54	- Is the primary keyword used in the first 150 words?
55	- Are there H2/H3 headings to break up the text (using `== Heading ==` syntax)?
56	- Are features presented as user benefits, not just a bullet dump?
57	- Is there social proof -- active installs, ratings, notable users?
58	- Is there a clear call to action (e.g. link to Pro, docs, or demo)?
59	- Does it include FAQ-style content or video embeds for richness?
60	- Are secondary/long-tail keywords naturally woven in?
61
62	#### Installation
63
64	- Are the steps numbered and complete?
65	- Does it cover both manual (FTP) and automatic (dashboard) methods?
66	- Are there any post-activation steps mentioned?
67
68	#### FAQ
69
70	- Are the questions things real users actually ask (check support forum topics if possible)?
71	- Do the answers contain keywords naturally?
72	- Is there at least one question that surfaces a common objection or concern?
73	- Are questions phrased the way a user would type them, not how a developer would write them?
74
75	#### Screenshots
76
77	- Is there a `== Screenshots ==` section?
78	- Does each screenshot have a caption (captions are indexed by the search engine)?
79	- Do captions describe what the user sees AND include relevant keywords?
80	- Are there enough screenshots to cover the key UI flows?
81
82	#### Changelog
83
84	- Is the changelog up to date?
85	- Does it follow the format `= X.X.X =` with bullet points underneath?
86	- Does the most recent entry communicate user-facing value, not just `"bug fixes"`?
87	- Is there a reasonable update cadence visible (signals active maintenance)?
88
89	#### Stable Tag & Plugin

People who liked this also viewed

6 picks

Type