dispute-respond
Skill97 starsChanged 34 days agoApache-2.0View on GitHub
Prepare and explicitly file an evidence-bound payment dispute response using native receipt proof, approval, provider execution, and independent readback.
In this repository94 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- runxSkill
- adopt-skillSkill
- agencySkill
- answer-from-docsSkill
- attention-reviewSkill
- audit-receiptSkill
- brand-voiceSkill
- business-opsSkill
- chargeSkill
- chief-of-staffSkill
- cold-outreachSkill
- content-pipelineSkill
- contract-drafterSkill
- conversation-replySkill
- conversation-reviewSkill
- crm-cleanupSkill
- cve-auditSkill
- data-storeSkill
- data-subject-requestSkill
- deep-researchSkill
- diagnose-skill-runSkill
- ecosystem-briefSkill
- extractSkill
- ghostwriteSkill
- github-pr-commentSkill
- github-pr-reviewSkill
- github-syncSkill
- google-analyticsSkill
- google-calendarSkill
- google-search-consoleSkill
- governed-outboundSkill
- helpdeskSkill
- incident-commanderSkill
- issue-intakeSkill
- issue-to-prSkill
- issue-triageSkill
- knowledge-routerSkill
- lead-enrichmentSkill
- lead-qualifySkill
- least-privilegeSkill
- ledgerSkill
- list-hygiene-judgeSkill
- marketplace-invokeSkill
- meeting-followupSkill
- mock-chargeSkill
- mock-paySkill
- mock-refundSkill
- moltbookSkill
- n8n-handoffSkill
- nitrosendSkill
- nws-weather-forecastSkill
- open-meteo-weather-forecastSkill
- operator-inboxSkill
- ops-deskSkill
- organic-growthSkill
- policy-authorSkill
- postmortem-makerSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 23
Use dispute-respond after a provider has created a bounded dispute event and the original charge should exist in Runx receipt history.
- Very specific: line 43
When the operator deliberately invokes file, Runx validates the unchanged ready packet, binds it to a SHA-256 digest, obtains approval, and …
- Very specific: line 65
Use the named file runner only after reviewing that packet.
- Distinctive: line 79
Do not contest without evidence of delivery, consent, or the provider-specific fact on which the response depends.
- Distinctive: line 81
Do not file a packet that is incomplete, failed validation, already marked as filed, or different from the packet approved by the operator.
- Distinctive: line 83
Do not claim filing from the mutation response alone.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Dispute Respond
Turn one provider dispute event and the exact Runx payment history behind it into a reviewable response posture. A good dispute packet does not merely tell a persuasive story: it proves which charge and refund receipts were consulted, which external evidence may be cited, what remains unknown, and why the operator should accept, contest, review, or acknowledge an existing refund.
The default file-response runner prepares the evidence-bound response, files
it through the selected configured provider after one exact approval, and
requires independent readback. respond remains the explicit draft-only
runner, while file consumes an admitted prior response packet without
repeating the evidence work. No runner closes a dispute, moves money, or
invents provider acceptance.
When to use it
Use dispute-respond after a provider has created a bounded dispute event and
the original charge should exist in Runx receipt history. Use refund when the
operator chooses a new reversal rather than a dispute response. If the original
settlement cannot be proven, gather that evidence before contesting.
How it works
- Normalize provider, dispute, charge, amount, currency, reason, and optional response deadline.
- Resolve the exact original charge and every prior refund by content-addressed Runx receipt id. Caller-supplied receipt rows or summary projections are not accepted as substitutes.
- Require complete signature verification, a hosted or CI issuer, and redacted native detail for each linked receipt tree. A receipt signed by a runx home's own local key proves only that operator's word.
- Admit external evidence only as bounded ref, SHA-256 digest, kind, and summary. Raw provider payloads and credentials remain outside the packet.
- Draft one posture using only admitted receipt ids and evidence refs.
- Deterministic finalization rejects invented citations, effect claims, and any completion state the evidence cannot support.
- When the operator deliberately invokes
file, Runx validates the unchanged ready packet, binds it to a SHA-256 digest, obtains approval, and calls the configured provider under the narrowdispute.filescope. - Runx projects only the filing reference, dispute id, request digest, and
status from the provider result, then performs an independent
dispute.readand requires those fields to match before reporting success.
A contest posture must cite delivery or consent evidence. A verified prior
refund forces refund_already_sent or operator_review; the model cannot ignore
it to produce a stronger contest narrative.
Inputs and result
The input includes the normalized dispute event, exact original receipt id, prior refund ids, and bounded external evidence. The result contains the posture, response summary, cited receipt ids and evidence refs, open questions, validation, and an exact provider-filing handoff for later review.
ready_for_review means only that the packet is complete enough for an
operator. The preparation result always reports filing.status: not_filed,
provider_status: not_called, and approval_status: not_requested.
Use the named file runner only after reviewing that packet. Supply the exact
packet, the configured provider name, and one stable idempotency key for that
filing. Runx injects the key into the provider request, rejects a conflicting
nested key, refuses a packet whose decision or filing state has drifted, and
does not accept the mutation response as proof by itself. A successful run must
also return matching dispute.read evidence. Provider credentials remain in
the configured adapter boundary; they never belong in skill inputs or output.
Stop conditions
- Return
needs_more_evidencefor missing, invalid, locally signed, or incompletely verified receipt trees. - Refuse caller-authored receipt detail, raw provider evidence, credentials, or citations not present in the admitted set.
- Do not contest without evidence of delivery, consent, or the provider-specific fact on which the response depends.
- Do not file a packet that is incomplete, failed validation, already marked as filed, or different from the packet approved by the operator.
- Do not claim filing from the mutation response alone. Require the independent provider readback, and do not equate a filed response with dispute acceptance, closure, settlement, or a refund.
Example
A dispute alleges an unrecognized charge. Native history proves the charge but
contains no consent evidence. The packet may recommend operator_review and
name the missing evidence; it should not contest by inference. If a verified
refund receipt already covers the amount, the posture becomes
refund_already_sent and cites that exact receipt. If the operator later invokes
file, the approved packet—not a rewritten summary—is what reaches the provider,
and matching provider readback is the completion proof.
Agent task contract
dispute-response-draft
Choose accept, contest, refund_already_sent, needs_more_evidence, or
operator_review from the admitted dispute, evidence refs, and native redacted
receipt detail. Cite only exact admitted ids and refs. Never claim filing,
provider acceptance, closure, settlement, or a refund not proven by the packet.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

