skills/ios-libs-contribute/SKILL.md
Contribute a client-discovered fix or improvement back to the configured iOS library repo from an ios_app tusk project.
npx skillsauth add gioe/tusk ios-libs-contributeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Open a pull request against the iOS library repo configured by the current tusk client project, while keeping the upstream work linked to the originating local task. Use a fork-based PR by default because most client projects will not have direct push access to the shared library repo.
Determine the local task that surfaced the library change:
/ios-libs-contribute <id>, use that task ID.TASK_ID=$(tusk branch-parse | python3 -c 'import json,sys; print(json.load(sys.stdin).get("task_id") or "")')
Fetch the task:
tusk task-get "$TASK_ID"
Record task.summary for the PR body and progress note.
Never hard-code the library repo. Read it from project_libs.<project_type>.repo:
PROJECT_TYPE=$(tusk config project_type)
LIB_REPO=$(tusk config "project_libs.${PROJECT_TYPE}.repo")
LIB_REF=$(tusk config "project_libs.${PROJECT_TYPE}.ref")
Validate:
PROJECT_TYPE is not ios_app, stop with: /ios-libs-contribute requires project_type=ios_app in tusk/config.json.LIB_REPO is empty, stop with: project_libs.ios_app.repo is unset in tusk/config.json.LIB_REF is optional. Mention it in the PR body when present.
Ask the user to identify the local change that should be moved upstream:
Which local files or behavior should be contributed to <LIB_REPO>?
Before editing the library repo, inspect the local diff and summarize exactly what will be ported. If the change is ambiguous, ask for clarification. Do not copy unrelated client project code or secrets into the library repo.
Use a sibling or temp workspace outside the client repo. Change into that parent before cloning so the fork is not created inside the client project:
LIB_WORKSPACE_PARENT=$(mktemp -d)
cd "$LIB_WORKSPACE_PARENT"
Fork first so the branch can be pushed even when the user lacks write access:
gh repo fork "$LIB_REPO" --clone --remote
If the repo is already cloned, reuse it after confirming it is clean:
git status --short
Create the upstream work branch:
git switch -c "tusk/<task_id>-<slug>"
Use a short lowercase slug from the local task summary. Keep the literal branch shape tusk/<task_id>-<slug>.
Copy or re-implement the selected client change into the library workspace. Keep the PR focused on library code and tests only.
After editing:
git diff --stat
git diff
Confirm the diff contains only the intended upstream contribution.
Detect the library's test command from its own repo files. Prefer the repo's documented test suite command. Common iOS library checks include:
swift test
xcodebuild test -scheme <scheme> -destination 'platform=iOS Simulator,name=<device>'
If no test command is discoverable, explain what was checked manually and why automated verification was unavailable.
Commit in the library repo:
git add <changed-files>
git commit -m "Contribute TASK-${TASK_ID} fix"
git push -u origin "tusk/<task_id>-<slug>"
Open a draft PR by default:
gh pr create --repo "$LIB_REPO" --draft --title "<title>" --body-file -
Pass the body via stdin. Include:
## Summary
<what changed>
## Verification
- <test command and result>
## Originating tusk task
TASK-<task_id> - <task.summary>
## Client lib ref
<LIB_REF or "unspecified">
If gh pr create fails due to authentication or repository access, surface the exact stderr and stop. Do not retry automatically because a PR may have been partially created.
When the PR URL is available, record it on the originating local task:
tusk progress "$TASK_ID" --note "Opened upstream PR against $LIB_REPO: $PR_URL"
This keeps the external contribution visible in local task history.
Print:
Opened upstream PR against <LIB_REPO>: <PR_URL> (linked on TASK-<task_id>).
Do not close the originating task automatically. The upstream PR may need review before the client work can finish.
data-ai
Autonomously work through the backlog — dispatches /chain for chain heads, /tusk for standalone tasks, repeating until empty
tools
Investigate the scope of a problem and form an honest assessment — task creation is optional
data-ai
Groom the backlog by closing completed tickets, removing redundant/stale tickets, reprioritizing, and assigning agents
tools
File a GitHub issue against the tusk repo itself — tusk bugs, CLI limitations, skill improvements, or missing features. Use anytime the user identifies a gap in tusk (not in their own project's code).