One-Click Push to GitHub

Feature Description

Push the current project to GitHub in one click, covering the full lifecycle:

First-time Push — New project from scratch to GitHub
Daily Update — Push after modifying files (commit + push)
Version Release — Create tag + Release, optional attached download files

Core Principle: Safety First. It's better to ask one more question than push something that shouldn't be pushed.

Workflow

Step 0: Environment Check + Mode Determination

Check prerequisites in sequence, terminate and provide guidance if any is not met:

1. Is git installed?

❌ → Prompt:
```
brew install git
```
, terminate
✅ → Continue

2. Is gh CLI installed?

❌ → Prompt:
```
brew install gh
```
, terminate
✅ → Continue

3. Is gh logged into GitHub?

Execute
```
gh auth status
```
to check
❌ Not logged in → Prompt:
```
gh auth login
```
, terminate
✅ Logged in → Record account name, inform user "Current logged-in account: [xxx]", continue

4. Are git user configurations set?

Execute

git config user.name

and

git config user.email

to check

❌ Not configured → Prompt user to set:

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

Terminate

✅ Configured → Continue

5. Is the current directory already a git repository → Determines which path to take

Not a git repository → [First-time Push] Start from Step 1
Is a git repository, no remote → "Local git exists but not linked to remote"
    → First perform large file scanning in Step 1 (ensure safety)
    → Then jump to Step 2 to link remote
Is a git repository, has remote → [Existing Repository] Enter mode selection:
    ├── "Push daily update" → Jump to Step 3B (Daily Update)
    ├── "Release new version"   → Check for uncommitted changes
    │   ├── Has changes → First go through Step 3B, then Step 4
    │   └── No changes → Directly jump to Step 4 (only create tag + Release)
    └── "Restart"
        → ⚠️ Warning: "This will delete all Git history (including all commits, branches, tags), which cannot be recovered."
        → Delete .git after user's second confirmation, start from Step 1

Step 1: Project Scanning + .gitignore Generation

⚠️ Iron Rule: .gitignore must be in place before the first
git add
. Never commit first then exclude—large files in Git history cannot be fully deleted, leading to bloated repositories and push failures.

1.1 Scan Directory Size

Use

du -sh

to scan all top-level directories and files, sorted by size.

Large File Hierarchical Handling:

Size	Handling Method
>10MB	List them, ask user one by one "Do you want to push this?"
>50MB	Additional warning "This is large, pushing will be slow"
Single file >100MB	Must exclude, GitHub hard limit, cannot be pushed

Display Format (Example):

Scanned content exceeding 10MB:

  1. 109MB  slides/   (PPT + large images)
  2.  12MB  assets/   (video files)

⚠️ slides/ exceeds 50MB, pushing will be slow.
❌ recording.mp4 (150MB) exceeds GitHub's 100MB single file limit, must be excluded.

Which ones to exclude? (Enter serial numbers, or "exclude all" / "keep all")

1.2 Sensitive Content Scanning (Public Repositories Only)

If user selects public repository, additionally scan:

```
.env
```
/
```
.env.*
```
— Environment variables/keys
```
*secret*
```
/
```
*credential*
```
/
```
*token*
```
— Secret files
```
*.pem
```
/
```
*.key
```
— Certificate files
```
memory/
```
/
```
MEMORY.md
```
— AI tool memory files
Any files that appear to be private content

List suggested exclusions, let user confirm item by item.

1.3 Generate or Update .gitignore

If .gitignore does not exist: Generate new file based on scanning results.

If .gitignore already exists: Read existing content, merge new exclusions, show differences for user confirmation. Do not overwrite user's existing rules.

Base Template:

gitignore

# macOS
.DS_Store
.AppleDouble
.LSOverride
._*

# Editor
*.swp
*.swo
*~
.vscode/
.idea/

# [Dynamically generated based on scanning results below]
# Large files (confirmed to exclude by user)
[Path1]
[Path2]

# Sensitive content (only for public repositories)
[Path3]

Write to file after displaying to user for confirmation.

Step 2: User Decision

1. Repository Name (Default: Current directory name)

2. Description (One sentence, can be left blank)

3. Public / Private

Public → Second confirmation: "Public repositories are visible to everyone, confirm that .gitignore has excluded sensitive content?"
- Not confirmed → Return to Step 1.2 (sensitive content scanning) for re-review, then return to this step to continue

4. Check for Duplicate Repository Names

Execute
```
gh repo view [account]/[repo-name]
```
to check
❌ Does not exist → Continue
✅ Exists → Inform user, ask:
- "Change name" → Re-enter
- "Use this existing repository" → Skip creation, directly link remote (record repository URL for Step 3)
- "Delete and rebuild" → Requires user's second confirmation

Step 3: Push

3A. First-time Push (New Project)

Strictly execute in the following order:

1. git init + git branch -m main
2. git add -A
3. git commit -m "init: Initialize [repo-name]"
4. Create remote repository (if repository does not exist in Step 2):
   gh repo create [repo-name] --private/--public --description "[description]" --source=. --remote=origin
   (If user selected "use existing repository" in Step 2, skip creation, directly: git remote add origin [existing repo URL])
5. git push -u origin main

3B. Daily Update (Existing Repository)

1. Scan changes: git status to check what was modified
2. Check newly added large files:
   - New files >10MB → Ask user for confirmation
   - Single new file >100MB → Must exclude, add to .gitignore
   - If .gitignore is modified, ensure .gitignore itself is included in subsequent git add
3. git add -A
4. git commit -m "[Automatically generate commit message based on changes]"
   - Commit message rule: Concise, one sentence summarizing main changes
   - Example: "update: Add user module + fix login bug"
5. git push

