tinysocs-change-control

Gates TinySocs changes through pivot-alignment checks, change-class rules, and a pre-merge checklist.

Updated Oct 12, 2025
One-click install
npx skills add https://github.com/lukefitzg/tinysocs --skill tinysocs-change-control-lukefitzg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tinysocs-change-control
Source: https://github.com/lukefitzg/tinysocs/tree/main/.claude/skills/tinysocs-change-control
Command: npx skills add https://github.com/lukefitzg/tinysocs --skill tinysocs-change-control-lukefitzg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? TinySocs is a solo-founder SIEM project with a hard deadline and a history of costly mistakes — stale license claims, silently broken CI, recurring PowerShell encoding bugs, and scope creep away from the content-as-a-service pivot. This Skill acts as the mandatory front door for any change, ensuring every edit to detection rules, public claims, licensing, or the installer passes the right review gate before it lands. ## Core Features & Use Cases - Pivot-Alignment Filter: A three-question decision procedure that rejects work not serving the 7 roadmap gaps, fixing an active blocker, or addressing a non-negotiable violation. - Change-Class Gate Table: Maps five change classes (detection behavior, public claims, schema/licensing/tiers, installer/trust path, rule migration) to their required evidence and owning sibling skills. - Non-Negotiables with Incident History: Codifies hard rules earned from real incidents — BSL-1.1 licensing discipline, dual-engine honesty, CI-green verification, ASCII-only PowerShell, and no committed plan documents. - CLAUDE.md Stale-Facts Protocol: A verified table of known-stale CLAUDE.md claims with file:line citations of ground truth, plus a 10-item pre-merge checklist. - Use Case: Before enabling detection rule TS-135 and updating the one-pager to say "20 rules", load this Skill to discover you need an Atomic Red Team test, an xUnit firing/silent pair, and a banned-numbers check on the public claim. ## Quick Start Ask the assistant to load the tinysocs-change-control skill and review whether your planned change to a detection rule, doc, or installer file passes the pivot filter and which gates apply.

Frequently Asked Questions about tinysocs-change-control

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I know which gate applies before changing a TinySocs detection rule?

Detection-behavior changes require an Atomic Red Team test case in tests/atomic-tests.yaml plus an xUnit firing/silent pair in tests/TinySocs.Agent.Tests, with no rule shipping enabled without that evidence. If the change also touches public claims or schema, every applicable gate in the change-class table applies.

What is the pivot-alignment filter for deciding if a task is in scope?

Answer three questions in order: does it serve one of the 7 roadmap gaps, does it fix something actively blocking a gap, or is it a non-negotiable violation. If all three are no, decline the task or explicitly park it as out of scope for the content-as-a-service pivot.

Why must PowerShell scripts be ASCII-only in this repo?

Windows PowerShell 5.1 mangles non-ASCII characters like em-dashes under the console codepage, corrupting string terminators and silently swallowing statements. This bug recurred at least five times, so every .ps1 change must pass a grep check that excludes the CR byte from CRLF line endings.

Can I trust that merged TinySocs commits passed CI?

Not automatically — CI was silently red for about a month in mid-2026 while the signed-feed and licence-gate work landed. Also, dotnet test runs nowhere in CI, so the C# xUnit detection-engine suite must be run by hand for any C# change.

When should I not use the change-control skill?

Skip it when you already know the change class and need only the mechanics — go straight to the owning sibling skill such as tinysocs-validation-and-qa or tinysocs-architecture-contract. It also does not cover detection domain theory, live debugging, or config flag references.

How are stale CLAUDE.md facts handled during a task?

CLAUDE.md rules remain binding even where its facts are stale. State the code-verified reality with file:line citations, flag the gap explicitly, and never silently edit CLAUDE.md unless the task is specifically to update it.