Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/ducksss/codex-profiles/github-lead-gennpx skills add Ducksss/codex-profiles --skill github-lead-gengit clone --depth 1 https://github.com/Ducksss/codex-profilesWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00040 | $0.00938 |
| Opus 5 | $0.00020 | $0.00469 |
| Sonnet 5 | $0.00008 | $0.00188 |
| Haiku 4.5 | $0.00004 | $0.00094 |
Grade A, and why
github-lead-gen scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 104 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub Lead Gen
Purpose
Find GitHub repository candidates for codex-profiles, dedupe them against
Airtable, and hand them off for later qualification. This skill only handles
candidate discovery and shallow intake.
Required Context
Before searching, read current product positioning from README.md, policy
gates from LAUNCH.md, and live distribution state from the Airtable tracker.
Load references/search-patterns.md for approved search lanes and example
queries.
Boundaries
- Create or update Airtable
Targetsonly. - Dedupe against existing Airtable targets before creating records.
- Use
Log.Workflow = github-lead-genfor every meaningful intake decision. - Set
Next Action = Run lead qualificationon every accepted candidate. - Record only a shallow candidate reason; do not assign final ICP.
- Do not draft PRs, issues, comments, emails, DMs, forum posts, or listing submissions.
- Do not contact externally.
- Do not change
LAUNCH.mdunless the user explicitly asks for a repo-local handoff.
Accepted Input
- A new repository candidate with no matching Airtable target, or an existing target that needs shallow lead-generation evidence refreshed.
- Do not overwrite a qualified or submitted target's
Status, ICP decision, or phase-specificNext Action. - Every accepted new target leaves this phase as
Status = BacklogandNext Action = Run lead qualification.
Tracker Protocol
Create one unique run-<UTC-timestamp>-<random-suffix> value and use it as
<run-id> for the whole invocation. Start with the complete ledger:
node scripts/outreach-tracker.mjs list --json
For an existing target, claim it before changing fields. For a new target, atomically create the shallow row first, then claim it before adding evidence or logging the handoff:
node scripts/outreach-tracker.mjs upsert <key> --name "<name>" \
--channel "<channel>" --status Backlog \
--next-action "Run lead qualification" --notes "<candidate reason and source>"
node scripts/outreach-tracker.mjs claim <key> --by <run-id>
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 104 lines · 40 tokens per session scan A 7e5675e1bb53
github-lead-gen is a skill published in the GitHub repository Ducksss/codex-profiles (108 stars, last pushed 2d ago), licensed MIT. It adds 40 tokens to every session and 938 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
claude-api
Build, debug, and optimize Claude API / Anthropic SDK apps. Apps built with this skill should include prompt caching. Also handles migrating existing Claude API code between Claude model versions (4.5 → 4.6, 4.6 → 4.7, retired-model replacements). TRIGGER when: code imports anthropic/@anthropic-ai/sdk; user asks for…
create-skill
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
contacts
Manage contacts, communication channels, access control, and invite links.
gmail
Manage Gmail email — drafting, sending, organizing, filters, vacation replies, and inbox analysis.
gui-integration-test
GUI desktop app only. Writes, runs, and debugs Warp integration tests using the custom Builder/TestStep framework in crates/integration. Use when adding a new integration test, fixing a failing integration test, wiring a test into the manual runner or nextest suite, or verifying end-to-end UI and terminal behavior in…
gui-onboarding-verification-skill
GUI desktop app only. Launch two parallel Oz cloud agents with computer use to download and install the latest stable Linux Warp build, capture screenshots while walking through first-time onboarding in both logged-out and logged-in states, then selectively fan out follow-up cloud agents for distinct onboarding…