Dont anger mario

Skill dannote/dot-pi/skills/extra/dont-anger-mario

Curated Pi package with extensions, skills, prompt shortcuts, and rules

Install

npx -y skills add dannote/dot-pi --skill dont-anger-mario

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Prepare concise, high-signal issues or contribution proposals for the pi repository without annoying maintainers. Use when filing issues/PR proposals for earendil-works/pi or mentioning Mario/pi tracker etiquette.

SKILL.md

3.5 KB, as published. Nobody here has run it

Don't Anger Mario

Use this skill before opening an issue or contribution proposal in earendil-works/pi.

Rules

Read CONTRIBUTING.md first.
Use an official issue template; blank issues are disabled.
Keep it short. If it does not fit on one screen, it is too long.
Write in the user's own voice, not corporate/AI slop.
Be concrete: what, why, and optionally how.
Do not submit automatically.
Before submitting, ask the user to confirm they carefully read the exact final draft and explicitly approve posting it.
If proposing a change, use Contribution Proposal rather than Bug Report.
If reporting a bug, include minimal repro and version.
If opening a PR, only proceed after maintainer approval (lgtm for PRs; lgtmi is issues only).
Do not send agent-only PRs. If the user cannot explain the change without the agent, stop.

Safe workflow

Inspect templates and contributing docs:

gh api repos/earendil-works/pi/contents/.github/ISSUE_TEMPLATE --jq '.[].name'
gh api repos/earendil-works/pi/contents/CONTRIBUTING.md --jq .content | base64 --decode

Draft the issue body in /tmp, never inline long Markdown through shell quoting:

cat > /tmp/pi-issue.md <<'EOF'
### What do you want to change?

...

### Why?

...

### How? (optional)

...
EOF

Show the exact final title and body to the user.
Ask for explicit approval with this wording:

Please read the draft carefully. Do you explicitly approve me posting this issue/proposal as written?

Do not proceed on vague approval like "ok" if the user has not seen the exact final draft.

Create only after explicit approval:

gh issue create \
  --repo earendil-works/pi \
  --template contribution.yml \
  --title "Short concrete title" \
  --body-file /tmp/pi-issue.md

Extra caution from prior tracker behavior

Known maintainer reactions that shape this workflow:

Auto-close gate is intentional; maintainers review closed issues later.
GitHub Actions outages can let the issue/PR gate fail and flood the repo.
Maintainers dislike agent-only PRs because they take time to review and are often broken.
"Clanker misunderstood the code" is a real failure mode; verify the claim before drafting.
A label/comment like possibly-openclaw-clanker is a warning sign: shorten, verify, and make the human reasoning obvious.

Useful receipts:

https://github.com/earendil-works/pi/issues/3589 — "very tired of clankers"
https://github.com/earendil-works/pi/issues/5259 — "your clanker misunderstood"
https://github.com/earendil-works/pi/pull/2666 — "You and your clanker are banned"
https://github.com/earendil-works/pi/pull/5296 — "please do not send more agent only PRs"

Good contribution proposal shape

### What do you want to change?

One concrete change.

### Why?

The user-visible problem and why it matters.

### How? (optional)

Small implementation sketch, if useful. Avoid over-design.

Tone

Good:

Prompt templates support $1 and $ARGUMENTS, but optional arguments cannot have defaults. I want /next and /next 3 to expand cleanly without asking the model to interpret an empty argument.

Bad:

Implement advanced Bash-compatible templating with all parameter expansion semantics, conditionals, filters, and expression evaluation.