[MattieTK]

When a skill gives incorrect, outdated, or missing guidance, agents have no instructions for reporting it to the maintainers. This adds a short reference that lets an agent turn that report into a GitHub issue, with the user's agreement.

Changes

• Each skill gets references/skill-feedback.md. It tells the agent to:
  1. ask whether the user wants to send feedback
  2. draft an issue from the conversation using a field table: type, skill, source file and section, agent, task, expected, actual, impact, suggested fix
  3. show the user the exact title and body and ask a yes/no question before posting; agreeing to send feedback is not approval of the text
  4. create it on cloudflare/skills with a skill-feedback: <skill>: <summary> title
  5. share the issue URL, or give the approved issue and the issues/new link if submission fails
• The reference opens with a reminder that issues are public. A "What not to include" section lists what to remove before drafting: credentials and tokens, account and zone IDs, customer or personal data, internal hostnames and URLs, and private code, configuration, and logs.
• Each SKILL.md ends with a ## Skill feedback section that links to the reference.
• The turnstile-spin README layout table lists the new file.

The reference is copied into every skill rather than shared, because skills can be installed individually (for example with npx skills or by copying folders). Each copy contains its own skill name so issues can be triaged by skill.

The skill-feedback: prefix makes these issues searchable without new labels or issue templates. We can add those later if the volume justifies it.

Testing

• python3 .github/scripts/check-reference-code-blocks.py reports no warnings for the new files.
• turnstile-spin tests pass (python3 -m unittest discover -s skills/turnstile-spin/tests).
• A script confirmed that each SKILL.md links to an existing references/skill-feedback.md exactly once, and that the copies differ only in the skill name.

[kale-stew]

Nice addition, and the per-skill copies make sense given skills install individually. I checked that all 19 SKILL.md files link the reference exactly once and that each copy names its own skill; the copies are otherwise identical, so the two comments below apply to every references/skill-feedback.md.

Both are about the one irreversible step here: posting conversation-derived content to a public issue.

1. The only data guidance is the general reminder on line 3. Since step 2 drafts the body from the conversation, it would help to name what must never go in: credentials or tokens, account or zone IDs, customer or personal data, internal hostnames or URLs, and private code.
2. Line 3 says to review the submission with the user, but the numbered steps go straight from drafting (step 2) to gh issue create (step 3). An agent following the steps can read the step 1 "yes" as approval to post text the user hasn't seen. A separate step that shows the exact title and body and asks for confirmation would close that gap.

Reviewed at 0e09df4.