opencode-skills-collection 3.1.14 → 3.1.16

package/bundled-skills/context-kit/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: context-kit
+description: "Evaluate, adapt, and safely install Context Kit personal context artifacts for Claude Code or adjacent agent workflows."
+category: productivity
+risk: critical
+source: community
+source_repo: JDDavenport/context-kit
+source_type: community
+date_added: "2026-07-04"
+author: JDDavenport
+tags: [personal-context, claude-code, memory, knowledge-management, agent-workflows]
+tools: [claude, codex, cursor, gemini]
+---
+
+# Context Kit
+
+## When to Use
+
+Use this skill when the user wants to:
+
+- Set up durable personal context files for Claude Code or another coding agent
+- Compare Context Kit's Personal Context Artifact pattern with an existing memory or project-notes system
+- Adapt a context template structure without copying private details into the chat
+- Review whether a one-line installer or downloaded skill pack is appropriate before running it
+- Create a safer, local-first plan for CRM notes, open loops, session digests, or morning briefings
+
+## Overview
+
+Context Kit is an external project that organizes personal context into Markdown artifacts and companion
+Claude Code skills. This skill helps the user decide what to adopt, where to store it, and how to avoid
+turning a useful context system into a pile of sensitive data.
+
+Treat every personal context file as private by default. These files may contain identity details, family
+context, work history, contact notes, mental models, health constraints, or relationship information. Do
+not paste them into third-party tools, public repositories, issue trackers, or model contexts unless the
+user explicitly approves the exact subset.
+
+## Safety Rules
+
+1. Do not run a remote install script until the user has seen the command, source repository, and target
+   paths it will write to.
+2. Prefer cloning or downloading the repository for inspection before executing any installer:
+   ```bash
+   git clone https://github.com/JDDavenport/context-kit.git
+   cd context-kit
+   sed -n '1,220p' scripts/install.sh
+   ```
+3. Never store passwords, API keys, recovery codes, private keys, session tokens, or payment details in
+   personal context artifacts.
+4. If the user wants contact notes or CRM files, store only information they are comfortable keeping in
+   local plaintext Markdown.
+5. Before adding these files to a repo, confirm `.gitignore` excludes the chosen private context directory.
+6. If adapting Context Kit to a team or company setting, separate personal context from company-confidential
+   or customer-confidential information.
+
+## Setup Workflow
+
+1. Ask what the user wants Context Kit to improve: session startup context, voice consistency, relationship
+   memory, open-loop tracking, daily briefings, or handoff summaries.
+2. Inspect the upstream project and installer before running anything.
+3. Choose a storage location:
+   - Claude Code default: `~/.claude/context/` and `~/.claude/skills/`
+   - Project-local context: `.agent/context/` or another ignored directory
+   - Portable setup: a private notes repo with explicit sync rules
+4. Create a minimal starter set before filling everything:
+   - `pca-wiki.md` for durable identity and domains
+   - `pca-mental-models.md` for decision rules
+   - `pca-voice.md` for writing preferences
+   - `pca-protocols.md` for hard rules and boundaries
+5. Add only enough detail to make the next agent session useful. Leave sensitive, speculative, or outdated
+   details out until there is a clear reason to include them.
+6. Add a recurring review cadence. Personal context goes stale quickly; stale context is worse than no
+   context when it drives decisions.
+
+## Installation Review Checklist
+
+Before running an installer, verify:
+
+- The repository URL is exactly the one the user intended
+- The script writes only to expected local directories
+- The script does not upload files, send telemetry, or edit shell startup files unexpectedly
+- The target directories are not inside a public repo
+- The user has a rollback path, such as removing the copied templates and skills
+
+If anything is unclear, stop at inspection and provide the user with the exact lines that need review.
+
+## Examples
+
+### Example: Inspect before installing
+
+```bash
+git clone https://github.com/JDDavenport/context-kit.git
+cd context-kit
+sed -n '1,220p' scripts/install.sh
+find templates skills -maxdepth 2 -type f | sort
+```
+
+After inspection, summarize the files that would be installed and ask for confirmation before running the
+installer.
+
+### Example: Create a private project-local context directory
+
+```bash
+mkdir -p .agent/context
+printf '.agent/context/\n' >> .gitignore
+cp ~/Downloads/context-kit/templates/pca-wiki.md .agent/context/pca-wiki.md
+```
+
+Then trim the template to the minimum useful fields for the project instead of filling every personal
+section immediately.
+
+## Best Practices
+
+- Keep context files short enough that an agent can read them at session start without drowning in stale
+  detail.
+- Separate durable facts from temporary state. Use project workplans or task trackers for temporary state.
+- Label assumptions and uncertain memories instead of presenting them as facts.
+- Review personal context after major life, role, health, or project changes.
+- Store voice examples and anti-examples separately from private identity details when possible.
+
+## Common Pitfalls
+
+- Running a shell installer directly from `curl` without inspecting it first
+- Committing personal context files to a public repository
+- Storing secrets because "the agent needs to know everything"
+- Letting relationship or health notes become outdated and still treating them as current
+- Copying upstream paid or license-unclear content instead of linking to it or writing original local notes
+
+## Limitations
+
+- This skill does not verify the current upstream license or installer behavior on its own; inspect the live
+  repository before running commands.
+- It does not replace a dedicated secrets manager, CRM, password vault, or medical record system.
+- It is for local personal context hygiene, not for collecting private information about other people
+  without a legitimate reason.

