From 2233fd232a7c969046375f9d101111be3d960ec7 Mon Sep 17 00:00:00 2001 From: thuanle Date: Tue, 28 Apr 2026 06:23:28 +0700 Subject: [PATCH] update workflow - auto assign yourself as assignee/reviewer --- .codex/skills/implement-task/SKILL.codex.md | 53 -------- .codex/skills/implement-task/SKILL.md | 3 + .codex/skills/review-pr/SKILL.codex.md | 133 -------------------- .codex/skills/review-pr/SKILL.md | 7 +- 4 files changed, 8 insertions(+), 188 deletions(-) delete mode 100644 .codex/skills/implement-task/SKILL.codex.md delete mode 100644 .codex/skills/review-pr/SKILL.codex.md diff --git a/.codex/skills/implement-task/SKILL.codex.md b/.codex/skills/implement-task/SKILL.codex.md deleted file mode 100644 index 15a5dbc..0000000 --- a/.codex/skills/implement-task/SKILL.codex.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -name: do-task -description: Use when handling a Gitea issue/task end-to-end, including validation, planning, implementation, PR creation, and review-feedback iteration. ---- - -# Do Task - -## Overview -Process a single Gitea issue from analysis to merge-ready PR with explicit decision gates. Prefer Gitea MCP tools for all issue/PR actions. - -## Workflow - -1. **Load issue** - - Read issue by ID from Gitea. - - Extract: problem, expected behavior, impact, acceptance checks. - -2. **Validate technical correctness** - - Verify against current code/docs/tests. - - Decide: - - **Valid issue** -> continue to planning. - - **Not valid / out of scope** -> comment rationale on issue and stop. - -3. **If valid: plan and comment** - - Create implementation plan using Superpowers planning flow. - - Post summary plan to the issue before coding. - -4. **Implement** - - Use Superpowers execution flow (TDD + verification before completion). - - Keep changes scoped strictly to issue requirements. - -5. **Create PR** - - Open PR from feature branch. - - PR description must include: - - Summary of changes - - Test evidence (exact commands) - - `Fixes #` (or `Closes #`) - - Add reviewer: `codex`. - -6. **Review feedback loop** - - Read all feedback. - - For each item: - - If technically valid -> implement + re-test + reply. - - If not valid -> reply with concise technical reasoning. - - Do not blindly accept external feedback without verification. - -## Required Rules -- Use Gitea MCP tools first for issue/PR/review operations. -- Do not use `tea` or other CLI Gitea clients unless MCP is unavailable. -- Never claim completion without fresh verification output. - -## Quick Command Pattern -- Invoke as: `/do-task ` -- Example: `/do-task 12` diff --git a/.codex/skills/implement-task/SKILL.md b/.codex/skills/implement-task/SKILL.md index 17c8338..3ff1f9e 100644 --- a/.codex/skills/implement-task/SKILL.md +++ b/.codex/skills/implement-task/SKILL.md @@ -23,6 +23,8 @@ description: Phase 2 skill. Use when issue scope is locked by Product Owner (Pha - Read issue: `mcp__gitea__.issue_read` (`method: "get"`). - Read comments, find the **Final Requirements** comment: `mcp__gitea__.issue_read` (`method: "get_comments"`). - If Final Requirements not found → stop, tell user to validate issue first. + - Read current Gitea user: `mcp__gitea__.get_me`. + - If current user is not already in the issue assignee list, update the issue with `mcp__gitea__.issue_write` (`method: "update"`) and set `assignees` to the existing assignees plus the current username. 2. **Read codebase** - Use `mcp__gitea__.get_file_contents`, `mcp__gitea__.get_repository_tree` to understand current state. @@ -72,6 +74,7 @@ description: Phase 2 skill. Use when issue scope is locked by Product Owner (Pha ## Rules - Use Gitea MCP tools for all issue/PR operations. +- Preserve existing assignees when adding yourself unless the user explicitly asks to replace them. - Never edit remote files directly — always work on local branch. - Never claim completion without fresh verification output. - Keep changes strictly scoped to the approved plan. diff --git a/.codex/skills/review-pr/SKILL.codex.md b/.codex/skills/review-pr/SKILL.codex.md deleted file mode 100644 index 4618329..0000000 --- a/.codex/skills/review-pr/SKILL.codex.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: review-pr -description: Review pull requests in Gitea repositories using Gitea MCP for server-side PR metadata, comments, reviews, diffs, workflow state, and PR comments. Use local CLI tools such as git and test runners only for local repository inspection and validation. Use when the user asks to "Review PR", "review pull request", "check PR", "recheck PR after updates", or "post review comment". Inspect PR metadata and discussion, compare the PR head against its base branch, produce a clear PASS/FAIL verdict, and optionally post the result back to the PR. ---- - -# Review PR - -## Local Preference - -For repositories on `git.thuanle.me`, prefer the `mcp__gitea__` tools for Gitea-hosted pull request metadata, comments, reviews, server-side diffs, repository contents, branches, commits, workflow runs, and PR comments. Do not use `tea` or other command-line Gitea API clients unless the user explicitly asks for them or the MCP tools are unavailable for the required Gitea operation. Other local CLI tools such as `git`, `go`, `rg`, test runners, and formatters are OK for local repository inspection and validation. - -## Workflow - -Follow this sequence: - -1. Identify the PR and current repo context. -- Use the current repository when the user is already inside it. -- If the user gives only a PR number and the repo context is ambiguous, ask a short clarifying question. -- Do not ask follow-up questions when the repository, PR, and requested reviewer action are already clear. -- If the user has already given a standing instruction earlier in the same thread such as "if you're confident, post it", carry that instruction forward for later re-reviews until the user changes it. -- Read the PR first with `mcp__gitea__.pull_request_read` using `method: "get"`, and read issue comments with `mcp__gitea__.issue_read` using `method: "get_comments"`. -- Read reviews with `mcp__gitea__.pull_request_read` using `method: "get_reviews"` when review state matters. -- Note the PR status exactly. If it is already merged or closed, say so explicitly before continuing. - -2. Read the review history before judging the latest update. -- Find the latest blocking review comments first. -- If the author says they addressed feedback in a follow-up commit, focus on the new commits after that discussion. -- Still sanity-check the current full PR diff before concluding `PASS`. - -3. Compare against the real base branch. -- Use PR metadata from MCP as the source of truth for base/head refs and SHAs. -- Prefer the PR base branch from MCP metadata; use `main` only when the base branch is not obvious from PR metadata. - -4. Inspect the code changes. -- Use `mcp__gitea__.pull_request_read` with `method: "get_diff"` to read the PR diff. -- Use `mcp__gitea__.get_file_contents`, `mcp__gitea__.get_repository_tree`, and commit/branch MCP reads for surrounding context. -- If the user asks for a re-review after updates, optionally diff the latest fix commit range as a helper view, but do not skip the full PR sanity check. - -5. Validate behavior where it matters. -- Prefer an isolated worktree when validation should run on the PR snapshot instead of the currently checked out branch. -- Use a repository-local worktree under `.worktrees/` by default, for example `git worktree add .worktrees/pr- origin/`. Before creating it, run `git worktree list` and confirm the repo-local `.worktrees/` path. -- For `/Users/tm/working/thuanle/crypto/crypto-price-bot`, PR validation worktrees must be under `.worktrees/pr-` from the repository root. Do not use `/tmp` for this repo; if `.worktrees/` is unavailable, stop and ask the user before using any fallback path. -- Run validation commands inside that worktree. -- Remove it afterward with `git worktree remove .worktrees/pr-` when it is no longer needed. -- For other repositories, if `git worktree add` fails because the environment blocks writes to `.git/worktrees`, fall back to exporting a temporary snapshot for validation and say that you used the fallback. -- Run repo-appropriate checks when feasible. -- Prefer targeted checks first, then broader validation such as `go test ./...` and `go vet ./...` in Go repositories. -- Say explicitly when validation could not be run. - -6. Write the verdict for the user. -- Start with `PASS` or `FAIL`. -- For `FAIL`, list blocking findings first, ordered by severity. -- Include file and line references whenever possible. -- Explain the concrete behavior impact, not style preferences. -- For `PASS`, say that no blocking issues were found and then add any non-blocking notes. - -7. Post a review result proactively by default. -- When acting as a reviewer, prefer an official PR review over a plain issue comment if the result should affect PR state. -- Default stance: if the verdict is clear and you are confident in it, post the review without waiting for another prompt from the user. -- If the user has already asked you to post the result, or has given a standing instruction such as "if you're confident, post it", treat that as continuing authority for later re-reviews in the same thread unless the user revokes or narrows it. -- Ask the user only when there is a real ambiguity you cannot safely resolve, such as unclear repo/PR context, unclear whether they explicitly want a local-only verdict instead of a posted review, or a materially uncertain finding. -- If the user explicitly asks for a local verdict only, do not post. -- Use `mcp__gitea__.pull_request_review_write` for review posting. -- For normal review results, prefer a single `create` call with the final `state` and `body`. This is the default path for `PASS`, `FAIL`, and neutral review comments. -- Use `submit` only when you intentionally need a multi-step pending review flow, such as staging a pending review first and finalizing it later. -- Never send the same review narrative through both `create` and `submit`; that is a process bug and can surface as duplicate review content in the UI. -- Map the verdict to review state: - - `PASS` -> `APPROVED` - - `FAIL` -> `REQUEST_CHANGES` - - neutral/non-blocking note only -> `COMMENT` -- Use `mcp__gitea__.issue_write` with `method: "add_comment"` only for plain discussion comments that should not change PR review status. -- Do not add bracketed author/tool tags such as `[codex]`. -- Start directly with the review result or author response, depending on your role in the thread. -- Keep the review/comment concise and direct. -- Mention the validation commands you actually ran when posting review results. - -## Command Patterns - -Use these MCP operations directly: - -- `mcp__gitea__.pull_request_read` with `method: "get"` -- `mcp__gitea__.pull_request_read` with `method: "get_diff"` -- `mcp__gitea__.pull_request_read` with `method: "get_reviews"` -- `mcp__gitea__.pull_request_read` with `method: "get_review_comments"` when a specific review thread is needed -- `mcp__gitea__.issue_read` with `method: "get_comments"` -- `mcp__gitea__.get_file_contents` -- `mcp__gitea__.get_repository_tree` -- `mcp__gitea__.get_commit` -- `mcp__gitea__.actions_run_read` for workflow status and logs -- `mcp__gitea__.pull_request_review_write` with `method: "create"` for the normal one-shot final review path - - Set the final `state` on `create` - - Put the final review text on `create` -- `mcp__gitea__.pull_request_review_write` with `method: "submit"` only when finishing an intentionally pending review -- `mcp__gitea__.issue_write` with `method: "add_comment"` when posting a plain PR comment - -Do not use `tea` for Gitea PR review unless the user explicitly requests it or MCP cannot provide the needed data. Local CLI usage such as `git diff`, `git worktree`, and test commands remains acceptable when it materially improves local validation. - -## Comment Template - -Use this structure when posting a review result: - -```text -PASS - -No blocking issues found in the latest update. - -Validation: -- -- - -Non-blocking note: -- -``` - -```text -FAIL - -1. [High] -2. [Medium] - -Validation: -- -- -``` - -When acting as a reviewer and the user asks to approve/reject or otherwise post the result, also submit the matching official review state: -- `PASS` -> `APPROVED` -- `FAIL` -> `REQUEST_CHANGES` -- neutral note only -> `COMMENT` - -When responding as the PR author rather than reviewer, do not use `PASS`/`FAIL`; write a concise author response that explains what feedback was addressed and which validation ran. - -Do not add filler. Keep the review specific, technical, and actionable. diff --git a/.codex/skills/review-pr/SKILL.md b/.codex/skills/review-pr/SKILL.md index 6aa98f7..8ca6fa5 100644 --- a/.codex/skills/review-pr/SKILL.md +++ b/.codex/skills/review-pr/SKILL.md @@ -22,11 +22,13 @@ description: Phase 2 skill. Use when a PR is created or updated. Review PR again 1. **Load PR and issue** - Read PR: `mcp__gitea__.pull_request_read` (`method: "get"`). + - If PR is already merged or closed, say so and stop. + - Read current Gitea user: `mcp__gitea__.get_me`. + - Read existing reviews: `mcp__gitea__.pull_request_read` (`method: "get_reviews"`). + - If the current user is not already requested as a reviewer and has not already reviewed this PR, add them with `mcp__gitea__.pull_request_write` (`method: "add_reviewers"`). - Identify the linked issue from PR body (`Fixes #` or `Closes #`). - Read issue comments, find the **Final Requirements** comment: `mcp__gitea__.issue_read` (`method: "get_comments"`). - - Read existing reviews: `mcp__gitea__.pull_request_read` (`method: "get_reviews"`). - Read PR discussion comments: `mcp__gitea__.issue_read` (`method: "get_comments"`), using the PR number as the index. - - If PR is already merged or closed, say so and stop. 2. **Read review history** (for re-reviews) - Get review comments: `mcp__gitea__.pull_request_read` (`method: "get_review_comments"`). @@ -101,6 +103,7 @@ Validation: ## Rules - Use Gitea MCP tools for all PR/review operations. +- Do not add yourself as reviewer twice; check requested reviewers and existing reviews first. - Do NOT edit code on the PR. - FAIL if PR contains unrelated changes or scope creep. - Post review proactively if verdict is clear.