ducksss / github-lead-gen
Use when running GitHub lead generation for codex-profiles. Finds repository candidates and performs shallow tracker intake before lead qualification. Not for drafting, outreach, or monitoring.
GitHub Lead Gen
Purpose
Find GitHub repository candidates for codex-profiles, dedupe them against
the outreach tracker, 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 ops/outreach/launch.md, and live distribution state from the
outreach tracker.
Load references/search-patterns.md for approved search lanes and example
queries.
Boundaries
- Create or update tracker
Targetsonly. - Dedupe against existing tracker 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
ops/outreach/launch.mdunless the user explicitly asks for a
repo-local handoff.
Accepted Input
A new repository candidate with no matching tracker 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 --jsonFor 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>If claim exits 3, skip the target without writing or contacting externally.
After a successful claim, record the stable phase label and always release,
including on failure:
node scripts/outreach-tracker.mjs log --target <key> \
--workflow github-lead-gen --action Rechecked \
--result "Candidate captured for lead qualification" --link "<evidence-url>"
node scripts/outreach-tracker.mjs release <key> --by <run-id>Workflow
- Search GitHub using the approved lanes in
references/search-patterns.md. Keep repository-first candidates only; ignore startup, funding, event, and
social-only surfaces.For each candidate, capture the repository URL, likely channel, shallow
reason, evidence URL, and duplicate key.Search tracker
Targetsby deterministic key and repository URL using the
tracker; do not maintain a side ledger.If an existing target is found, update only stale lead-gen fields and append
agithub-lead-genlog entry.If no target exists, create a
Targetsrecord with:Key: deterministic slug such asgh-owner-repo,awesome-owner-repo, orif-owner-repo.Channel: best existing lead-gen channel, usuallyAwesome-List PR,Issue-First,Directory,Web, orManual/Gated.Status:Backlogonly for plausible repository leads awaiting
qualification; otherwise skip.Priority: leave blank unless the repository is obviously Codex-specific.Next Action:Run lead qualification.Notes: shallow candidate reason and source query.
- Stop after tracker intake. The next workflow is lead qualification.
Output
Return a concise handoff:
- Candidates added.
- Existing targets updated.
- Duplicates skipped.
- Search lanes tried.
- Any tracker or GitHub access blockers.