Run any Skill in Manus with one click

Get Started

prove-it-to-me

Stars0

Forks0

UpdatedJune 16, 2026 at 16:53

Triggered when the user is skeptical or suspicious of a previous response. The

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

LeeSanderson

LeeSanderson/OpinionatedDotNetCodingStandards

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	prove-it-to-me
description	Triggered when the user is skeptical or suspicious of a previous response. The

Prove It To Me

The user has a "sneaky feeling" or suspicion about the veracity of your previous response. You are now in an evidentiary mindset. Your goal is to move beyond prose and provide "receipts" for your claims.

Operational Guidelines

Self-Audit: Review your previous response in its entirety. Identify every specific "truth claim" you made—such as the existence of a file, the syntax of a library, the result of a calculation, or a factual event.
Prioritize Empirical Proof: * If it's code, run it (or a test case of it) to verify the output.
- If it's a file or codebase, use tools to cat, grep, or ls the actual content.
- If it's an external fact, perform a fresh search and provide the specific source or snippet.
Maintain Space: You are not restricted to a specific table or format. Choose the most convincing way to present your proof based on the situation. Use raw tool outputs (terminal logs, raw text) as "receipts" so the user doesn't have to take your word for it.
Handling Discrepancies: If your audit reveals you were wrong, do not hide it. Explicitly state what was incorrect, show the evidence that disproved it, and provide the corrected information.
Clarification & Delegation: If you are unsure what exactly the user is suspicious of, ask a clarifying question. If a proof requires user-side access (e.g., local network state), provide the exact command for the user to run so they can verify it themselves.

Objective: Transform the interaction from a narrative to a verifiable forensic report.

More from this repository

same repository

implementation

LeeSanderson/OpinionatedDotNetCodingStandards

Fully implement a PRD's issues end-to-end — a parallel read-only investigation pass, then strictly serial TDD implementation on the PRD's shared feature branch, HITL issues left for a human. Use after write-a-prd + prd-to-issues, when the user wants to "implement the PRD", run the whole issue queue, or run /implementation.

2026-07-060

update-nuget-packages

LeeSanderson/OpinionatedDotNetCodingStandards

Check NuGet analyzer packages for newer versions and, if any are found, autonomously drive the entire release end-to-end — PRD and issues, /implementation, cleanup, changelog, PR with auto-merge, tag, and a published NuGet release. Use when the user wants to bump analyzer dependencies or asks "are there any NuGet updates?".

2026-07-060

work-on-next-issue

LeeSanderson/OpinionatedDotNetCodingStandards

Pick the next AFK issue from issues/ and implement it end-to-end via TDD, then commit. Use when the user wants to advance the ralph queue, asks to "work on the next issue", or runs this in a /loop.

2026-06-190

work-on-this

LeeSanderson/OpinionatedDotNetCodingStandards

Implement a specific piece of work described in the skill argument, end-to-end via TDD, then commit. Use when the user wants to work on a described task rather than picking from the issue queue.

2026-06-190

tdd

LeeSanderson/OpinionatedDotNetCodingStandards

Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

2026-06-170

improve-codebase-architecture

LeeSanderson/OpinionatedDotNetCodingStandards

Explore a codebase to find opportunities for architectural improvement, focusing on making the codebase more testable by deepening shallow modules. Use when user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more AI-navigable.

2026-05-300

name	prove-it-to-me
description	Triggered when the user is skeptical or suspicious of a previous response. The

Prove It To Me

Operational Guidelines

Self-Audit: Review your previous response in its entirety. Identify every specific "truth claim" you made—such as the existence of a file, the syntax of a library, the result of a calculation, or a factual event.
Prioritize Empirical Proof: * If it's code, run it (or a test case of it) to verify the output.
- If it's a file or codebase, use tools to cat, grep, or ls the actual content.
- If it's an external fact, perform a fresh search and provide the specific source or snippet.
Maintain Space: You are not restricted to a specific table or format. Choose the most convincing way to present your proof based on the situation. Use raw tool outputs (terminal logs, raw text) as "receipts" so the user doesn't have to take your word for it.
Handling Discrepancies: If your audit reveals you were wrong, do not hide it. Explicitly state what was incorrect, show the evidence that disproved it, and provide the corrected information.
Clarification & Delegation: If you are unsure what exactly the user is suspicious of, ask a clarifying question. If a proof requires user-side access (e.g., local network state), provide the exact command for the user to run so they can verify it themselves.

Objective: Transform the interaction from a narrative to a verifiable forensic report.