Communitygithub.com

AlemTuzlak/skills

Use when the user runs /prove-it or says prove it, prove the changes, show me in the browser, or asks to prove a UI or API change. Don't use only because the agent is about to say done, for types-only work, or for docs with no behavior to prove.

Qu'est-ce que skills ?

skills is a Claude Code agent skill that use when the user runs /prove-it or says prove it, prove the changes, show me in the browser, or asks to prove a UI or API change. Don't use only because the agent is about to say done, for types-only work, or for docs with no behavior to prove.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/AlemTuzlak/skills/tree/HEAD/skills/prove-it

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Prove It

Prove the change the way a person uses it. Do not claim it works without that proof.

This skill does not auto-load on “done.” The user must ask. It does not load other skills.

When To Use

Load when the user:

  • runs /prove-it
  • says prove it, prove the changes, show me in the browser, or the same idea (including in the first message)

Skip if they did not ask. Skip types-only, comments, lockfile, docs with no behavior.

Hard Gates

  1. User asked. If they did not ask to prove, this skill does not run.
  2. Do not say it works, is done, or is fixed unless this skill actually proved it. Skip means not proved.
  3. A screenshot of one screen is not proof. Click, type, submit, navigate.
  4. No new package, dependency, example app, or browser runner unless the user picked that option and said yes.
  5. Stop any server this skill started before the skill ends. Do not leave dev / preview running.

UI vs server

  • UI (page, component, route, form, visible state): prove in the browser.
  • Server / API / library with no screen: ask how to prove. Do not pick in silence.
  • Both: browser the UI, and ask how to prove the server half.

Procedures

Procedure 1: Classify

  1. List the surfaces: UI, server/API, or both.
  2. UI → Procedure 2.
  3. Server/API → Procedure 3.
  4. Both → Procedure 2, then Procedure 3 for the API.

Procedure 2: Browser (UI)

  1. If the app is not running, start only an existing command (dev, preview, the repo’s documented start). If none exists, say UI cannot be proved. Offer skip, or that the user starts the app.
  2. Use it like a user:
    • click, type, submit, navigate
    • every route/page that shares this state
    • empty and error UI if this change has them
    • desktop and a narrow viewport if layout or CSS changed
  3. Hunt for breakage, not only the happy path.
  4. In chat, say what you did and what you saw. Do not say “looks good” with no steps.
  5. Stop the process from step 1 if this skill started it.
  6. Procedure 4.

Procedure 3: Ask (server / API)

  1. Stop. Show 2–3 options. Put a reasonable first pick first. Always include skip.
    • existing example / playground / demo
    • example app that uses the new API (only if they confirm place + any new package/dep)
    • curl or a small script against a running server
    • skip
  2. Wait. Do not build or run until they pick.
  3. If skip: say not proved. Do not say it works. Stop (no Procedure 4).
  4. If existing playground: run that, then prove in the browser if it has a UI, or show the command output if it is a script.
  5. If example app: ask where. Prefer an existing example. Do not add a package or dependency unless they said yes. Then run it and prove.
  6. If curl/script: run it. Quote exit code and the part of the output that proves the claim.
  7. Procedure 4.

Procedure 4: Optional report

  1. After a real proof, ask: write a screenshot report? Default no.
  2. If no: stop. Chat already has the evidence.
  3. If yes: write .agent/scratch/prove-it.md (overwrite). Gitignore .agent/scratch/ if missing (same as other scratch files). Include what was clicked and the shots. Open the file. Do not commit it.
  4. Skip proof → no report.

Procedure 5: Stop

After proof or skip, stop. Do not start unrelated work from this skill.

Decision Tree

  • User did not ask to prove → this skill does not apply.
  • UI → Procedure 2 → 4 → 5.
  • Server/API → Procedure 3 → 4 → 5 (skip ends at 3).
  • Both → 2 then 3, then 4 → 5.
  • No start command and app not running → say cannot prove UI. Skip or user starts it.
  • User says skip → not proved. No success claim.

Red Flags