Push Failure Handling

Error	Cause	Handling
`rejected (fetch first)` or `non-fast-forward`	Remote has commits not present locally	Default to execute `git pull --rebase` then retry
Still failed / Remote conflicts	Incompatible history	Ask user "Force overwrite remote?" ⚠️ Inform: "This will overwrite all remote content, only use if you confirm remote content can be discarded"→ `git push --force`
Timeout / Stuck	Network or repository too large	Check repository size, suggest excluding large files then retry
Authentication failed	Token expired	Prompt `gh auth login`
`file exceeds 100MB`	Single file exceeds limit	Prompt specific file name, add to .gitignore, re-commit and push
`git add` or `git commit` failed	File exception / Missing configuration	Display error message, guide user to troubleshoot

Step 4: Optional — Version Release

Trigger Timing

After first-time push, actively ask once "Need to create a version?"
After daily update, do not actively ask (avoid disturbance)
User actively says "release version", "create release", "create tag"

Process

1. Determine Version Number

Read existing tags (git tag --sort=-v:refname | head -5)

├── No tags → Suggest v0.1.0
└── Has tags → Show latest version, suggest next one (default minor +1)
    - v0.1.0 → Suggest v0.2.0
    - v1.2.3 → Suggest v1.3.0
    - User can customize any version number

Version Number Explanation (for user reference):
- v0.1.0 → v0.2.0  Minor update (added features, modified content)
- v0.2.0 → v1.0.0  Major milestone (first official release, major refactoring)
- v1.0.0 → v1.0.1  Bug fixes (fixed a bug)

2. Release Notes

Automatically read commit records since last tag (
```
git log [last tag]..HEAD --oneline
```
)
Generate change summary, let user confirm or modify
If it's the first version (no historical tags), use all commits to generate summary

3. Attach Download Files?

Need to attach downloadable files? (e.g., App installation package, tool zip package, etc.)

├── No → Only create tag + Release page
└── Yes → User provides file path
    └── Check if file exists → Prompt re-entry if not exists

4. Execution

git tag [version]
git push origin [version]
gh release create [version] --title "[repo-name] [version]" --notes "[Release Notes]"
# If there are attachments:
gh release upload [version] [file path]

Release Failure Handling:

Tag already exists → Prompt user "This version number is already in use", let user change it
Attachment file does not exist → Prompt re-entry of path
Other errors → Display error message

Completion Output

✅ Push completed!

- Repository: [URL]
- Visibility: Private / Public
- Number of files: [N]
- Repository size: [X]
- Exclusions: [List content excluded by .gitignore]
- Release: [Version number + URL] / Not created

Core Principles

1. Scanning Comes First

.gitignore must be in place before the first

git add

. Once large files enter Git history, even if deleted later, repository size won't shrink, leading to push failures or extreme slowness. For projects with local git but no remote link, scan first then push.

2. Proactively Block Large Files

Proactively ask user for files over 10MB. Warn about slowness for files over 50MB, single files over 100MB are GitHub's hard limit and must be excluded. Check newly added file sizes during daily updates as well.

3. Double Check for Public Repositories

Public repositories additionally scan sensitive content (keys, AI memory files, private documents), and require second confirmation before pushing.

4. Do Not Destroy Existing Content

If project already has .git or .gitignore, do not overwrite by default, ask user first. Destructive operations like deleting .git must clearly warn of consequences and require second confirmation.

5. Interruptible at Every Step

User can say "stop" or "go back to previous step" at any time. Don't run through all steps without giving user a chance to react.

6. Lightweight for Daily Updates

Daily updates do not ask about Release, repository name, or re-scan the entire project. Only check newly added large files, commit + push, quick in and out.

Usage Examples

Scenario 1: First-time Push for New Project

User: Help me push to GitHub

Skill:
→ Check environment: git ✅ gh ✅ Logged in ✅ git user configured ✅ Not a git repository
→ Scan project...Found content exceeding 10MB:
  - 85MB slides/ → User confirms exclusion
  - 15MB images/ → User confirms retention
→ Generate .gitignore, user confirms
→ Repository name: my-project, private
→ Initialize + push successfully
→ "Need to create a Release?" → Skip
→ ✅ Completed

Scenario 2: Daily Update

User: Push it

Skill:
→ Detected linked remote repository
→ Scan changes: Modified 3 files, added 2 files (all <10MB)
→ Commit message: "update: Add user module + update configuration file"
→ Push successfully
→ ✅ Completed

Scenario 3: Release Version

User: Create a release

Skill:
→ Current latest tag: v0.1.0
→ "Suggest next version v0.2.0, okay?"
→ Automatically generate change summary (based on commit records)
→ "Need to attach download files?" → No
→ Create tag + Release
→ ✅ Release v0.2.0 created successfully!

Scenario 4: Large File Found During Push

→ git push failed: file recording.mp4 exceeds 100MB
→ "recording.mp4 (150MB) exceeds GitHub's limit, needs to be excluded"
→ Add to .gitignore, re-commit and push
→ ✅ Success

Scenario 5: New Large File Added During Daily Update

User: Push it

→ Scan changes...Found new file:
  - demo.pptx (25MB)
→ "This file is 25MB, confirm to push?"
→ User confirms exclusion → Add to .gitignore
→ Push successfully
→ ✅ Completed

Scenario 6: Release Version Without New Changes

User: Create a release

→ No uncommitted changes currently, directly enter version release
→ Current latest tag: v0.2.0
→ "Suggest v0.3.0, okay?"
→ User customizes input v1.0.0
→ Generate change summary + create Release
→ ✅ Release v1.0.0 created successfully!

git-push

NPX Install

Tags

SKILL.md Content (Chinese)