بنقرة واحدة
pr
How Matt creates pull requests - branch naming, commit style, PR workflow
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
How Matt creates pull requests - branch naming, commit style, PR workflow
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Daily review workflow - process completed work, roll over unfinished items, prepare for tomorrow
Prepare for upcoming calendar events - identify prep needs, research attendees, create briefings
Prune and consolidate state files, surface important items from journal to core state
Weekly review for pattern recognition, commitment hygiene, and identity refinement
Guide for setting up Innie from scratch - global config, memory repo, MCP servers, and scheduler
Send alerts and notifications using AppleScript - banners, modals, and text-to-speech
| name | pr |
| description | How Matt creates pull requests - branch naming, commit style, PR workflow |
Follow this workflow when contributing changes to any repository.
Always create a branch and PR, even for small changes, unless specifically told otherwise. This applies to:
Use descriptive kebab-case branch names:
feat/add-opencode-detection
fix/calendar-permission-error
docs/update-setup-guide
refactor/simplify-scheduler
Prefixes:
feat/ - New featuresfix/ - Bug fixesdocs/ - Documentation onlyrefactor/ - Code restructuringchore/ - Maintenance, dependenciesgit checkout main
git pull
git checkout -b feat/my-feature
Use conventional commit messages:
git add -A
git commit -m "feat: add OpenCode detection via OPENCODE env var"
Commit message format:
feat: - New featurefix: - Bug fixdocs: - Documentationrefactor: - Code change that neither fixes nor addschore: - MaintenanceIf the repo uses changesets (has .changeset/ directory), and your change needs a release (features, fixes - not docs/chore), create one:
# Check if changesets is used
ls .changeset/config.json
# Create a changeset
pnpm changeset
# or
npx changeset
This opens an interactive prompt:
patch (fixes), minor (features), major (breaking)This creates a markdown file in .changeset/ like:
---
"am-i-vibing": minor
---
Add OpenCode detection via OPENCODE env var
Commit the changeset file with your other changes.
When to create a changeset:
feat: → minor bumpfix: → patch bumpdocs:, chore:, refactor: → usually no changeset neededBefore pushing, run tests to catch issues early:
pnpm test
# or
npm test
Fix any failing tests. If your change affects existing tests, update them.
git push -u origin feat/my-feature
gh pr create --title "feat: add OpenCode detection" --body "$(cat <<'EOF'
## Summary
- Added OPENCODE env var to detection
- Renamed sst-opencode to opencode
## Testing
Ran `npx am-i-vibing` in OpenCode session - now detects correctly.
EOF
)"
git checkout main
git pull
git branch -d feat/my-feature
## Summary
[1-3 bullet points describing what changed]
## Testing
[How you verified the change works]
## Notes
[Any additional context, breaking changes, etc.]
If changes were pushed directly to main that should have been a PR:
# Create a branch at the current commit
git branch feat/my-feature
# Reset main to before your commits
git checkout main
git reset --hard origin/main~N # N = number of commits to undo
# Push the reset (if you pushed to remote)
git push --force-with-lease
# Push the feature branch
git checkout feat/my-feature
git push -u origin feat/my-feature
# Create PR
gh pr create