From 19e4b5097469fc97b646b85c1a799cdc241e093e Mon Sep 17 00:00:00 2001 From: Tak Hoffman <781889+Takhoffman@users.noreply.github.com> Date: Thu, 19 Mar 2026 14:36:38 -0500 Subject: [PATCH] add openclaw github authoring skill --- skills/openclaw-github-authoring/SKILL.md | 172 ++++++++++++++++++ .../openclaw-github-authoring/bug_report.yml | 137 ++++++++++++++ .../feature_request.yml | 74 ++++++++ .../pull_request_template.md | 122 +++++++++++++ 4 files changed, 505 insertions(+) create mode 100644 skills/openclaw-github-authoring/SKILL.md create mode 100644 skills/openclaw-github-authoring/bug_report.yml create mode 100644 skills/openclaw-github-authoring/feature_request.yml create mode 100644 skills/openclaw-github-authoring/pull_request_template.md diff --git a/skills/openclaw-github-authoring/SKILL.md b/skills/openclaw-github-authoring/SKILL.md new file mode 100644 index 00000000000..60e22cb459e --- /dev/null +++ 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: +- Question: +``` + +```text +BLOCKED_UNSAFE_CONTENT +- Field: +- Reason: +``` + +```text +READY_TO_CREATE +- Type: bug issue | feature issue | pr +- Title: +``` + +```text +CREATED +- URL: https://github.com/openclaw/openclaw/... +``` diff --git a/skills/openclaw-github-authoring/bug_report.yml b/skills/openclaw-github-authoring/bug_report.yml new file mode 100644 index 00000000000..3d940311753 --- /dev/null +++ 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: + 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. diff --git a/skills/openclaw-github-authoring/feature_request.yml b/skills/openclaw-github-authoring/feature_request.yml new file mode 100644 index 00000000000..ccf5c3945e3 --- /dev/null +++ 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..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. diff --git a/skills/openclaw-github-authoring/pull_request_template.md b/skills/openclaw-github-authoring/pull_request_template.md new file mode 100644 index 00000000000..570910862ec --- /dev/null +++ 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: