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

adr-review

スター0

フォーク0

更新日2026年6月11日 16:20

Review an ADR that Zoha has written in docs/adr/. Use when Zoha says an ADR is ready for review, or asks for feedback on a decision record. Never use this to write or rewrite an ADR.

インストール

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

Manusで実行

ソース

ahamedzoha

ahamedzoha/dinotable

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

ダウンロード

Manusで実行

Reviewing a dinotable ADR

ADRs are Zoha's writing — that constraint is the point of the exercise. You review; you never draft, rewrite, or "clean up" the ADR text. The only file you may edit is the index table in docs/adr/README.md.

Review checklist

Read the ADR (and the template docs/adr/0000-template.md), then assess:

Context — would Zoha-in-six-months understand why this was a question? Are the real constraints named (team-of-one, learning goals, Dhaka-scale numbers from design doc §5)?
Options — are at least two real options presented? Is each option's strongest case made fairly, or is one a strawman? Is "defer / do nothing" considered where legitimate?
Decision — does it name the one or two factors that actually tipped it, or does it just restate all the pros?
Consequences — are the costs of the chosen option stated honestly? Is there a concrete revisit-trigger ("if X happens, reopen this")?
Consistency — does it contradict the design doc or a prior ADR? If it changes the plan, flag that the design doc needs a matching update (by Zoha or by you — design doc edits are allowed).

How to deliver the review

Start with what the ADR gets right — specifically, not generically.
Raise issues as questions where possible ("what would make you reopen this?") rather than corrections. Socratic first, direct second.
Distinguish blocking problems (unfair option framing, missing consequences) from polish (wording, formatting). Don't nitpick prose.
End with a clear verdict: accept as-is / accept with noted gaps / worth another pass — and if accepted, update the status in the ADR's own header is Zoha's edit, but update the index row in docs/adr/README.md yourself.
If you disagree with the decision itself but the reasoning is sound and the trade-off is understood: say so, then accept it. A defended decision Zoha owns beats a correct decision Zoha was handed.

このリポジトリの他の Skills

同じリポジトリ

milestone

ahamedzoha/dinotable

Produce the next guided milestone build doc for dinotable (six-part format - Concept, ADR, Guided build, Challenges, Verify, Stretch). Use when Zoha asks to start a phase, begin a milestone, or requests the next build doc.

2026-06-210

mode

ahamedzoha/dinotable

Switch how much application code the AI writes for dinotable — between guided (Zoha writes all code), collab (split), and autopilot (AI writes the frontend, Zoha drives the guided core). Use when Zoha says "set mode to X", "switch to autopilot", "let me write it myself", "just build the web app for me", or asks what the modes are.

2026-06-210

postman

ahamedzoha/dinotable

Generate, extend, or fix the local Postman collection + environment for hitting the dinotable API. Use when Zoha wants to import the API into Postman, add a request for an endpoint, regenerate the collection after routes change, or debug token/OTP/id-chaining in the saved requests. The collection is GENERATED — edit the SPEC in gen-postman.sh, never hand-edit the JSON.

2026-06-210

progress

ahamedzoha/dinotable

Compare the dinotable repo's actual state against the roadmap, log progress, and plan the next session. Use when Zoha asks where things stand, what to do next, starts a session after a break, or seems stuck or demotivated.

2026-06-180

sql-lesson

ahamedzoha/dinotable

Produce or continue a SQL bootcamp lesson for dinotable, or review Zoha's submitted SQL/ERD work. Use when Zoha asks for the next SQL lesson, help with a SQL exercise, or review of schema/query work.

2026-06-110

Reviewing a dinotable ADR

Review checklist

Read the ADR (and the template docs/adr/0000-template.md), then assess:

Context — would Zoha-in-six-months understand why this was a question? Are the real constraints named (team-of-one, learning goals, Dhaka-scale numbers from design doc §5)?

Options — are at least two real options presented? Is each option's strongest case made fairly, or is one a strawman? Is "defer / do nothing" considered where legitimate?

Decision — does it name the one or two factors that actually tipped it, or does it just restate all the pros?

Consequences — are the costs of the chosen option stated honestly? Is there a concrete revisit-trigger ("if X happens, reopen this")?

Consistency — does it contradict the design doc or a prior ADR? If it changes the plan, flag that the design doc needs a matching update (by Zoha or by you — design doc edits are allowed).

How to deliver the review

Start with what the ADR gets right — specifically, not generically.

Raise issues as questions where possible ("what would make you reopen this?") rather than corrections. Socratic first, direct second.

Distinguish blocking problems (unfair option framing, missing consequences) from polish (wording, formatting). Don't nitpick prose.

End with a clear verdict: accept as-is / accept with noted gaps / worth another pass — and if accepted, update the status in the ADR's own header is Zoha's edit, but update the index row in docs/adr/README.md yourself.

If you disagree with the decision itself but the reasoning is sound and the trade-off is understood: say so, then accept it. A defended decision Zoha owns beats a correct decision Zoha was handed.

name	adr-review
description	Review an ADR that Zoha has written in docs/adr/. Use when Zoha says an ADR is ready for review, or asks for feedback on a decision record. Never use this to write or rewrite an ADR.