SignalWhat it meansDo instead
Saying done because tests passedThis skill was not asked, or proof was skippedOnly claim proved after Procedure 2 or 3.
One screenshot, no clicksNot a user pathProcedure 2 step 2.
Building examples/foo before they pickUnasked appProcedure 3. Wait.
Adding Playwright / a new serverNew dependencyExisting start command only.
Leaving pnpm dev runningWatcher left onHard gate 5.
"Skip, but it works"Skip turned into a claimSay not proved.
Report file in docs/Product doc.agent/scratch/prove-it.md.
Opening the report when they said noUnasked fileProcedure 4 default no.
Proving only the page for a new public APIServer half skipped in silenceProcedure 3 for the API.

Error Handling

  • No browser tools: say UI cannot be proved here. Offer skip, or that they click while you wait on a URL. Do not fake a screenshot.
  • Start command fails: quote the error. Do not say the UI works. Offer skip or a fix, then prove again.
  • Proof fails (click does the wrong thing, curl is not 200): say not proved. Name what failed. Do not call it done.
  • They pick example app then refuse a new package: use curl, an existing example, or skip. Do not add the package anyway.
  • Scratch write fails: keep the proof in chat. Say the report file was not written.

See nothing else. Chat is the default evidence. The markdown file is optional.

Individual skills in this repo

This repo contains 10 individual skills — each has its own dedicated page.

AlemTuzlak/skills

Use when the user wants to write a blog post about a feature, product change, PR, git diff, or any technical topic - accepts marketing briefs, PRs, git refs, codebase paths, or freeform descriptions as input

AlemTuzlak/skills

Use when the user wants to generate a changelog, release notes, or document what changed between versions, tags, or PRs

AlemTuzlak/skills

Use when writing, editing, or organizing documentation, when planning what docs a feature needs, and whenever planning or implementing a new feature or change in a repo (docs ship with the code). Also use when tempted to write docs without showing the discovered readers to the user, without asking for tone, or without loading simple-english and i-have-adhd. Triggers on "write docs for X", "document this feature", "add a guide", "update the docs", "reorganize the docs", "plan feature X", "implement X", or /docs.

AlemTuzlak/skills

Use when a bug is in play: a test fails, CI is red, an API returns the wrong result, a stack trace appears, or the user says it is broken or fix this. Don't use for a new feature with no failure, for types-only work, or for docs.

AlemTuzlak/skills

Use when the user invokes /i-have-adhd, says they have ADHD, or asks for ADHD-friendly output. Also used as a required writing filter by the docs skill. Don't use for marketing copy or after the user says "stop adhd mode" or "normal mode".

AlemTuzlak/skills

Use when a settled change must be turned into an ordered stack of small blocks before anyone implements. Don't use for unsettled intent, typos, comments, formatting, docs-only work, or writing the implementation itself.

AlemTuzlak/skills

Use when the user wants to write a product update email, feature announcement newsletter, or digest email for users or subscribers

AlemTuzlak/skills

Use when the user wants to write, draft, or author an RFC (Request for Comments) / technical design doc for a feature, change, or architectural decision. Interactively interviews the user, grounds the proposal in the actual codebase, presents 2-3 concrete API/code-snippet approaches to choose from, then writes a review-ready RFC. Triggers on "write an RFC", "draft an RFC", "RFC for X", "design doc for X", or /rfc.

AlemTuzlak/skills

Use when the user wants to deeply learn a new topic from scratch. Runs a pre-interview (current knowledge, end-goal proficiency, depth, practice load, background, scope), researches online (articles, niche-influencer blogs, canonical docs, subtopic landscape), then produces a structured markdown course with mandatory visual diagrams, evidence-based learning-science features (retrieval practice, spaced callbacks, worked-example fading, concept ledger, jargon gate, analogy hygiene), and a self-contained interactive HTML mini-course. Triggers on /teach-me, "teach me about X", "I want to learn X", "deep dive on X", "create a course on X", "study X with me".

AlemTuzlak/skills

Use when the change intent is already settled and the agent must map what a behavior change touches before an implementation plan or any code. Use for new features, bug fixes, and refactors that move a boundary. Don't use for typos, comments, formatting, lockfile-only diffs, docs with no code, or while the user is still deciding what they want.

Skills associés