add openclaw github authoring skill

2026-03-19 14:36:38 -05:00 · 2026-03-19 14:36:38 -05:00 · 19e4b50974
commit 19e4b50974
parent 3dfd8eef7f
4 changed files with 505 additions and 0 deletions
--- a/skills/openclaw-github-authoring/SKILL.md
+++ b/skills/openclaw-github-authoring/SKILL.md
@ -0,0 +1,172 @@
+---
+name: openclaw-github-authoring
+description: Use when the user wants to create an issue or PR for `openclaw/openclaw`. The skill should run a very short, pointed interview first, collect any missing grounded details, then create the OpenClaw GitHub issue or PR for the user as soon as it has enough safe information.
+user-invocable: true
+metadata:
+  {
+    "openclaw":
+      {
+        "emoji": "🐙",
+        "requires": { "bins": ["gh"] },
+        "install":
+          [
+            {
+              "id": "brew",
+              "kind": "brew",
+              "formula": "gh",
+              "bins": ["gh"],
+              "label": "Install GitHub CLI (brew)",
+            },
+            {
+              "id": "apt",
+              "kind": "apt",
+              "package": "gh",
+              "bins": ["gh"],
+              "label": "Install GitHub CLI (apt)",
+            },
+          ],
+      },
+  }
+---
+
+# OpenClaw GitHub Authoring
+
+Use this skill only for `openclaw/openclaw`.
+
+Primary goal
+
+- Help the user create an issue or PR for `openclaw/openclaw` with as little user effort as possible while keeping the filing accurate and safe.
+
+Core policy
+
+- Default to a very short, pointed interview before filing.
+- Keep the interview small: usually 1-3 targeted questions.
+- Ask only for the information that materially improves the filing.
+- Prefer doing the drafting, cleanup, and template-mapping work yourself instead of forcing the user through each field verbatim.
+- Automatically redact obvious secrets and unnecessary PII when that can be done safely without losing the meaning needed for the filing.
+- Try recovery in this order: infer the likely filing type, sanitize obvious risky content, ask a very short grouped follow-up, then draft the strongest accurate issue or PR you can.
+- Once the filing is sufficiently grounded and safe, create it for the user instead of stopping at a draft or asking the user to submit it manually.
+- Return exact `NOT_ENOUGH_INFO` only after the brief recovery attempt still leaves the filing too weak, ambiguous, or misleading.
+- Return `BLOCKED_UNSAFE_CONTENT` only when automatic masking would materially damage correctness or the remaining content is still unsafe.
+
+Never do these
+
+- Do not file against any repo other than `openclaw/openclaw`.
+- Do not push branches.
+- Do not invent repro steps, versions, evidence, branch names, or verification details.
+- Do not leave obvious secrets or unnecessary PII unredacted if you can safely mask them yourself.
+
+Bundled copies
+
+- Bug issue: [`bug_report.yml`](./bug_report.yml)
+- Feature issue: [`feature_request.yml`](./feature_request.yml)
+- PR: [`pull_request_template.md`](./pull_request_template.md)
+
+Submission states
+
+- `NOT_ENOUGH_INFO`
+- `BLOCKED_UNSAFE_CONTENT`
+- `READY_TO_CREATE`
+- `CREATED`
+
+Default workflow
+
+1. Decide whether the request is a bug issue, feature issue, or PR.
+2. Load the copied template file for the chosen issue or PR type.
+3. Run a short targeted interview even if the initial request is terse but plausible.
+4. Prefer grouped interview questions over replaying the whole template.
+5. Stop interviewing as soon as the payload is strong enough.
+6. Draft the issue or PR body yourself using the bundled template structure instead of forcing the user to fill every field manually.
+7. If critical facts are still missing after the brief recovery attempt, return `NOT_ENOUGH_INFO`.
+8. If the payload is complete and safe, create the issue or PR with `gh` for the user; do not stop at `READY_TO_CREATE` unless actual creation is blocked.
+
+Interview policy
+
+- Prefer 1-3 grouped questions.
+- Ask the smallest number of questions that materially improves the filing.
+- Recover thin requests instead of rejecting them early when the user intent is clear.
+- For issues, prioritize:
+  - What breaks and how to reproduce it
+  - Expected vs actual behavior and exact environment
+  - Impact and evidence
+- For PRs, prioritize:
+  - Exact change summary and title
+  - Verification and evidence
+  - Branch/base context, risks, and recovery
+
+Issue requirements
+
+- Use the exact title prefix from the canonical issue template.
+- Keep the filed issue grounded in observed evidence.
+- Include only helpful optional context; avoid filler.
+- If the user gives terse but usable facts, draft the issue body for them instead of replaying every template label.
+
+PR requirements
+
+- Require:
+  - explicit PR title
+  - explicit base branch
+  - explicit head branch
+  - proof that the remote head branch already exists
+- If the remote head branch does not exist, return `NOT_ENOUGH_INFO`.
+- Preserve the canonical PR section structure in the generated body.
+- If branch context is missing, ask the smallest grouped follow-up possible before failing.
+
+Unsafe content rules
+
+Automatically mask obvious risky strings when the filing can remain accurate, including:
+
+- API keys, tokens, bearer headers, cookies, passwords, or secrets
+- email addresses
+- phone numbers
+- other unnecessary identifying personal details
+
+Use compact placeholders that preserve meaning, such as:
+
+- `[token-redacted]`
+- `[cookie-redacted]`
+- `[email-redacted]`
+- `[phone-redacted]`
+
+Return `BLOCKED_UNSAFE_CONTENT` only if:
+
+- the unsafe content cannot be removed without breaking the technical meaning
+- the remaining payload would still expose sensitive information
+- the user is trying to file content that should not be published even in redacted form
+
+Creation commands
+
+```bash
+# Issue
+gh issue create --repo openclaw/openclaw --title "$TITLE" --body-file "$BODY_FILE"
+
+# PR
+gh pr create --repo openclaw/openclaw --base "$BASE_BRANCH" --head "$HEAD_BRANCH" --title "$TITLE" --body-file "$BODY_FILE"
+```
+
+Output format
+
+Use `READY_TO_CREATE` only as a transient internal state before immediate creation, or when creation is blocked by a concrete external precondition such as missing auth or missing required PR branch context. Do not leave the user with a draft when creation can proceed.
+
+```text
+NOT_ENOUGH_INFO
+- Missing: <field label>
+- Question: <targeted question>
+```
+
+```text
+BLOCKED_UNSAFE_CONTENT
+- Field: <field label>
+- Reason: <brief reason>
+```
+
+```text
+READY_TO_CREATE
+- Type: bug issue | feature issue | pr
+- Title: <sanitized title>
+```
+
+```text
+CREATED
+- URL: https://github.com/openclaw/openclaw/...
+```
--- a/skills/openclaw-github-authoring/bug_report.yml
+++ b/skills/openclaw-github-authoring/bug_report.yml
@ -0,0 +1,137 @@
+name: Bug report
+description: Report defects, including regressions, crashes, and behavior bugs.
+title: "[Bug]: "
+labels:
+  - bug
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Prepared via the `openclaw-github-authoring` skill template copy.
+        Draft the report for the user instead of replaying the form field-by-field when the intent is already clear.
+        Keep every answer concise, reproducible, and grounded in observed evidence.
+        Automatically mask obvious secrets, tokens, cookies, passwords, emails, phone numbers, and similar sensitive strings when they are not needed verbatim.
+        Ask only a very short grouped follow-up when a few missing facts would materially improve the report.
+        If a required narrative section still cannot be grounded after that brief recovery attempt, respond with exactly `NOT_ENOUGH_INFO`.
+  - type: dropdown
+    id: bug_type
+    attributes:
+      label: Bug type
+      description: Choose the category that best matches this report.
+      options:
+        - Regression (worked before, now fails)
+        - Crash (process/app exits or hangs)
+        - Behavior bug (incorrect output/state without crash)
+    validations:
+      required: true
+  - type: textarea
+    id: summary
+    attributes:
+      label: Summary
+      description: One-sentence statement of what is broken, based only on observed evidence. If the evidence is insufficient, respond with exactly `NOT_ENOUGH_INFO`.
+      placeholder: After upgrading from 2026.2.10 to 2026.2.17, Telegram thread replies stopped posting; reproduced twice and confirmed by gateway logs.
+    validations:
+      required: true
+  - type: textarea
+    id: repro
+    attributes:
+      label: Steps to reproduce
+      description: Provide the shortest deterministic repro path supported by direct observation. If the repro path cannot be grounded from the evidence, respond with exactly `NOT_ENOUGH_INFO`.
+      placeholder: |
+        1. Start OpenClaw 2026.2.17 with the attached config.
+        2. Send a Telegram thread reply in the affected chat.
+        3. Observe no reply and confirm the attached `reply target not found` log line.
+    validations:
+      required: true
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behavior
+      description: State the expected result using a concrete reference such as prior observed behavior, attached docs, or a known-good version. If no grounded reference exists, respond with exactly `NOT_ENOUGH_INFO`.
+      placeholder: In 2026.2.10, the agent posted replies in the same Telegram thread under the same workflow.
+    validations:
+      required: true
+  - type: textarea
+    id: actual
+    attributes:
+      label: Actual behavior
+      description: Describe only the observed result, including user-visible errors and cited evidence. If the observed result cannot be grounded from the evidence, respond with exactly `NOT_ENOUGH_INFO`.
+      placeholder: No reply is posted in the thread; the attached gateway log shows `reply target not found` at 14:23:08 UTC.
+    validations:
+      required: true
+  - type: input
+    id: version
+    attributes:
+      label: OpenClaw version
+      description: Exact version/build tested.
+      placeholder: <version such as 2026.2.17>
+    validations:
+      required: true
+  - type: input
+    id: os
+    attributes:
+      label: Operating system
+      description: OS and version where this occurs.
+      placeholder: macOS 15.4 / Ubuntu 24.04 / Windows 11
+    validations:
+      required: true
+  - type: input
+    id: install_method
+    attributes:
+      label: Install method
+      description: How OpenClaw was installed or launched.
+      placeholder: npm global / pnpm dev / docker / mac app
+  - type: input
+    id: model
+    attributes:
+      label: Model
+      description: Effective model under test.
+      placeholder: minimax/text-01 / openrouter/anthropic/claude-opus-4.1 / anthropic/claude-sonnet-4.5
+    validations:
+      required: true
+  - type: input
+    id: provider_chain
+    attributes:
+      label: Provider / routing chain
+      description: Effective request path through gateways, proxies, providers, or model routers.
+      placeholder: openclaw -> cloudflare-ai-gateway -> minimax
+    validations:
+      required: true
+  - type: textarea
+    id: provider_setup_details
+    attributes:
+      label: Additional provider/model setup details
+      description: Optional. Include redacted routing details, per-agent overrides, auth-profile interactions, env/config context, or anything else needed to explain the effective provider/model setup. Do not include API keys, tokens, or passwords.
+      placeholder: |
+        Default route is openclaw -> cloudflare-ai-gateway -> minimax.
+        Previous setup was openclaw -> cloudflare-ai-gateway -> openrouter -> minimax.
+        Relevant config lives in ~/.openclaw/openclaw.json under models.providers.minimax and models.providers.cloudflare-ai-gateway.
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs, screenshots, and evidence
+      description: Include the logs, screenshots, recordings, docs, or version comparisons that support the grounded answers above. Automatically redact obvious secrets and unnecessary PII before filing.
+      render: shell
+  - type: textarea
+    id: impact
+    attributes:
+      label: Impact and severity
+      description: |
+        Explain who is affected, how severe it is, how often it happens, and the practical consequence using only observed evidence.
+        If any part cannot be grounded from the evidence, respond with exactly `NOT_ENOUGH_INFO`.
+        Include:
+        - Affected users/systems/channels
+        - Severity (annoying, blocks workflow, data risk, etc.)
+        - Frequency (always/intermittent/edge case)
+        - Consequence (missed messages, failed onboarding, extra cost, etc.)
+      placeholder: |
+        Affected: Telegram group users on 2026.2.17
+        Severity: High (blocks thread replies)
+        Frequency: 4/4 observed attempts
+        Consequence: Agents do not respond in the affected threads
+  - type: textarea
+    id: additional_information
+    attributes:
+      label: Additional information
+      description: Add any remaining grounded context that helps triage but does not fit above. If this is a regression, include the last known good and first known bad versions when observed. If there is still not enough evidence after a brief targeted follow-up, respond with exactly `NOT_ENOUGH_INFO`.
+      placeholder: Last known good version 2026.2.10, first known bad version 2026.2.17, temporary workaround is sending a top-level message instead of a thread reply.
--- a/skills/openclaw-github-authoring/feature_request.yml
+++ b/skills/openclaw-github-authoring/feature_request.yml
@ -0,0 +1,74 @@
+name: Feature request
+description: Propose a new capability or product improvement.
+title: "[Feature]: "
+labels:
+  - enhancement
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Prepared via the `openclaw-github-authoring` skill template copy.
+        Draft the request for the user instead of replaying the form field-by-field when the intent is already clear.
+        Help evaluate the request with concrete use cases and tradeoffs.
+        Automatically mask obvious secrets and unnecessary PII before filing.
+        Ask only a very short grouped follow-up when a few missing facts would materially improve the request.
+  - type: textarea
+    id: summary
+    attributes:
+      label: Summary
+      description: One-line statement of the requested capability.
+      placeholder: Add per-channel default response prefix.
+    validations:
+      required: true
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem to solve
+      description: What user pain this solves and why current behavior is insufficient. Recover terse requests into a concrete problem statement when the user intent is clear.
+      placeholder: Agents cannot distinguish persona context in mixed channels, causing misrouted follow-ups.
+    validations:
+      required: true
+  - type: textarea
+    id: proposed_solution
+    attributes:
+      label: Proposed solution
+      description: Desired behavior/API/UX with as much specificity as possible. Draft the strongest accurate proposal you can from the user’s intent and a brief follow-up if needed.
+      placeholder: Support channels.<channel>.responsePrefix with default fallback and account-level override.
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered
+      description: Other approaches considered and why they are weaker.
+      placeholder: Manual prefixing in prompts is inconsistent and hard to enforce.
+  - type: textarea
+    id: impact
+    attributes:
+      label: Impact
+      description: |
+        Explain who is affected, severity/urgency, how often this pain occurs, and practical consequences.
+        Include:
+        - Affected users/systems/channels
+        - Severity (annoying, blocks workflow, etc.)
+        - Frequency (always/intermittent/edge case)
+        - Consequence (delays, errors, extra manual work, etc.)
+      placeholder: |
+        Affected: Multi-team shared channels
+        Severity: Medium
+        Frequency: Daily
+        Consequence: +20 minutes/day/operator and delayed alerts
+    validations:
+      required: true
+  - type: textarea
+    id: evidence
+    attributes:
+      label: Evidence/examples
+      description: Prior art, links, screenshots, logs, or metrics. Automatically redact obvious secrets and unnecessary PII before filing.
+      placeholder: Comparable behavior in X, sample config, and screenshot of current limitation.
+  - type: textarea
+    id: additional_information
+    attributes:
+      label: Additional information
+      description: Extra context, constraints, or references not covered above. If a small targeted follow-up still does not produce enough grounded substance for the request, respond with exactly `NOT_ENOUGH_INFO`.
+      placeholder: Must remain backward-compatible with existing config keys.
--- a/skills/openclaw-github-authoring/pull_request_template.md
+++ b/skills/openclaw-github-authoring/pull_request_template.md
@ -0,0 +1,122 @@
+Prepared via the `openclaw-github-authoring` skill template copy.
+
+Draft this PR body for the user instead of replaying every heading as a questionnaire when the intent is already clear.
+Ask only a very short grouped follow-up for missing high-value facts such as branch context, verification, or risk.
+Automatically redact obvious secrets, tokens, cookies, passwords, emails, phone numbers, and similar sensitive strings before filing when the technical meaning remains intact.
+If explicit title, base branch, head branch, or proof of an existing remote head branch is still missing after the brief follow-up, respond with exactly `NOT_ENOUGH_INFO`.
+
+## Summary
+
+Describe the problem and fix in 2–5 bullets:
+
+- Problem:
+- Why it matters:
+- What changed:
+- What did NOT change (scope boundary):
+
+## Change Type (select all)
+
+- [ ] Bug fix
+- [ ] Feature
+- [ ] Refactor
+- [ ] Docs
+- [ ] Security hardening
+- [ ] Chore/infra
+
+## Scope (select all touched areas)
+
+- [ ] Gateway / orchestration
+- [ ] Skills / tool execution
+- [ ] Auth / tokens
+- [ ] Memory / storage
+- [ ] Integrations
+- [ ] API / contracts
+- [ ] UI / DX
+- [ ] CI/CD / infra
+
+## Linked Issue/PR
+
+- Closes #
+- Related #
+
+## User-visible / Behavior Changes
+
+List user-visible changes (including defaults/config).  
+If none, write `None`.
+
+## Security Impact (required)
+
+- New permissions/capabilities? (`Yes/No`)
+- Secrets/tokens handling changed? (`Yes/No`)
+- New/changed network calls? (`Yes/No`)
+- Command/tool execution surface changed? (`Yes/No`)
+- Data access scope changed? (`Yes/No`)
+- If any `Yes`, explain risk + mitigation:
+
+## Repro + Verification
+
+### Environment
+
+- OS:
+- Runtime/container:
+- Model/provider:
+- Integration/channel (if any):
+- Relevant config (redacted):
+
+### Steps
+
+1.
+2.
+3.
+
+### Expected
+
+-
+
+### Actual
+
+-
+
+## Evidence
+
+Attach at least one:
+
+- [ ] Failing test/log before + passing after
+- [ ] Trace/log snippets
+- [ ] Screenshot/recording
+- [ ] Perf numbers (if relevant)
+
+## Human Verification (required)
+
+What you personally verified (not just CI), and how:
+
+- Verified scenarios:
+- Edge cases checked:
+- What you did **not** verify:
+
+## Review Conversations
+
+- [ ] I replied to or resolved every bot review conversation I addressed in this PR.
+- [ ] I left unresolved only the conversations that still need reviewer or maintainer judgment.
+
+If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.
+
+## Compatibility / Migration
+
+- Backward compatible? (`Yes/No`)
+- Config/env changes? (`Yes/No`)
+- Migration needed? (`Yes/No`)
+- If yes, exact upgrade steps:
+
+## Failure Recovery (if this breaks)
+
+- How to disable/revert this change quickly:
+- Files/config to restore:
+- Known bad symptoms reviewers should watch for:
+
+## Risks and Mitigations
+
+List only real risks for this PR. Add/remove entries as needed. If none, write `None`.
+
+- Risk:
+  - Mitigation: