feat: vendorizar as 10 skills do pilar de seguranca em skills/

Copia local (nao fork, nao submodule) de safedeps, sca-audit,
secrets-scan, code-review-security, api-security-review,
web-security-review, cve-triage, patch-prioritization,
dependency-scanning e hermaguard -- commit exato de origem e licenca
de cada uma em skills/NOTICE.md. Elimina o passo de clone externo
pro pilar de seguranca do wf-security-review: git clone deste repo
ja traz tudo funcional.

Corrige tambem o comando de instalacao pro Claude Code nos dois
READMEs e no docs/SKILLS.md: Claude Code exige um diretorio por
skill (skills/<nome>/SKILL.md), nao aceita os .md soltos que o
comando antigo copiava -- confirmado testando a instalacao real.

skills/safedeps/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: safedeps
+description: >
+  Grounds dependency decisions in live OSV.dev vulnerability data instead of a
+  model's frozen training-cutoff knowledge. Trigger whenever you are about to
+  add a dependency, bump/upgrade a package version, choose between package
+  versions, answer "is <package> safe / vulnerable", or review a manifest or
+  lockfile (requirements.txt, package.json, package-lock.json, go.mod) for
+  security issues. Also trigger on requests like "check my dependencies for
+  vulnerabilities" or "what version of X should I use".
+---
+
+# safedeps
+
+Your training data has a cutoff. CVEs published after it are invisible to
+you, and a vulnerable package version doesn't error at runtime -- it just
+runs, quietly exploitable. Don't guess. Ask OSV.dev.
+
+## When to run this
+
+Before you write a version number into a manifest, or when asked to review
+one, run the checker and use its real output instead of your own
+recollection of which versions are safe.
+
+```bash
+python3 <skill_dir>/../../check_deps.py <package>@<version>:<ecosystem>
+python3 <skill_dir>/../../check_deps.py path/to/requirements.txt
+```
+
+(`<skill_dir>` is this file's directory; the script lives at the repo/plugin
+root as `check_deps.py`. Ecosystems: `npm`, `PyPI`, `Go`, `crates.io`,
+`Maven`, etc. -- omit `:ecosystem` and it defaults to `npm`.)
+
+The script prints one of two things per package, straight from OSV.dev:
+
+```
+OK    npm:[email protected] -- no known advisories
+VULN  npm:[email protected] -- 2 advisory(ies):
+  - CVE-2026-4800 [HIGH] lodash vulnerable to Code Injection via `_.template` imports key names
+      fix: upgrade to 4.18.0
+```
+
+## What to do with the output
+
+1. If a package you're about to add/bump shows `VULN`, do not use that
+   version. Use the version named in `fix:` instead (or newer).
+2. If no fixed version is listed, tell the user there's an open advisory
+   with no patch yet -- let them decide.
+3. Always surface the advisory IDs and severities to the user; don't
+   silently swap versions without saying why.
+4. If the script reports OSV.dev is unreachable, say so plainly and fall
+   back to your own knowledge with a caveat that it may be stale -- don't
+   pretend you checked.
+
+## Examples
+
+**Adding a dependency**: user asks to add `flask` to a Python project.
+Run `check_deps.py [email protected]:PyPI` (the version you were about to pick)
+before writing it to `requirements.txt`. If it's clean, proceed. If not,
+check the `fix:` version and use that instead.
+
+**Reviewing a project**: user asks "are my dependencies safe?" Run
+`check_deps.py requirements.txt` (or `package.json`) in their project root
+and report every `VULN` line with its fix version.