ase-arch-analyze
FreeReview software architecture, including package cohesion and inter-package coupling
The English summary is being prepared. Showing the original description.
Mint an identifier or a name of a requested type out of a free-text hint: a UUID, a SHA-1 digest, a NanoId-style hash, a constant, variable, function, or class identifier, a path component, or a product-like name. Use when the user wants an identifier, id, symbol, slug, or name "minted", "coined", "derived", or "generated" from a description.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
<purpose name="ase-meta-mint"> Mint an Identifier or Name </purpose><expand name="getopt" arg1="ase-meta-mint" arg2="--type|-t=(uuid|sha1|nanoid|const|var|class|func|path|name) --count|-c=1"> $ARGUMENTS </expand>
<objective> *Mint* an identifier or a name of the requested type out of the following hint: <hint><getopt-arguments/></hint> </objective> <flow>Set <type><getopt-option-type/></type> and set <hint/> to <getopt-arguments/> with any leading and trailing whitespace stripped.
Determine the number of identifiers to mint: set <count/> to <getopt-option-count/>; if <getopt-option-count/> is non-numeric, less than 1, or greater than 100, use the default 1 instead.
Set <results></results> and <warning></warning> (set both to empty).
Call the ase_mint(type: "<type/>", hint: "<hint/>", count: <count/>) tool of the ase MCP server and set <results/> to
the returned lines of its text output, one identifier per
line. You MUST NOT derive a UUID, a SHA-1 digest, or a NanoId-style hash yourself
-- only the tool hashes correctly and reproducibly.
Distill <hint/> into its essential words: drop filler words, articles, and prepositions, keep the two to four words which carry the actual meaning, and order them from the most general to the most specific one. Prefer established terminology of the surrounding domain over invented wording. Do not output anything.
Assemble <count/> distinct candidates from these words, ordered best-first, honoring the rules of <type/>:
const: an UPPER_SNAKE_CASE constant identifier such as
FOO_BAR_QUUX -- upper-case ASCII words joined by _,
never starting with a digit.
var: a lowerCamelCase variable identifier such as
fooBarQuux -- the last part MUST be a substantive
(Quux) naming what the value is, never a verb, as a
variable holds a thing and not an action.
func: a lowerCamelCase function identifier such as
fooBarQuux -- the first part MUST be a verb (foo)
naming what the function does, as a function performs an
action and does not hold a thing.
class: an UpperCamelCase class identifier such as
FooBarQuux -- a substantive phrase naming the modeled
entity, in singular form and without a The prefix.
path: a kebab-case path component such as
foo-bar-quux -- lower-case ASCII letters, digits, and -
only, never starting or ending with -.
name: an UpperCamelCase product name such as
FooBarQuux -- optimize for a brand, not for a
description: short (preferably two to three syllables),
pronounceable, memorable, and distinctive. Coinages,
blends, and evocative metaphors are explicitly welcome
here, and a plain concatenation of the hint words is
explicitly not.
Store the candidates in <results/>. Do not output anything.
Output the minted identifiers of <results/>, one per line and each enclosed in backticks, with the following <template/>:
<template> <ase-tpl-boxed title="MINT" subtitle="<type/>"> ● **HINT**: <hint-shown/>○ <result-1/>
○ <result-2/>
○ [...]
</ase-tpl-boxed>
</template>
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review software architecture, including package cohesion and inter-package coupling
The English summary is being prepared. Showing the original description.
Discover additional, third-party components (libraries/frameworks) for the technology stack to provide needed functionality.
The English summary is being prepared. Showing the original description.
Analyze the source code for problems in either the logic and semantics and its related control flow, performance and efficiency, or security.
The English summary is being prepared. Showing the original description.
Edit Source Code: Use when the user wants to "edit" the code base in one shot from a query or a bare analyzer issue id like "P1", fusing crafting, refactoring, and resolving with optional grilling, verification, looping, and Git worktree isolation.
The English summary is being prepared. Showing the original description.
Explains code with WHAT, WHY, ANALOGY, DIAGRAM, CRUXES, and GOTCHAS. Use when you want to know how code works or when the user asks "how does this work?"
The English summary is being prepared. Showing the original description.
Give insights into the source code.
The English summary is being prepared. Showing the original description.