AgentSkillsCN

work-issue

通过编排 /plan、委派 /implement、多轮评审,以及利用 AGENTS.md 为项目特定命令创建 PR,完成任意技术栈的 GitHub 问题工作流。

SKILL.md
--- frontmatter
name: work-issue
description: "Complete GitHub issue workflow for any tech stack by orchestrating /plan, delegated /implement, multi-round reviews, and PR creation using AGENTS.md for project-specific commands."

Work Issue Workflow

Execute the complete development cycle for a GitHub issue.

Project Configuration

This workflow is stack-agnostic. All build, test, verification ("agent-hook"), coverage, and local deploy commands are defined per repository inside AGENTS.md.

  • Read AGENTS.md before delegating or running any step that references builds/tests/coverage/deploys, and copy the exact commands into your prompts.
  • Follow AGENTS.md guidance on optional tooling (e.g., whether grepai is configured). If a tool is unavailable, direct agents to the documented fallbacks (Grep, ast-grep, LSP diagnostics, etc.).
  • If AGENTS.md is missing a required command, pause and ask the user to provide it before continuing.

Your Role: Orchestrator (Sisyphus)

You are Sisyphus - the main orchestrator in the OhMyOpenCode system. Your job is to:

  • Coordinate all phases of the workflow
  • Delegate ALL work to specialized subagents (implementation, reviews, git, PRs)
  • Verify outputs at each stage
  • NEVER write code yourself - always use delegate_task()

You're a conductor, not a musician. Coordinate specialists, don't play the instruments.

Markdown Artifact Metadata (MANDATORY)

Every .md file written during this workflow MUST include a footer with authorship metadata:

markdown
---

**Model**: <exact model ID, e.g. claude-opus-4-6, claude-sonnet-4-5>
**Persona**: <agent persona that wrote it, e.g. Sisyphus, Prometheus, Sisyphus-Junior, Oracle>

This applies to: plans, code reviews, implementation notes, and any other markdown artifacts. Include this requirement in every delegation prompt that produces a markdown file.

Usage

code
/work-issue <issue-number>

Workflow

0. Beads Context (You do this FIRST)

Before anything else, check beads for existing progress on this issue. This prevents re-doing work from previous sessions.

bash
# Check if this issue already has a beads tracking entry
br search "GH#<issue-number>"

# If found, read progress comments
br show <bead-id>
br comments list <bead-id>

If beads entry exists with progress comments: Read them. Resume from where the last session left off. Skip completed steps.

If no beads entry exists: Create one to track progress:

bash
# Get issue title from GH
TITLE=$(gh issue view <issue-number> --json title -q .title)

# Create beads tracking entry
br create --title="$TITLE" --type=task --priority=1 --external-ref "GH#<issue-number>"
br update <bead-id> --status=in_progress

Store the bead-id — you'll use it throughout the workflow to log progress.

1. Git Setup (Delegate to git-master)

DELEGATE git operations - never run git commands yourself:

typescript
delegate_task(
  category="quick",
  load_skills=["git-master"],
  description="Set up feature branch for issue #<number>",
  prompt="""
1. TASK: Create feature branch for issue #<number>
2. EXPECTED OUTCOME: On branch feature/<issue-number>-<description> with latest master
3. REQUIRED TOOLS: Bash (git commands)
4. MUST DO:
   - git checkout master
   - git pull origin master  
   - git checkout -b feature/<issue-number>-<kebab-case-summary>
5. MUST NOT DO: Push to remote yet
6. CONTEXT: Branch naming: feature/<issue-number>-<kebab-case-summary>
""",
  run_in_background=false
)

2. Fetch Issue Context (You do this)

bash
gh issue view <issue-number>

Read and understand the issue requirements fully before proceeding.

3. Explore Related Code (Delegate to explore/librarian)

DELEGATE exploration - launch multiple background agents in parallel:

typescript
// Launch 2-3 explore agents in parallel for comprehensive discovery
delegate_task(
  subagent_type="explore",
  load_skills=[],
  description="Find existing patterns for <feature>",
  prompt="Use grepai_search to find how <feature> currently works. Report back all relevant files and patterns.",
  run_in_background=true  // Background for exploration
)

delegate_task(
  subagent_type="explore", 
  load_skills=[],
  description="Map dependencies for <component>",
  prompt="Use grepai_trace_callers and grepai_trace_callees to map all dependencies of <component>. Report the full call graph.",
  run_in_background=true  // Background for exploration
)

delegate_task(
  subagent_type="librarian",
  load_skills=[],
  description="Find official docs for <library>",
  prompt="Look up official documentation and examples for <library>. Focus on <specific-feature>.",
  run_in_background=true  // Background for exploration
)

