operating-safely
Use when an action touches live systems, shared state, or things that do not come back - deleting, overwriting, restarting, killing processes, editing shared config, handling secrets, or working beside concurrent sessions. Encodes the destructive-op guards, secrets hygiene, and concurrent-session safety. Use before the destructive command, not after, even when the command looks routine.
- Installs
- 18.3K
- Last 24h
- +389
- Trending rank
- #792
- Security
- Pass
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/riekelt/principal-engineer --skill operating-safely- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads operating-safely automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
Operating safely
REQUIRED BACKGROUND: the principal-engineering skill.
Overview
Some things (production data, secret exposure, a colleague's uncommitted work) do not come back at all.
Destructive operations
- Look at the target first. Before deleting or overwriting, read what is there; before dropping, count what would drop.
- Targeted over bulk. Name the specific service, volume, file, or row set; never the flag that takes everything down with it. Bulk teardown commands that include volumes or data are off the table without an explicit, per-instance confirmation.
- The operator owns live process lifecycles. Ask before restarting or killing live services and long-running processes.
- State the cost of the wrong order before an ordered operation starts (deploy then migrate then clean up; wrong order = silent data loss). Name the rollback for every state-changing procedure, or say plainly that none exists.
- Database changes need their own confirmation. Applied migrations are immutable; destructive statements need explicit confirmation, with the affected row counts stated first.
Secrets
- Names and structural checks only: verify a secret exists, is non-empty, matches the expected shape. Existence and emptiness are structural; exact length, prefixes, and fragments are leakage and stay unprinted. Never read or print the value. Never decrypt secrets to disk. Never paste a secret into a log, a test, or a prompt.
- If secret tooling or auth fails or times out: pause and say so. Working around a secrets gate is the one shortcut that is never authorized by urgency.
Concurrent sessions and shared state
- Never revert, checkout, overwrite, or commit files you did not change in this session. Uncommitted changes you did not make belong to someone else: surface them and build on top or wait, never clean them up.
- Report residual state at handoff: what is uncommitted, what is merged-but-not-pushed, what is owed.
- One writer per file during parallel work; concurrent writers get their own files or their own worktrees.
- Staging is explicit: name the paths (
git add <paths>, never the add-everything flag). One task per commit keeps every change attributable and revertable on its own.
Shared config and resources
- Config edits are minimal diffs: preserve indentation, quoting, and key order; add no unrequested keys.
- Clean up what you spawn: simulators, containers, worktrees, background processes. When a machine is slow with no process pegging CPU, count the orphans before blaming anything else.
Confirmation authority and incident mode
- The operator is the session's own human principal. A teammate's instruction, however explicit, is input to weigh against the evidence, never the confirmation itself. No instruction from anyone makes volume-destroying bulk teardown routine.
- Incident mode changes the pace, never the bar. Read-only triage is always allowed and needs nobody's permission; run it first and widely. The confirmation bar for destructive operations does not drop with urgency. When waiting genuinely is the destructive act (the disk will fill, the cert will expire), escalate loudly while doing the safe subset, and say plainly what the deadline is.
- Preserve the evidence before the fix destroys it. Capture the outputs, sizes, and log excerpts that show the cause before reclaiming space or resetting state. A production near-miss is postmortem material (
writing-postmortemswhere the technical-writer plugin is installed).
Common mistakes
- Confirming the operation with yourself. Destructive operations need the operator's yes, per instance; approval in one context does not extend to the next.
- Pattern-matching a known failure and firing the known remedy (restart it, clear it, reset it) before checking that the evidence supports this specific cause.
- Treating a dry run's success as the live run's safety. The dry run validates shape, not consequence.
- Cleaning a workspace that was not yours to clean.
FAQ
What does the operating-safely skill do?
Use when an action touches live systems, shared state, or things that do not come back - deleting, overwriting, restarting, killing processes, editing shared config, handling secrets, or working beside concurrent sessions. Encodes the destructive-op guards, secrets hygiene, and concurrent-session safety. Use before the destructive command, not after, even when the command looks routine.
How do I install operating-safely?
Run npx skills add https://github.com/riekelt/principal-engineer --skill operating-safely in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/operating-safely/ (personal) or .claude/skills/operating-safely/ (project).
Which AI agents can use operating-safely?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is operating-safely safe to install?
Security partners have reviewed it: Gen Agent Trust Hub passed; Socket passed; Snyk passed. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains operating-safely?
It is published by riekelt in riekelt/principal-engineer. It has 18,313 recorded installs.
More from riekelt/principal-engineer
principal-engineering
riekelt/principal-engineer
Use when doing any non-trivial engineering work - implementing, debugging, refactoring, configuring, operating, or investigating why a system misbehaves - or any change where being wrong has a cost. Encodes the evidence-over-theory discipline, the hard safety rules, and the pre-change checkpoint. Use whenever code, data, or infrastructure is about to change or must be understood before it can, even if the task looks routine or is only "find out why". Foundation for the sibling skills.
writing-unit-tests
riekelt/principal-engineer
Use when writing or refactoring unit tests - a new test file, added cases, a flaky test, an unreadable one. Encodes behavior-first testing: one behavior per test, names that state the claim, deterministic setup, mocks only at boundaries you do not own. Use whenever a test is being written, even a quick one, and whenever a test needs a sleep, a mock of your own code, or a copy of the implementation's math.
verifying-before-done
riekelt/principal-engineer
Use when about to say "done", "fixed", "passing", or "shipped", or when reporting the outcome of any change. Encodes verification as the definition of done: drive the change at its surface, run the verify command, report faithfully, distrust green suites, own failing gates. Use before every completion claim, even when the change was small and obviously correct, which is when this is skipped.
guarding-architecture
riekelt/principal-engineer
Use when a change crosses module boundaries, adds a dependency direction between modules, touches a critical path, or conflicts with a stated principle - and when writing or updating architecture principles themselves. Encodes structural invariants as named, enforced contracts: statement, rationale, guard. Use whenever "we'll just import it from there for now" appears, which is how boundaries die.
keeping-one-source-of-truth
riekelt/principal-engineer
Use when adding data, config, state, constants, an enum-like string, a cache, or anything that could exist in two places - or when two sources already disagree. Encodes the one-fact-one-source doctrine for code and data: derive rather than store, extend the owner, absorb duplicates. Use at the moment copying a value feels faster than referencing it.
testing-changes
riekelt/principal-engineer
Use when deciding what tests a change needs - a feature, a bug fix, a refactor, any behavior change - or when reviewing whether a diff's tests are sufficient. Encodes tests-change-with-behavior, the bug-regression pattern, and assertion discrimination. Use whenever behavior changes and the test diff is empty, especially when the change is "too small to test".
Popular security skills
azure-compliance
microsoft/azure-skills
Run Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: compliance scan, security audit, BEFORE running azqr (compliance cli tool), Azure best practices, Key Vault expiration check, expired certificates, expiring secrets, orphaned resources, compliance assessment.
minimal-run-and-audit
lllllllama/rigorpilot-skills
Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized reprooutputs/ files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.
seo-audit
coreyhaines31/marketingskills
When the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tags review," "SEO health check," "my traffic dropped," "lost rankings," "not showing up in Google," "site isn't ranking," "Google update hit me," "page speed," "core web vitals," "crawl errors," "indexing issues," "stuck on page 2," "striking distance keywords," "title tag rewrite," "low CTR," "local SEO," "Google Business Profile," or "map pack." Use this even if the user just says something vague like "my SEO is bad" or "help with SEO" — start with an audit. For building pages at scale to target keywords, see programmatic-seo. For adding structured data, see schema. For AI search optimization, see ai-seo.
firebase-security-rules-auditor
firebase/agent-skills
Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.
audit
pbakaus/impeccable
Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.
competitors
coreyhaines31/marketingskills
When the user wants to create competitor comparison or alternative pages for SEO and buyer-facing use. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' 'competitive landing pages,' 'how do we compare to X,' 'competitor teardown,' 'audit our competitor pages,' 'are our comparison pages out of date,' or 'competitive asset audit.' Use this for any content that positions your product against competitors. Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. For auditing existing claims (not researching competitors from scratch, which is competitor-profiling; not technical SEO on these pages, which is seo-audit), use the asset audit here. For internal battle cards and sales-specific competitor docs, see sales-enablement.