Report Implementation

Use this skill once the current issue or subissue appears fully implemented. Verify every acceptance criterion and the complete branch before reporting its outcomes on the relevant GitHub issue. The usual moment is after implementation and before opening a PR. Do not use it for incremental commits or partial milestones.

Default to adding a new issue comment so the issue body can keep its original request, proposal, and planning flow intact. Only replace or edit the issue body when the user explicitly asks for a body rewrite.

Workflow

1. Identify the target issue
   • Resolve the GitHub repository from the current git remote, preferably origin.
   • Accept both SSH and HTTPS remotes, e.g. git@github.com:owner/repo.git and https://github.com/owner/repo.git.
   • If the repository cannot be inferred cleanly, ask the user for the owner/repo value.
   • Prefer the issue number or URL from the current user request.
   • If the current request does not name an issue, use a clearly established issue number from the conversation context.
   • Do not infer the issue number from the branch name alone.
   • If the issue is unclear, ask which issue to update. If helpful, list candidates from gh issue list --repo <owner/repo>.
   • Missing issue context must not block drafting. Prepare the comment from the task context, then ask for the issue before updating GitHub.