From new-radicle-os
Run the full pre-publish pipeline for the New Radicle OS plugin before pushing changes. This skill orchestrates documentation consistency review, AI security gate (via ai-security-audit Mode A), version bump inference, and final summary before code goes to GitHub. Use this skill whenever someone says 'push changes', 'publish plugin', 'release update', 'push this version', 'ship it', 'push to marketplace', 'ready to publish', or any variation of wanting to push plugin changes to the repo. Also trigger when the user says 'pre-publish check', 'release checklist', or 'what needs to happen before we push'. This skill MUST run before any git push of plugin changes — it is the standardized gate between local work and published code.
npx claudepluginhub new-radicle/nr_plugins --plugin new-radicle-osThis skill uses the workspace's default tool permissions.
The standardized gate between working on the plugin locally and pushing changes to the repo. Every push goes through the same sequence: verify docs are consistent, run the AI security gate, bump the version, and confirm.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
The standardized gate between working on the plugin locally and pushing changes to the repo. Every push goes through the same sequence: verify docs are consistent, run the AI security gate, bump the version, and confirm.
Without a checklist, pushes are ad hoc. Someone updates a SKILL.md but forgets to update the schema description in the README, or bumps behavior without bumping the version, or ships without running security review. This skill makes the pipeline explicit and repeatable — the same steps every time, nothing skipped.
All file paths below are relative to the plugin root (nr_plugins/new-radicle-os/). When this skill triggers, locate the plugin root first — it contains .claude-plugin/plugin.json.
Four phases, run in order. Each phase produces a PASS or FAIL. A FAIL in any phase blocks the push until resolved.
Cross-reference the plugin's documentation to catch drift between files. Read references/consistency-checklist.md for the full checklist, but the core checks are:
Schema alignment — Do the Notion field definitions in load-context SKILL.md and share-with-team SKILL.md match each other? Do they match what's actually in the Notion database? Check field names, types, and option values.
Skill count — Does the README's skill table list every skill that exists in the skills/ directory? Are any missing or removed?
Version string — Does plugin.json's version match what the README's version history describes?
Cross-references — When one skill references another (e.g., load-context references the Context Index format that share-with-team writes), do the formats still match?
Reference artifact consistency — Do the .jsx and .md reference artifacts in the workspace folder reflect the current state of the implementation? Check for stale "proposed" labels, outdated skill counts, or superseded architecture descriptions.
How to run this phase:
Read these files and cross-reference:
skills/load-context/SKILL.md — schema section, Context Index descriptionskills/share-with-team/SKILL.md — schema section, index entry format, metadata questionsskills/engineering/ai-security-audit/SKILL.md — mode descriptionsskills/assess-state/SKILL.md — any cross-skill referencesskills/founder-agents/SKILL.md — any cross-skill referencesskills/internal-comms/SKILL.md — any cross-skill references.claude-plugin/plugin.json — version, descriptionREADME.md — skill table, version historyAlso check any reference artifacts in the workspace folder (the parent repo directory) that describe the plugin's architecture. Common files to check: marketplace-architecture-spec.md, plugin-architecture-overview.jsx, intent-aware-retrieval-schema.jsx.
Output: List of findings, each marked CONSISTENT or DRIFT. Any DRIFT finding must be resolved before proceeding.
Chain to the existing ai-security-audit skill in Mode A (Pre-Push Security Gate).
The security audit skill already knows how to scope a push, run targeted intake, score across security domains, and return a gate decision (PASS / PASS WITH CONDITIONS / BLOCK). Don't duplicate that work — invoke it.
How to run this phase:
Read skills/engineering/ai-security-audit/SKILL.md and follow Mode A (Pre-Push Security Gate). Tell the user: "Running AI security gate on plugin changes..." then:
If BLOCK: Stop. The user must resolve security findings before proceeding. If PASS WITH CONDITIONS: Present conditions. The user decides whether to resolve now or accept risk. If PASS: Continue to Phase 3.
Infer the appropriate semver bump from what changed, present it for confirmation, and apply it.
Read references/version-strategy.md for the full decision tree, but the summary:
How to infer the bump:
.claude-plugin/plugin.jsonAfter confirmation:
plugin.json version fieldPresent a final summary for the user to approve before the actual push:
## Pre-Publish Summary
Version: 0.3.0 → 0.3.1
Changes: [1-3 line summary of what changed]
Documentation: ✓ Consistent (N checks passed)
Security gate: ✓ PASS
Version bump: ✓ 0.3.1 applied
Ready to push. Proceed?
If the user confirms, the push can proceed (via normal git workflow — this skill doesn't run git push itself, it gates the decision).
Methodical but not bureaucratic. This is a checklist, not a compliance audit. Move briskly through passing checks, spend time only on findings that matter. The goal is confidence before pushing — not a report for its own sake.