원클릭으로 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.