agentleFS
Sign inStart free
issue-orchestratorissue-orchestrator/issue-orchestrator/.claude/skills/onboarding/SKILL.md

onboarding

Skill10 starsChanged 2 months agoApache-2.0View on GitHub

Guide a user or AI agent through first-time issue-orchestrator onboarding for a target repository. Use when setting up a brand-new repo, onboarding an existing repo, validating the first issue flow, or enabling the E2E runner on a real repo.

100 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use paywalls, popups and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • CesarjoquinSkill

    paywalls

    When the user wants to create or optimize in-app paywalls, upgrade screens, upsell modals, or feature gates. Also use when the user mentions "paywall," "upgrade screen," "upgrade modal," "upsell," "feature gate," "convert free to paid," "freemium conversion," "trial expiration screen," "limit reached screen," "plan upgrade prompt," "in-app pricing," "free users won't upgrade," "trial to paid conversion," or "how do I get users to pay." Use this for any in-product moment where you're asking users to upgrade. Distinct from public pricing pages (see cro) — this focuses on in-product upgrade moments where the user has already experienced value. For pricing decisions, see pricing.

    Also in 19 projects that use this

  • CesarjoquinSkill

    popups

    When the user wants to create or optimize popups, modals, overlays, slide-ins, or banners for conversion purposes. Also use when the user mentions "exit intent," "popup conversions," "modal optimization," "lead capture popup," "email popup," "announcement banner," "overlay," "collect emails with a popup," "exit popup," "scroll trigger," "sticky bar," or "notification bar." Use this for any overlay or interrupt-style conversion element. For forms outside of popups, see cro. For general page conversion optimization, see cro.

    Also in 18 projects that use this

  • coreyhaines31Skill

    marketing-council

    When the user wants multiple expert perspectives on a marketing question — a simulated board of advisors staffed by legendary marketers (Seth Godin, David Ogilvy, Eugene Schwartz, April Dunford, Rory Sutherland, Alex Hormozi, Byron Sharp, and more). Also use when the user mentions 'marketing council,' 'board of advisors,' 'advisory board,' 'what would Seth Godin say,' 'what would Ogilvy think,' 'channel Hormozi,' 'get multiple perspectives,' 'debate this,' 'have the council review,' 'marketing mentors,' or asks how a famous marketer would approach their problem. The council gives each advisor's take through their documented frameworks, surfaces where they disagree, and synthesizes a recommendation. For executing the winning direction, hand off to positioning, offers, copywriting, ads, or the relevant skill.

    Also in 13 projects that use this

  • roerohanSkill

    prospecting

    When the user wants to find, qualify, and build a list of prospects to reach out to — across B2B SaaS, general B2B, or local small businesses. Also use when the user mentions "prospecting," "build a prospect list," "find prospects," "find leads," "lead gen list," "find SaaS companies that," "find B2B companies," "find local businesses," "ICP-fit accounts," "who should we go after," "outbound list," "target account list," "find clients near me," "businesses without websites," "prospect research," "qualified leads," "find my first customers," "early adopters," "design partners," "beta users," or "who has this problem." Use this for the list-building and qualification phase. For writing the outbound copy after the list is built, see cold-email. For deep competitive research on specific accounts, see competitor-profiling.

    Also in 16 projects that use this

  • roerohanSkill

    emails

    When the user wants to create or optimize an email sequence, drip campaign, automated email flow, or lifecycle email program. Also use when the user mentions "email sequence," "drip campaign," "nurture sequence," "onboarding emails," "welcome sequence," "re-engagement emails," "email automation," "lifecycle emails," "trigger-based emails," "email funnel," "email workflow," "what emails should I send," "welcome series," or "email cadence." Use this for any multi-email automated flow. For cold outreach emails, see cold-email. For in-app onboarding, see onboarding.

    Also in 18 projects that use this

  • +7 more from Cesarjoquin

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 5 are distinctive, and 10 are very specific to this project.

  • 0

    Common

    Most of the 85 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 10

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this skill when the job is "get issue-orchestrator working in this target repo" rather than "change orchestrator code."

    line 8
  2. Distinctive:

    Always follow setup with:

    line 26
  3. Distinctive:

    create or label one trivial GitHub issue with a configured agent label

    line 35
  4. Distinctive:

    If E2E is in scope:

    line 38
  5. Very specific:

    add an e2e: section to config

    line 39
  6. Very specific:

    run the manual E2E API start call with bearer auth and config_name

    line 40
  7. Very specific:

    Prefer a fixed ui.web_port like 8080 for first-run clarity.

    line 45
  8. Very specific:

    Prefer a validation command that actually exists in the target repo.

    line 46
  9. Very specific:

    Treat doctor as mandatory before start, but only after the onboarding files are on the worktree seed ref or worktrees.seed_ref: HEAD is …

    line 48
  10. Very specific:

    If setup fails while creating labels, tell the user to rerun issue-orchestrator doctor.

    line 53
  11. Very specific:

    Prefer codex for the smoothest hands-free first run when it is available.

    line 58
  12. Very specific:

    If the user picks codex, prefer leaving the wizard's model prompt blank so Codex uses its current CLI default.

    line 59
  13. Very specific:

    If the repo is using claude-code, warn that Claude may pause on workspace trust prompts in fresh worktrees.

    line 61
  14. Distinctive:

    If Claude is the only option, call out that the first runtime validation should explicitly check for a stuck trust prompt in the session …

    line 62
  15. Distinctive:

    Stop and surface the exact blocker when:

    line 75

