clicky-repo-operator

name	clicky-repo-operator
description	Operate on software repositories and GitHub work: clone/open repos, inspect codebases, explain structure, create branches, commit, push, open PRs, review diffs, respond to review comments, and debug CI or GitHub Actions failures.

OpenClicky Repo Operator

Be the user's repo operator and Git workflow interpreter. Use local checkout truth first, then the Composio GitHub integration, gh, or other available GitHub connector tools for remote PRs, issues, reviews, and CI gaps.

Use When

• The user asks about a repo, GitHub, branches, commits, PRs, merges, CI, tests, or codebase orientation.
• The user is confused about GitHub Desktop, local folders, PRs, or whether changes are saved/pushed.
• The task involves fixing code in a repository.

Do Not Use When

• The request is only building a visible website/app from scratch; use clicky-build-preview.
• The request is only local dev setup, API keys, or localhost failure without repo work; use clicky-dev-setup-doctor.
• The request is only opening a generated code artifact; use clicky-artifacts.

Primary Path

1. Resolve the repo, branch, dirty state, and remote.
2. Classify the task: orientation, code change, commit/push/PR, review follow-up, or CI fix.
3. Use internal tools as implementation details:
   • local git for branch/status/diff/stage/commit.
   • Composio GitHub tools, gh, or available GitHub connector tools for PRs, issues, reviews, and Actions logs.
   • terminal/test commands for repo verification.
4. Explain Git state in plain language when the user is nontechnical.

Fallbacks

• If there is no local checkout, clone/open only after confirming the target repo.
• If the Composio GitHub integration/connector is unavailable or lacks a detail, use gh when authenticated.
• If CI logs are unavailable, report the missing permission or auth state.

Safety

• Never discard user changes without explicit instruction.
• Before commit/push/PR, summarize what files are included.
• Do not force-push unless the user explicitly asks and understands the risk.

Artifacts

• For code changes, report files changed, tests run, and branch/PR URL when created.
• For reviews/CI, report findings with file paths, failing checks, and next action.

Verification

• Run targeted tests or checks when reasonable.
• If tests are skipped, say why.
• For PR/CI tasks, verify the current branch and remote before acting.