SKILL DIRECTORY

스킬 탐색

설치 수와 최근 흐름을 기준으로 필요한 Agent Skill을 찾아보세요.

skills.sh API 기준방금 확인

writing-runbooks

Use when writing operational documentation - runbooks, setup guides, release procedures, migration guides, deprecation guides, troubleshooting entries, or any ordered procedure someone will execute under time pressure. Encodes the runbook skeleton, the risk legend, the symptom-first troubleshooting format, and the migration-guide rules (mapping table, mandatory rollback, deprecation dates, built-in expiry). Use whenever someone will execute the text, even if it is called a "guide" or "setup notes".

1282

riekelt/technical-writerGitHub

writing-changelogs

Use when writing a changelog entry, release notes, or a "what shipped" summary after completing work. Encodes the entry shape, the handover template, and the honesty conventions. Use after shipping meaningful work, even if the user just says "summarize what we did".

1283

riekelt/multi-agent-reviewGitHub

multi-agent-review

Use when a spec or plan needs review before execution begins - "review my spec", "is this plan ready to execute", "check this before I build it", "second opinion on this plan" - and specifically before writing-plans (spec mode) or before subagent-driven-development (plan mode). Reviews specs and plans, not code. Panels six reviewers across two model tiers and three topics, invokes a reasoning-tier juror only when the tiers disagree, and gates the next workflow step with a fail-closed Blockers / Warnings / Observations verdict.

1284

riekelt/principal-engineerGitHub

writing-unit-tests

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.

1285

riekelt/principal-engineerGitHub

principal-engineering

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.

1286

riekelt/technical-writerGitHub

writing-postmortems

Use when writing a postmortem, incident report, or root-cause analysis after an outage, a defect that reached users, a data issue, or a near miss - or when turning an incident channel, alert log, or war-room thread into a durable document. Encodes the blameless framing, the evidence-only timeline, contributing factors, and owned action items. Use whenever something broke and the write-up must outlive the incident.

1287

riekelt/principal-engineerGitHub

grounding-before-coding

Use when starting any non-trivial change, investigating a bug, or working in unfamiliar code - before the first line is written. Also use for pure investigation with no change planned yet - \"dig into this\", \"figure out why\", \"sometimes the export is empty\", intermittent errors after a deploy. Encodes the ground-first discipline: map the real code and data, quote evidence, never guess conventions. Use whenever a change or a conclusion is about to be built from belief instead of from the tree, even under time pressure.

1288

riekelt/principal-engineerGitHub

guarding-architecture

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.

1289

riekelt/principal-engineerGitHub

verifying-before-done

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.

1290

riekelt/technical-writerGitHub

recording-decisions

Use when a decision needs recording - an ADR, a decision log entry, or when someone asks to write down why something was chosen, rejected, or superseded. Encodes the ADR and decision-log formats. Use whenever a choice was made that would otherwise live only in chat, even if nobody says "ADR".

1291

antfu/skillsGitHub

pnpm

엄격한 종속성 해결 기능을 갖춘 Node.js 패키지 관리자입니다. pnpm 전용 명령어를 실행하거나, pnpm-workspace.yaml을 통해 작업 공간을 구성하거나, 카탈로그, 패치, 오버라이드, 구성 종속성 또는 전역 가상 저장소를 사용하여 종속성을 관리할 때 사용합니다.

1292

riekelt/technical-writerGitHub

writing-issues

Use when writing or refining tracker items - epics, stories, tasks, bug reports, spikes, or acceptance criteria - or when turning a discussion, review finding, or plan into tickets. Encodes the survives-without-you test, the issue-type glossary, and the story and bug skeletons. Use whenever work is written into a tracker, even from a rough verbal dump.

1293

riekelt/technical-writerGitHub

documenting-legacy-codebases

Use when documenting an existing codebase whose documentation is missing, stale, or untrusted - an inherited system, a legacy application, a repo where the docs lie - or when regrounding a documentation tree against the code, or when someone asks what a system actually does. Encodes the survey-first inventory, the writer-side evidence hierarchy, depth-per-surface rules, the refactor test, dead-or-alive proofs, the quirks-and-findings split, the coverage ledger, the parallel campaign, and the docs-tree skeleton. Use whenever documentation must be reconstructed from the code rather than written alongside a change.

1294

riekelt/principal-engineerGitHub

testing-changes

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".

1295

getsentry/skillsGitHub

security-review

취약점을 파악하기 위한 보안 코드 검토. “보안 검토”, “취약점 탐지”, “보안 문제 확인”, “보안 감사”, “OWASP 검토”를 요청받았을 때, 또는 인젝션, XSS, 인증, 권한 부여, 암호화 관련 문제를 확인하기 위해 코드를 검토해야 할 때 사용합니다. 신뢰도 기반 보고 기능을 통해 체계적인 검토를 제공합니다.

1296

riekelt/principal-engineerGitHub

keeping-one-source-of-truth

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.

1297

riekelt/principal-engineerGitHub

scoping-changes

Use when deciding how big a fix should be, when scope is drifting mid-task, when a plan is being quietly trimmed to fit, or when "while you're at it" appears in any form. Encodes size-to-trigger, decompose-not-descope, and drive-to-completion. Use whenever the work is about to grow past its cause or shrink below its promise.

1298

riekelt/principal-engineerGitHub

handling-failures

Use when writing or touching any error path, catch block, fallback, default value, retry, or degraded mode - in any language, any repo. Encodes the no-silent-swallows contract and the fail-loud discipline. Use whenever an exception is about to be caught, a null is about to get a default, or a failure could pass unnoticed, even if the goal is "just make it not crash".

1299

riekelt/principal-engineerGitHub

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.

1300

riekelt/principal-engineerGitHub

adding-dependencies

Use when about to add, update, vet, or remove a dependency - a package, library, SDK, GitHub action, base image, or vendored code - or when a project's dependency posture needs declaring. Encodes the exhaust-what-you-have ladder, the vetting questions, and pin-and-prove updating. Use even for a tiny utility package: that is exactly how the tree grows.