Compare commits

...

5 Commits

Author SHA1 Message Date
Tak Hoffman
c34a9fea78
rename github authoring skill to openclaw feedback 2026-03-20 16:49:56 -05:00
Tak Hoffman
408f3ffbeb
tighten security and pr branch guidance 2026-03-19 15:11:12 -05:00
Tak Hoffman
997b440e32
fix authoring skill review edge cases 2026-03-19 15:00:36 -05:00
Tak Hoffman
6b3a1ea8e4
address github authoring skill review feedback 2026-03-19 14:54:23 -05:00
Tak Hoffman
19e4b50974
add openclaw github authoring skill 2026-03-19 14:36:38 -05:00
3 changed files with 366 additions and 0 deletions

View File

@ -0,0 +1,155 @@
---
name: openclaw-feedback
description: Use when the user wants to report a problem, give feedback, or file an issue for `openclaw/openclaw`. The skill should run a very short, pointed interview first, collect any missing grounded details, then create the OpenClaw GitHub issue 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)",
},
],
},
}
---
# OpenClaw Feedback
Use this skill only for `openclaw/openclaw`.
Primary goal
- Help the user create an issue 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.
- If the request is actually a vulnerability report, leaked credential report, or other security disclosure, do not create a public GitHub issue. Route it to the private reporting path in `SECURITY.md` instead.
- 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 you can.
- Once the issue 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, 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)
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 a private security disclosure. If it is an issue, also set `$LABEL` to `bug` or `enhancement` to match the bundled template.
2. Load the copied template file for the chosen issue 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 body yourself using the bundled template structure instead of forcing the user to fill every field manually.
7. If the request is a private security disclosure, follow `SECURITY.md`: prepare the private report using the required fields there, direct the user to report privately to `security@openclaw.ai` when needed, and do not publish the details in a public issue.
8. If critical facts are still missing after the brief recovery attempt, return `NOT_ENOUGH_INFO`.
9. If the payload is complete and safe, create the issue 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 bug issues, prioritize:
- What breaks and how to reproduce it
- Expected vs actual behavior and exact environment
- Impact and evidence
- For feature issues, prioritize:
- Problem to solve
- Proposed solution and alternatives
- Impact and evidence
Issue requirements
- Infer bug vs feature when the user intent is clear, otherwise ask the smallest targeted follow-up possible.
- Use the exact title prefix from the chosen 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.
- Preserve the canonical issue label:
- bug issue -> `bug`
- feature issue -> `enhancement`
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 command
```bash
gh issue create --repo openclaw/openclaw --title "$TITLE" --label "$LABEL" --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. 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
- Title: <sanitized title>
```
```text
CREATED
- URL: https://github.com/openclaw/openclaw/...
```

View File

@ -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-feedback` 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.

View File

@ -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-feedback` 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 users 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.