1.3.0 — srx-initial-setup policy model opt-out

srx-initial-setup v1.1.0 — adds explicit zone-to-zone policy opt-out to align with srx-policy skill's enforced global-policy contract. The baseline policy is generated as global policy; when a zone-pair exception applies (existing-estate compatibility, isolated exceptions clearer as zone-pair policies, or customer standards requiring zone-pair contexts), the policy stage routes to srx-policy for zone-pair design on non-Branch platforms (Branch SRX zone-pair policy is unowned). Adds runtime intake question sis_policy_model to confirm the architecture before generating the baseline.

---

Tagged retroactively at b8fb5a1, the commit whose CHANGELOG top entry is 1.3.0. Notes are that entry verbatim.

1.2.0 — srx-initial-setup skill

New skill: srx-initial-setup v1.0.0 — first-time SRX bring-up from factory-default or zeroized state to a reachable, zoned, screened, and minimally policied device. Automates Day-0 and Day-1 setup for Branch SRX300/400, campus SRX1600/4120, and datacenter SRX4300/4700/5000 platforms. At 1.0.0 this skill is written from vendor documentation and existing verified repository references; no device validation has been performed. Validation against vSRX and against SRX345, SRX1600, and SRX4700 hardware is deferred to a later release. Key features:

• Assess-first architecture: read-only entry-state assessment classifies device into one of five states before proposing any writes
• Dependency-ordered gap model: closes only the gaps that are actually open, making the skill idempotent
• Per-stage approval gates with confirmed commit and rollback timers on all lockout-risk changes
• Branch factory-default handling: removal of shipped zones, DHCP server, and permissive policy only after replacement management path is verified
• Five stages: access and recovery, management plane, interfaces and zones with host-inbound-traffic, starter IDS screens, and minimal baseline policy
• Entitlement readout across three independent axes (entitled, configured, active) that routes to sibling skills for license mutation and feature configuration

---

Tagged retroactively at a998e45, the commit whose CHANGELOG top entry is 1.2.0. Notes are that entry verbatim.

v1.1.1 — README split

Documentation-only release. No skill content changed — all 27 skills keep the versions they carried in 1.1.0.

What changed

• README.md trimmed from 783 to 494 lines.
• Per-skill detail for the compliance and SRX operational playbooks moved to SKILLS.md.
• The v1.1.0 parser notes moved out of the README into CHANGELOG.md.
• The 21-row intermediate-schema table condensed to prose plus a link at its canonical copy, skills/parsing-srx-configs/references/intermediate-schema.md.
• Usage examples cut from eleven to five; each skill's own SKILL.md carries worked examples for its topic.

Why

Repeated feedback that the README was too long. The two "(detail)" sections restated what the Reference catalog and each skill's own SKILL.md already said, and the fatcat/converter notes were release history rather than an introduction.

Full detail in CHANGELOG.md.

v1.1.0 — 27 skills, downstream publish pipeline

Since v1.0.0 (24 skills): three new skills, a one-way publish pipeline for
redistributing a de-branded copy downstream, and a user-facing section on the
risks of installing agent skills.

New skills

• srx-syslog-logging — external syslog/SIEM delivery, the RE vs PFE logging
  split, and why a non-default syslog port can be discarded silently
• srx-chassis-cluster-proxmox — chassis cluster whose nodes are Proxmox guests
• clearpass-proxmox-deploy (draft) — HPE Aruba ClearPass 6.14 on Proxmox VE

25 of 27 reviewed. clearpass-proxmox-deploy ships as a draft and
srx-syslog-logging has not yet been through the two-stage review.

Publish pipeline

scripts/publish-jnpr.py exports a de-branded copy to a downstream org with no
shared git history, so branding cannot travel downstream and downstream copyright
cannot travel back. The de-branding is verified, not assumed — the run fails
closed if any forbidden token, unpublished-docs link, or doc-dependent script
survives into the export.

Attribution is scoped deliberately: nested metadata.sources[].author entries
keep crediting the original lab work while the package author is rewritten.

Before You Install

New README section covering risks that had no user-facing mention: a skill is
instructions your agent follows (read the whole directory — the deployment skills
ship Python helpers), and a pasted config is untrusted input that can carry
prompt injection. Also covers secret disclosure to model providers, and frames
skill selection around discovery quality rather than token cost.

CI

Secret scanning moved from gitleaks-action to a version-pinned,
checksum-verified gitleaks binary. The Action requires a paid licence for
organization repos and fails closed without one — a red check that means
"unlicensed" is indistinguishable from one that means "leak found".

v1.0.0 — 24 skills, all reviewed

First tagged release. 24 skills across five families, 24/24 with an independent technical review behind them.

curl -fsSL https://raw.githubusercontent.com/fastrevmd-lab/fwskillsshare/main/install.sh | bash

Install everything, one family (--family srx), or a single skill (--skill srx-nat). Targets Claude Code, Codex, and Hermes.

What's in it

Family	Skills
Config parsers	4 — Cisco ASA/FTD, FortiGate, PAN-OS, Juniper SRX → one shared intermediate schema
SRX operational playbooks	9
NGFW compliance and STIG	7 — PCI, HIPAA, CMMC/NIST 800-171, CIS, ISO 27001, SOC 2, SRX DISA STIG
Cross-vendor tooling	3 — best-practices audit, conversion, diff
Security management deployment	1 — Security Director On-Prem on Proxmox

Since the last milestone

Two new skills reached 1.0.0.

• srx-license-signature-maintenance — AppID and IDP/IPS entitlement audit, license installation, and offline signature updates behind two independent approval gates, with secret-safe license handling, per-node chassis-cluster verification, pilot-then-batch rollout, and condition-based polling. Validated read-only across 9 devices / 10 node records on three Junos releases.
• sd-onprem-proxmox-deploy — promoted after three complete field deployments.

Live-device validation found and fixed real defects. These were not caught by review or offline tests:

• parsing-srx-configs did not extract security dynamic-address, so GeoIP and feed-backed objects read as dangling references — false SEC-ORPHAN-REF on every rule using one.
• It also dropped match dynamic-application, which collapsed distinct AppID-scoped rules into false SEC-REDUNDANT pairs and let an AppID-scoped deny pass as a terminal deny-all, silencing SEC-NO-DENY-ALL on a device that had none.
• show system license accepts no node argument on a chassis cluster — every per-node form is a syntax error, while the IDP and AppID version commands do take node 0/node 1.
• IDP and AppID emit different version-qualifier formats; one parser written to the IDP shape mis-handles AppID.
• On a live cluster the two nodes disagreed on AppID package version while IDP matched — the case that justifies per-node verification, found in the field rather than in a fixture.

Security Director On-Prem onboarding now gates on proven NTP sync. A skewed SRX clock completes the mTLS handshake and gets its payloads acknowledged while logs never appear in the GUI. The gate decides on show ntp associations, because sync_ntp alone can accompany no_sys_peer and a missing clock_sync can accompany a genuinely synced device.

Honest boundaries

• The licensing skill's mutating paths (request system license add, security-package install) have never been executed against hardware. The read-only surface is validated; that boundary is documented in the skill-test record.
• CI here gates secret scanning only. Everything else — 14 validators, installer e2e, trivy — runs locally.
• These are research and assessment-support skills, not certified products. Review output against current vendor documentation, live device behavior, and a qualified assessor before relying on it.

Unofficial community project, MIT licensed. Not affiliated with Cisco, Fortinet, Palo Alto Networks, Juniper Networks, or HPE.