Skill: shunsukehayashi/prompt-request (version 1.0.0)

--- name: prompt-request description: > GitHub Issue → auto-implement → PR → review → auto-merge pipeline. Write an Issue with [auto] tag, and the pipeline handles everything: task analysis, implementation, testing, PR creation, review, and merge. Includes progress comments on Issues and early-exit optimization. version: 1.0.0 author: ShunsukeHayashi tags: [github, webhook, automation, pipeline, prompt-request] --- # Prompt Request Pipeline Issue を書くだけで、自動実装 → PR → レビュー → マージまで全自動で回るパイプライン。 ## Overview ``` [auto] Issue 起票 → 🚀 実装開始コメント → Phase A: タスク分解（Omega-bridge or Issue本文） → 📋 分析完了コメント → Phase B: 実装 + テスト → ✅ 実装完了コメント → Phase C: commit → push → PR作成 → 🔗 PR作成コメント → 自動レビュー → 自動マージ → Issue close ``` ## Prerequisites - OpenClaw Gateway running with hooks enabled - GitHub CLI (`gh`) authenticated - Git SSH access to target repository - GitHub Webhook pointing to OpenClaw hooks endpoint ## Setup ### 1. Register GitHub Webhook On your GitHub repo → Settings → Webhooks → Add webhook: - **Payload URL**: `https://<your-openclaw-endpoint>/hooks/github` - **Content type**: `application/json` - **Secret**: Your OpenClaw hooks token - **Events**: Select individual events: - Issues - Pull requests - Pull request reviews - Check runs - Issue comments - Push ### 2. Configure OpenClaw hooks Add this to your `openclaw.json` under `hooks.mappings`: ```json { "match": { "path": "github" }, "action": "agent", "name": "GitHub", "sessionKey": "hook:github:{{repository.name}}:{{headers.x-github-event}}:{{issue.number}}{{pull_request.number}}{{check_run.id}}", "messageTemplate": "<see templates/messageTemplate.txt>", "deliver": true, "allowUnsafeExternalContent": true, "channel": "telegram", "to": "<your-chat-id>", "model": "anthropic/claude-opus-4-6", "thinking": "high", "timeoutSeconds": 900 } ``` ### 3. Set working directory In the messageTemplate, replace the working directory path: - `WORKDIR` variable: where repositories are cloned (e.g., `C:\Users\you\Dev` or `/home/you/dev`) ### 4. (Optional) Omega-bridge If you have Miyabi's omega-bridge for SWML-based task decomposition: - Set the path to `omega-bridge.ts` in the messageTemplate - If not available, the pipeline falls back to implementing directly from Issue body ## Usage ### Basic: Create an [auto] Issue ```markdown Title: [auto] Add utility function X Body: ## Requirements - Create scripts/x.sh with function do_x() - Add tests in tests/test-x.sh ## Acceptance Criteria - Function returns expected output - Tests pass ``` ### Advanced: With agent personality ```markdown Title: [auto] [content] Write article about Y Body: Read agents/content-agent/AGENTS.md and SOUL.md first. Follow the rules defined there. ## Topic ... ## Output - File: articles/y.md - Word count: 6000 ``` ### Advanced: With skill reference ```markdown Title: [auto] Generate report with weather data Body: Read skills/weather/SKILL.md for API usage. ## Requirements ... ``` ## How It Works ### Issue Events (action=opened) 1. **Early exit check**: If action is closed/labeled/etc → 1-line reply, stop 2. **[auto] check**: Title starts with `[auto]` or body contains `<!-- auto-implement -->` 3. **Phase A**: Task decomposition (omega-bridge or direct) 4. **Phase B**: Implementation (branch, code, test) 5. **Phase C**: Integration (commit, push, PR) 6. Progress comments posted at each phase ### PR Events (action=opened/synchronize) 1. Skip bot senders (loop prevention) 2. Diff review for quality/security 3. Auto-merge if ALL conditions met: - PR title contains `[auto]` or branch starts with `feature/issue-` - Review is LGTM - CI checks pass (or empty = pass) - No merge conflicts ### Safety Rules - Never force push - Never push directly to main - Never run permission commands (icacls/chmod/chown) - Max 3 CI fix retries per PR - Bot sender events are skipped ## Configuration Options | Option | Default | Description | |--------|---------|-------------| | `model` | `claude-opus-4-6` | Model for hook sessions | | `thinking` | `high` | Thinking level | | `timeoutSeconds` | `900` | Max execution time (15 min) | | `deliver` | `true` | Send results to chat | | `channel` | `telegram` | Delivery channel | ## Performance (measured) | Metric | Before optimization | After optimization | |--------|--------------------|--------------------| | close/push events | 8-12 min, ~500 tokens | 3 sec, ~15 tokens | | [auto] Issue → merged PR | N/A (stuck) | ~5 min | | Full pipeline (Issue → merge) | N/A | ~5 min | ## Tips - **Keep Issues small**: 1 Issue = 1 clear deliverable, ≤300 lines of diff - **Be specific**: The quality of the Issue body directly determines output quality - **Use templates**: Create Issue templates for recurring task types - **Reference skills**: Point the agent to relevant SKILL.md files for domain knowledge - **Reference agent definitions**: Store AGENTS.md/SOUL.md in the repo for consistent behavior