“Common” is measured: kept by at least 6 in 10 of the 85 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Onboarding

Use this skill when the job is "get issue-orchestrator working in this target repo" rather than "change orchestrator code."

Pick the path

  • New repo: no existing issue-orchestrator config, labels, or agent prompts to preserve.
  • Existing repo: there may be real issues, labels, prompts, or config that should survive onboarding.
  • Agent-guided: same repo-state decision as above, but the AI drives the setup and validation hands-free.

Core workflow

  1. Confirm you are in the target repo, not the issue-orchestrator checkout.
  2. Verify prerequisites:
    • issue-orchestrator CLI is available from the shared dev env.
    • GitHub auth works for the target repo.
    • At least one supported AI CLI is installed.
  3. Choose issue-orchestrator setup path:
    • New project - set up from scratch for new repos.
    • Existing project - I have labels/issues already for repos with existing state.
  4. Always follow setup with:
    • issue-orchestrator setup-guardrails
    • issue-orchestrator init
  5. Publish the generated onboarding files to the worktree seed ref before the first issue run:
    • at minimum, the configured prompt files and .issue-orchestrator/config
    • by default this means commit and push them to your default branch
    • for local-only evaluation, set worktrees.seed_ref: HEAD
  6. Run issue-orchestrator doctor
  7. Validate a real first issue:
    • create or label one trivial GitHub issue with a configured agent label
    • run issue-orchestrator start
    • confirm the issue reaches queued or running
  8. If E2E is in scope:
    • add an e2e: section to config
    • run the manual E2E API start call with bearer auth and config_name
    • confirm the run reaches passed or produce the exact failing note

Defaults and guardrails

  • Prefer a fixed ui.web_port like 8080 for first-run clarity.
  • Prefer a validation command that actually exists in the target repo. Do not leave make test in place if the repo does not have it.
  • Existing-project onboarding is incomplete until at least one agent is configured.
  • Treat doctor as mandatory before start, but only after the onboarding files are on the worktree seed ref or worktrees.seed_ref: HEAD is configured.

GitHub auth

  • A token merely existing is not enough; it must access the target repo.
  • If setup fails while creating labels, tell the user to rerun issue-orchestrator doctor.
  • issue-orchestrator auth store is the fallback when a local token needs to live in keychain storage.

AI CLI guidance

  • Prefer codex for the smoothest hands-free first run when it is available.
  • If the user picks codex, prefer leaving the wizard's model prompt blank so Codex uses its current CLI default.
  • For agent-guided runs, prefer scripted stdin for issue-orchestrator setup instead of leaving the wizard interactive. Nested interactive CLIs are a common failure mode for both Codex and Claude-style agents.
  • If the repo is using claude-code, warn that Claude may pause on workspace trust prompts in fresh worktrees.
  • If Claude is the only option, call out that the first runtime validation should explicitly check for a stuck trust prompt in the session recording.

E2E specifics

  • The control API requires:
    • bearer auth from ~/.issue-orchestrator/api-token
    • repo_root
    • config_name such as default.yaml
  • Repos without uv.lock are valid.
  • Repos whose synced env lacks pytest are still valid; the E2E worktree bootstraps a fallback pytest>=8.0.

When to stop and report

Stop and surface the exact blocker when:

  • GitHub auth cannot access the repo
  • the selected AI CLI is missing
  • doctor still returns errors after setup
  • the first issue never leaves queued
  • E2E cannot start or finishes with status=error

Report findings in three buckets:

  • setup/docs drift
  • runtime UX
  • agent-guided opportunities

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free