## Proposal I would like to contribute an Agent Skill, `gitlab-org-contribution`, to this repository as a **synced skill**, with its source of truth in a public personal-namespace repository. Before I open any MR, I want to check that you are comfortable mirroring an externally hosted SSoT, since both synced entries today (`postgresai`, and `gitlab-backport` since !189) track first-party `gitlab-org/gitlab` sources. ## What the skill is `gitlab-org-contribution` is a community-contributor playbook for sending merge requests and issues to GitLab's own projects on gitlab.com (`gitlab-org/*`, the public `gitlab-com/*` groups, components). It covers the path a community contributor actually walks: the contributor platform and the community forks; what gitlab-bot, Danger and GitLab Duo Code Review do on a community MR and which of their notes need an answer; commit, changelog and MR conventions where they are linted; getting a reviewer and staying out of the automatic inactivity close; documentation contributions; and why community MRs get closed, read from several hundred closed MRs. Every rule cites public evidence and says whether it is enforced, documented, or observed. It is an independent community resource, not official GitLab guidance; where it differs from a project's own `CONTRIBUTING.md` or `AGENTS.md`, those win. It names no individuals. ## Source - SSoT: [https://gitlab.com/jmrp/gitlab-org-contribution-skill](https://gitlab.com/jmrp/gitlab-org-contribution-skill) (public), MIT. The skill lives at `skills/gitlab-org-contribution/` (`SKILL.md` plus `references/`). - It passes this repository's convention suite when placed under `skills/gitlab-org-contribution/`: frontmatter (`name` matching the directory, plus `description`, `version`, `license`), skill-length, content-quality with zero broken links, the distribution validators and the version-bump check, and `bin/sync-skill` reports it in sync. I ran every check `bin/ci-checks` runs, and content-quality, on its latest release, v0.6.0, added to `main` at 1f49aff3 together with what `bin/distribute-skill` and the auto-fix steps generate; all of them pass, and the length check notes `SKILL.md` at 101 lines, one over its 100-line target. The skill carries a semver `version` bumped on every change and is released from a tag with release notes, and the repository root carries an `UPDATING.md` describing the drift-check procedure its `sources.json` drives. - Its triggering and answer quality were measured with a public, provider-neutral evaluation lab, [https://github.com/jmrplens/skill-eval-lab](https://github.com/jmrplens/skill-eval-lab) (mirror `https://gitlab.com/jmrp/skill-eval-lab`): whether the skill loads on the prompts it should and stays off the ones it should not, and whether it improves the model's answer, measured across several model providers. It is an independent tool you are welcome to point at any skill. ## The question `scripts/sync_external_skills.py` reads any `source_project` over `glab api` and does not restrict the namespace, so a public personal-namespace source is handled the same as an internal one; the only hard requirement I can see is that the source be public, which it is. Are you comfortable adding a synced entry whose SSoT lives in a personal namespace and is mirrored read-only through the existing mechanism? If yes, it takes two MRs rather than one, the way `postgresai` (!146, then !152) and `gitlab-backport` (!184, then !189) came in: 1. An MR from the New Skill template that adds the skill at its latest release as an ordinary skill, with what `bin/distribute-skill` and `lefthook run auto-fix` generate. 2. Once that is merged, an MR adding this entry under `skills:` in `synced-skills.yml`, and its row in `doc/synced-skills.md`: ```yaml gitlab-org-contribution: source_project: jmrp/gitlab-org-contribution-skill source_path: skills/gitlab-org-contribution source_ref: main mode: mr ``` One MR cannot do both. `guard-synced-skills` reads the manifest from the MR itself and fails the MR when it changes a listed directory: run on both shapes, a single MR with the directory and the entry failed on all 48 files of the skill, and each of the two MRs passed. And the sync job runs only the auto-fix steps, which do not include `bin/distribute-skill`, so a skill that arrived through the sync alone would have no `.agents/skills` or `.opencode/skills` link, no Claude Code plugin and no `marketplace.json` entry. After the second MR, the first sync would find nothing to change as long as the source's `main` is at the release tag, as it is now; with `mode: mr`, every later change reaches this repository only as the sync bot's MR, which a maintainer reviews and merges. ## Out of scope: the Duo CLI plugin marketplace For context only, not part of this request: landing the skill here does not surface it in the GitLab Duo CLI plugin marketplace (`gitlab-org/ai/gitlab-duo-plugins`). That repository is not connected to this one, vendors each plugin in-repo under `plugins/`, and its validator rejects external sources, so reaching it would be a separate, later MR that copies the skill into a `plugins/gitlab-org-contribution/` package. I mention it only so the scope here is clear.