CtrlK
BlogDocsLog inGet started
Tessl Logo

architectural-decisions

Use when encountering questions about WHY code is built a certain way, when about to make architectural changes (new patterns, restructuring, choosing between approaches), or when the user asks about design rationale in a Repowise-indexed codebase (.repowise/ directory exists). Also activates when commit messages or code comments contain decision signals like "WHY:", "DECISION:", "TRADEOFF:", "ADR:".

64

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/claude-code/skills/architectural-decisions/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A tight, highly actionable body that gives concrete tool calls and clear scenario-based workflows with good section structure. The only minor gap is the absence of an explicit validation feedback loop in the change workflow.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — no padding, no explaining what an ADR or architectural decision is — with only minor framings like the opening restatement that could be trimmed, placing it just below the fully-lean 5 anchor.

4 / 5

Actionability

It provides concrete, copy-paste-ready invocations for all four get_why modes (e.g. get_why(query="why is auth using JWT?")) plus exact CLI commands (repowise decision health, /repowise:why, repowise decision add), fully covering the common cases.

5 / 5

Workflow Clarity

The 'When about to make an architectural change' section gives a clear numbered sequence with a human checkpoint (present decisions to the user before proceeding) and a fallback branch, but lacks an explicit validate-then-retry feedback loop, sitting just below the 5 anchor.

4 / 5

Progressive Disclosure

The skill is under 50 lines, single-purpose, and has no bundle files; it is organized into well-signaled sections (When the user asks..., When about to make..., When called with no query) so the simple-skill exception applies and structure alone earns a 5.

5 / 5

Total

18

/

20

Passed

Description

65%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A trigger-rich, distinctive description that excels at telling Claude when to activate, but it is missing an explicit statement of what the skill does. Adding a concrete capability clause would lift specificity and completeness.

Suggestions

Add an explicit 'what' clause naming the action, e.g. "Surfaces and records architectural decisions (the why behind code) from a Repowise-indexed codebase." before the 'Use when' triggers.

Include a couple of natural synonyms users might say, such as 'design decisions', 'architecture choices', or 'reasoning behind the code', to broaden trigger coverage toward a 5.

Name the primary action verbs (retrieve, review, record) so the capability is stated, not just the triggering context.

DimensionReasoningScore

Specificity

The description names the domain ("architectural changes", "design rationale", "decision signals") and concrete triggering scenarios, but never states a concrete action verb for what the skill does (e.g. retrieves/surfaces/records decisions), so it sits at 'names domain and a couple concrete actions but not comprehensive' rather than 4.

3 / 5

Completeness

The 'when' is explicit and strong ("Use when...", "Also activates when..."), but the 'what' is only weakly implied through the topic rather than an explicit capability statement, matching the 'only when present without a clear what' band between 2 and 4.

3 / 5

Trigger Term Quality

It includes natural user phrases like "why code is built a certain way" and "design rationale" plus concrete markers ("WHY:", "DECISION:", "TRADEOFF:", "ADR:"), giving good keyword coverage with a few synonyms/common variations missing, so just below the comprehensive 5 anchor.

4 / 5

Distinctiveness Conflict Risk

The niche is sharply bounded — a Repowise-indexed codebase (.repowise/ directory) plus specific decision-signal markers — giving distinct triggers and minimal overlap with other skills, matching the 'clear niche, minimal conflict risk' anchor.

5 / 5

Total

15

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
repowise-dev/repowise
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.