neko-harness 0.2.3 → 0.2.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/gateway.js +10 -1
- package/dist/neko.js +14 -6
- package/dist/skills/skill-creator/LICENSE.txt +202 -0
- package/dist/skills/skill-creator/SKILL.md +270 -0
- package/dist/skills/skill-creator/assets/eval_review.html +146 -0
- package/dist/skills/skill-finder/SKILL.md +51 -0
- package/package.json +1 -1
package/dist/gateway.js
CHANGED
|
@@ -1192,6 +1192,7 @@ ${text}
|
|
|
1192
1192
|
};
|
|
1193
1193
|
|
|
1194
1194
|
// packages/core/src/prompt/resources.ts
|
|
1195
|
+
import { existsSync as existsSync2 } from "fs";
|
|
1195
1196
|
import { readFile as readFile3 } from "fs/promises";
|
|
1196
1197
|
import { homedir as homedir3 } from "os";
|
|
1197
1198
|
import { join as join4 } from "path";
|
|
@@ -1200,7 +1201,15 @@ var userAgentsFile = (home) => join4(home, ".agents", "AGENTS.md");
|
|
|
1200
1201
|
var userSkillsDir = (home) => join4(home, ".agents", "skills");
|
|
1201
1202
|
var workspaceAgentsFile = (workspace) => join4(workspace, "AGENTS.md");
|
|
1202
1203
|
var workspaceSkillsDir = (workspace) => join4(workspace, ".agents", "skills");
|
|
1203
|
-
var
|
|
1204
|
+
var resolveBuiltinSkillsDir = () => {
|
|
1205
|
+
for (const url of [new URL("./skills/", import.meta.url), new URL("../../skills/", import.meta.url)]) {
|
|
1206
|
+
const path = fileURLToPath(url);
|
|
1207
|
+
if (existsSync2(join4(path, "skill-creator", "SKILL.md")))
|
|
1208
|
+
return path;
|
|
1209
|
+
}
|
|
1210
|
+
return null;
|
|
1211
|
+
};
|
|
1212
|
+
var BUILTIN_SKILLS_DIR = resolveBuiltinSkillsDir();
|
|
1204
1213
|
var readResources = async (workspace, home, builtinDir, report, invocationName) => {
|
|
1205
1214
|
const contextFiles = [];
|
|
1206
1215
|
for (const path of [userAgentsFile(home), workspaceAgentsFile(workspace)]) {
|
package/dist/neko.js
CHANGED
|
@@ -1098,11 +1098,19 @@ var init_prompt = __esm(() => {
|
|
|
1098
1098
|
});
|
|
1099
1099
|
|
|
1100
1100
|
// packages/core/src/prompt/resources.ts
|
|
1101
|
+
import { existsSync as existsSync2 } from "fs";
|
|
1101
1102
|
import { readFile as readFile3 } from "fs/promises";
|
|
1102
1103
|
import { homedir as homedir3 } from "os";
|
|
1103
1104
|
import { join as join4 } from "path";
|
|
1104
1105
|
import { fileURLToPath } from "url";
|
|
1105
|
-
var userAgentsFile = (home) => join4(home, ".agents", "AGENTS.md"), userSkillsDir = (home) => join4(home, ".agents", "skills"), workspaceAgentsFile = (workspace) => join4(workspace, "AGENTS.md"), workspaceSkillsDir = (workspace) => join4(workspace, ".agents", "skills"),
|
|
1106
|
+
var userAgentsFile = (home) => join4(home, ".agents", "AGENTS.md"), userSkillsDir = (home) => join4(home, ".agents", "skills"), workspaceAgentsFile = (workspace) => join4(workspace, "AGENTS.md"), workspaceSkillsDir = (workspace) => join4(workspace, ".agents", "skills"), resolveBuiltinSkillsDir = () => {
|
|
1107
|
+
for (const url of [new URL("./skills/", import.meta.url), new URL("../../skills/", import.meta.url)]) {
|
|
1108
|
+
const path = fileURLToPath(url);
|
|
1109
|
+
if (existsSync2(join4(path, "skill-creator", "SKILL.md")))
|
|
1110
|
+
return path;
|
|
1111
|
+
}
|
|
1112
|
+
return null;
|
|
1113
|
+
}, BUILTIN_SKILLS_DIR, readResources = async (workspace, home, builtinDir, report, invocationName) => {
|
|
1106
1114
|
const contextFiles = [];
|
|
1107
1115
|
for (const path of [userAgentsFile(home), workspaceAgentsFile(workspace)]) {
|
|
1108
1116
|
try {
|
|
@@ -1168,7 +1176,7 @@ var userAgentsFile = (home) => join4(home, ".agents", "AGENTS.md"), userSkillsDi
|
|
|
1168
1176
|
};
|
|
1169
1177
|
var init_resources = __esm(() => {
|
|
1170
1178
|
init_skills();
|
|
1171
|
-
BUILTIN_SKILLS_DIR =
|
|
1179
|
+
BUILTIN_SKILLS_DIR = resolveBuiltinSkillsDir();
|
|
1172
1180
|
});
|
|
1173
1181
|
|
|
1174
1182
|
// packages/core/src/prompt/snapshots.ts
|
|
@@ -5491,7 +5499,7 @@ var init_src2 = __esm(() => {
|
|
|
5491
5499
|
|
|
5492
5500
|
// packages/tui/src/gateway.ts
|
|
5493
5501
|
import { spawn as spawn2 } from "child_process";
|
|
5494
|
-
import { existsSync as
|
|
5502
|
+
import { existsSync as existsSync3, readFileSync as readFileSync2 } from "fs";
|
|
5495
5503
|
import { basename as basename6, dirname as dirname8, join as join11 } from "path";
|
|
5496
5504
|
import { isServerId as isServerId2 } from "@earendil-works/pi-protocol";
|
|
5497
5505
|
async function connectToGateway(options = {}) {
|
|
@@ -5513,7 +5521,7 @@ async function connectToGateway(options = {}) {
|
|
|
5513
5521
|
}
|
|
5514
5522
|
const socketPath = options.socketPath ?? config.gateway?.socketPath ?? (fileServerId !== undefined ? join11(nekoDir, `${fileServerId}.sock`) : undefined);
|
|
5515
5523
|
const serverIdFor = (path) => fileServerId ?? serverIdFromSocketPath2(path) ?? readServerId(join11(nekoDir, SERVER_ID_FILENAME2));
|
|
5516
|
-
if (socketPath !== undefined &&
|
|
5524
|
+
if (socketPath !== undefined && existsSync3(socketPath)) {
|
|
5517
5525
|
const serverId = serverIdFor(socketPath);
|
|
5518
5526
|
if (serverId !== undefined) {
|
|
5519
5527
|
try {
|
|
@@ -5574,7 +5582,7 @@ ${outputTail()}`);
|
|
|
5574
5582
|
const generated = await waitForValue(() => readServerId(join11(plan.nekoDir, SERVER_ID_FILENAME2)), "gateway serverId file", timeoutMs, child, outputTail, spawnError);
|
|
5575
5583
|
socketPath = join11(plan.nekoDir, `${generated}.sock`);
|
|
5576
5584
|
}
|
|
5577
|
-
await waitForValue(() =>
|
|
5585
|
+
await waitForValue(() => existsSync3(socketPath) ? true : undefined, `gateway ready (socket: ${socketPath})`, timeoutMs, child, outputTail, spawnError);
|
|
5578
5586
|
const serverId = plan.fileServerId ?? serverIdFromSocketPath2(socketPath) ?? readServerId(join11(plan.nekoDir, SERVER_ID_FILENAME2));
|
|
5579
5587
|
if (serverId === undefined) {
|
|
5580
5588
|
throw new Error(`Cannot determine gateway serverId (socket: ${socketPath})`);
|
|
@@ -7644,7 +7652,7 @@ switch (command2) {
|
|
|
7644
7652
|
}
|
|
7645
7653
|
case "--version":
|
|
7646
7654
|
case "-v":
|
|
7647
|
-
console.log("0.2.
|
|
7655
|
+
console.log("0.2.4");
|
|
7648
7656
|
break;
|
|
7649
7657
|
case undefined:
|
|
7650
7658
|
case "-h":
|
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. We also recommend that a
|
|
186
|
+
file or class name and description of purpose be included on the
|
|
187
|
+
same "printed page" as the copyright notice for easier
|
|
188
|
+
identification within third-party archives.
|
|
189
|
+
|
|
190
|
+
Copyright 2026 Anthropic, PBC.
|
|
191
|
+
|
|
192
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
193
|
+
you may not use this file except in compliance with the License.
|
|
194
|
+
You may obtain a copy of the License at
|
|
195
|
+
|
|
196
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
197
|
+
|
|
198
|
+
Unless required by applicable law or agreed to in writing, software
|
|
199
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
200
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
201
|
+
See the License for the specific language governing permissions and
|
|
202
|
+
limitations under the License.
|
|
@@ -0,0 +1,270 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: skill-creator
|
|
3
|
+
description: Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance, or optimize a skill's description for better triggering accuracy.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!--
|
|
7
|
+
Adapted from anthropics/skills `skill-creator` (Apache-2.0, see LICENSE.txt in this directory).
|
|
8
|
+
Trimmed for neko-harness: removed Claude.ai / Cowork platform sections, the subagent-based
|
|
9
|
+
parallel eval machinery, the eval-viewer server scripts, blind comparison, and
|
|
10
|
+
package_skill.py / present_files packaging. The test loop is adapted to neko mechanics:
|
|
11
|
+
project-level skill directories, `/skill:<name>` explicit invocation, and fresh sessions.
|
|
12
|
+
Update via a dedicated change when refreshing from upstream.
|
|
13
|
+
-->
|
|
14
|
+
|
|
15
|
+
# Skill Creator
|
|
16
|
+
|
|
17
|
+
A skill for creating new skills and iteratively improving them.
|
|
18
|
+
|
|
19
|
+
At a high level, the process of creating a skill goes like this:
|
|
20
|
+
|
|
21
|
+
- Decide what you want the skill to do and roughly how it should do it
|
|
22
|
+
- Write a draft of the skill
|
|
23
|
+
- Create a few test prompts and run them with the skill active
|
|
24
|
+
- Help the user evaluate the results, qualitatively and (where outputs are objectively checkable) quantitatively
|
|
25
|
+
- Rewrite the skill based on feedback
|
|
26
|
+
- Repeat until you're satisfied
|
|
27
|
+
- Expand the test set and try again at larger scale
|
|
28
|
+
|
|
29
|
+
Your job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. Maybe they're like "I want to make a skill for X" — help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, and repeat. Or maybe they already have a draft — go straight to the test/iterate part of the loop.
|
|
30
|
+
|
|
31
|
+
Of course, be flexible: if the user is like "I don't need to run a bunch of evaluations, just vibe with me", do that instead.
|
|
32
|
+
|
|
33
|
+
After the skill is done (order is flexible), you can also optimize the description for better triggering — there's a dedicated section below.
|
|
34
|
+
|
|
35
|
+
## Communicating with the user
|
|
36
|
+
|
|
37
|
+
The skill creator is liable to be used by people across a wide range of familiarity with coding jargon. Pay attention to context cues to understand how to phrase your communication. In the default case:
|
|
38
|
+
|
|
39
|
+
- "evaluation" and "benchmark" are borderline, but OK
|
|
40
|
+
- for "JSON" and "assertion" you want to see serious cues from the user that they know what those things are before using them without explaining them
|
|
41
|
+
|
|
42
|
+
It's OK to briefly explain terms if you're in doubt.
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## Skills in neko
|
|
47
|
+
|
|
48
|
+
Where skills live and how they load, because this shapes how you test:
|
|
49
|
+
|
|
50
|
+
- **Locations**: `~/.agents/skills/<name>/` (user level, every workspace) and `<workspace>/.agents/skills/<name>/` (project level, this workspace only). Same-named project skills override user-level ones.
|
|
51
|
+
- **SKILL.md format**: YAML frontmatter + Markdown body. `description` is required (max ~1000 characters); `name` is optional and falls back to the directory name (max 64 characters, no whitespace). Optional `disable-model-invocation: true` hides the skill from the model's automatic discovery while keeping `/skill:<name>` available.
|
|
52
|
+
- **Loading**: only name + description + location go into the system prompt; the body is read on demand. New or edited skill files take effect on the user's **next submitted message** — there is no hot reload mid-run.
|
|
53
|
+
- **Explicit testing**: `/skill:<name> [args]` injects the skill body into a fresh run. This is your main testing tool.
|
|
54
|
+
|
|
55
|
+
## Creating a skill
|
|
56
|
+
|
|
57
|
+
### Capture Intent
|
|
58
|
+
|
|
59
|
+
Start by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say "turn this into a skill"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding.
|
|
60
|
+
|
|
61
|
+
1. What should this skill enable the agent to do?
|
|
62
|
+
2. When should this skill trigger? (what user phrases/contexts)
|
|
63
|
+
3. What's the expected output format?
|
|
64
|
+
4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.
|
|
65
|
+
|
|
66
|
+
### Interview and Research
|
|
67
|
+
|
|
68
|
+
Proactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out. If research would help (searching docs, finding similar skills, looking up best practices), do it before asking — come prepared with context to reduce burden on the user.
|
|
69
|
+
|
|
70
|
+
### Write the SKILL.md
|
|
71
|
+
|
|
72
|
+
Based on the user interview, fill in these components:
|
|
73
|
+
|
|
74
|
+
- **name**: Skill identifier (usually just the directory name)
|
|
75
|
+
- **description**: When to trigger, what it does. This is the primary triggering mechanism — include both what the skill does AND specific contexts for when to use it. All "when to use" info goes here, not in the body. Models tend to *undertrigger* skills, so make descriptions a little bit "pushy". For instance, instead of "How to build a dashboard for internal data.", write "How to build a simple fast dashboard to display internal data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'"
|
|
76
|
+
- **compatibility**: Required tools, dependencies (optional, rarely needed)
|
|
77
|
+
- **the rest of the skill :)**
|
|
78
|
+
|
|
79
|
+
Write drafts into the workspace's `.agents/skills/<name>/` (project level) while iterating — it keeps experiments out of the user-level directory and makes cleanup a single `rm -rf`.
|
|
80
|
+
|
|
81
|
+
### Skill Writing Guide
|
|
82
|
+
|
|
83
|
+
#### Anatomy of a Skill
|
|
84
|
+
|
|
85
|
+
```
|
|
86
|
+
skill-name/
|
|
87
|
+
├── SKILL.md (required)
|
|
88
|
+
│ ├── YAML frontmatter (name, description required)
|
|
89
|
+
│ └── Markdown instructions
|
|
90
|
+
└── Bundled Resources (optional)
|
|
91
|
+
├── scripts/ - Executable code for deterministic/repetitive tasks
|
|
92
|
+
├── references/ - Docs loaded into context as needed
|
|
93
|
+
└── assets/ - Files used in output (templates, icons, fonts)
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
#### Progressive Disclosure
|
|
97
|
+
|
|
98
|
+
Skills use a three-level loading system:
|
|
99
|
+
1. **Metadata** (name + description) - Always in context (~100 words)
|
|
100
|
+
2. **SKILL.md body** - In context whenever skill triggers (<500 lines ideal)
|
|
101
|
+
3. **Bundled resources** - As needed (unlimited, scripts can execute without loading)
|
|
102
|
+
|
|
103
|
+
These word counts are approximate and you can feel free to go longer if needed.
|
|
104
|
+
|
|
105
|
+
**Key patterns:**
|
|
106
|
+
- Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.
|
|
107
|
+
- Reference files clearly from SKILL.md with guidance on when to read them. Relative references resolve against the skill directory (the parent of SKILL.md).
|
|
108
|
+
- For large reference files (>300 lines), include a table of contents.
|
|
109
|
+
|
|
110
|
+
**Domain organization**: When a skill supports multiple domains/frameworks, organize by variant:
|
|
111
|
+
|
|
112
|
+
```
|
|
113
|
+
cloud-deploy/
|
|
114
|
+
├── SKILL.md (workflow + selection)
|
|
115
|
+
└── references/
|
|
116
|
+
├── aws.md
|
|
117
|
+
├── gcp.md
|
|
118
|
+
└── azure.md
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
The model reads only the relevant reference file.
|
|
122
|
+
|
|
123
|
+
#### Principle of Lack of Surprise
|
|
124
|
+
|
|
125
|
+
Skills must not contain malware, exploit code, or any content that could compromise system security. A skill's contents should not surprise the user in their intent if described. Don't go along with requests to create misleading skills or skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Things like a "roleplay as an XYZ" are OK though.
|
|
126
|
+
|
|
127
|
+
#### Writing Patterns
|
|
128
|
+
|
|
129
|
+
Prefer using the imperative form in instructions.
|
|
130
|
+
|
|
131
|
+
**Defining output formats** - You can do it like this:
|
|
132
|
+
|
|
133
|
+
```markdown
|
|
134
|
+
## Report structure
|
|
135
|
+
ALWAYS use this exact template:
|
|
136
|
+
# [Title]
|
|
137
|
+
## Executive summary
|
|
138
|
+
## Key findings
|
|
139
|
+
## Recommendations
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
**Examples pattern** - It's useful to include examples:
|
|
143
|
+
|
|
144
|
+
```markdown
|
|
145
|
+
## Commit message format
|
|
146
|
+
**Example 1:**
|
|
147
|
+
Input: Added user authentication with JWT tokens
|
|
148
|
+
Output: feat(auth): implement JWT-based authentication
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
### Writing Style
|
|
152
|
+
|
|
153
|
+
Try to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.
|
|
154
|
+
|
|
155
|
+
### Test Cases
|
|
156
|
+
|
|
157
|
+
After writing the skill draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user: "Here are a few test cases I'd like to try. Do these look right, or do you want to add more?" Then run them.
|
|
158
|
+
|
|
159
|
+
Save test cases to `evals/evals.json` inside the skill directory. Don't write assertions yet — just the prompts. You'll draft assertions while reviewing the first runs.
|
|
160
|
+
|
|
161
|
+
```json
|
|
162
|
+
{
|
|
163
|
+
"skill_name": "example-skill",
|
|
164
|
+
"evals": [
|
|
165
|
+
{
|
|
166
|
+
"id": 1,
|
|
167
|
+
"prompt": "User's task prompt",
|
|
168
|
+
"expected_output": "Description of expected result",
|
|
169
|
+
"files": []
|
|
170
|
+
}
|
|
171
|
+
]
|
|
172
|
+
}
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
## Running and evaluating test cases in neko
|
|
176
|
+
|
|
177
|
+
neko runs one conversation at a time, so the test loop is conversational rather than scripted:
|
|
178
|
+
|
|
179
|
+
1. **With-skill runs**: ask the user to open a **new session** and submit `/skill:<name> <test prompt>` for each test case. A fresh session matters — the current conversation already knows how the skill was written, which contaminates the test. Save notable outputs under `<skill-name>-workspace/iteration-<N>/eval-<id>/with_skill/` as a sibling of the skill directory when the outputs are files worth comparing across iterations.
|
|
180
|
+
2. **Baseline runs**: for a new skill, the baseline is the same prompt in a fresh session *without* invoking the skill. For improving an existing skill, snapshot the old version first (`cp -r <skill> <workspace>/skill-snapshot/`) so you can diff behavior.
|
|
181
|
+
3. **Draft assertions while waiting**: good assertions are objectively verifiable and have descriptive names ("output CSV has a profit_margin column", not "output looks right"). Subjective skills (writing style, design) are better evaluated qualitatively — don't force assertions onto things that need human judgment. Add them to `evals/evals.json` as an `expectations` array per eval.
|
|
182
|
+
4. **Grade**: when outputs come back, check each assertion against them. For programmatically checkable assertions, write and run a small script rather than eyeballing it — scripts are faster, more reliable, and reusable across iterations. Record results next to the outputs (e.g. `grading.json` with `{text, passed, evidence}` entries per assertion).
|
|
183
|
+
5. **Review with the user**: present the outputs and grading inline — for each test case, show the prompt, what happened, and what passed/failed. Ask: "How does this look? Anything you'd change?"
|
|
184
|
+
|
|
185
|
+
## Improving the skill
|
|
186
|
+
|
|
187
|
+
This is the heart of the loop. You've run the test cases, the user has reviewed the results, and now you need to make the skill better based on their feedback.
|
|
188
|
+
|
|
189
|
+
1. **Generalize from the feedback.** The skill should work across a million future prompts, not just the few examples you're iterating on. Rather than fiddly overfit changes or oppressively constrictive MUSTs, if there's a stubborn issue, try different metaphors or different patterns of working.
|
|
190
|
+
2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Read the transcripts, not just the final outputs — if the skill makes the model waste time on unproductive steps, cut the parts causing that.
|
|
191
|
+
3. **Explain the why.** Today's LLMs are smart and have good theory of mind. If you find yourself writing ALWAYS or NEVER in all caps, that's a yellow flag — reframe and explain the reasoning so the model understands why the thing you're asking for matters.
|
|
192
|
+
4. **Look for repeated work across test cases.** If every test run independently wrote a similar helper script or took the same multi-step approach, that's a strong signal the skill should bundle that script in `scripts/` and reference it. This saves every future invocation from reinventing the wheel.
|
|
193
|
+
|
|
194
|
+
Take your time and really mull improvements over. Write a draft revision, then look at it anew.
|
|
195
|
+
|
|
196
|
+
### The iteration loop
|
|
197
|
+
|
|
198
|
+
After improving the skill:
|
|
199
|
+
|
|
200
|
+
1. Apply your improvements to the skill
|
|
201
|
+
2. Rerun all test cases in fresh sessions (new iteration directory), including baselines
|
|
202
|
+
3. Review with the user, read the feedback, improve again, repeat
|
|
203
|
+
|
|
204
|
+
Keep going until the user is happy, the feedback is all empty, or you're not making meaningful progress.
|
|
205
|
+
|
|
206
|
+
---
|
|
207
|
+
|
|
208
|
+
## Description Optimization
|
|
209
|
+
|
|
210
|
+
The description field in SKILL.md frontmatter is the primary mechanism that determines whether the skill triggers. After creating or improving a skill, offer to optimize it.
|
|
211
|
+
|
|
212
|
+
### Step 1: Generate trigger eval queries
|
|
213
|
+
|
|
214
|
+
Create 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:
|
|
215
|
+
|
|
216
|
+
```json
|
|
217
|
+
[
|
|
218
|
+
{"query": "the user prompt", "should_trigger": true},
|
|
219
|
+
{"query": "another prompt", "should_trigger": false}
|
|
220
|
+
]
|
|
221
|
+
```
|
|
222
|
+
|
|
223
|
+
The queries must be realistic — concrete and specific, with file paths, personal context, column names, company names, URLs, a little backstory. Some lowercase, some with typos or casual speech. Focus on edge cases rather than clear-cut ones.
|
|
224
|
+
|
|
225
|
+
Bad: `"Format this data"`, `"Extract text from PDF"`
|
|
226
|
+
|
|
227
|
+
Good: `"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage..."`
|
|
228
|
+
|
|
229
|
+
For **should-trigger** queries (8-10), cover different phrasings of the same intent — formal and casual — including cases where the user doesn't name the skill or file type but clearly needs it. For **should-not-trigger** queries (8-10), the valuable ones are near-misses: adjacent domains, ambiguous phrasing sharing keywords but needing something different. "Write a fibonacci function" as a negative for a PDF skill is too easy — it tests nothing.
|
|
230
|
+
|
|
231
|
+
Note that models only consult skills for tasks they can't easily handle on their own — simple one-step queries may not trigger a skill even with a perfect description. Make your eval queries substantive enough that consulting a skill would actually help.
|
|
232
|
+
|
|
233
|
+
### Step 2: Review with user
|
|
234
|
+
|
|
235
|
+
Present the eval set for review using the HTML template in this skill's `assets/eval_review.html`:
|
|
236
|
+
|
|
237
|
+
1. Read the template
|
|
238
|
+
2. Replace the placeholders: `__EVAL_DATA_PLACEHOLDER__` → the JSON array (no quotes — it's a JS assignment), `__SKILL_NAME_PLACEHOLDER__` → the skill's name, `__SKILL_DESCRIPTION_PLACEHOLDER__` → the current description
|
|
239
|
+
3. Write to a temp file (e.g. `/tmp/eval_review_<skill-name>.html`) and open it with `open` (macOS) or tell the user the path
|
|
240
|
+
4. The user can edit queries, toggle should-trigger, add/remove entries, then "Export Eval Set" downloads the final JSON
|
|
241
|
+
|
|
242
|
+
This step matters — bad eval queries lead to bad descriptions.
|
|
243
|
+
|
|
244
|
+
### Step 3: Iterate the description
|
|
245
|
+
|
|
246
|
+
For each should-trigger query, reason honestly about whether the current description would make a model pick this skill; for each should-not-trigger query, whether it would wrongly fire. Rewrite the description to fix the failures, keeping it pushy but honest. Show the user before/after. The real confirmation is behavioral: the user tries a few of the trigger queries in fresh sessions and sees whether the skill gets picked up.
|
|
247
|
+
|
|
248
|
+
---
|
|
249
|
+
|
|
250
|
+
## Packaging for the skill market
|
|
251
|
+
|
|
252
|
+
When the user wants to share a skill through the skill market, package the directory as a zip with the skill folder as the single top-level entry (the market requires exactly one SKILL.md per package):
|
|
253
|
+
|
|
254
|
+
```bash
|
|
255
|
+
cd <parent-of-skill-dir> && zip -r <name>.zip <name>
|
|
256
|
+
```
|
|
257
|
+
|
|
258
|
+
Hand the resulting zip to the user — uploads are done by market administrators, not from this client.
|
|
259
|
+
|
|
260
|
+
---
|
|
261
|
+
|
|
262
|
+
Repeating the core loop for emphasis:
|
|
263
|
+
|
|
264
|
+
- Figure out what the skill is about
|
|
265
|
+
- Draft or edit the skill (in the workspace's `.agents/skills/`)
|
|
266
|
+
- Test via fresh sessions and `/skill:<name>`
|
|
267
|
+
- Evaluate with the user, improve, repeat
|
|
268
|
+
- Package the final skill and hand it to the user
|
|
269
|
+
|
|
270
|
+
Good luck!
|
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
<!DOCTYPE html>
|
|
2
|
+
<html lang="en">
|
|
3
|
+
<head>
|
|
4
|
+
<meta charset="UTF-8">
|
|
5
|
+
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
6
|
+
<title>Eval Set Review - __SKILL_NAME_PLACEHOLDER__</title>
|
|
7
|
+
<link rel="preconnect" href="https://fonts.googleapis.com">
|
|
8
|
+
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
|
|
9
|
+
<link href="https://fonts.googleapis.com/css2?family=Poppins:wght@500;600&family=Lora:wght@400;500&display=swap" rel="stylesheet">
|
|
10
|
+
<style>
|
|
11
|
+
* { box-sizing: border-box; margin: 0; padding: 0; }
|
|
12
|
+
body { font-family: 'Lora', Georgia, serif; background: #faf9f5; padding: 2rem; color: #141413; }
|
|
13
|
+
h1 { font-family: 'Poppins', sans-serif; margin-bottom: 0.5rem; font-size: 1.5rem; }
|
|
14
|
+
.description { color: #b0aea5; margin-bottom: 1.5rem; font-style: italic; max-width: 900px; }
|
|
15
|
+
.controls { margin-bottom: 1rem; display: flex; gap: 0.5rem; }
|
|
16
|
+
.btn { font-family: 'Poppins', sans-serif; padding: 0.5rem 1rem; border: none; border-radius: 6px; cursor: pointer; font-size: 0.875rem; font-weight: 500; }
|
|
17
|
+
.btn-add { background: #6a9bcc; color: white; }
|
|
18
|
+
.btn-add:hover { background: #5889b8; }
|
|
19
|
+
.btn-export { background: #d97757; color: white; }
|
|
20
|
+
.btn-export:hover { background: #c4613f; }
|
|
21
|
+
table { width: 100%; max-width: 1100px; border-collapse: collapse; background: white; border-radius: 6px; overflow: hidden; box-shadow: 0 1px 3px rgba(0,0,0,0.08); }
|
|
22
|
+
th { font-family: 'Poppins', sans-serif; background: #141413; color: #faf9f5; padding: 0.75rem 1rem; text-align: left; font-size: 0.875rem; }
|
|
23
|
+
td { padding: 0.75rem 1rem; border-bottom: 1px solid #e8e6dc; vertical-align: top; }
|
|
24
|
+
tr:nth-child(even) td { background: #faf9f5; }
|
|
25
|
+
tr:hover td { background: #f3f1ea; }
|
|
26
|
+
.section-header td { background: #e8e6dc; font-family: 'Poppins', sans-serif; font-weight: 500; font-size: 0.8rem; color: #141413; text-transform: uppercase; letter-spacing: 0.05em; }
|
|
27
|
+
.query-input { width: 100%; padding: 0.4rem; border: 1px solid #e8e6dc; border-radius: 4px; font-size: 0.875rem; font-family: 'Lora', Georgia, serif; resize: vertical; min-height: 60px; }
|
|
28
|
+
.query-input:focus { outline: none; border-color: #d97757; box-shadow: 0 0 0 2px rgba(217,119,87,0.15); }
|
|
29
|
+
.toggle { position: relative; display: inline-block; width: 44px; height: 24px; }
|
|
30
|
+
.toggle input { opacity: 0; width: 0; height: 0; }
|
|
31
|
+
.toggle .slider { position: absolute; inset: 0; background: #b0aea5; border-radius: 24px; cursor: pointer; transition: 0.2s; }
|
|
32
|
+
.toggle .slider::before { content: ""; position: absolute; width: 18px; height: 18px; left: 3px; bottom: 3px; background: white; border-radius: 50%; transition: 0.2s; }
|
|
33
|
+
.toggle input:checked + .slider { background: #d97757; }
|
|
34
|
+
.toggle input:checked + .slider::before { transform: translateX(20px); }
|
|
35
|
+
.btn-delete { background: #c44; color: white; padding: 0.3rem 0.6rem; border: none; border-radius: 4px; cursor: pointer; font-size: 0.75rem; font-family: 'Poppins', sans-serif; }
|
|
36
|
+
.btn-delete:hover { background: #a33; }
|
|
37
|
+
.summary { margin-top: 1rem; color: #b0aea5; font-size: 0.875rem; }
|
|
38
|
+
</style>
|
|
39
|
+
</head>
|
|
40
|
+
<body>
|
|
41
|
+
<h1>Eval Set Review: <span id="skill-name">__SKILL_NAME_PLACEHOLDER__</span></h1>
|
|
42
|
+
<p class="description">Current description: <span id="skill-desc">__SKILL_DESCRIPTION_PLACEHOLDER__</span></p>
|
|
43
|
+
|
|
44
|
+
<div class="controls">
|
|
45
|
+
<button class="btn btn-add" onclick="addRow()">+ Add Query</button>
|
|
46
|
+
<button class="btn btn-export" onclick="exportEvalSet()">Export Eval Set</button>
|
|
47
|
+
</div>
|
|
48
|
+
|
|
49
|
+
<table>
|
|
50
|
+
<thead>
|
|
51
|
+
<tr>
|
|
52
|
+
<th style="width:65%">Query</th>
|
|
53
|
+
<th style="width:18%">Should Trigger</th>
|
|
54
|
+
<th style="width:10%">Actions</th>
|
|
55
|
+
</tr>
|
|
56
|
+
</thead>
|
|
57
|
+
<tbody id="eval-body"></tbody>
|
|
58
|
+
</table>
|
|
59
|
+
|
|
60
|
+
<p class="summary" id="summary"></p>
|
|
61
|
+
|
|
62
|
+
<script>
|
|
63
|
+
const EVAL_DATA = __EVAL_DATA_PLACEHOLDER__;
|
|
64
|
+
|
|
65
|
+
let evalItems = [...EVAL_DATA];
|
|
66
|
+
|
|
67
|
+
function render() {
|
|
68
|
+
const tbody = document.getElementById('eval-body');
|
|
69
|
+
tbody.innerHTML = '';
|
|
70
|
+
|
|
71
|
+
// Sort: should-trigger first, then should-not-trigger
|
|
72
|
+
const sorted = evalItems
|
|
73
|
+
.map((item, origIdx) => ({ ...item, origIdx }))
|
|
74
|
+
.sort((a, b) => (b.should_trigger ? 1 : 0) - (a.should_trigger ? 1 : 0));
|
|
75
|
+
|
|
76
|
+
let lastGroup = null;
|
|
77
|
+
sorted.forEach(item => {
|
|
78
|
+
const group = item.should_trigger ? 'trigger' : 'no-trigger';
|
|
79
|
+
if (group !== lastGroup) {
|
|
80
|
+
const headerRow = document.createElement('tr');
|
|
81
|
+
headerRow.className = 'section-header';
|
|
82
|
+
headerRow.innerHTML = `<td colspan="3">${item.should_trigger ? 'Should Trigger' : 'Should NOT Trigger'}</td>`;
|
|
83
|
+
tbody.appendChild(headerRow);
|
|
84
|
+
lastGroup = group;
|
|
85
|
+
}
|
|
86
|
+
|
|
87
|
+
const idx = item.origIdx;
|
|
88
|
+
const tr = document.createElement('tr');
|
|
89
|
+
tr.innerHTML = `
|
|
90
|
+
<td><textarea class="query-input" onchange="updateQuery(${idx}, this.value)">${escapeHtml(item.query)}</textarea></td>
|
|
91
|
+
<td>
|
|
92
|
+
<label class="toggle">
|
|
93
|
+
<input type="checkbox" ${item.should_trigger ? 'checked' : ''} onchange="updateTrigger(${idx}, this.checked)">
|
|
94
|
+
<span class="slider"></span>
|
|
95
|
+
</label>
|
|
96
|
+
<span style="margin-left:8px;font-size:0.8rem;color:#b0aea5">${item.should_trigger ? 'Yes' : 'No'}</span>
|
|
97
|
+
</td>
|
|
98
|
+
<td><button class="btn-delete" onclick="deleteRow(${idx})">Delete</button></td>
|
|
99
|
+
`;
|
|
100
|
+
tbody.appendChild(tr);
|
|
101
|
+
});
|
|
102
|
+
updateSummary();
|
|
103
|
+
}
|
|
104
|
+
|
|
105
|
+
function escapeHtml(text) {
|
|
106
|
+
const div = document.createElement('div');
|
|
107
|
+
div.textContent = text;
|
|
108
|
+
return div.innerHTML;
|
|
109
|
+
}
|
|
110
|
+
|
|
111
|
+
function updateQuery(idx, value) { evalItems[idx].query = value; updateSummary(); }
|
|
112
|
+
function updateTrigger(idx, value) { evalItems[idx].should_trigger = value; render(); }
|
|
113
|
+
function deleteRow(idx) { evalItems.splice(idx, 1); render(); }
|
|
114
|
+
|
|
115
|
+
function addRow() {
|
|
116
|
+
evalItems.push({ query: '', should_trigger: true });
|
|
117
|
+
render();
|
|
118
|
+
const inputs = document.querySelectorAll('.query-input');
|
|
119
|
+
inputs[inputs.length - 1].focus();
|
|
120
|
+
}
|
|
121
|
+
|
|
122
|
+
function updateSummary() {
|
|
123
|
+
const trigger = evalItems.filter(i => i.should_trigger).length;
|
|
124
|
+
const noTrigger = evalItems.filter(i => !i.should_trigger).length;
|
|
125
|
+
document.getElementById('summary').textContent =
|
|
126
|
+
`${evalItems.length} queries total: ${trigger} should trigger, ${noTrigger} should not trigger`;
|
|
127
|
+
}
|
|
128
|
+
|
|
129
|
+
function exportEvalSet() {
|
|
130
|
+
const valid = evalItems.filter(i => i.query.trim() !== '');
|
|
131
|
+
const data = valid.map(i => ({ query: i.query.trim(), should_trigger: i.should_trigger }));
|
|
132
|
+
const blob = new Blob([JSON.stringify(data, null, 2)], { type: 'application/json' });
|
|
133
|
+
const url = URL.createObjectURL(blob);
|
|
134
|
+
const a = document.createElement('a');
|
|
135
|
+
a.href = url;
|
|
136
|
+
a.download = 'eval_set.json';
|
|
137
|
+
document.body.appendChild(a);
|
|
138
|
+
a.click();
|
|
139
|
+
document.body.removeChild(a);
|
|
140
|
+
URL.revokeObjectURL(url);
|
|
141
|
+
}
|
|
142
|
+
|
|
143
|
+
render();
|
|
144
|
+
</script>
|
|
145
|
+
</body>
|
|
146
|
+
</html>
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: skill-finder
|
|
3
|
+
description: Discover and suggest installable skills from the neko skill market. Use when the user asks "how do I do X", "is there a skill for X", "find a skill that can...", or expresses interest in extending the agent's capabilities — especially for specialized domains like documents, frontend, testing, or workflow automation.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Skill Finder
|
|
7
|
+
|
|
8
|
+
Help the user discover skills from the neko skill market. You search and present; the user installs.
|
|
9
|
+
|
|
10
|
+
## When to use
|
|
11
|
+
|
|
12
|
+
- The user asks "how do I do X" where X might be a common task with an existing skill
|
|
13
|
+
- The user says "find a skill for X", "is there a skill for X", "can you do X" where X is a specialized capability
|
|
14
|
+
- The user expresses interest in extending your capabilities or mentions a recurring workflow
|
|
15
|
+
|
|
16
|
+
## How to search
|
|
17
|
+
|
|
18
|
+
The market has a read-only JSON API that needs no credentials. Search it with bash:
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
curl -s "<market-url>/api/skills?q=<query>"
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
Each result has `name`, `description`, `category`, `metadata.source`, `version`, and `size_bytes`. Try a couple of keyword variants if the first query misses (e.g. "pdf", then "document").
|
|
25
|
+
|
|
26
|
+
The default market URL is `https://skill.kirineko.tech`. If the user has configured a different one (`skills.marketUrl` in `neko.config.json`), use that instead.
|
|
27
|
+
|
|
28
|
+
## Presenting candidates
|
|
29
|
+
|
|
30
|
+
Present matches compactly: name, one-line description, category and source. Example:
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
I found a couple of skills that might help:
|
|
34
|
+
|
|
35
|
+
- **pdf** (documents · Anthropic) — read, extract, merge, and manipulate PDF files
|
|
36
|
+
- **read** (research · Tw93/Waza) — fetch URLs and PDFs into clean Markdown
|
|
37
|
+
|
|
38
|
+
To install one, open the skill market: the market page in the Web UI, or `/skills` in the TUI.
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## The install boundary
|
|
42
|
+
|
|
43
|
+
Do not download or install skills yourself — no fetching the zip, no writing into skills directories. Installation belongs to the user through the market interface, which shows install status, previews, and overwrite confirmations. Your job ends at a good recommendation plus pointing at the entry point.
|
|
44
|
+
|
|
45
|
+
If neither market interface is available in this environment, say so and give the user the exact skill name to install later.
|
|
46
|
+
|
|
47
|
+
## When nothing matches
|
|
48
|
+
|
|
49
|
+
1. Say that no existing skill matched.
|
|
50
|
+
2. Offer to help with the task directly with your general capabilities.
|
|
51
|
+
3. If it looks like a recurring need, suggest creating one — the `skill-creator` skill walks through that.
|
package/package.json
CHANGED
|
@@ -24,7 +24,7 @@
|
|
|
24
24
|
},
|
|
25
25
|
"packageManager": "bun@1.4.2",
|
|
26
26
|
"trustedDependencies": [],
|
|
27
|
-
"version": "0.2.
|
|
27
|
+
"version": "0.2.4",
|
|
28
28
|
"description": "A local AI coding assistant with terminal and web interfaces, powered by Pi and Bun.",
|
|
29
29
|
"license": "MIT",
|
|
30
30
|
"repository": {
|