path: examples/sample-hook-config.json
content: {
  "hooks": {
    "enabled": true,
    "path": "/hooks",
    "token": "<generate-a-secure-token>",
    "mappings": [
      {
        "match": { "path": "github" },
        "action": "agent",
        "name": "GitHub",
        "sessionKey": "hook:github:{{repository.name}}:{{headers.x-github-event}}:{{issue.number}}{{pull_request.number}}{{check_run.id}}",
        "messageTemplate": "<paste contents of templates/messageTemplate.txt here, replacing WORKDIR with your actual path>",
        "deliver": true,
        "allowUnsafeExternalContent": true,
        "channel": "telegram",
        "to": "<your-chat-id>",
        "model": "anthropic/claude-opus-4-6",
        "thinking": "high",
        "timeoutSeconds": 900
      }
    ]
  }
}


path: templates/issue-content.md
content: ---
name: Content generation Issue
description: Issue template for article/content creation tasks
---

# [auto] [content] <TITLE>

## Agent Instructions
Read agents/content-agent/AGENTS.md and SOUL.md first.

## Content Specification
- **Type**: article / blog post / documentation / landing page
- **Target platform**: note.com / GitHub / website
- **Word count**: <number>
- **Tone**: <casual / professional / technical / emotional>
- **Language**: <ja / en>

## Topic & Context
<What the article is about. Key points to cover.>

## Structure (optional)
1. Introduction — <angle>
2. Section A — <key point>
3. Section B — <key point>
4. Conclusion — <call to action>

## SEO (optional)
- **Target keywords**: <keyword1>, <keyword2>
- **Target audience**: <who reads this>
- **Search intent**: <informational / transactional / navigational>

## Assets
- Insert `[--IMAGE--]` at positions where images should go
- Amazon Associate tag: `tag=<your-tag>`
- Include relevant product links as CTAs

## Output
- File: `content/<filename>.md`
- Format: Markdown


path: templates/issue-detailed.md
content: ---
name: Detailed auto-implement Issue
description: High-precision Issue template for maximum output quality
---

# [auto] <TITLE>

## Context
<Why this task exists. What problem it solves.>

## Agent Instructions (optional)
Read agents/<agent-name>/AGENTS.md and SOUL.md first.
Read skills/<skill-name>/SKILL.md for domain-specific instructions.

## File Structure
- `path/to/new-file.ext` — <description>
- `path/to/existing-file.ext` — <what to modify>

## Detailed Specification

### Function/Module Signatures
```
function_name(param1: type, param2: type) → return_type
  - description of behavior
  - error handling: <what to do on failure>
```

### Integration Points
- <which existing files/functions this connects to>
- <specific line numbers or function names if known>

### Test Cases
1. Input: X → Expected output: Y
2. Input: Z → Expected output: W
3. Edge case: <description> → Expected: <behavior>

## Acceptance Criteria
- [ ] All specified files created/modified
- [ ] All test cases pass
- [ ] No regressions in existing tests
- [ ] Code follows project conventions

## Constraints
- Max diff size: ~300 lines
- Timeout: 15 minutes
- Dependencies: <list any required packages or tools>


path: templates/issue-simple.md
content: ---
name: Simple auto-implement Issue
description: Minimal Issue template for straightforward tasks
---

# [auto] <TITLE>

## Requirements
- <what to build>
- <files to create/modify>

## Acceptance Criteria
- <how to verify it works>
- <test expectations>


path: templates/messageTemplate.txt
content: GitHub {{headers.x-github-event}} event (action: {{action}})
Repo: {{repository.full_name}}
Sender: {{sender.login}}

## Issue/PR Info
Title: {{issue.title}}{{pull_request.title}}{{check_run.name}}
Number: #{{issue.number}}{{pull_request.number}}
Labels: {{issue.labels}}{{pull_request.labels}}
URL: {{issue.html_url}}{{pull_request.html_url}}{{check_run.html_url}}

Body:
{{issue.body}}{{pull_request.body}}{{check_run.output.summary}}

## EARLY EXIT RULES (check FIRST before doing anything):
- If action is 'closed', 'deleted', 'edited', 'labeled', 'unlabeled', 'assigned', 'unassigned', 'milestoned', 'demilestoned', 'transferred', or 'pinned': Reply with a ONE-LINE summary (e.g. 'Issue #X closed. No action needed.') and STOP. Do NOT analyze, review, or process further.
- If the event is 'push': Reply 'Push event noted.' and STOP.
- If sender.login is a bot or contains '[bot]': Reply 'Bot event skipped.' and STOP.
- ONLY continue to the full instructions below if the event requires actual work (issues:opened, pull_request:opened/synchronize, check_run:failure, issue_comment with actionable content).

