adam-s-daniel/adam
Adam's general-purpose skills, safe anywhere including cloud sessions: writing voice, GitHub Actions debugging and hardening, ADRs, resolving task ambiguity.
Write in Adam Daniel's voice — professional but warm, direct, em-dash-friendly, free of corporate buzzwords. Trigger whenever the user asks Claude to write something that will go out under Adam's name or be lifted into his materials: emails, replies, bios, proposal blurbs, cover letters, LinkedIn posts, performance self-appraisals, comments on other people's drafts, "ghostwrite this for me", or any "in my voice / sound like me" request. Also trigger when polishing or rewriting Adam's own draft. Do NOT trigger for generic third-party content the user is helping someone else produce (e.g. "draft a press release for the company") unless they ask for Adam's voice specifically.
Debugging GitHub Actions workflow failures. Use when workflows are failing, showing unexpected results, or when you need to read workflow run logs and diagnose CI/CD issues.
Surface and resolve the ambiguities in a task before, during, and after implementation — the blind-spot pass, the self-interview, reference-driven specs, implementation notes, and a post-hoc explainer or quiz. Use at the start of any non-trivial build, when working in an unfamiliar codebase or a new domain, when acceptance criteria are subjective ("make it feel polished", "clean this up"), when a plan keeps needing rework mid-implementation, or when the user says "help me find my unknowns", "what am I missing", "poke holes in this", "what haven't I thought about". Also use after a change lands, to produce the explainer or comprehension check that proves the work is understood.
Configure and enforce GitHub repository security settings as code: require actions to be pinned to full-length commit SHAs, require approval for all outside collaborators' fork pull-request workflow runs, and protect the default branch via a repository ruleset. Includes a generate/diff/apply engine (introspect current state -> emit YAML; detect drift; apply desired state) and a central fan-out workflow to enforce a baseline across many repos. Trigger when: setting up a new repo, running a security audit, onboarding a repo to org standards, enforcing settings across a fleet, or when asked to configure or harden Actions security settings. Trigger on mentions of "actions settings", "repo security settings", "repo settings as code", "settings drift", "fork approval", "outside collaborators", "actions policy", "branch protection", "ruleset", or "harden repo".
Review bash scripts for CI/CD reliability issues. Use when writing or reviewing shell scripts that run in GitHub Actions or other CI environments to catch silent failure patterns, missing error propagation, and environment assumptions.
Diagnose skill DELIVERY health for the current session: name the surface, diff the expected set in skills.lock against what actually loaded (the session's own skill listing, ~/.claude/skills/, the account synced/manifest.json, claude plugin list), attribute every skill to the registry and bundle it came from by reading the bootstrap hook's own install record rather than guessing, and flag silent shadowing, account-store staleness, dangling payload references, and always-on context cost. Reports only — it never installs, copies, deletes or repairs anything. Use when a skill you expected is missing or won't trigger, when a repo-owned skill looks overridden, when the session-start skills: verdict reads DEGRADED, when you need to know where a skill came from or whether the hook installed it, or when the user says "why didn't that skill load", "which skills do I actually have", "is my registry stale", "audit my skills", "skills doctor".
Audit GitHub Actions workflows for salient-path conditionals — every workflow that triggers on pull_request or push must filter on the files and directories its steps actually depend on, and skip with success when nothing salient changed. Use when adding a new workflow, modifying an existing one's steps, renaming/moving files a workflow depends on, or when a CI bill spike points at workflows running on irrelevant changes.
Write a lightweight Nygard-style Architecture Decision Record under docs/decisions/ when a non-obvious decision needs context that won't fit in a code comment and would rot if left only in a PR description. Trigger when the user asks "should I document this", "add an ADR", "why did we do X" referring to a past choice with no comment trail, or when you find yourself drafting a multi-paragraph PR description justifying a one-line change. Also covers the bootstrap case (creating docs/decisions/README.md + the first ADR from scratch) if the folder doesn't exist yet.