package/bundled-skills/cyber-audit/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: cyber-audit
+description: "Run read-only exposure checks for security advisories and write a structured local audit report."
+category: security
+risk: safe
+source: community
+source_repo: davidondrej/skills
+source_type: community
+date_added: "2026-07-07"
+author: davidondrej
+tags: [security, audit, read-only]
+tools: [claude, codex]
+license: "MIT"
+license_source: "https://github.com/davidondrej/skills/blob/main/LICENSE"
+disable-model-invocation: true
+---
+
+# cyber-audit
+
+## When to Use
+
+- Use when the user asks whether their machine or projects are affected by a CVE, breach, or package advisory.
+- Use when a read-only local security exposure report is appropriate.
+
+## Hard rules
+
+- **Read-only.** No installs, removes, upgrades, restarts, network calls, or file modifications outside `~/Documents/security-audits/`.
+- **No `sudo`.** Never.
+- **One report per invocation.** Always end by writing the `.md` file (even if the verdict is "Not affected" — the audit trail matters).
+- If a check requires a state-changing command, **skip it and note "not checked (would require state change)"** in the table. Do not run it.
+
+## Workflow
+
+1. **Identify scope.** Extract from the advisory: package/binary name, affected versions, platform (macOS / Linux / Windows), attack vector (supply chain / RCE / local / network).
+2. **Run checks in parallel** (Bash tool, multiple calls in one message). Pick relevant checks for the advisory type — don't run all of them.
+3. **Build the table** as you go. Each row = one check + concrete result (version number, path, "None", "N/A").
+4. **Write the report** to `~/Documents/security-audits/YYYY-MM-DD-<short-kebab-slug>.md`. Use today's date from the environment header.
+5. **Tell the user** the verdict in one line + path to the report.
+
+## Check menu (pick what's relevant)
+
+```bash
+# --- Node / npm ecosystem (supply-chain advisories) ---
+which npm pnpm yarn; npm root -g; pnpm root -g 2>/dev/null
+ls /opt/homebrew/lib/node_modules                                  # global npm
+find ~ -maxdepth 8 -type d -name "<pkg>" 2>/dev/null \
+  | grep -v -E "(Library/Caches|\.Trash)"                          # installed copies
+find ~/Documents ~/Desktop ~/Downloads -maxdepth 8 -type f \
+  \( -name "package.json" -o -name "package-lock.json" \
+     -o -name "pnpm-lock.yaml" -o -name "yarn.lock" \) 2>/dev/null \
+  | xargs grep -l "<pkg>" 2>/dev/null                              # direct + transitive
+
+# --- Python ecosystem ---
+which python3 pip pipx uv
+pip list 2>/dev/null | grep -i "<pkg>"
+find ~/Documents -maxdepth 6 -name "requirements*.txt" -o -name "pyproject.toml" \
+  -o -name "poetry.lock" -o -name "uv.lock" 2>/dev/null | xargs grep -l "<pkg>" 2>/dev/null
+
+# --- Homebrew / system binaries ---
+brew list --versions <formula> 2>/dev/null
+which <binary>; <binary> --version 2>/dev/null
+
+# --- Running processes / listeners (for RCE / network CVEs) ---
+pgrep -lf "<binary>"
+lsof -iTCP -sTCP:LISTEN -P -n 2>/dev/null | grep "<port>"
+
+# --- LaunchAgents / LaunchDaemons (persistence / autostart) ---
+ls ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons 2>/dev/null \
+  | grep -i "<vendor>"
+
+# --- Env vars that change exposure (e.g. OLLAMA_HOST, listening addr) ---
+launchctl getenv <VAR>; grep -r "<VAR>" ~/.zshrc ~/.zprofile ~/.config 2>/dev/null
+
+# --- VS Code / browser extensions (for IDE-targeted advisories) ---
+ls ~/.vscode/extensions 2>/dev/null | grep -i "<ext>"
+```
+
+If the advisory mentions an ecosystem not above (Rust cargo, Go modules, Ruby gems, Docker images, etc.), apply the same pattern: global install path + manifest grep + running processes.
+
+## Report template
+
+File: `~/Documents/security-audits/YYYY-MM-DD-<short-kebab-slug>.md`
+
+```markdown
+# <Subject> — Audit
+
+**Date:** YYYY-MM-DD
+**Host:** the user's Mac
+
+## <CVEs | Advisory> in scope
+
+- **<ID or source> "<Name>"** — <one-line description>. <Affected versions or scope>.
+
+## Audit results
+
+| Check | Result |
+|---|---|
+| <Check 1> | <Result> |
+| <Check 2> | <Result> |
+
+## Verdict
+
+**<Not affected. | Affected. | Partially affected.>**
+
+- <Rationale bullet 1>
+- <Rationale bullet 2>
+
+## Action taken
+
+None — diagnostic only, no files modified, no <packages installed/removed | services started/stopped | firewall rules changed>.
+
+## Follow-ups
+
+- <Actionable item, or "None" if truly nothing>
+```
+
+Match the tone of the two existing reports in `~/Documents/security-audits/` — terse, factual, bulleted, no hedging.
+
+## Verdict wording
+
+- **Not affected.** — package/binary absent, or installed but patched, or not running and not exposed.
+- **Affected.** — vulnerable version present *and* reachable by the attack vector.
+- **Partially affected.** — present but mitigated (e.g. binary installed but service not running, or listener bound to loopback only). Spell out the mitigation in the bullets.
+
+## When to break the read-only rule
+
+Never on your own. If the verdict is "Affected", list the remediation command in **Follow-ups** and stop. The user runs it.
+
+## Reference
+
+Two existing reports in `~/Documents/security-audits/` show the expected style:
+- `baseline-audit.md` (long-form baseline audit — different format, do not mimic)
+- `YYYY-MM-DD-example-advisory.md` and any newer `YYYY-MM-DD-*.md` files (this is the format to match)
+
+## Limitations
+
+- Adapted from `davidondrej/skills`; verify local paths, tools, credentials, and agent features before acting.
+- For commands, remote access, scheduling, browser automation, or file-changing workflows, get explicit user approval and confirm the target environment first.