// Wait for all exploration to complete, then synthesize findings

Why background agents: Exploration tasks are independent and can run in parallel. This is MUCH faster than sequential searches.

NeedAgentWhen
Understand featureexplore + grepaiAlways before planning
Map dependenciesexplore + grepai traceWhen modifying existing code
Find patternsexplore + grepaiWhen adding similar functionality
Official docslibrarian + Context7When using external libraries

Collect all findings before moving to planning.

Tooling Note: If grepai is configured per AGENTS.md, use grepai_search and the trace tools. Otherwise instruct agents to use Grep, ast-grep, and LSP diagnostics as fallbacks.

4. Create Issue Directory

bash
mkdir -p .md/issues/<issue-number>

All artifacts for this issue will be stored in .md/issues/<issue-number>/.

5. Plan (MANDATORY)

Invoke /plan skill to create detailed implementation plan:

code
/plan

Context: Issue #<number> - <title>
<issue body summary>

IMPORTANT: The plan markdown file MUST include a footer with:
**Model**: <your exact model ID>
**Persona**: <your persona name>

Plan will be saved to .md/issues/<issue-number>/plan.md.

Iterate with Prometheus until plan is finalized and saved.

6. Implement (Delegate - NEVER Do This Yourself)

CRITICAL: You are the orchestrator. NEVER implement code yourself. Always delegate to specialized implementer subagents.

Before delegating: Log the start in beads:

bash
br comments add <bead-id> "PROGRESS: Starting implementation. Plan has N steps."

Delegate implementation and STORE THE session_id for follow-ups:

typescript
delegate_task(
  category="unspecified-high",
  load_skills=["implement"],
  description="Implement issue #<number>",
  prompt="""
1. TASK: Implement the plan for Issue #<number>
2. EXPECTED OUTCOME: All plan tasks completed, tests passing, code committed
3. REQUIRED TOOLS: Read, Write, Edit, Bash, LSP tools, grepai (semantic search)
4. MUST DO:
   - Use grepai_search to find existing patterns before writing new code (if grepai isn't configured per `AGENTS.md`, fall back to Grep/ast-grep/LSP tools)
   - Use grepai_trace_callers/callees to understand impact of changes (or the documented fallbacks if grepai is unavailable)
   - Follow the plan in .md/issues/<issue-number>/plan.md sequentially
   - Run the build/test verification command defined in `AGENTS.md` after changes (see `AGENTS.md` for build/test verification command)
   - Commit after each logical unit with conventional commit messages
   - Run the primary test command from `AGENTS.md` and ensure all tests pass before completing
   - Write any implementation notes to .md/issues/<issue-number>/
   - Every .md file you write MUST end with a metadata footer: `**Model**: <your model ID>` and `**Persona**: <your persona name>`
   - After each major step, log progress: `br comments add <bead-id> "PROGRESS: Step X/N done - <what>"`
5. MUST NOT DO:
   - Skip plan tasks
   - Leave code in broken state
   - Commit without running agent-hook
   - Implement without first searching for existing patterns (use grepai)
   - Write .md files without the model/persona metadata footer
6. CONTEXT: Branch: feature/<issue-number>-<description>, Plan: .md/issues/<issue-number>/plan.md, Beads ID: <bead-id>
""",
  run_in_background=false
)
// Output includes session_id - STORE IT!

IMPORTANT: Store the returned session_id from the output. You'll need it for:

  • Verification failures
  • Code review fixes
  • Any follow-up work

If implementation fails or needs fixes, resume the SAME session:

typescript
delegate_task(
  session_id="ses_xyz789",  // Use stored session_id
  load_skills=["implement"],
  description="Fix implementation issues",
  prompt="FAILED: {specific error}. Fix by: {specific instruction}",
  run_in_background=false
)

Why session_id? The subagent already has full context - no need to re-read files or re-explore. Saves 70%+ tokens.

7. Code Review (Delegate to intelligent reviewer, max 3 rounds)

DELEGATE the code review to a high-intelligence agent. The reviewer must form independent opinions - do NOT influence their judgment.

Preparing context for the reviewer

Before delegating, gather the raw context the reviewer needs:

bash
# Get the diff
git diff master...HEAD > /tmp/review-diff.txt

# Get the list of changed files
git diff master...HEAD --name-only

Delegating the review

