القائمة
Review a new blog post before publishing. Finds the latest post by its dated path under `src/posts/`, then spell-checks and offers content suggestions — without touching tone.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Review engine and infrastructure changes before commit. Use when the user runs /precheck, asks to review site engine code, or wants a pre-commit check on JavaScript/TypeScript, Eleventy config, Netlify functions, or build tooling — not blog posts.
Review a new blog post before publishing. Trigger immediately whenever the user asks to "check", "review", or "prepublish" a blog post, or says "check my latest blog post". Finds the latest post by its dated path under `src/posts/`, then spell-checks and offers content suggestions — without touching tone.
| name | prepublish |
| description | Review a new blog post before publishing. Finds the latest post by its dated path under `src/posts/`, then spell-checks and offers content suggestions — without touching tone. |
Run this right before pushing a new post. Blog posts live in src/posts/YYYY/MM/DD/ as .md files.
Do NOT use git to figure out which post is newest. Use the dated path under src/posts/ — sort highest year → month → day and pick the most recent .md file.
A reliable command: find src/posts -type f -name '*.md' | sort -r | head -5. The first entry is the latest post; the rest are there in case there's a tie or the user wants to pick another.
If multiple .md files share the newest date directory, ask the user which one. Otherwise, confirm in one line ("Reviewing path/to/post.md — sound right?") before proceeding.
Read the post and surface misspellings. Ignore code blocks, fenced code, inline code, URLs, and proper nouns the user clearly intended (product names, people, libraries).
Present findings as a short list: word → suggestion (line N). Don't auto-edit. Ask which corrections to apply, then apply them with Edit.
Read the post end-to-end and give feedback focused on substance, not tone:
Do NOT comment on tone, voice, snark level, casual phrasing, or stylistic choices. The user likes their voice; leave it alone.
Present feedback as a numbered list grouped by category. Keep each item to one or two sentences. Don't rewrite paragraphs — point at the issue and let the user decide.
When you look at the front matter, if you see banner_image set to 'welcome2018.jpg', flag that as a mistake and suggest updating it to a more relevant image.
Ask which suggestions to act on. Apply only what's confirmed. Then stop — the user handles the actual publish/push.
