Add get-reviews agent skill

.agents/skills/get-reviews/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: get-reviews
+description: >-
+  This skill is utilized when requesting reviews from GitHub pull requests.
+  Get the reviews, organize, and resolve them by applying or dismissing.
+argument-hint: "Provide the number of the pull request to get the reviews."
+---
+
+<!-- deno-fmt-ignore-file -->
+
+Get reviews from GitHub pull requests
+=====================================
+
+This skill is utilized when requesting reviews from GitHub pull requests.
+
+1.  Get the reviews.
+2.  Organize the reviews.
+3.  Resolve the reviews by applying or dismissing them.
+
+
+Get the reviews
+---------------
+
+To get the reviews from a GitHub pull request, you can use the GitHub API.
+Check the [`gh` CLI tool][gh] is installed and authenticated.
+`gh auth status` can be used to check the authentication status.
+If `gh` isn't installed, try installing it by `apt install gh`.
+If authentication is not set up, tell the contributor to run `gh auth login`
+to authenticate with GitHub.
+
+Use the GraphQL API to fetch the reviews for a specific pull request.
+Check [fetch\_reviews.sh](./fetch_reviews.sh) to fetch the reviews
+and save them in a JSON file:
+
+ -  Replace `$VARIABLES` with the actual values or variables in the command.
+ -  If already saved reviews existed, use `after: $LAST_REVIEW_ID` instead of
+    `first: $NUMBER_OF_THREADS` to fetch new reviews.
+ -  Use `jq` to filter the reviews and information if necessary.
+
+[gh]: https://cli.github.com/
+
+
+Organize the reviews
+--------------------
+
+After fetching the PR and its reviews, organize the reviews.
+[*plans* directory in the root](../../../plans/) is a good place to store them.
+
+ -  *plans/{PR\_NUMBER}/index.md*: The main file for the PR.
+     -  The body of the PR
+ -  *plans/{PR\_NUMBER}/reviews/{REVIEW\_ID}.md*: The file for each review
+    which is not resolved.
+     -  After applying or dismissing the review, move the file to
+        *plans/{PR\_NUMBER}/reviews/resolved/{REVIEW\_ID}.md*.
+     -  If the review file is too long, move the content to
+        \**plans/{PR\_NUMBER}/reviews/{REVIEW\_ID}/index.md*, and separate the
+        content into multiple files in the same directory. In this case, after
+        resolving the review, move the whole directory to
+        *plans/{PR\_NUMBER}/reviews/resolved/{REVIEW\_ID}/*.
+ -  *plans/{PR\_NUMBER}/reviews/resolved/{REVIEW\_ID}.md*: The file for each
+    review which is resolved.
+
+The format of review files should be as [review.md](./review.md).
+
+All related information with the review should be stored in
+*plans/{PR\_NUMBER}/reviews/{REVIEW\_ID}.md* or the files in
+*plans/{PR\_NUMBER}/reviews/{REVIEW\_ID}/*.
+
+
+Resolve the reviews
+-------------------
+
+Let the contributor read the review files, decide the judgement and the plans
+for each review, and let them update the review files if necessary.
+After the contributor decides the judgement and the plans, apply or dismiss the
+reviews based on the files.
+
+Categorize the reviews and the plans, and apply them at once by category.
+After applying the review, use [`/commit` skill](../commit/SKILL.md) to commit
+the changes. The commit message should include the related review links.
+`https://github.com/fedify-dev/fedify/pull/{PR_NUMBER}#discussion_r{REVIEW_THREAD.COMMENTS[0].DATABASE_ID})`
+
+After committing the changes, update the review file to include the commit hash
+and the comment section. If the review is dismissed, update the review file to
+include the reason for dismissing and the comment section.
+
+If the `Comments` are written only in the contributor's language, provide an
+English translation and have the contributor review it. If they are written in
+both languages, check for any discrepancies between the two. If differences
+exist between the two versions, review them based on the facts and revise
+the English version to match the content in the contributor's language.
+
+Post all of the review in English, even if the file written in the contributor's
+native language. The comments should be polite and constructive.

.agents/skills/get-reviews/fetch_reviews.sh

@@ -0,0 +1,29 @@
+mkdir -p 'plans/$PR_NUMBER/fetched'
+gh api graphql -f query='query($owner: String!, $repo: String!, $number: Int!) {
+  repository(owner: $owner, name: $repo) {
+    pullRequest(number: $number) {
+      reviewThreads(first: $NUMBER_OF_THREADS) {
+        nodes {
+          id
+          isResolved
+          isOutdated
+          path
+          line
+          comments(first: $NUMBER_OF_COMMENTS_PER_THREAD) {
+            nodes {
+              id
+              databaseId
+              author { login }
+              body
+              url
+              createdAt
+            }
+          }
+        }
+      }
+    }
+  }
+}' -F owner=fedify-dev -F repo=fedify -F number=$PR_NUMBER \
+> 'plans/$PR_NUMBER/fetched/$CURRENT_TIMESTAMP_MMDDHHMM.json'
+
+# cspell: ignore MMDDHHMM

.agents/skills/get-reviews/review.md

@@ -0,0 +1,125 @@
+---
+id: REVIEW_ID
+description: summary of the review
+link: the link to the review on GitHub
+links:
+ -  If there are multiple links related to the review,
+ -  list all the links.
+ - `link`–`links` are mutually exclusive.
+commit: the hash of commit after applying the review to add the comment
+commits:
+ -  If the review applies to multiple commits, list the hashes of the commits
+ -  after applying the review, update the list to include the new commit hash
+ - `commit`–`commits` are mutually exclusive. `commit` and `commits` are
+ - optional, and only used when the review is applied.
+---
+
+<!-- deno-fmt-ignore-file -->
+
+Title
+=====
+
+<!-- One line summary of the review -->
+
+
+Summary
+-------
+
+<!--
+  The summary of the review, but in little more detail
+  If the review is too short even enough with the title, omit this section.
+-->
+
+
+Judgement
+---------
+
+<!--
+  The judgement about the review.
+
+  The first line should be one of the following:
+  - **CORRECT**: If the review is correct and should be applied.
+  - **WRONG**: If the review is wrong and should be dismissed.
+  - **PARTIAL**: If the review is partially correct and should be applied with
+    some modifications.
+  - **NEEDS EVALUATION**: If the review requires testing or evaluation,
+    such as a review pointing out efficiency issues.
+  - **NEEDS DISCUSSION**: If the review needs further discussion,
+    such as about direction of the project or design choices.
+  Try to use these words to indicate judgement status whenever possible,
+  but if you feel they are truly insufficient,use an appropriate word
+  and then update this part of *SKILL.md*.
+
+  After the first line, explain the judgement in more detail.
+  - The reasons for the judgement.
+  - The key factors that influence the judgement.
+-->
+
+
+Plans
+-----
+
+<!--
+  If the review is judged as **WRONG**, omit this section or write the plans
+  to add comments explaining the code to prevent similar misunderstandings.
+
+  If the review is judged as **CORRECT** or **PARTIAL**,
+  write the plans to apply the review.
+  - How to apply the review?
+  - If the review is judged as **PARTIAL**, what are the modifications to apply?
+  - Why the plans can apply the review correctly?
+
+  If the review is judged as **NEEDS EVALUATION**,
+  write the plans to evaluate the review, such as testing plans.
+  - How to test or evaluate?
+  - What are the criteria for success or failure?
+  - Why the tests or evaluation can determine the correctness of the review?
+  And after the evaluation, write the plans to apply or dismiss the review
+  based on the evaluation results.
+
+  If the review is judged as **NEEDS DISCUSSION**,
+  write the plans to discuss the review, such as topics to discuss and
+  potential options.
+  - What are the topics to discuss?
+  - What are the potential options and their pros and cons?
+  - What is the most reasonable option and why?
+-->
+
+
+Comments
+--------
+
+<!--
+  Prepare the response comments in advance after applying the review or
+  judging the review as wrong. The comments should be polite and constructive.
+
+  If the contributor don't use English, separate this section into two parts,
+  - the language of the contributor using
+  - English, ready to be posted as a response
+
+  If the review is judged as **CORRECT**, write comments to apply the review
+  to explain how to apply the review and why it is correct. The comments to
+  applied reviews should be started with "Addressed in {COMMIT_HASH}.".
+
+  If the review is judged as **WRONG**, write comments to dismiss the review
+  to explain why the review is wrong and should be dismissed.
+
+  If the review is judged as **PARTIAL**, write comments to partially apply the
+  review to explain how to apply the review with modifications and why it is
+  partially correct. Referring to the above, write the incorrect parts based
+  on the **WRONG** part, and the correct parts based on the **CORRECT** part.
+
+  If the review is judged as **NEEDS EVALUATION**, write the comments to
+  evaluate the review explain how to evaluate the review, the test results,
+  and the resulting application/rejection details.
+  - If the results of the evaluation are the review is correct,
+    write comments referring to the **CORRECT** part.
+  - If the results of the evaluation are the review is wrong,
+    write comments referring to the **WRONG** part.
+
+  If the review is judged as **NEEDS DISCUSSION**,
+  write the comments to discuss the review.
+  - The comments should explain what to discuss
+    about the review and why it needs discussion.
+  - The comments should be polite and constructive.
+-->