Menu
Bump version, commit code changes, and push a GitHub tag for the stigix project. Use whenever making code changes that should trigger a Docker image rebuild via GitHub Actions CI.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Audit and synchronize the Stigix MCP server tools with the stigix-cli. Use this whenever stigix-cli.py changes (new commands, bug fixes, new API parameters) to ensure Claude's MCP tools stay in sync. Also use when MCP tools have bugs that were already fixed in the CLI.
Language policy for the Stigix repository. Use this skill whenever writing or editing any file that will be committed to the GitHub repository (docs/, mcp-server/Exemple/, README, CHANGELOG, code comments, docstrings, tool descriptions, etc.). Conversation with the user may remain in French, but all repo-facing content must be in English.
Evaluate whether a new feature or change warrants a documentation update in the Stigix docs. Use after adding new features (not bug fixes). Decides which docs to update, writes the content, and proposes the update to the user when the value is uncertain.
Pre-push security checklist to prevent leaking Palo Alto SASE credentials and other secrets into the Stigix GitHub repository. Use this skill BEFORE any git commit or push, and whenever modifying files that could contain credentials (.env, credentials.json, *.old, *.bak, etc.)
Cross-platform awareness guide for commands targeting external hosts. Use this skill whenever you are about to generate a shell command, script, or file path intended for a host whose OS is unknown or could be Windows, Linux, or macOS.
Troubleshoot synchronization issues with the Stigix Registry (Cloudflare Worker). Use this when autodiscovery is failing or peers are not appearing in the dashboard.
| name | stigix-deploy |
| description | Bump version, commit code changes, and push a GitHub tag for the stigix project. Use whenever making code changes that should trigger a Docker image rebuild via GitHub Actions CI. |
Use this skill whenever you make code changes to the stigix project that should be shipped to Docker Hub via GitHub Actions.
server.ts, *.tsx, Dockerfile, targets-manager.ts, or other source filesengines/ scripts, iot/, vyos/, or mcp-server/docs/, README.md, CHANGELOG.md, *.md) — those don't need a tag/rebuild[!IMPORTANT] Dockerfile Audit: If you added a NEW
.tsfile or a new directory inweb-dashboard/, you MUST ensure it is explicitly copied in theRuntime Stageof theweb-dashboard/Dockerfile. Otherwise, the container will fail withERR_MODULE_NOT_FOUND.
Read the current version:
cat /Users/jsuzanne/Github/stigix/VERSION
The format is vX.Y.Z-patch.NNN. You MUST strictly increment NNN by exactly +1 (e.g., from 140 to 141). Do not skip numbers or round to tens unless the USER explicitly requests it.
[!IMPORTANT] All four items below are MANDATORY. Run them as a single block — do NOT skip the README line.
NEW_VER="v1.2.1-patch.NNN" # replace NNN with the next sequential number
echo "$NEW_VER" > VERSION
echo "$NEW_VER" > web-dashboard/VERSION
echo "$NEW_VER" > engines/VERSION
# README badge — MUST be updated in the same step, not after
# Note the double dash (--) before patch in the shields.io URL
sed -i '' "s|Version-[0-9][^-]*--patch\.[0-9]*|Version-1.2.1--patch.NNN|g" README.md
Verify all four files are in sync before proceeding:
cat VERSION && cat web-dashboard/VERSION && cat engines/VERSION
grep "img.shields.io/badge/Version" README.md
All four must show the same NNN.
[!IMPORTANT] Mandatory step —
CHANGELOG.mdmust be updated before every code commit. Never ship a patch without a changelog entry.
Before writing the new entry, run this command to compare git tags with CHANGELOG entries:
# List all v1.x tags
git tag | grep "^v" | sort -V
# List all documented versions in CHANGELOG
grep "^## \[v" CHANGELOG.md | head -20
# Find the gap: last documented version
grep "^## \[v" CHANGELOG.md | head -1
If git tag shows versions that do NOT appear in the CHANGELOG, you MUST add entries for ALL missing versions before proceeding. Use git log --oneline to reconstruct what changed:
# Get commits for a specific range (replace TAG_A and TAG_B)
git log --oneline TAG_A..TAG_B
# Or get the full history since v1.3.0 in chronological order
git log --oneline --reverse v1.3.0..HEAD
Add one CHANGELOG entry per tagged version. Do not group multiple patches into one entry unless they are truly inseparable.
Open /Users/jsuzanne/Github/stigix/CHANGELOG.md and prepend a new entry at the very top (after the file header), following this exact format:
## [vX.Y.Z-patch.NNN] - YYYY-MM-DD
### Added / Fixed / Changed / Performance / Refactored
- **Component**: Description of what changed and why. Use emojis for readability. 🚀
Rules for the entry:
YYYY-MM-DD in local time).Added, Fixed, Changed, Performance, Refactored, Removed, Documentation.Stage all changed files (source + VERSION files + CHANGELOG together in one commit).
[!IMPORTANT] Visibility Rule: Always prefix the commit message with the new version number. This makes it easy to track which version is being built in the GitHub Actions list.
git add -A
git commit -m "$NEW_VER: <feat|fix>: <short description>
<expanded bullet summary of what changed>"
git push
git tag $NEW_VER
git push origin $NEW_VER
This triggers GitHub Actions which automatically creates:
v1.2.1-patch.239) and pushes to the main branch. This speeds up the development CI cycle.v1.2.1). This ensures Raspberry Pi compatibility for releases.Check the Actions tab: https://github.com/jsuzanne/stigix/actions.
You should see the run name labeled with 🚀 Release $NEW_VER.
$NEW_VER: prefix in the commit message.git tag output against documented entries in CHANGELOG.md. All missing versions MUST be backfilled — one entry per version — before committing.