datalad-push

name	datalad-push
description	Auto-invoke when the user wants to transfer saved dataset state to a remote, publish a dataset, upload annexed content to a sibling, share changes with collaborators, or push to GitHub, OSF, or other storage. Trigger on "push to remote", "publish dataset", "upload to sibling", "share changes", "push to GitHub", "send to storage", or /datalad-push. Do NOT trigger for plain git push in repos without DataLad context.
argument-hint	--to <sibling> [--data {nothing|anything|auto-if-wanted}] [-r]
user-invocable	true
disable-model-invocation	false
allowed-tools	Read, Bash, Glob

Skill: datalad-push

Transfer saved dataset state — git history and/or annexed file content — to a configured sibling (remote). Respects publish-depends ordering so annexed data reaches storage before git history reaches the git host.

Steps

1. Verify DataLad context — check for .datalad/ in the current directory or a parent:

   ls .datalad/ 2>/dev/null
   

   If no dataset is found, inform the user and stop.

2. Check for uncommitted changes — run datalad status:

   datalad status
   

   If the working tree is dirty, warn:

   "There are unsaved changes. Push will only transfer already-committed state. Save first with datalad save -m '...'?" Wait for the user to save or confirm they want to push the current committed state.

3. Identify target sibling — read from $ARGUMENTS. If not provided, list available siblings and ask which one to push to:

   datalad siblings
   

4. Determine data mode — present the choice:

   • auto-if-wanted (default): pushes only content the sibling has declared it wants via its annex-wanted expression. This is the default but only works when the sibling has annex-wanted configured — if not configured, no content will be pushed
   • nothing: push git history only, skip all annexed content
   • anything: push all locally present annexed content regardless of wanted rules

   Ask if annexed data handling is unclear from context.

5. Determine recursion — ask if the user wants to push subdatasets too:

   "Push subdatasets recursively as well? (-r)" If yes, also mention --on-failure ignore — without it a single subdataset failure aborts the entire recursive push. With it, failures are logged and the push continues across remaining subdatasets.

6. Construct and show command:

   datalad push --to <sibling> [--data {nothing|anything|auto-if-wanted}] [-r]
   

   Show the full command before executing.

7. Execute and report — run the command. Report:

   • Which git refs were pushed
   • How many annexed objects were transferred (if any)
   • If a --publish-depends sibling was pushed first, note that too

Reference

Load ${CLAUDE_PLUGIN_ROOT}/../references/siblings-and-remotes.md for publish-depends ordering, --data mode details, and why annexed content must reach storage before git history reaches the git host.

Load ${CLAUDE_PLUGIN_ROOT}/../references/global-options.md when the user asks about --on-failure for recursive pushes, wants JSON output from push results, or needs to debug a failed push (-l debug).

Constraints

• Always check for a dirty working tree before pushing — never push without this check.
• Always show the full command before executing.
• Warn if the target sibling has no --publish-depends configured and annexed content is present in the dataset:

  "This sibling has no storage dependency configured. Annexed file content may not be accessible to consumers who clone the git history. Consider setting up a storage sibling and adding --publish-depends."

• Never use git push directly inside a DataLad dataset — it bypasses annexed content handling and publish-depends ordering.