ワンクリックでManusで任意のスキルを実行

change-quiz

スター212

フォーク17

更新日2026年7月5日 13:46

After a working session, produce a report on what changed plus a quiz the user must pass before merging. Use when the user asks "what did we actually do," wants to review a large change, or invokes a quiz before merge.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Neeeophytee

Neeeophytee/finding-unknowns-skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Change quiz

After a long session the agent has often done more than the user realizes, and a diff only shows surface. Behavior lives in how the change interacts with existing code paths. The user should merge only what they can pass a quiz on.

Steps

Build the report first, in four short sections:
- Context — what problem this session set out to solve.
- What changed — grouped by intent (feature, fix, refactor), not by file.
- How it interacts — the existing code paths the change touches, and what now behaves differently even in files the diff doesn't show.
- Intuition — the 2-3 mental-model updates the user should walk away with ("retries are now idempotent because X").
For long sessions, offer the report as a single self-contained HTML page with the quiz at the bottom — it reads better than a wall of markdown.
Then the quiz: 5-8 questions targeting what would bite an unaware maintainer.
- Mix recall ("what happens to in-flight jobs during deploy now?") with prediction ("if someone calls X with a stale token, what do they see?").
- Weight questions toward deviations, edge cases, and interaction effects — not trivia about names.
Grade honestly, one round at a time. For each miss, explain the right answer AND flag it: a miss is either a gap in the user's model or a sign the change is too clever — say which.
Pass = merge-ready. Fail = point back to the specific report sections to reread, then offer a fresh variant quiz. Do not soften the bar; the whole point is that unread changes don't ship.

Guardrails

The quiz covers the change and its blast radius, not general knowledge.
If the user can't pass after two rounds, the recommendation is to simplify the change or split it, not to keep quizzing.
Never mark the user correct out of politeness. A false pass defeats the skill.

このリポジトリの他の Skills

同じリポジトリ

implementation-plan

Neeeophytee/finding-unknowns-skills

Write an implementation plan that leads with the decisions the user is most likely to change, and buries the mechanical work at the bottom. Use when planning is requested before a build, especially after brainstorming or an interview.

2026-07-05212

blindspot-pass

Neeeophytee/finding-unknowns-skills

Surface the user's unknown unknowns before work starts. Use when the user is entering an unfamiliar codebase area, an unfamiliar domain (design, video, infra), or explicitly asks for a "blindspot pass" or to find their "unknown unknowns."

2026-07-05212

brainstorm-prototypes

Neeeophytee/finding-unknowns-skills

Generate several genuinely different throwaway variations (designs, approaches, drafts) for the user to react to. Use when the user can only recognize what they want by seeing it — visual design, UX flows, naming, tone — or asks to brainstorm or prototype before building.

2026-07-05212

implementation-notes

Neeeophytee/finding-unknowns-skills

Keep a running implementation-notes.md during a build, logging every deviation from the plan and every discovered edge case. Use whenever implementing against an agreed plan or spec, especially in long autonomous sessions.

2026-07-05212

interview-me

Neeeophytee/finding-unknowns-skills

Interview the user one question at a time to resolve remaining ambiguity before implementation. Use when planning or brainstorming is done but unknowns remain, or when the user asks to be interviewed about a task or spec.

2026-07-05212

pitch-packager

Neeeophytee/finding-unknowns-skills

Package a finished piece of work (spec, prototype, implementation notes) into a single document that gets reviewers to understanding and approval fast. Use when the user needs buy-in, a review, or a shareable summary of what was built and why.

2026-07-05212

name	change-quiz
description	After a working session, produce a report on what changed plus a quiz the user must pass before merging. Use when the user asks "what did we actually do," wants to review a large change, or invokes a quiz before merge.

Change quiz

Steps

Build the report first, in four short sections:
- Context — what problem this session set out to solve.
- What changed — grouped by intent (feature, fix, refactor), not by file.
- How it interacts — the existing code paths the change touches, and what now behaves differently even in files the diff doesn't show.
- Intuition — the 2-3 mental-model updates the user should walk away with ("retries are now idempotent because X").
For long sessions, offer the report as a single self-contained HTML page with the quiz at the bottom — it reads better than a wall of markdown.
Then the quiz: 5-8 questions targeting what would bite an unaware maintainer.
- Mix recall ("what happens to in-flight jobs during deploy now?") with prediction ("if someone calls X with a stale token, what do they see?").
- Weight questions toward deviations, edge cases, and interaction effects — not trivia about names.
Grade honestly, one round at a time. For each miss, explain the right answer AND flag it: a miss is either a gap in the user's model or a sign the change is too clever — say which.
Pass = merge-ready. Fail = point back to the specific report sections to reread, then offer a fresh variant quiz. Do not soften the bar; the whole point is that unread changes don't ship.

Guardrails

The quiz covers the change and its blast radius, not general knowledge.
If the user can't pass after two rounds, the recommendation is to simplify the change or split it, not to keep quizzing.
Never mark the user correct out of politeness. A false pass defeats the skill.