osscontributing
Use when: writing or reviewing OSS contributing guidance, CONTRIBUTING.md structure, DCO/CLA guidance, or contributor onboarding checklists.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when: writing or reviewing OSS contributing guidance, CONTRIBUTING.md structure, DCO/CLA guidance, or contributor onboarding checklists.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when: reviewing .prompt.md, .agent.md, SKILL.md, or .instructions.md files for contradictions, ambiguity, persona consistency, cognitive load, coverage gaps, and composition conflicts.
Use when: checking xanadAssistant workspace health, install status, repair reasons, or lockfile validity before proposing install, update, repair, or restore operations.
Use when: designing or reviewing CI/CD pipelines, GitHub Actions, stage design, environment gates, or artifact discipline.
Use when: writing or reviewing Dockerfiles, container images, multi-stage builds, layer caching, or image security.
Use when: writing or reviewing Infrastructure as Code for naming, state management, modularity, and drift detection.
Use when: reviewing DevOps changes for pipeline safety, secret hygiene, permissions, rollback, and deployment risk.
| name | ossContributing |
| description | Use when: writing or reviewing OSS contributing guidance, CONTRIBUTING.md structure, DCO/CLA guidance, or contributor onboarding checklists. |
| type | reference |
| version | 1.0 |
| license | MIT |
Skill metadata: version "1.0"; tags [oss, contributing, dco]; recommended tools [].
Use this skill when a user asks about contribution workflows, CONTRIBUTING.md structure, or how to prepare a first contribution to an open-source project.
ossCodeReviewossLicensingA complete CONTRIBUTING.md should cover these sections in order:
| Section | Required | Purpose |
|---|---|---|
| Code of Conduct reference | Yes | Link to CODE_OF_CONDUCT.md or inline CoC |
| Getting started | Yes | Fork, clone, branch naming, local setup |
| Development workflow | Yes | How to build, test, lint before opening a PR |
| Commit message format | Yes | Conventional Commits or project-specific format |
| Pull request checklist | Yes | What a PR must include before review |
| DCO / CLA | If applicable | Sign-off requirement or contributor license |
| Release process | Recommended | How maintainers tag and publish releases |
| Issue reporting | Recommended | Bug report template link, reproduction steps expectation |
feat/<short-description>
fix/<issue-number>-<short-description>
docs/<topic>
chore/<task>
If the project uses DCO instead of a CLA, every commit must include a sign-off line:
Signed-off-by: Name <email@example.com>
Add it automatically with: git commit --signoff
Verify with: git log -n 5 --pretty=full — confirm each commit message body includes a Signed-off-by: trailer.
## [Unreleased]git remote add upstream <project-url> to track the source.git checkout -b feat/my-change.main or develop).