typescript
delegate_task(
  category="ultrabrain",  // High-intelligence agent for rigorous review
  load_skills=["code-review"],
  description="Code review for issue #<number>",
  prompt="""
1. TASK: Perform a rigorous code review of the changes on this branch
2. EXPECTED OUTCOME: Review written to .md/issues/<issue-number>/code-review.md with a verdict (APPROVE/REQUEST CHANGES/BLOCK MERGE)
3. REQUIRED TOOLS: Read, Bash (git), Grep, grepai (semantic search), LSP diagnostics
4. MUST DO:
   - Run `git diff master...HEAD` to see all changes
   - Read every modified file completely
   - Apply ALL review criteria from the code-review skill (architecture, security, concurrency, etc.)
    - Use grepai to understand how changed code fits into the larger system (or use Grep/ast-grep/LSP diagnostics if grepai isn't configured per `AGENTS.md`)
   - Write review to .md/issues/<issue-number>/code-review.md
   - Be brutally honest - this is the last gate before merge
   - End the review .md file with a metadata footer: `**Model**: <your exact model ID>` and `**Persona**: <your persona name>`
5. MUST NOT DO:
   - Skip any review category
   - Make excuses for code quality ("it's fine for now")
   - Fix code yourself - only review and report
   - Omit the model/persona metadata footer from the review file
6. CONTEXT: Branch: feature/<issue-number>-<description>
   Changed files: <list files here>
""",
  run_in_background=false
)
// Store review_session_id for follow-up rounds

CRITICAL: Do NOT include your own opinions or concerns in the prompt. Let the reviewer discover issues independently. Only add mandatory context (branch name, file list, issue number). If there's something that absolutely must be flagged (e.g., "the user explicitly asked for X approach, don't flag that as wrong"), include it under a separate "User decisions (do not flag)" section.

Fixing review issues (DELEGATE to implementer)

code
round = 1
implementation_session_id = "ses_xyz789"  # Stored from step 6

while round <= 3:
    # DELEGATE review (above pattern)
    
    if verdict == APPROVE:
        break
    
    # DELEGATE fixes to implementer (resume their session!)
    delegate_task(
      session_id=implementation_session_id,
      load_skills=["implement"],
      description="Fix code review issues round <round>",
      prompt="""
Fix CRITICAL and REQUIRED issues from code-review-round-<round>.md:
- Issue 1: [specific fix needed]
- Issue 2: [specific fix needed]
Run agent-hook and tests after fixes.
""",
      run_in_background=false
    )
    
    round += 1

if round > 3 and verdict != APPROVE:
    STOP - escalate to user

Round priorities:

  • CRITICAL issues: Must fix before next round
  • REQUIRED issues: Must fix before next round
  • SUGGESTED issues: Fix if time permits

Key patterns:

  • Use session_id to resume the implementer for fixes (they already have full context)
  • Each review round gets a fresh ultrabrain agent (independent perspective)
  • NEVER bias the reviewer - let them find issues on their own

Code reviews saved to .md/issues/<issue-number>/code-review.md (and code-review-round-N.md for subsequent rounds).

8. Coverage Report

Run coverage and report to user:

bash
# Run the coverage command defined in AGENTS.md
# See AGENTS.md for coverage command

Report the coverage percentage to the user. Example:

"✅ Tests passing. Coverage: 94%"

9. Create PR (Delegate to gh-pr-issue-workflow)

After receiving APPROVE verdict, DELEGATE PR creation:

typescript
delegate_task(
  category="quick",
  load_skills=["git-master", "gh-pr-issue-workflow"],
  description="Create PR for issue #<number>",
  prompt="""
1. TASK: Push branch and create PR for issue #<number>
2. EXPECTED OUTCOME: PR created and linked to issue
3. REQUIRED TOOLS: Bash (git, gh commands)
4. MUST DO:
   - git push -u origin feature/<issue-number>-<description>
   - gh pr create --title "<type>: <description> (#<issue>)" --body-file <body-file>
   - Use proper Markdown formatting (see gh-pr-issue-workflow skill)
   - Link PR to issue with "Closes #<issue>"
5. MUST NOT DO: Force push, skip linking to issue
6. CONTEXT: Branch: feature/<issue-number>-<description>, Code review: APPROVED
""",
  run_in_background=false
)

Why delegate? Git operations should use git-master skill for consistency. PR body formatting should use gh-pr-issue-workflow to avoid Markdown corruption.

10. Close Beads Issue

After PR is created, close the beads tracking entry:

bash
br comments add <bead-id> "PROGRESS: PR created. All steps complete."
br close <bead-id> --reason="PR created - Closes GH#<issue-number>"
br sync --flush-only

11. Local Deploy (Optional)

Ask the user if they want to deploy locally for manual testing:

