fleet-onboarding

Fleet onboarding

You are running this skill once, when the factory is first being adopted across the OgenticAI fleet. It is the bulk counterpart to repo-bootstrap (one repo) and project-planner (one project). Use it the day the factory goes live and never again.

After this run, growth happens organically: new repos via repo-create, new projects via project-planner, day-to-day work via feature-factory.

§0 — Pre-flight (always run first)

Before anything else, invoke the setup-check skill. It verifies that:

• gh CLI is authenticated as davidoladeji-ogenticai (the org-admin account)
• The local git author email is an OgenticAI identity
• The SSH key for OgenticAI plugin pushes is present
• The current branch is sensible for this run

setup-check is fast (~1s) and halts with the exact fix if anything is off. If the operator sets OGENTICAI_BYPASS_IDENTITY=1, it short-circuits — only use that when the operator explicitly authorises it in chat. See CLAUDE-FACTORY.md §F5 for the full identity contract.

When to invoke this skill

The operator said:

• "Get all our current projects and repos on board"
• "Onboard the fleet"
• "Run the factory across everything we already have"
• "Bulk-install the factory"

If the operator only wants one repo onboarded → use repo-bootstrap. If they only want one project shaped → use project-planner.

What this skill does in one paragraph

It runs in three phases — Discover, Confirm, Apply — with one approval gate at the end of Confirm. It pulls the current state from GitHub (OgenticAI/* repos) and Linear (OGE team — projects, labels, active issues). It maps each repo to its primary Linear project and surfaces orphan projects (Linear projects with no corresponding repo) so the operator can decide which deserve a fresh codebase. It ensures the factory labels exist on the OGE team. It opens one PR per repo to install the factory (never pushes to main directly). For every orphan project approved as needs-repo, it chains into repo-create and then repo-bootstrap. It writes a single registry update PR on the agent-factory repo with primary_project filled in for every onboarded repo (existing and newly-created). It then prints a fleet dashboard.

Phase 1 — Discover (read-only, no side effects)

Print a header to chat: Discovering the fleet — read-only…

1.1 Repos

• Call gh repo list OgenticAI --limit 200 --json name,description,visibility,defaultBranchRef,isArchived,updatedAt,primaryLanguage.
• Filter out: isArchived=true repos, repos whose updatedAt is older than 12 months and have <5 commits in the last year (treat as dormant — report separately, do not onboard).
• For each active repo:
  • Check for existing CLAUDE.md at root (gh api repos/OgenticAI/<name>/contents/CLAUDE.md — 404 means no).
  • Check for existing .claude/ directory (look for .claude/CLAUDE-FACTORY.md — 404 means no).
  • Classify: clean (no CLAUDE.md, no .claude/), existing-claude-md (has CLAUDE.md, no .claude/), partial-factory (has either .claude/CLAUDE-FACTORY.md or .claude/agents/), fully-onboarded (has both CLAUDE-FACTORY.md AND agents/).
• Cross-check against kit/.claude/registry/repos.yml: list any repo in the org but NOT in the registry, and any repo in the registry but NOT in the org.

1.2 Linear projects

• Call linear.list_projects(team="OGE", state in ["Planned","Started","Paused"]). Skip projects in Completed, Cancelled, Archived.
• For each project, count active issues (state in [Backlog, Triage, Todo, "In Progress", "In Review"]).
• Flag projects with zero active issues and no updates in 60 days — likely dormant, surface separately.

1.3 Labels

• Call linear.list_issue_labels(team="OGE").
• Check for each required factory label:
  • factory-in-progress
  • needs-story-approval
  • needs-brief-approval
  • building
  • validator-blocked
  • security-blocked
  • compliance-blocked
  • cross-repo
  • from-validator
  • from-security
  • from-compliance
  • from-project-planner
  • from-factory
• Build a list of missing_labels to create in Phase 3.

1.4a Orphan projects (Linear without a repo)

After §1.1 + §1.2, compute the inverse map: which Linear projects in §1.2 don't appear as a primary_project candidate for any active repo in §1.1?

For each orphan project:

• Read its description + last 20 issues' titles.
• Classify it as one of:
  • code-shaped — issues mention features, endpoints, services, UI, builds. Suggests there should be a repo.
  • ops-or-research — issues are research notes, vendor evaluations, hiring threads, ops checklists. Code-less by design; do NOT create a repo.
  • existing-but-unmapped — issues clearly reference one of the existing repos by name. Suggest mapping instead of creating.

Hold this set for Phase 2.

1.4 Output — the discovery dashboard

Post this to chat (use mono spacing, one row per repo):

FLEET DISCOVERY
============================================================
GitHub:  <N> active repos in OgenticAI/  ·  <M> archived/dormant (skipped)
Linear:  <P> active projects in OGE team ·  <Q> dormant (separate list)
Labels:  <K> of 13 factory labels missing (will create in Apply)

REPOS — current state vs. factory
----------------------------------------------------------------
NAME                       STATE                  STACK         OWNER
ogentic-audit              clean                  rust-lib      David
agent-reviewer             existing-claude-md     nextjs-ts     David
sotto-desktop              partial-factory        tauri-rust    David
agent-knowledge            existing-claude-md     fastapi-py    David
…
zashboard-ultimate         clean                  nextjs-ts     David
----------------------------------------------------------------
<TOTALS>:  clean: N1  ·  existing-claude-md: N2  ·  partial-factory: N3  ·  fully-onboarded: N4

LINEAR PROJECTS (active)
----------------------------------------------------------------
NAME                              STATE      ISSUES   LAST UPDATE
Agent DealSizer v3                Started      42       2 days ago
Covenant Monitor pilot            Started      18       1 day ago
Ogentic-Audit OSS Wave 1          Planned       7       5 days ago
…
----------------------------------------------------------------

REGISTRY DRIFT
----------------------------------------------------------------
In GitHub but NOT in kit/.claude/registry/repos.yml:
  - <repo>      (will add)
In registry but NOT in GitHub:
  - <repo>      (will remove; archived? deleted?)
----------------------------------------------------------------

DORMANT (skipped — surface only)
----------------------------------------------------------------
Repos:    <list>      Linear projects:  <list>

ORPHAN PROJECTS (active in Linear, no repo mapping)
----------------------------------------------------------------
NAME                              CLASSIFICATION         ACTIVE ISSUES
Therapy onboarding rebuild        code-shaped                  6
Quarterly partner research        ops-or-research              4
DealSizer mobile prototype        code-shaped                  3
Audit OSS extraction              code-shaped                  2
Hiring — Q3 senior backend        ops-or-research              5
DealSizer pricing refresh         existing-but-unmapped (agent-dealsizer)   3
----------------------------------------------------------------

Halt here. Do not advance.

Phase 2 — Confirm (operator approves the mapping)

For each active repo, propose its primary_project based on:

1. Name similarity (e.g., agent-knowledge → "Knowledge Agent" project, agent-reviewer → "Reviewer Agent" project).
2. Active-issue keyword overlap (call linear.list_issues(project=<p>, limit=50) and check repo name occurrences in titles).
3. Falls back to operator decision if ambiguous.

Post a single mapping table:

PROPOSED REPO → PRIMARY PROJECT MAPPING
============================================================
REPO                          →  LINEAR PROJECT                          CONFIDENCE
ogentic-audit                 →  Ogentic-Audit OSS Wave 1                high
agent-reviewer                →  Agent Reviewer                          high
agent-knowledge               →  Agent Knowledge                         medium  ← ambiguous, two candidates
sotto-desktop                 →  Sotto Desktop pilot                     high
zashboard-ultimate            →  Internal Ops                            low    ← guessed, please confirm
…
============================================================

PROPOSED FACTORY-LABEL CREATIONS (on OGE team)
- factory-in-progress  (#7C3AED)
- needs-story-approval (#F59E0B)
- needs-brief-approval (#F59E0B)
- building             (#3B82F6)
- validator-blocked    (#DC2626)
- security-blocked     (#DC2626)
- compliance-blocked   (#DC2626)
- cross-repo           (#475569)
- from-validator       (#94A3B8)
- from-security        (#94A3B8)
- from-compliance      (#94A3B8)
- from-project-planner (#94A3B8)
- from-factory         (#94A3B8)
(labels already present are omitted)

PROPOSED ORPHAN-PROJECT ACTIONS
----------------------------------------------------------------
ORPHAN                              SUGGESTED ACTION                              CONFIDENCE
Therapy onboarding rebuild          A. repo-create → new repo `therapy-onboarding`     high
DealSizer mobile prototype          A. repo-create → new repo `dealsizer-mobile`       high
Audit OSS extraction                A. repo-create → new repo `audit-rs` (oss-library) medium
DealSizer pricing refresh           B. map to existing repo `agent-dealsizer`          high
Quarterly partner research          C. leave as ops-only project (no repo)             —
Hiring — Q3 senior backend          C. leave as ops-only project (no repo)             —
--------------------------------------------------------

---

*Content truncated.*