human-architect-mindset
Systematic architectural thinking for irreplaceable human capabilities - domain modeling, systems thinking, constraint navigation, and AI-aware problem decomposition. Use proactively when detecting architectural decisions, system design discussions, or multi-component planning.
44
47%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./human-architect-mindset/skills/human-architect-mindset/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has good structural completeness with explicit 'what' and 'when' clauses, which is its strongest aspect. However, it relies heavily on abstract, buzzword-heavy language ('irreplaceable human capabilities,' 'AI-aware problem decomposition') rather than concrete, actionable tasks. The trigger terms are somewhat relevant but could be more grounded in natural user language.
Suggestions
Replace abstract phrases like 'irreplaceable human capabilities' and 'AI-aware problem decomposition' with concrete actions (e.g., 'design system architectures, define component boundaries, map domain models, evaluate trade-offs between design approaches').
Expand trigger terms with natural user language variations such as 'architecture review,' 'microservices design,' 'API design,' 'database schema,' 'tech stack decisions,' or 'scaling strategy'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (architectural thinking) and lists some actions like 'domain modeling, systems thinking, constraint navigation, and AI-aware problem decomposition,' but these are abstract concepts rather than concrete, actionable tasks. Terms like 'irreplaceable human capabilities' are vague fluff. | 2 / 3 |
Completeness | Clearly answers both 'what' (domain modeling, systems thinking, constraint navigation, AI-aware problem decomposition) and 'when' ('Use proactively when detecting architectural decisions, system design discussions, or multi-component planning') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'architectural decisions,' 'system design,' and 'multi-component planning' that users might naturally say. However, it misses common variations and concrete terms users would use (e.g., 'architecture review,' 'design patterns,' 'microservices,' 'API design,' 'database schema'). | 2 / 3 |
Distinctiveness Conflict Risk | The focus on 'architectural thinking' and 'AI-aware problem decomposition' provides some distinctiveness, but terms like 'systems thinking' and 'constraint navigation' are broad enough to overlap with general planning, project management, or software engineering skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is philosophically rich but operationally bloated. It attempts to cover too much ground in a single file—architectural thinking, loyalty philosophy, AI-aware decomposition, tool evaluation, self-learning patterns, user-facing skills, AND a full Spec Driven Development framework. The content would benefit enormously from aggressive trimming of philosophical/motivational content and splitting into focused sub-files, with the main SKILL.md serving as a concise overview with clear references.
Suggestions
Cut the 'Loyalty' foundation section to 5-10 lines max (a brief principle statement) and move the philosophical elaboration to a separate LOYALTY.md if needed—Claude doesn't need persuasion about why loyalty matters.
Extract the entire 'Spec Driven Development Extension' into its own SDD.md file and reference it with a one-line link from the main skill.
Add concrete output examples for each phase—e.g., a sample constraint matrix table, a sample task decomposition with actual input/output contracts, a sample domain model—to make the guidance actionable rather than abstract.
Add explicit phase-completion criteria and validation checkpoints (e.g., 'Phase 1 is complete when you can state the problem in domain terms without technical jargon and the user confirms understanding') to strengthen the workflow.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~500+ lines. Extensive philosophical content about 'loyalty' and 'betrayal' that Claude already understands conceptually. Explains basic ideas like 'what is domain modeling' and 'what is systems thinking' at length. The SDD extension adds significant bulk. Many sections are padded with rhetorical questions and motivational framing rather than actionable content. | 1 / 3 |
Actionability | Provides structured phases and checklists of questions to ask, which is somewhat actionable for an instruction-only skill. However, there are no concrete code examples, no executable commands, no templates, and no specific output formats. The guidance remains at the level of 'ask these questions' and 'follow these phases' without showing what actual outputs look like (e.g., a sample constraint matrix, a sample domain model, a sample task spec). | 2 / 3 |
Workflow Clarity | The five-phase architect process (Domain Discovery → Systems Analysis → Constraint Mapping → AI Decomposition → Solution Synthesis) provides a clear sequence. However, there are no validation checkpoints between phases, no explicit criteria for when a phase is 'done' enough to proceed, and no feedback loops for when later phases reveal earlier assumptions were wrong. The SDD section adds another three-phase process but similarly lacks verification steps. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no bundle files to offload content to. The SDD extension alone could be its own separate file. The loyalty foundation section, the AI operational loyalty section, the common mistakes section, and the tools evaluation tables all bloat the main file. References to related skills exist but the core content desperately needs splitting into separate files (e.g., SDD.md, LOYALTY.md, TOOLS.md). | 1 / 3 |
Total | 6 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (802 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Repository
- bencium/bencium-marketplace
- Commit
2e2fa33
- 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.