code
"¿Quieres hacer deploy local para probar manualmente?"
- Solo app: (See AGENTS.md for the local deploy command without DB)
- Con DB: (See AGENTS.md for the local deploy command with DB)
- No: Skip

12. Address PR Review Comments (Post-PR)

When the user asks to address PR feedback, follow this loop for each comment:

Fetch PR comments

bash
# Get the repo from git remote
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)

# List all review comments on the PR
gh api repos/$REPO/pulls/<pr-number>/comments --jq '.[] | {id, path, line, body, user: .user.login}'

For each comment: fix → acknowledge

code
for each comment:
    1. DELEGATE the fix to implementer (resume session_id)
    2. After fix is committed and pushed:
       - React with 🚀 to the comment
       - Reply with a brief note of what was done

    # React with rocket emoji
    gh api --method POST \
      repos/$REPO/pulls/comments/<comment_id>/reactions \
      -f content='rocket'

    # Reply explaining the fix (use --input to avoid shell issues)
    gh api --method POST \
      repos/$REPO/pulls/<pr-number>/comments \
      -f body='Fixed in <commit-sha>: <brief description of what changed>' \
      -F in_reply_to_id=<comment_id>

Delegation pattern for PR comment fixes

typescript
// Resume the implementer session — they already have full context
delegate_task(
  session_id=implementation_session_id,
  load_skills=["implement"],
  description="Fix PR comment <comment_id>",
  prompt="""
1. TASK: Address PR review comment
2. EXPECTED OUTCOME: Code fixed, tests passing, committed
3. REQUIRED TOOLS: Read, Write, Edit, Bash, LSP tools
4. MUST DO:
   - Fix the issue described in this PR comment:
     File: <path>, Line: <line>
     Comment: "<comment body>"
   - Run agent-hook and tests after fix
   - Commit with message: fix: <description> (PR feedback)
5. MUST NOT DO: Change unrelated code, skip tests
6. CONTEXT: PR #<number>, comment by @<user>
""",
  run_in_background=false
)

// After implementer confirms fix, YOU acknowledge on GitHub:
// 1. Push the changes
// 2. React + reply to the comment

Acknowledging comments — rules

SituationReactionReply
Fixed the issue🚀 rocket"Fixed in <sha>: <what changed>"
Already addressed by previous fix👍 +1"Already addressed in <sha>"
Won't fix (with reason)👀 eyes"Keeping as-is because: <reason>. Let me know if you disagree."
Need clarification😕 confused"Could you clarify? I'm not sure if you mean X or Y."

IMPORTANT: Always acknowledge EVERY comment. Never leave a reviewer hanging.

Success Criteria

  • Beads context checked (existing progress read, or new bead created) (you do this)
  • Branch created from latest master (delegated to git-master)
  • Issue context fetched and understood (you do this)
  • Related code explored (delegated to explore/librarian agents)
  • Issue directory created: .md/issues/<issue-number>/ (you do this)
  • Plan created and saved to .md/issues/<issue-number>/plan.md (delegated to /plan)
  • Implementation completed with progress logged in beads (delegated to implement skill)
  • session_id stored for follow-ups (you store this)
  • Code review APPROVE verdict received 1-3 rounds (delegated to ultrabrain + code-review skill, fixes delegated to implementer)
  • All tests pass (verified by you via the test command in AGENTS.md, fixed by subagent if needed)
  • Coverage reported to user (you run and report)
  • PR created and linked to issue (delegated to gh-pr-issue-workflow)
  • Beads issue closed with final progress note (you do this)
  • Local deploy offered optional (you offer, user decides)
  • PR review comments addressed if any (fixes delegated to implementer, acknowledgments by you via gh api)

Key Principles

As Sisyphus (orchestrator):

YOU DO:

  • Coordinate workflow phases
  • Gather raw context for delegated tasks
  • Verify outputs at each stage
  • Manage session_ids for continuity
  • Report progress to user

YOU DELEGATE (via delegate_task):

  • All git operations → quick + git-master skill
  • Code exploration → explore/librarian agents (parallel, background)
  • Planning → /plan skill (via Prometheus)
  • Implementation → unspecified-high + implement skill
  • Code review → ultrabrain + code-review skill (unbiased, independent)
  • Code fixes → resume implementer's session_id
  • PR creation → quick + git-master + gh-pr-issue-workflow skills
  • PR comment fixes → resume implementer's session_id, then acknowledge via gh api

YOU NEVER:

  • Write/edit code directly
  • Run git commands yourself
  • Implement features
  • Fix code issues yourself
  • Bias the code reviewer with your opinions