## Instructions
You are an AI automation agent.
The repository is: {{repository.full_name}} (clone name: {{repository.name}})
Your working directory is WORKDIR/{{repository.name}}.
If the directory does not exist, clone it first: git clone [REDACTED_SECRET]:{{repository.full_name}}.git WORKDIR/{{repository.name}}
You MUST execute the instructions below. Do NOT just notify - actually DO the work.

### For issues events (action=opened):
CHECK: Does the title start with '[auto]' OR does the body contain '<!-- auto-implement -->'?

IF YES - MANDATORY AUTO-IMPLEMENT SEQUENCE (do ALL steps, do NOT skip any):

**Phase A: Structural Analysis**
0. Post start comment: gh issue comment {{issue.number}} --repo {{repository.full_name}} --body '🚀 Auto-implementation started by Prompt Request pipeline.'
1. cd WORKDIR/{{repository.name}}
2. (Optional) Run task decomposition if omega-bridge is available:
   exec("npx tsx OMEGA_BRIDGE_PATH --issue {{issue.number}} --repo {{repository.full_name}}")
   If omega-bridge fails or is not configured, skip to Phase B step 7 and implement directly from the issue description.
3. Parse the JSON stdout output. Extract the 'tasks' array and 'omega.intermediates.allocation' section.
4. Post analysis comment: gh issue comment {{issue.number}} --repo {{repository.full_name}} --body '📋 Phase A complete: Task analysis done. Starting implementation...'

**Phase B: Execution (actual implementation)**
5. git fetch origin && git checkout main && git pull origin main
6. git checkout -b feature/issue-{{issue.number}}
7. Read the issue requirements carefully
8. Using the task list from omega-bridge (or the issue body if omega-bridge was skipped) as your implementation plan, implement each meaningful task (skip meta tasks titled 'overview', 'design doc', 'completion criteria', etc.).
9. Run existing tests if they exist (look for test scripts, package.json test commands, etc.)

**Phase C: Integration**
9.5. Post implementation comment: gh issue comment {{issue.number}} --repo {{repository.full_name}} --body '✅ Phase B complete: Implementation done. Pushing and creating PR...'
10. git add -A && git commit -m 'feat: implement {{issue.title}} (Closes #{{issue.number}})'
11. git push origin feature/issue-{{issue.number}}
12. gh pr create --title 'feat: {{issue.title}}' --body 'Closes #{{issue.number}}\n\nAuto-implemented by Prompt Request pipeline.\nRepo: {{repository.full_name}}' --base main --repo {{repository.full_name}}
13. Post PR comment: gh issue comment {{issue.number}} --repo {{repository.full_name}} --body '🔗 PR created. Auto-review and merge in progress...'
14. Log the PR URL (do NOT use message tool or react - deliver handles notifications automatically)

IF NO - Just log results (do NOT use message tool or react) about the new issue (title, body summary, URL).

### For pull_request events (action=opened/synchronize):
1. SKIP if sender is a bot (prevent infinite loops)
2. cd WORKDIR/{{repository.name}}
3. Run: gh pr diff {{pull_request.number}} --repo {{repository.full_name}}
4. Review code quality, security, test coverage
5. Post review: gh pr review {{pull_request.number}} --repo {{repository.full_name}} --comment --body '<your review>'
6. AUTO-MERGE CHECK: If ALL of these are true, merge the PR automatically:
   a. The PR title contains '[auto]' OR the PR body contains 'auto-implement' OR the source branch starts with 'feature/issue-'
   b. Your review verdict is LGTM (no security issues, no bugs found)
   c. Run: gh pr checks {{pull_request.number}} --repo {{repository.full_name}} --json name,state | If the result is empty (no CI configured), treat this condition as PASSED. If checks exist, verify all states are SUCCESS or SKIPPED.
   d. Run: gh pr view {{pull_request.number}} --repo {{repository.full_name}} --json mergeable | check mergeable is MERGEABLE (no conflicts)
   If ALL conditions pass: gh pr merge {{pull_request.number}} --repo {{repository.full_name}} --squash --delete-branch
   If ANY condition fails: log why auto-merge was skipped (do NOT use message tool)
7. Log results (do NOT use message tool or react - deliver handles notifications automatically)

### For check_run events (action=completed, conclusion=failure):
1. cd WORKDIR/{{repository.name}}
2. Get failed logs: gh run view <run_id> --log-failed
3. Analyze the error
4. If auto-fixable (lint, simple test fix): fix, commit, push (max 3 retries per PR)
5. If not: log error analysis (do NOT use message tool or react - deliver handles notifications automatically)
6. NEVER push directly to main branch

### For issue_comment events:
1. If comment is on a PR and requests changes: address the feedback by implementing changes
2. Otherwise: log results (do NOT use message tool or react)

### Safety rules:
- NEVER force push
- NEVER push directly to main (always use feature branches)
- NEVER run icacls/chmod/chown
- NEVER stop the gateway
- Use 'trash' instead of 'rm'
- Max 3 CI fix retries per PR
- Skip events from bot senders to prevent loops
- Always cd to repo dir before git commands
- Always include --repo {{repository.full_name}} in gh commands to ensure correct repo targeting


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: suspicious | SkillSpector: suspicious (HIGH)