hello
Show a nice greeting message with a timestamp. Use this when the user wants to greet or say hello, optionally to a certain subject <subject> and in a certain…
Discover additional, third-party components (libraries/frameworks) for the technology stack to provide needed functionality.
$ npx -y skills add rse/ase --skill ase-arch-discover --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/ase-arch-discoverContext preview
The summary Claude sees to decide when to auto-load this skill.
Discover additional, third-party components (libraries/frameworks) for the technology stack to provide needed functionality.
name: ase-arch-discover
argument-hint: "[--help|-h] [--limit|-l=12] [--staleness|-s=18] [--small-scope|-S] <functionality>"
description: >
Discover additional, third-party components (libraries/frameworks) for
the technology stack to provide needed functionality.
user-invocable: true
disable-model-invocation: false
effort: high
allowed-tools:
- "Bash(npm search --json *)"
- "Bash(curl -s *)"
- "Skill"
- "Agent"@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md @${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
<purpose name="ase-arch-discover"> Discover Components </purpose>
<expand name="getopt" arg1="ase-arch-discover" arg2="--limit|-l=12 --staleness|-s=18 --small-scope|-S"> $ARGUMENTS </expand>
<objective> *Discover* additional, *third-party components* (libraries/frameworks) for the technology stack to *provide* the *needed functionality* <request><getopt-arguments/></request>. </objective>
<flow> 1. <step id="STEP 1: Determine Functionality"> 1. Derive the needed <functionality/> from the <request/>, but keep the functionality description very *brief* but still *precise*.
2. If <functionality/> is not clear, not precise, or not specific enough, let the *user interactively choose* the intended functionality.
In the following, you *MUST* *NOT* use your built-in <user-dialog-tool/> tool! Instead, you *MUST* just show a custom dialog according to the expanded `custom-dialog` definition. You *MUST* closely follow this definition:
<expand name="custom-dialog" arg1="--no-other"> Functionality: Which functionality should the components provide? <answer-1/>: (grounded candidate functionality 1) <answer-2/>: (grounded candidate functionality 2) <answer-3/>: (grounded candidate functionality 3) <answer-4/>: (grounded candidate functionality 4) </expand>
Then use the <result/> and its corresponding grounded candidate functionality to adjust <functionality/> accordingly.
3. Display the determined final functionality with just the following <template/>:
<template> <ase-tpl-bullet-normal/> **FUNCTIONALITY**: <functionality/> </template> </step>
2. <step id="STEP 2: Determine Technology Stack"> 1. Determine the used technology stack:
1. If a file `package.json` is found in the top-level directory of the project and contains an entry `typescript` under `dependencies` or `devDependencies`, then <stack>TypeScript</stack>.
2. Else, if a file `package.json` is found in the top-level directory of the project, then <stack>JavaScript</stack>.
3. Else, if a file `build.gradle.kts` is found in the top-level directory and is applying `kotlin`, `org.jetbrains.kotlin.jvm`, `kotlin-android`, or `kotlin-multiplatform` plugins, then <stack>Kotlin</stack>.
4. Else, if a file `build.gradle` is found in the top-level directory and is applying `kotlin`, `org.jetbrains.kotlin.jvm`, `kotlin-android`, or `kotlin-multiplatform` plugins, then <stack>Kotlin</stack>.
5. Else, if a file `pom.xml` is found in the top-level directory and contains `kotlin-maven-plugin` or `kotlin-stdlib` dependencies, then <stack>Kotlin</stack>.
6. Else, if a file `pom.xml`, `build.gradle`, or `build.gradle.kts` is found in the top-level directory of the project, then <stack>Java</stack>.
7. Else, use <stack>Unknown</stack>.
2. Display the determined final technology stack with just the following <template/>:
<template> <ase-tpl-bullet-normal/> **TECHNOLOGY STACK**: <stack/> </template> </step>
3. <step id="STEP 3: Discover Components"> 1. If <stack/> is "Unknown", the technology stack could not be determined and no component discovery backend is available. Inform the user with just the following <template/> and then *STOP* the entire flow (do not perform any further steps):
<template> <ase-tpl-bullet-normal/> **RESULT**: technology stack could not be determined -- component discovery is only supported for JavaScript, TypeScript, Java, and Kotlin projects. </template>
2. From <stack/> and <functionality/>, derive essential keywords <keyword-L/> (L=1-M), which allow you to search for suitable components.
3. Determine the *candidate pool size* <pool/> as twice the <getopt-option-limit/> (i.e. <pool/> = 2 × <getopt-option-limit/>). Each discovery source below may fetch up to <pool/> candidates so that the later ranking and trimming (which alone is governed by <getopt-option-limit/>) has a meaningful set to choose from.
In the to-be-discovered candidate set of components <component-K/> (K=1-C, where C is the merged and deduplicated candidate count), remember the component name as <name-K/>, the official package name as <package-K/>, the latest version as <version-K/>, the stars as <stars-K/>, the created date as <created-K/>, the last updated date as <updated-K/>, the total number of downloads in the last month as <downloads-K/>.
4. If <stack/> is "JavaScript" or "TypeScript":
1. Based on the essential keywords <keyword-L/> (L=1-M), use the `ase-meta-search` skill in a sub-agent to *generally* discover an initial set of a maximum of <pool/> *NPM packages* <component-K/> and at least their real name <name-K/> and their unique package names <package-K/>.
2. Use the shell command `npm search --json --searchlimit <pool/>
Repo: rse/ase
Show a nice greeting message with a timestamp. Use this when the user wants to greet or say hello, optionally to a certain subject <subject> and in a certain…
Review software architecture, including package cohesion and inter-package coupling
Analyze the source code for problems in either the logic and semantics and its related control flow, performance and efficiency, or security.
Craft Source Code: Use when user wants to "create", "add", or "craft" a new feature from scratch.
Dissect the current Git change set, treated as an epic, domain-wise and logically into cohesive parts and materialize each part in its own dedicated Git…
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,…