diff --git a/dev/skills/x-post-publisher/SKILL.md b/dev/skills/x-post-publisher/SKILL.md index 36c8675..b5cb1ff 100644 --- a/dev/skills/x-post-publisher/SKILL.md +++ b/dev/skills/x-post-publisher/SKILL.md @@ -18,6 +18,7 @@ Decodex plugin skill. - `docs/spec/social-publishing.md` - `docs/spec/upstream-impact.md` - `docs/runbook/social-publishing-workflow.md` +- `dev/skills/x-post-quality-system/SKILL.md` - `dev/skills/codex-release-analysis/SKILL.md` - `dev/skills/codex-code-analysis/SKILL.md` @@ -25,7 +26,8 @@ Decodex plugin skill. - `signal_entry/v1`, `upstream_impact/v1`, `upstream_review/v1`, release-analysis note, or checked source URLs -- Optional style observations from `@Codex_Changelog`, `@LLMJunky`, or `@decodexspace` +- Optional style observations from `@CodexReleases`, `@Codex_Changelog`, `@LLMJunky`, + or `@decodexspace` - Target account: `decodexspace` - Controller account for attribution and site links: `hackink` @@ -52,7 +54,8 @@ Use these as format patterns only: | Pattern | Good for | Decodex adaptation | | --- | --- | --- | -| Release-bot bullet | Fast `release_pulse` posts. | Version or source headline, two or three evidence-backed bullets, source link. | +| Release/update card | `release_pulse` or high-value `release_rollup` posts. | Product/version/theme headline, two or three reader-visible changes, source link, optional thread details. | +| High-density changelog | One-post summaries from a source changelog or release. | Headline, three high-signal bullets, source card; no extra commentary. | | Release rollup | `release_rollup` posts after a release or prerelease. | Summarize what prior commit/PR analysis found: useful now, Control Plane impact, deprecations, and watch-only gaps. | | Human workflow read | `practical_explainer` and `operator_impact`. | Start with the concrete workflow change, then explain why it matters and what caveat remains. | | Watch note | Interesting but incomplete evidence. | Say what changed, why Radar is watching, and what evidence is still missing. | @@ -79,6 +82,10 @@ Publish only when all are true: - The post is in English. - The source evidence is enough for every technical claim. +- `dev/skills/x-post-quality-system/SKILL.md` passes the candidate as externally + valuable. +- The candidate answers in one screen: what changed, who can use or observe it, and what + source proves it. - The item is `critical` or `high`, or it is a release/prerelease rollup with clear reader value. - The post is useful to Codex users, Decodex operators, or builders tracking the Codex @@ -86,7 +93,10 @@ Publish only when all are true: - The idempotency key has not already been published or blocked for the same source. - The daily cap has not been reached. -Skip low-value internal churn. Do not post just because a signal exists. +Skip low-value internal churn. Do not post just because a signal exists. In particular, +do not publish single-PR renames, trace-only compatibility notes, low-context operator +cautions, or Decodex-internal audit reminders unless they roll up into a broader +release/update story or concrete external operator decision. ## Daily Cap @@ -104,11 +114,20 @@ If publishing the candidate would exceed the cap: ## Image Generation -Generate an image for each published post unless media is explicitly skipped. Use -`image_template = "decodex_signal_card"` and the exact base prompt in -`docs/spec/social-publishing.md`. Do not rely on the generated image for readable text. -Render any title, PR number, release tag, or mode with deterministic overlay tooling or -keep it in the post body. +Generate an image for each published post only when useful media can pass +`dev/skills/x-post-quality-system/SKILL.md`. Use +`image_template = "decodex_signal_card"` as a visual system, not as a fixed reusable +asset. Start with the exact base prompt in `docs/spec/social-publishing.md`, then add +candidate-specific subject, source, visual metaphor, palette, and forbidden-elements +slots from the quality-system skill. + +Do not rely on the generated image for readable text. Render any title, source, date, +PR number, release tag, or mode with deterministic overlay tooling or keep it in the +post body. Never reuse prior live-test images, old generic signal-card assets, unrelated +abstract cards, or weak decorative filler. + +If no fresh candidate-specific image passes visual review, publish text-only only when +the post remains valuable with the source link card. Otherwise skip or fail closed. ## Claim Review diff --git a/dev/skills/x-post-quality-system/SKILL.md b/dev/skills/x-post-quality-system/SKILL.md new file mode 100644 index 0000000..a1ddc1b --- /dev/null +++ b/dev/skills/x-post-quality-system/SKILL.md @@ -0,0 +1,176 @@ +--- +name: x-post-quality-system +description: Use before Decodex X Publisher decides to publish or generate media. Defines the @decodexspace editorial bar, benchmark-derived post formats, and the decodex_signal_card visual system so automation rejects low-value content and weak images. +--- + +# Decodex X Post Quality System + +Use this skill before `x-post-publisher` decides that a candidate is publishable. +It raises the bar from source-backed correctness to public-reader value and media quality. + +This is a repo-local skill for the `@decodexspace` automation. It is not a generic +social-media style guide. + +## Benchmarks Studied + +The current standard comes from live-readback sampling on 2026-06-03: + +- `@CodexReleases`: 55 visible posts/thread nodes from 2026-06-03 back to + 2026-04-24. +- `@Codex_Changelog`: 34 visible posts from 2026-06-03 back to 2026-02-18. + +Treat these accounts as operational benchmarks, not as technical evidence for claims. +Every technical claim still needs source-backed GitHub, changelog, release, signal, +upstream-review, or upstream-impact evidence. + +## Editorial Bar + +Publish only when the candidate can answer all three questions in one screen: + +- What changed? +- Who can use, observe, or act on it? +- What source proves it? + +Reject candidates that are only: + +- single-PR renames +- trace-only compatibility notes +- narrow bug/fix/source-only details +- Decodex-internal audit targets +- low-context operator cautions +- generic "watching this" notes + +Those items can still be tracked in Radar artifacts. They should not become X posts +unless they roll up into a broader release, product update, concrete workflow change, or +external operator decision. + +## Good Post Shapes + +Prefer one of these shapes. + +### Release Or Update Card + +Use when a release, prerelease, app update, or changelog entry is the story. + +Pattern: + +```text +Codex update: + +What changed: +- +- +- + +Source: +``` + +Use a short thread only when the main post already has enough value and details would not +fit cleanly. Follow-up posts should be `details`, `fixed`, `availability`, or `source`; +do not fragment weak material into a thread. + +### High-Density Changelog + +Use when the value is a concise summary of a known source. + +Pattern: + +```text +Codex is out. + +- +- +- + +Changelog: +``` + +This shape should be dense and source-led. Do not add commentary that hides the actual +change. + +### Operator Decision + +Use `operator_impact` sparingly. It must read as an external operator decision, not a +Decodex maintenance note. + +Good operator-impact posts name a concrete action: + +- enable or avoid a provider/config/path +- update an integration assumption +- plan a rollout or migration +- watch a beta/availability boundary + +Do not publish an operator-impact post if the action is only "Decodex should audit this +internally." + +## Visual System + +`decodex_signal_card` is a visual system, not a fixed image. Each publishable candidate +should get a fresh candidate-specific image when media is useful, but the image must share +the same visual grammar. + +Required shared elements: + +- square card, suitable for X image preview +- calm technical composition, not a decorative poster +- restrained off-white or near-black background +- thin signal paths, sparse nodes, light grid or terminal/UI structure +- one dominant subject tied to the source: release, provider, platform, workflow, or UI +- stable Decodex identity area or small label zone +- deterministic title/source/date overlay when text is needed +- no AI-rendered long text +- no mascots, people, logos, noisy gradients, generic orbs, or stock-like abstraction + +Allowed subject variations: + +- release card: product/version/date/source +- source card: GitHub or OpenAI changelog source preview +- product card: simplified UI or device/workflow preview +- operator card: provider/config/sandbox/control-plane diagram with concrete labels + +Do not reuse: + +- prior live-test images +- old generic signal-card images +- unrelated abstract cards +- weak decorative filler + +If no fresh, candidate-specific, quality-checked media exists, prefer text-only plus the +source link card when the post still has enough standalone value. Otherwise skip or fail +closed. + +## Image Prompt Contract + +Start from the `docs/spec/social-publishing.md` base prompt, then add source-specific +slots: + +- `subject`: the concrete release/update/workflow being explained +- `source`: GitHub release, OpenAI changelog, PR, or signal artifact +- `visual_metaphor`: release card, source card, UI/workflow preview, or operator diagram +- `palette`: near-black or off-white with restrained magenta, lime, and blue accents +- `forbidden`: generic abstract art, long text, unreadable labels, people, mascots, + decorative blobs, unrelated UI + +Before upload, perform a visual quality check. The image must pass all: + +- It is specific to this candidate. +- It is visually consistent with the Decodex system. +- It is not ugly, noisy, generic, or off-brand. +- It still makes sense if the post text is read first. +- It does not rely on AI-rendered readable text. + +Record the prompt, media path, and quality-check outcome in `social_post/v1` evidence +notes or caveats. + +## Failure Rules + +Fail closed when: + +- the candidate is source-backed but not externally valuable +- the post cannot be expressed as release/update, changelog, or concrete operator decision +- the media is generic, reused, ugly, or unavailable but the post depends on media +- duplicate detection, account verification, upload, or final readback is unreliable + +Write a `social_post/v1` `skipped` or `failed` record only when the artifact itself has +durable value for later analysis. Do not create repository PRs for meaningless failed +publication records.