Skip to main content الرئيسية المنشئون akillness jeo-skills security-best-practices
security-best-practices Routing-first skill for web/application/API hardening. Use when the main job is classifying which security layer is missing — browser/perimeter policy, session/cookie/CSRF, abuse controls, validation/unsafe execution, secrets/runtime config, or verification — and turning vague OWASP/security asks into one concrete hardening brief. Route auth-stack choice to `authentication-setup`, schema work to `database-schema-design`, code-level bug fixing to `debugging` / `code-review`, and environment wiring to `system-environment-setup`.
الانتقال إلى التثبيت سوق المهارات اكتشف واستكشف مهارات الذكاء الاصطناعي التي بناها المجتمع.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
نسخ Promptعرض تفاصيل Prompt يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/akillness/jeo-skills --skill security-best-practicesيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
تحميل Zip جاري التحميل... المزيد من هذا المستودع Drive Godogen (htdt/godogen), the MIT-licensed publish-time generator that turns a game description into an autonomous Claude Code or Codex build for Godot 4 C#, Bevy Rust, or Babylon.js TypeScript. Route one request to one mode: preflight the toolchain and API keys; publish a fresh game repository or safely refresh a matching existing runtime with `./publish.sh --engine ...`; run the build and prove it from the live game or a 15-20s recording; budget paid Gemini, Grok, and Tripo3D asset generation; apply engine-specific build and capture rules; troubleshoot rendering and capture failures; or contribute through the issue-first upstream process. Use when the user wants an agent to build a playable game end to end with Godogen. Triggers on: godogen, htdt/godogen, publish.sh --engine, autonomous game development, Godot C# agent build, Bevy agent build, Babylon.js agent game, asset-gen, Tripo3D rig, proof video.
Install, route, and operate zenstory-ai/drama-skills, the MIT-licensed 10-skill creator-first suite for Chinese short dramas and motion comics. Use when the user wants to import or troubleshoot the suite; initialize or resume a filesystem project; analyze a novel; develop an adaptation; write episodes; build visual assets; produce image prompts, storyboards, or video prompts; review a project; open its local Dashboard; or run confirm-gated image, video, TTS, or music production. Route each request to the correct `short-drama-*` owner while preserving the five-document episode contract. Triggers on: drama-skills, zenstory-ai/drama-skills, short-drama, Chinese short drama, motion comic, creator-first drama workflow, 剧本, 视觉设定, 分镜, 图片提示词, 视频提示词. Route generic programmable-video work to `video-production`, webtoon panel production to `webtoon-harness`, and the OpenStory codebase to `openstory`.
Drive Mole (`mo`), tw93's GPL-3.0 macOS maintenance CLI that cleans caches and app leftovers, uninstalls apps with their remnants, purges rebuildable project artifacts, removes downloaded installers, explores disk usage, runs bounded system optimization, and reports live health. Routes one request to one mode: run a command safely (`--dry-run` first, the user runs the destructive step), consume the JSON/NDJSON agent surfaces (`mo analyze --json`, `mo status --json` / `--watch`, `mo history --json`, `~/.config/mole/clean-list.txt`), install/update/remove on the right channel, configure whitelists and scan paths, troubleshoot, or contribute to the repo. Use when a user wants to free Mac disk space or fully uninstall a Mac app. Triggers on: mole, `mo clean`, `mo uninstall`, `mo analyze`, `mo purge`, `mo status`, tw93/Mole, mole.fit, clean my Mac, what is eating my disk, CleanMyMac / AppCleaner / DaisyDisk alternative, brew install mole.
المهن ذات الصلة SOC
استنادا إلى تصنيف SOC المهني
name security-best-practices description Routing-first skill for web/application/API hardening. Use when the main job is classifying which security layer is missing — browser/perimeter policy, session/cookie/CSRF, abuse controls, validation/unsafe execution, secrets/runtime config, or verification — and turning vague OWASP/security asks into one concrete hardening brief. Route auth-stack choice to `authentication-setup`, schema work to `database-schema-design`, code-level bug fixing to `debugging` / `code-review`, and environment wiring to `system-environment-setup`.
allowed-tools Bash Read Write Edit Glob Grep compatibility Best for web apps, APIs, backend/fullstack services, marketing-site forms, edge/frontend-plus-backend systems, and game-adjacent service/web launch surfaces where the team needs a vendor-neutral hardening workflow instead of a giant middleware or scanner checklist.
license MIT metadata {"version":"2.1.0","modernization":"2026-04-14T00:00:00.000Z","hardening":"2026-04-18T00:00:00.000Z","tags":"security-best-practices, owasp, appsec, csp, csrf, secrets, rate-limiting, web-security, api-security","platforms":"Claude, ChatGPT, Gemini, Codex"}
Security Best Practices
Use this skill when the job is to name one missing security layer and turn it into a bounded hardening brief .
The job is not to dump a giant OWASP list, middleware catalog, or scanner parade.
The job is to:
frame the surface and risk,
choose one primary hardening mode,
recommend the smallest credible first slice,
name the verification ladder,
route adjacent work honestly.
Read these support docs first:
When to use this skill
A team says “make this secure” and the missing security layer is still unclear
A web app, API, marketing-site flow, admin panel, or game-service surface needs a hardening pass before launch or migration
You need to decide whether the main problem is CSP/headers, cookies/CSRF, abuse controls, validation/unsafe execution, secret handling, or weak verification
Scanner findings, OWASP requests, or launch-review notes need to be converted into one prioritized hardening brief
The current stack has some controls already, but trust is low and the next verification step is unclear
When not to use this skill
The main job is choosing an auth vendor, session architecture, org/member model, or enterprise SSO path → authentication-setup
The main job is API contract/interface design before security controls are slotted in → api-design
The main job is schema constraints, token tables, indexes, or migration safety → database-schema-design
The main job is backend regression coverage or auth/security test implementation → backend-testing
The main job is fixing a specific vulnerability in code or reviewing a concrete diff → debugging or code-review
The main job is secret injection mechanics, toolchain bootstrapping, or environment wiring → system-environment-setup / environment-setup
→ use the infrastructure-specific skill instead of this app-hardening anchor
The main job is cloud IAM, VPC/network, or broader infrastructure security
Instructions
Step 1: Frame the hardening job before naming tools Capture the minimum facts first.
security_intake:
surface: frontend | backend-api | fullstack | edge-worker | marketing-site | game-service-web | mixed | unknown
workflow_type: new-build | hardening-pass | audit-review | launch-readiness | incident-follow-up | migration
auth_session_model: cookie-session | bearer-token | mixed | unknown
current_controls:
- headers-csp
- csrf
- rate-limit
- validation
- secret-store
- scanning
- none
primary_risk: xss-browser-policy | csrf-session | abuse-automation | injection-unsafe-execution | secret-exposure | verification-gap | mixed | unknown
environments: local | preview | staging | prod | multi-env | unknown
ownership: app-team | platform | security | shared | unknown
Rule: do not start with “install Helmet,” “turn on CORS,” or “just add WAF rules.”
First label the missing layer.
Step 2: Choose exactly one primary hardening mode
browser-perimeter-policy
session-cookie-csrf
abuse-controls
validation-unsafe-execution
secrets-runtime-config
review-verification
Pick the highest-risk missing layer as primary.
List everything else as follow-up, not as equal co-owners.
Step 3: Keep the invariants visible These rules survive every answer:
CORS, auth, CSRF, rate limiting, validation, and secrets are separate concerns even when they touch the same route
browser-policy work may need staged rollout or report-only verification
framework defaults help, but they do not prove full coverage
secret scanning is detection, not storage/rotation policy
WAF and rate limiting are compensating/perimeter controls, not full substitutes for app-layer fixes
every recommendation needs a matching verification step
Step 4: Build the security hardening brief # Security Hardening Brief
## Scope
- Surface: ...
- Workflow type: ...
- Primary mode: ...
- Confidence: high | medium | low
## Current control state
- Controls already present: ...
- Missing or untrusted controls: ...
## Highest-risk gaps
1. ...
2. ...
3. ...
## Recommended first slice
1. ...
2. ...
3. ...
## Verification plan
- Manual review: ...
- Static/policy checks: ...
- Dynamic/runtime verification: ...
- Operational evidence: ...
## Ownership and route-outs
- Primary owner: ...
- Adjacent skills / teams: ...
Step 5: Use the mode packet, not a giant checklist
browser-perimeter-policy → headers, CSP, framing, secure transport, report-only rollout, proxy/CDN vs app ownership
session-cookie-csrf → cookie flags, state-changing browser routes, origin assumptions, web vs API/mobile differences
abuse-controls → login/reset/form/expensive-endpoint protection, per-route vs global limits, bot carve-outs, monitoring
validation-unsafe-execution → trust boundaries, validation/encoding, uploads, SSRF, command execution, dangerous patterns
secrets-runtime-config → secret-vs-config separation, storage/injection, least privilege, rotation/revocation, client-bundle avoidance
review-verification → classify findings, keep/fix/add/defer decisions, smallest proof ladder, honest ownership
Step 6: Route adjacent work explicitly Use these route-outs when the problem crosses boundaries:
If the real job is... Route to... auth vendor choice, enterprise SSO, org/member model, hosted-vs-native auth authentication-setupAPI auth/error/webhook contract design api-designschema constraints, token tables, migration/data-model safety database-schema-designbackend security regression tests or CI gates backend-testingconcrete vulnerability fix or risky diff review debugging / code-reviewenvironment bootstrap or secret injection wiring system-environment-setup / environment-setup
Output expectations A strong answer from this skill should:
identify the primary missing layer ,
recommend one bounded first slice,
name the verification ladder ,
avoid pretending one library/tool solves everything,
route adjacent work outward instead of absorbing it.
Examples
Example 1: cookie-based admin app hardening
Our Next.js admin app uses cookie sessions. POST routes lack CSRF protection and staging/prod cookie flags drift.
choose session-cookie-csrf
identify which routes need CSRF protection and which cookie flags must be fixed
include a verification step for staging/prod drift
avoid reframing the task as auth-vendor selection
Example 2: marketing-site form abuse
Our signup and demo-request forms are getting spammed even after adding a honeypot and CAPTCHA.
choose abuse-controls
separate form abuse controls from generic CSP/header work
recommend route-aware throttles / anti-automation steps plus monitoring
keep broader infrastructure or vendor-rule authoring outside the core brief
Example 3: game-service secret leakage risk
We have a game companion site plus backend APIs. I’m worried partner keys and admin tokens are drifting into CI logs and maybe client bundles.
choose secrets-runtime-config
separate secret detection from storage/rotation/injection policy
route environment bootstrapping details away when needed
include revocation/rotation proof requirements
Example 4: scanner report with weak ownership
The scanner says weak CSP and missing headers, but the app already added middleware and no one trusts the result.
choose review-verification or browser-perimeter-policy
keep middleware installation distinct from rollout proof
recommend staged/report-only verification or a scanner/runtime handoff
Best practices
Choose the missing security layer before naming tools.
Keep browser policy, session safety, abuse controls, validation, secrets, and verification separate.
Pair every recommendation with evidence that would prove it worked.
Treat framework defaults and scanners as inputs, not final answers.
Prefer one bounded hardening brief over a giant compliance dump.
References