Source control

"Create a new GitHub repository called my-awesome-project with MIT license and Python gitignore"

/create

You have files in: my-project/src/main.py, my-project/tests/...

Create repository "my-project" →
- Creates empty remote repository
- Pushes your existing session files as initial commit
- Respects .gitignore patterns
- Uses custom commit message if provided
- Single operation: create + push

Create repository →
- Creates repository with selected templates
- Clones template files to session
- Standard template-based initialization

"Clone my backend-api repository, develop branch"

/clone

"Clone https://github.com/org/repo/pull/123"

github.com/owner/repo/pull/123
github.com/owner/repo/pull/123/files
github.com/owner/repo/pull/123/commits
github.com/owner/repo/pull/123/checks

Clone records persist even when you:
- Clear memories (/forget)
- Compact session (/compact)
- Hide files (/hidefiles)

Maestro never forgets which repository/branch you're working on.

Repository already cloned: backend-api (branch: feature-123)

Clone again from branch feature-123:
- Detects changed files
- Creates new iterations for changed files
- Adds any new files
- Preserves your iteration history
- Informs Maestro of changes

I need to familiarize myself with recent changes to my PR.

Steps:
1. Clone my org/repo, branch main
2. Clone same repo again, branch my-feature-branch
3. Compute diffs between repositories
4. View the most important changed files
5. Give me comprehensive breakdown of what was accomplished

Focus on significant changes, not trivial updates.

After overwrite clone, local changes lost:

Maestro can recover by:
1. Viewing your previous iterations (still in history)
2. Reviewing remote changes
3. Intelligently merging lost work into new iterations

Request: "My changes from iteration 5 were lost. Restore that implementation while preserving the new remote changes."

Work in session:
- Files exist in Maestro's internal storage
- Changes tracked via iterations
- Full history preserved
- Nothing pushed to git

Until you create/update PR:
- No branches created on remote
- No commits pushed
- Team doesn't see changes

"Create a pull request for my authentication changes. Title: Add JWT auth. Base branch: main."

/pr

Update PR for feature-123:

Maestro will:
1. Show currently included files
2. Let you add/remove files
3. Compute diff against current PR state
4. Push updates to feature branch
5. PR automatically updates on GitHub

Previously included: auth.py, config.py, tests.py
You deselect: config.py

Result:
- config.py reverts to base branch state on remote
- Only auth.py and tests.py remain in PR
- Effectively removes config.py from PR

1. Run full test suite
2. Verify all tests pass
3. Clean up WIP code and debug statements
4. Update documentation
5. Check code follows project conventions
6. Review all changes yourself

Then create PR.

Working on same branch as teammate:
1. Overwrite clone to pull their changes
2. Review diffs to understand updates
3. Make your changes
4. Update PR to push your additions

Session 1: Implement authentication
Branch: feature/auth-system
PR: Add JWT authentication

Session 2: Implement caching
Branch: feature/redis-cache
PR: Add Redis caching layer

Keeps PRs focused, reviewable, mergeable independently

Session implements: auth + caching

PR 1: Select only auth files → Create PR on feature/auth
PR 2: Select only caching files → Create PR on feature/cache

Advantage: Single session, multiple deliverables

Initial PR:
- Core implementation
- Basic tests
- Documentation

Update 1 (after feedback):
- Address review comments
- Add requested tests
- Improve error handling

Update 2 (after more feedback):
- Performance optimizations
- Edge case fixes
- Final polish

Each update uses /pr with same repository and branch

"Clone https://github.com/org/repo/pull/456"

Maestro clones the PR branch, then:
"Review this PR for:
- Code quality issues
- Test coverage gaps
- Performance concerns
- Security vulnerabilities

Provide detailed feedback on each."

1. Fork repository on GitHub (manually or via Maestro)
2. Clone your fork to session
3. Implement changes
4. Create PR from your fork to upstream

PR tool handles:
- Pushing to your fork
- Creating PR to upstream repository
- Managing cross-repository workflow

Developer A:
- Creates feature branch
- Implements partial feature
- Creates PR (draft)

Developer B (in new session):
- Clones PR from A
- Continues implementation
- Updates same PR
- Marks as ready for review

Team works on main develop branch:
- Each developer uses separate feature branches
- Create focused PRs for specific parts
- PRs reviewed and merged independently
- Periodic overwrite clones to stay synced

Clone frontend repository
Clone backend repository
Clone shared library

Implement feature touching all three:
- Make changes in each repository
- Create separate PRs for each
- Link PRs in descriptions
- Coordinate reviews

Preparing v2.0 release:

Clone from main branch:
"Review all changes since v1.5 tag"

Maestro:
- Identifies changed files
- Creates comprehensive changelog
- Documents breaking changes
- Validates backward compatibility

Update documentation:
- API changes
- Migration guides
- Release notes

Create PR with all release docs

Critical bug in production:

1. Clone from production branch
2. Reproduce issue in sandbox
3. Implement minimal fix
4. Validate fix doesn't break anything
5. Create PR directly to production branch
6. Minimal, surgical change for fast review

Use Compute Diffs to see what changed
Ensure Apply Changes ran successfully
Check file selection in PR creation UI

/repo-name/
    src/
    tests/
    docs/
    ...

Matches: github.com/org/repo-name
Makes PR creation seamless

When creating PR, specify commit message:
"feat: implement JWT authentication with refresh tokens"

## Changes
[What was implemented]

## Testing
[How it was validated]

## Performance
[Benchmark results if relevant]

## Breaking Changes
[None or list them]

## Notes
[Additional context]

Instead of giant PR:
- authentication
- caching
- monitoring
- logging

Create sequential PRs:
1. PR #1: Add authentication (merged)
2. PR #2: Add caching (builds on #1, merged)
3. PR #3: Add monitoring (builds on #2, merged)
4. PR #4: Add logging (builds on #3)

Before creating PR:
1. Run full test suite locally (in sandbox)
2. Run linters and formatters
3. Check code coverage
4. Run any CI scripts locally
5. Verify build succeeds

Only create PR after local validation passes.

"Review our GitHub Actions workflow and ensure the new authentication module will be tested correctly in CI"

Maestro:
- Examines .github/workflows/*.yml
- Identifies if new tests will run
- Suggests workflow updates if needed
- Validates before PR creation

Base: main

PR #1: feature/core → main
  (Core infrastructure)

PR #2: feature/api → feature/core
  (API layer, depends on core)

PR #3: feature/ui → feature/api
  (UI, depends on API)

Each PR reviewable independently
Merge order: #1, then #2, then #3

Repository A (backend):
- API changes
- Create PR in repo A

Repository B (frontend):
- UI changes consuming new API
- Create PR in repo B

Link PRs in descriptions
Coordinate reviews and merges

1. Clone from production branch
2. Implement minimal fix
3. Test thoroughly in sandbox
4. Create PR with "hotfix/" prefix
5. Request immediate review
6. Small, focused change for fast approval

Clone same repo, different branches for comparison:
- Clone org/repo branch main → See production state
- Clone org/repo branch develop → See upcoming changes

Compare implementations:
- Clone org/repo-python branch main
- Clone org/repo-node branch main
- Analyze approach differences

"Show me all cloned repositories"
"Which branch of the backend am I on?"
"When did I last pull from main?"

"Show me all open issues labeled 'bug' in the backend repo"

Maestro uses GitHub API to fetch and display issues.

"Add a review comment to PR #123 suggesting optimization in the auth logic"

Maestro:
- Views PR
- Adds inline or general comments
- Can suggest code changes
- Participates in PR discussion