菜单
Onboard workflow skill. Use this skill when a repository handoff, maintainer transition, or first-contribution onboarding effort must preserve upstream workflow, copied support files, provenance, access expectations, and review safety before merge or transfer.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/diegosouzapw/awesome-omni-skills --skill git-pr-workflows-onboard-v2命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Daily Gift workflow skill. Use this skill when the user needs Relationship-aware daily gift engine with five-stage creative pipeline — editorial judgment, synthesis, concept generation, visual strategy, and rendering in H5, image, or video and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off.
Daily Gift workflow skill. Use this skill when the user needs Relationship-aware daily gift engine with five-stage creative pipeline — editorial judgment, synthesis, concept generation, visual strategy, and rendering in H5, image, or video and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off.
High-Agency Frontend Skill workflow skill. Use this skill when the user needs building high-agency frontend interfaces with strict design taste, calibrated color, responsive layout, and motion rules and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off.
基于 SOC 职业分类
| name | git-pr-workflows-onboard-v2 |
| description | Onboard workflow skill. Use this skill when a repository handoff, maintainer transition, or first-contribution onboarding effort must preserve upstream workflow, copied support files, provenance, access expectations, and review safety before merge or transfer. |
| version | 0.0.1 |
| category | devops |
| tags | ["git-pr-workflows-onboard-v2","onboarding","knowledge-transfer","repository-governance","handoff","pr-workflow","provenance","access-review","omni-enhanced"] |
| complexity | advanced |
| risk | caution |
| tools | ["codex-cli","claude-code","cursor","gemini-cli","opencode"] |
| source | omni-team |
| author | Omni Skills Team |
| license | Unknown |
| date_added | 2026-04-16 |
| date_updated | 2026-05-10 |
| source_type | omni-curated |
| maintainer | Omni Skills Team |
| family_id | git-pr-workflows-onboard-v2 |
| family_name | Onboard |
| variant_id | omni |
| variant_label | Omni Curated |
| is_default_variant | true |
| derived_from | skills/git-pr-workflows-onboard-v2 |
| upstream_skill | skills/git-pr-workflows-onboard-v2 |
| upstream_author | sickn33 |
| upstream_source | community |
| upstream_pr | 271 |
| upstream_head_repo | diegosouzapw/awesome-omni-skills |
| upstream_head_sha | 93ab394af5645f7127d5003ee02c9566ae5353cd |
| curation_surface | skills_omni |
| enhanced_origin | omni-skills-private |
| source_repo | diegosouzapw/awesome-omni-skills |
| replaces | ["git-pr-workflows-onboard-v2"] |
This skill preserves the intent of the upstream onboarding workflow while making it operational for repository-based DevOps, engineering handoff, and first-contribution work.
Use it when a new contributor, maintainer, reviewer, or inheriting team must become productive without losing repository context, workflow provenance, copied support files, or review safety.
This is not a generic employee welcome checklist. It is a review-oriented onboarding workflow for repositories, infrastructure, and delivery systems where access, ownership, environment setup, and handoff completeness must be checked before merge or transfer.
Activate this skill when most of the following are true:
Do not use this skill as the primary workflow when:
Confirm onboarding scope and success criteria
Inventory artifacts and preserve provenance
ORIGIN.md, metadata.json, imported notes, or copied examples.Check repository governance and access expectations
Validate local or reproducible setup path
Map the first safe contribution or review path
Create the handoff package
Run a readiness review before merge or transfer
references/review-criteria.md before declaring the handoff complete.Input
Repository: infra-deploy
Scenario: Original maintainer is leaving. New maintainer must review PRs and supervise releases.
Known materials: README, CONTRIBUTING.md, .github/PULL_REQUEST_TEMPLATE.md, CODEOWNERS, devcontainer.json
Problem: Release authority is unclear and local setup only works on one existing maintainer's laptop.
Expected output
Handoff summary:
- Scope: Maintainer transition for infra-deploy
- Provenance preserved: upstream README, CONTRIBUTING, PR template, CODEOWNERS, devcontainer config
- Ownership findings: CODEOWNERS covers app/, but release tagging authority is undocumented
- Access findings: new maintainer can review PRs but cannot access release secrets
- Setup findings: dev container exists but was not verified against current branch; local manual setup is incomplete
- First safe task: review and merge a docs-only PR using existing template and required checks
- Blockers: release authority owner unknown; secret access pending; setup validation needed
- Recommendation: do not transfer release responsibility until bootstrap and secret-access path are verified
Input
Repository: service-api
Scenario: New contributor must make a small bug fix and open a compliant PR.
Known materials: CONTRIBUTING.md, issue template, CI checks
Problem: Contributor can clone the repo but does not know branch naming, test scope, or reviewers.
Expected output
Onboarding summary:
- Scope: first safe contribution
- Workflow: create feature branch, run unit tests, open PR with template, request review from API owners
- Governance: CI checks required before merge; CODEOWNERS routes review to backend team
- Setup status: local bootstrap works; test command verified
- First task: fix a labeled good-first-issue in request validation
- Open questions: none blocking first PR
For a longer worked review with good and bad outcomes, open examples/review-example.md.
Do preserve provenance. Keep a clear line between imported upstream material and local edits.
Do define a minimum successful outcome. “Finish onboarding” is vague; “new reviewer can approve a low-risk PR safely” is testable.
Do verify ownership paths. If review, release, or environment ownership is unclear, treat that as a handoff risk.
Do prefer reproducible setup. Use documented local setup, containers, or dev containers when available.
Do choose a bounded first task. The first task should exercise the workflow without requiring broad production authority.
Do stop and escalate on missing permissions. Record the missing access and the responsible owner instead of suggesting workarounds.
Do link to source artifacts. Point operators to the exact files that govern contribution and review behavior.
Do not rewrite the upstream process unless the request explicitly includes process redesign.
Do not hide uncertainty. Missing reviewers, stale docs, or unverified setup should remain visible in the handoff.
Do not assume merge or deployment rights. Verify them explicitly.
Do not compress setup validation into “works on my machine.” Capture the tested path and its limits.
Do not assign ownership without evidence from repository controls or existing practice.
Symptoms: The new contributor can clone the repository but cannot determine who must review the PR.
Solution: Check CODEOWNERS, PR templates, repository rules, team docs, and recent merged PRs. If routing is still ambiguous, document the gap as an onboarding blocker and identify the maintainer who must confirm reviewer ownership.
Symptoms: Setup instructions exist, but the environment fails to start or differs from current CI behavior.
Solution: Prefer the documented reproducible path such as a dev container or containerized bootstrap if one exists. Record the exact failing step, expected result, and branch used for validation. Do not invent missing environment variables or secret values.
Symptoms: The onboarded person can review code but cannot complete merge or release tasks.
Solution: Separate review capability from merge or release authority in the handoff summary. List the exact missing permission, the governing control, and the owner required to grant access.
Symptoms: Handoff notes are long, but reviewers still do not know what changed from upstream.
Solution: Add a concise provenance section that distinguishes preserved upstream artifacts from local curation, unresolved gaps, and newly added instructions.
Symptoms: The first task is too large or touches sensitive systems.
Solution: Reduce the task to a narrow, observable change that still exercises the target workflow, such as docs, tests, or a low-risk bug fix with standard review checks.
references/review-criteria.md — Open this when you need a compact review checklist for access, ownership, provenance, setup validation, and handoff completeness.examples/review-example.md — Open this when you need a worked example showing strong versus weak onboarding review outcomes.No confirmed related local skills were provided in the source context.