Can you update CHANGELOG.md for a 0.1.1 with all the changes since repo was created. Keep the style of https://github.com/entireio/cli/blob/main/CHANGELOG.md Have in mind, this is the very first version. So we can just highlight the bigger areas of the repo.

sorry, version would be v0.4.2

ship it

Base directory for this skill: /Users/gtrrz-victor/.claude/skills/ship

Ship Changes

Commit current changes, push to remote, and update the PR.

Step 1: Analyze changes

1. Run git diff --stat and git diff to understand what changed
2. Run git status to see untracked files
3. Run git log --oneline -3 to match the repo's commit message style

Step 2: Commit

1. Stage only the relevant changed/untracked files by name (never git add -A or git add .)
2. Write a concise commit message that focuses on the "why" not the "what"
   • If `` is provided, use it as the commit message
   • Otherwise, draft one from the diff
3. Commit. If hooks fail, diagnose and fix — do NOT use --no-verify

Step 3: Push

1. Check if the branch tracks a remote: git rev-parse --abbrev-ref --symbolic-full-name @{u}
2. If not tracking, push with -u origin <branch>
3. If tracking, just git push
4. If push is rejected (remote has new commits), pull with rebase first then push

Step 4: Update PR

1. Find the open PR for the current branch: gh pr view --json number,body,title
2. If no PR exists, skip this step and inform the user
3. Compare the current PR body against the new changes:
   • If the changes are within the existing PR scope, update the description to reflect the current state
   • If the changes are additive or a follow-up, add a PR comment summarizing what was just pushed instead
4. When updating the PR body, preserve the overall structure but refresh the summary bullets and test plan
5. When adding a comment, keep it concise — bullet points of what changed and why
6. Before making any PR update (description edit or comment), show the user the exact text you plan to post and ask for their approval. Do NOT post until they confirm.

Rules

• Never commit files that look like secrets (.env, credentials, tokens)
• Never force push
• Always show the user what was committed and the PR URL when done