Qcom skills contribute

Skill qualcomm-linux/qcom-linux-skills/skills/qcom-skills-contribute

Turn local edits to an installed qcom-linux-skills skill into an upstream contribution: find the catalog clone behind the installed skill, validate the change, create a topic branch with a DCO-signed meta-qcom-style commit, and prepare (optionally open) the pull request. Use when asked to "upstream my skill changes", "propose this skill change back", "send my skill fix as a PR", or "contribute this skill improvement to the catalog". Only for changes to skills from this catalog; do NOT use for pull requests to meta-qcom or other target repositories (prepare those with qcom-yocto-pre-pr-checks).From its SKILL.md

Install

npx -y skills add qualcomm-linux/qcom-linux-skills --skill qcom-skills-contribute

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.0 KB, as published. Nobody here has run it

qcom-skills-contribute

Packages local modifications to an installed qcom-linux-skills skill into a DCO-signed commit on a topic branch, following the catalog's CONTRIBUTING.md conventions, and stops before push unless explicitly asked to open the pull request.

This works because the default install is a symlink: an installed skill under ~/.claude/skills/, ~/.codex/skills/ or ~/.cursor/skills/ points back into the git clone, so editing the installed skill is editing a branchable work tree. Copy installs are handled by a fallback that clones upstream into a temporary directory and transplants the modified skill.

When to use

After improving an installed skill locally (fixing a step, adding a board or machine, clarifying instructions) and the change is worth sharing upstream.
To convert an agent-authored skill fix into a well-formed PR without hand-running the fork/branch/sign-off mechanics.

Prerequisites

git with user.name and user.email configured (used verbatim for the Signed-off-by trailer — never fabricate an identity).
gh (GitHub CLI), authenticated, only for the optional --pr step.
The modified skill installed via symlink (preferred), via copy, or a local clone passed with --repo-dir.

Instructions

Identify the modified skill and review the diff before doing anything else. For a symlink install:
```
clone="$(dirname "$(dirname "$(readlink -f ~/.claude/skills/<skill-name>)")")"
git -C "$clone" status --porcelain -- skills/<skill-name>
git -C "$clone" diff -- skills/<skill-name>
```
Summarize the change to the user and confirm it is intended for upstream (local site-specific tweaks, credentials, or lab paths must never be upstreamed).
Write the commit body to a temporary file: plain-English prose wrapped at ~72 columns that first explains the problem (why the change is needed), then the imperative actions taken. Do not restate the diff.
Run the helper from this skill's directory (paths are relative to the skill):
```
scripts/contribute.sh <skill-name> \
  --summary "one-line summary for the subject" \
  --body-file /tmp/commit-body.txt \
  --assisted-by "AGENT_NAME:MODEL_VERSION"
```
The script locates the clone, shows the changes, runs the catalog checks (shellcheck, python compile, install.sh self-verification), creates a contribute/<skill-name> topic branch, and makes the DCO-signed commit with the trailers in the required order. It stops before push.
Verify the commit it reports: subject skills/<name>: summary, why-first body, Assisted-by: before Signed-off-by:, and only the intended files staged.
Ask the user before publishing anything. Only with their explicit go-ahead, rerun with --pr (add --yes when running without a tty) to fork, push the branch, and open the pull request against main.

Output format

Report to the user:

Skill:   <skill-name>
Clone:   <path to the catalog clone>   (symlink | copy-fallback)
Checks:  PASS | FAIL (<which check failed>)
Commit:  <abbrev-sha> skills/<name>: <summary>  on branch <branch>
PR:      not pushed (stopped before push) | <pull request URL>

Error handling

No changes found: the script fails with "nothing to contribute" — confirm the right skill name and that the edit landed in the installed location.
Checks fail: fix the reported shellcheck/python/install issues and rerun; only use --skip-checks when explicitly asked to.
Copy install: the fallback clones upstream and transplants the skill; the resulting diff can include upstream drift — re-review the diff (step 1) inside the temporary clone before committing.
Changes outside the skill: the script warns and excludes them; contribute them separately (one logical change per commit).

Notes

Non-destructive by default: nothing is pushed and no PR is opened without --pr, and --pr asks for confirmation.
One skill, one commit, one PR — matching the catalog's atomic-commit convention. For changes spanning several skills, run once per skill.
The Signed-off-by identity always comes from git config; the DCO sign-off is the user's attestation, which is why step 5 requires their explicit approval.