allemaar /assess
Structured evaluation of an approach, decision, or implementation — assess viability across multiple dimensions and deliver a clear recommendation.
Structured execution spec:
protocol.yon. Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the@STAMPdate.
Decision Support Protocol — convergent evaluation.
/insight-exploregenerates alternatives (divergent)./insight-assessevaluates them (convergent)./insight-critiquereviews outputs (reactive). Three complementary tools.
Phase 1 — Frame the Decision
Identify what is being assessed: a specific approach, a decision between options, an implementation pattern, or an architectural direction.
Load relevant context — files, docs, KIs, skills. Define what we are optimizing for and the constraints.
Gate: cannot assess without a clear subject. If the decision cannot be framed, ask for clarification before proceeding.
Phase 2 — Dimensional Analysis
Evaluate across all relevant dimensions. Skip dimensions that don't apply.
Pros & cons — concrete advantages and disadvantages. Cite actual code, dependencies, or patterns. No vague generalizations. If comparing multiple options, do side-by-side.
Quality assessment — score STRONG / ADEQUATE / WEAK with justification on:
- Performance — bundle size, runtime overhead, N+1 queries, render cycles
- Code quality — DRY violations, coupling, testability, readability
- Developer experience — API ergonomics, debugging ease, onboarding friction
- Maintainability — upgrade path, community support, lock-in risk
Impact assessment — map and classify overall impact LOW / MEDIUM / HIGH:
- Blast radius — packages/apps/files
- Migration effort — if replacing something
- Breaking changes — if any
- Learning curve — for the team
- Future flexibility — does this open or close doors?
Phase 3 — Alignment Check
- Does this align with repo coding standards?
- Does it follow existing patterns, or introduce a new one?
- If new, is it justified?
- Check relevant skills and KIs for prior art.
Phase 4 — Recommendation
Structure:
- VERDICT — one of:
PROCEED/PROCEED WITH CAVEATS/RECONSIDER/REJECT - RATIONALE — 1–2 sentences
- CONDITIONS — if
PROCEED WITH CAVEATS: what must be addressed - ALTERNATIVES — if
RECONSIDER/REJECT: what to do instead
Gate: assessment is incomplete without a recommendation delivered to the user.
Rules
- MUST be concrete and specific when listing pros/cons — cite actual code, libraries, or patterns.
- MUST check performance, DX, and maintainability — not just correctness.
- MUST use consistent dimensions across all options when comparing.
- MUST NOT make changes, write code, or execute — evaluation only.
- MUST NOT hedge without a clear verdict — always commit to a recommendation.
- SHOULD note caveats or conditions even if minor when recommending PROCEED.
- SHOULD suggest concrete alternatives when recommending RECONSIDER.
Next Steps
/plan-create— if verdict is PROCEED/insight-explore— if more options are needed before deciding/insight-critique— if a deeper review of specific output is needed
Human output. This skill's handler-facing output obeys the human-output contract (
human-output/SKILL.md).
Next skills. On completion, run the Next Skills protocol (
next-skills/SKILL.md): surface thenext-skillsrecommendations from front-matter for the caller to pick. Offer only — never auto-invoke.
Self-improvement. On completion, run the Self-Improvement Protocol (
self-improve/SKILL.md): if this run surfaced a concrete, blocking-or-recurring weakness in this skill, propose a specific fix for the handler to approve. Conservative — silent otherwise. Never auto-apply.