@dsh-cc/skill-loader 0.5.0
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/LICENSE +201 -0
- package/README.i18n.yaml +6 -0
- package/README.md +75 -0
- package/README.zh.md +75 -0
- package/lib/bundled/batch.d.ts +15 -0
- package/lib/bundled/batch.d.ts.map +1 -0
- package/lib/bundled/batch.js +97 -0
- package/lib/bundled/batch.js.map +1 -0
- package/lib/bundled/debug.d.ts +14 -0
- package/lib/bundled/debug.d.ts.map +1 -0
- package/lib/bundled/debug.js +51 -0
- package/lib/bundled/debug.js.map +1 -0
- package/lib/bundled/index.d.ts +36 -0
- package/lib/bundled/index.d.ts.map +1 -0
- package/lib/bundled/index.js +47 -0
- package/lib/bundled/index.js.map +1 -0
- package/lib/bundled/simplify.d.ts +12 -0
- package/lib/bundled/simplify.d.ts.map +1 -0
- package/lib/bundled/simplify.js +67 -0
- package/lib/bundled/simplify.js.map +1 -0
- package/lib/discovery.d.ts +70 -0
- package/lib/discovery.d.ts.map +1 -0
- package/lib/discovery.js +165 -0
- package/lib/discovery.js.map +1 -0
- package/lib/frontmatter.d.ts +72 -0
- package/lib/frontmatter.d.ts.map +1 -0
- package/lib/frontmatter.js +200 -0
- package/lib/frontmatter.js.map +1 -0
- package/lib/index.d.ts +100 -0
- package/lib/index.d.ts.map +1 -0
- package/lib/index.js +343 -0
- package/lib/index.js.map +1 -0
- package/lib/invariant.d.ts +16 -0
- package/lib/invariant.d.ts.map +1 -0
- package/lib/invariant.js +22 -0
- package/lib/invariant.js.map +1 -0
- package/lib/render.d.ts +111 -0
- package/lib/render.d.ts.map +1 -0
- package/lib/render.js +179 -0
- package/lib/render.js.map +1 -0
- package/lib/translate.d.ts +66 -0
- package/lib/translate.d.ts.map +1 -0
- package/lib/translate.js +134 -0
- package/lib/translate.js.map +1 -0
- package/lib/types.d.ts +46 -0
- package/lib/types.d.ts.map +1 -0
- package/lib/types.js +8 -0
- package/lib/types.js.map +1 -0
- package/package.json +59 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
52
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
53
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
54
|
+
means any form of electronic, verbal, or written communication sent
|
|
55
|
+
to the Licensor or its representatives, including but not limited to
|
|
56
|
+
communication on electronic mailing lists, source code control systems,
|
|
57
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
58
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
59
|
+
excluding communication that is conspicuously marked or otherwise
|
|
60
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
61
|
+
|
|
62
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
63
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
64
|
+
subsequently incorporated within the Work.
|
|
65
|
+
|
|
66
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
67
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
68
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
69
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
70
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
71
|
+
Work and such Derivative Works in Source or Object form.
|
|
72
|
+
|
|
73
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
74
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
75
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
76
|
+
(except as stated in this section) patent license to make, have made,
|
|
77
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
78
|
+
where such license applies only to those patent claims licensable
|
|
79
|
+
by such Contributor that are necessarily infringed by their
|
|
80
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
81
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
82
|
+
institute patent litigation against any entity (including a
|
|
83
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
84
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
85
|
+
or contributory patent infringement, then any patent licenses
|
|
86
|
+
granted to You under this License for that Work shall terminate
|
|
87
|
+
as of the date such litigation is filed.
|
|
88
|
+
|
|
89
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
90
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
91
|
+
modifications, and in Source or Object form, provided that You
|
|
92
|
+
meet the following conditions:
|
|
93
|
+
|
|
94
|
+
(a) You must give any other recipients of the Work or
|
|
95
|
+
Derivative Works a copy of this License; and
|
|
96
|
+
|
|
97
|
+
(b) You must cause any modified files to carry prominent notices
|
|
98
|
+
stating that You changed the files; and
|
|
99
|
+
|
|
100
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
101
|
+
that You distribute, all copyright, patent, trademark, and
|
|
102
|
+
attribution notices from the Source form of the Work,
|
|
103
|
+
excluding those notices that do not pertain to any part of
|
|
104
|
+
the Derivative Works; and
|
|
105
|
+
|
|
106
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
107
|
+
distribution, then any Derivative Works that You distribute must
|
|
108
|
+
include a readable copy of the attribution notices contained
|
|
109
|
+
within such NOTICE file, excluding those notices that do not
|
|
110
|
+
pertain to any part of the Derivative Works, in at least one
|
|
111
|
+
of the following places: within a NOTICE text file distributed
|
|
112
|
+
as part of the Derivative Works; within the Source form or
|
|
113
|
+
documentation, if provided along with the Derivative Works; or,
|
|
114
|
+
within a display generated by the Derivative Works, if and
|
|
115
|
+
wherever such third-party notices normally appear. The contents
|
|
116
|
+
of the NOTICE file are for informational purposes only and
|
|
117
|
+
do not modify the License. You may add Your own attribution
|
|
118
|
+
notices within Derivative Works that You distribute, alongside
|
|
119
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
120
|
+
that such additional attribution notices cannot be construed
|
|
121
|
+
as modifying the License.
|
|
122
|
+
|
|
123
|
+
You may add Your own copyright statement to Your modifications and
|
|
124
|
+
may provide additional or different license terms and conditions
|
|
125
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
126
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
127
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
128
|
+
the conditions stated in this License.
|
|
129
|
+
|
|
130
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
131
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
132
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
133
|
+
this License, without any additional terms or conditions.
|
|
134
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
135
|
+
the terms of any separate license agreement you may have executed
|
|
136
|
+
with Licensor regarding such Contributions.
|
|
137
|
+
|
|
138
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
139
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
140
|
+
except as required for reasonable and customary use in describing the
|
|
141
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
142
|
+
|
|
143
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
144
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
145
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
146
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
147
|
+
implied, including, without limitation, any warranties or conditions
|
|
148
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
149
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
150
|
+
appropriateness of using or redistributing the Work and assume any
|
|
151
|
+
risks associated with Your exercise of permissions under this License.
|
|
152
|
+
|
|
153
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
154
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
155
|
+
unless required by applicable law (such as deliberate and grossly
|
|
156
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
157
|
+
liable to You for damages, including any direct, indirect, special,
|
|
158
|
+
incidental, or consequential damages of any character arising as a
|
|
159
|
+
result of this License or out of the use or inability to use the
|
|
160
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
161
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
162
|
+
other commercial damages or losses), even if such Contributor
|
|
163
|
+
has been advised of the possibility of such damages.
|
|
164
|
+
|
|
165
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
166
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
167
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
168
|
+
or other liability obligations and/or rights consistent with this
|
|
169
|
+
License. However, in accepting such obligations, You may act only
|
|
170
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
171
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
172
|
+
defend, and hold each Contributor harmless for any liability
|
|
173
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
174
|
+
of your accepting any such warranty or additional liability.
|
|
175
|
+
|
|
176
|
+
END OF TERMS AND CONDITIONS
|
|
177
|
+
|
|
178
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
179
|
+
|
|
180
|
+
To apply the Apache License to your work, attach the following
|
|
181
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
182
|
+
replaced with your own identifying information. (Don't include
|
|
183
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
184
|
+
comment syntax for the file format. We also recommend that a
|
|
185
|
+
file or class name and description of purpose be included on the
|
|
186
|
+
same "printed page" as the copyright notice for easier
|
|
187
|
+
identification within third-party archives.
|
|
188
|
+
|
|
189
|
+
Copyright [yyyy] [name of copyright owner]
|
|
190
|
+
|
|
191
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
192
|
+
you may not use this file except in compliance with the License.
|
|
193
|
+
You may obtain a copy of the License at
|
|
194
|
+
|
|
195
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
196
|
+
|
|
197
|
+
Unless required by applicable law or agreed to in writing, software
|
|
198
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
199
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
200
|
+
See the License for the specific language governing permissions and
|
|
201
|
+
limitations under the License.
|
package/README.i18n.yaml
ADDED
|
@@ -0,0 +1,6 @@
|
|
|
1
|
+
# Bilingual-pair consistency record (docs/i18n/README.md): the git blob hash of each
|
|
2
|
+
# side as of the last confirmed-consistent state. Both languages carry equal authority;
|
|
3
|
+
# after editing either side, bring the other along and re-record with:
|
|
4
|
+
# pnpm run verify-translation-pairing --write packages/skill/skill-claude-code/README.md
|
|
5
|
+
README.md: b923e9dbaea04f31c9a3343cb60fa72873ea3aba
|
|
6
|
+
README.zh.md: 407d463dab330c7732dcc2d0960ace5a5f93ada0
|
package/README.md
ADDED
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# @dsh-cc/skill-loader
|
|
2
|
+
|
|
3
|
+
English | [中文](README.zh.md)
|
|
4
|
+
|
|
5
|
+
Claude Code skill-format compatible provider for the `ctx.skills` registry.
|
|
6
|
+
|
|
7
|
+
This package discovers `SKILL.md` skills in Claude Code's directory layout (managed, project, user, and additional roots), parses the full Claude Code frontmatter spec, and serves them through `@deepseek-ai/dsh-skill`. It is a compatibility provider: the harness can consume skills written for Claude Code without copying the runtime that executes them. The registry remains in `@deepseek-ai/dsh-skill`; the session catalogs and loader remain in `@deepseek-ai/dsh-tool-skill`.
|
|
8
|
+
|
|
9
|
+
## Plugin
|
|
10
|
+
|
|
11
|
+
Requires `ctx.skills` (`inject: ['skills']`).
|
|
12
|
+
|
|
13
|
+
### Config
|
|
14
|
+
|
|
15
|
+
| Field | Default | Meaning |
|
|
16
|
+
|---|---|---|
|
|
17
|
+
| `providerName` | `claude-code` | Unique name used to register this provider on `ctx.skills`. |
|
|
18
|
+
| `dshHome` | `$DSH_HOME` or `~/.dsh` | Harness home resolved by [`@deepseek-ai/dsh-home-paths`](../../util/home-paths/README.md); scans `skills` under this directory as the user root. |
|
|
19
|
+
| `managedDir` | — | Optional managed policy root scanned before all defaults. |
|
|
20
|
+
| `additionalDirs` | `[]` | Additional skill roots appended after project and user roots. |
|
|
21
|
+
|
|
22
|
+
## Discovery
|
|
23
|
+
|
|
24
|
+
Roots are discovered in this precedence order (lower rank wins name conflicts):
|
|
25
|
+
|
|
26
|
+
| Rank | Source | Path |
|
|
27
|
+
|---|---|---|
|
|
28
|
+
| 100 | managed | `config.managedDir` |
|
|
29
|
+
| 200 | project | `<projectRoot>/.claude/skills` |
|
|
30
|
+
| 300 | user | `<dshHome>/skills` |
|
|
31
|
+
| 400 | additional | each `config.additionalDirs` |
|
|
32
|
+
|
|
33
|
+
The project root is the nearest ancestor containing `.git`; without one, the current cwd is used. Skills are directory bundles `<name>/SKILL.md`; legacy `.claude/commands/*.md` files are also loaded and marked `deprecated` in their metadata. Discovery deduplicates by the real path, so a symlinked or overlapping file is served once.
|
|
34
|
+
|
|
35
|
+
## Skill Format
|
|
36
|
+
|
|
37
|
+
`SKILL.md` is parsed as a YAML frontmatter document split from a Markdown body. The provider reads every known Claude Code field and tolerates unknown fields; a known field with an invalid value fails loudly at load rather than silently mis-activating.
|
|
38
|
+
|
|
39
|
+
Supported fields: `description`, `name`, `allowed-tools`, `argument-hint`, `arguments`, `when_to_use`, `version`, `model` (including `inherit`), `user-invocable`, `disable-model-invocation`, `context` (including `fork`), `agent`, `effort`, `shell`, `hooks`, and `paths`. Names must be kebab-case to register on the registry.
|
|
40
|
+
|
|
41
|
+
## Semantic translation
|
|
42
|
+
|
|
43
|
+
The provider parses and serves Claude Code fields unchanged; for most fields applying them to harness seams is the consumer's job at activation time (`paths` is the exception — see [Conditional activation](#conditional-activation), which the provider wires itself). The package exports the translators:
|
|
44
|
+
|
|
45
|
+
- `ccRestriction(allowedTools)` — turns `allowed-tools` into an allow-only `tools.restrict()` filter (a `*` or empty list yields `undefined`, so the skill inherits the caller's surface).
|
|
46
|
+
- `ccPathMatcher(patterns)` / `registerPathActivator(ctx, ...)` — the low-level primitives behind conditional activation (see below).
|
|
47
|
+
- `ccInvocation(parsed)` — resolves `disable-model-invocation` and `user-invocable` into the registry's invocation policy.
|
|
48
|
+
- `context: fork` — surfaced as `metadata.executionContext`; consumers route the skill to `ctx.subagents.start()` with its rendered body.
|
|
49
|
+
|
|
50
|
+
## Conditional activation
|
|
51
|
+
|
|
52
|
+
A skill whose frontmatter declares `paths` is a *conditional* skill matching Claude Code's semantics: it is not served until a Read/Write/Edit tool touches a file that matches one of its gitignore-style project-relative `paths`. The provider wires this itself at `apply()`:
|
|
53
|
+
|
|
54
|
+
1. `list()` parses every candidate; a `paths`-gated skill is **excluded from the catalog** until activated.
|
|
55
|
+
2. On `fs/observed`, a `read`/`write`/`edit` actor touching a matching path inside the project activates that skill (once — repeat touches are idempotent), then calls the provider control's `invalidate()`. Consumers refetch the catalog via `skills/change` and the skill now appears.
|
|
56
|
+
3. `get()` serves the activated skill normally.
|
|
57
|
+
|
|
58
|
+
This is `registerPathActivator` wired onto the provider's live per-project conditional catalog (the helper's static `projects` shape cannot model per-skill dynamic patterns, so the provider owns the listener while reusing `ccPathMatcher`). Skills already in the catalog never re-notify.
|
|
59
|
+
|
|
60
|
+
## Bundled skills
|
|
61
|
+
|
|
62
|
+
The provider ships a portable subset of Claude Code's own bundled skills as in-package `SKILL.md` documents, served directly (no disk extraction). Current subset: `debug`, `simplify`, `batch`. They are provided with `source: 'bundled'`, `rank = BUNDLED_SKILL_RANK` (600), and bodies available via `get()`. Because 600 is the highest rank in this package's range, any managed (100), project (200), user (300), or additional (400) skill of the same name wins the name conflict — matching Claude Code's precedence where local skills override built-ins.
|
|
63
|
+
|
|
64
|
+
CC's `verify` and `stuck` bundled skills are **not** ported: both are `USER_TYPE === 'ant'`-only, and `verify`'s companion body/examples are absent from the Claude Code build surface, so they cannot be reproduced faithfully.
|
|
65
|
+
|
|
66
|
+
## Rendering
|
|
67
|
+
|
|
68
|
+
`renderSkillBody` substitutes `$ARGUMENTS`, `$ARGUMENTS[n]`, `$n`, named `$name` placeholders, and `${CLAUDE_SKILL_DIR}` / `${CLAUDE_SESSION_ID}`, and segments inline-shell `` !`...` `` commands for the caller to execute (guarded by `allowInlineShell`, which MCP-sourced skills must force off). `estimateFrontmatterTokens` counts only name, description, and `when_to_use` — the body is never counted during discovery.
|
|
69
|
+
|
|
70
|
+
## Known Limitations and Deferred Work
|
|
71
|
+
|
|
72
|
+
- **Most semantic translation is consumer-side** — `allowed-tools`, `context: fork`, and `argument-hint` are surfaced as metadata and helpers and applied by the consumer, because a provider has no agent reference at load time. `paths` conditional activation is the exception and is applied by this provider.
|
|
73
|
+
- **Inline shell is not executed by this package** — commands are extracted and returned; execution is the caller's responsibility.
|
|
74
|
+
- **One-level discovery** — only `<root>/<name>/SKILL.md` and legacy top-level `.claude/commands/*.md` are recognized.
|
|
75
|
+
- **Bundled subset is partial** — `verify` and `stuck` are omitted (ant-only / missing content); `batch`'s and `debug`'s runtime-injected values (tool names, log paths) are kept as authored literal placeholders rather than resolved at invocation.
|
package/README.zh.md
ADDED
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# @dsh-cc/skill-loader
|
|
2
|
+
|
|
3
|
+
[English](README.md) | 中文
|
|
4
|
+
|
|
5
|
+
面向 Claude Code skill 格式兼容的 `ctx.skills` 注册表 Provider。
|
|
6
|
+
|
|
7
|
+
本包在 Claude Code 的目录布局(managed、project、user 与附加目录)中发现 `SKILL.md` skill,解析完整的 Claude Code frontmatter 规范,并通过 `@deepseek-ai/dsh-skill` 提供给 harness。它是一个兼容性 Provider:harness 可以消费为 Claude Code 编写的 skill,而无需复制执行它们的运行时。注册表仍位于 `@deepseek-ai/dsh-skill`;会话目录与加载器仍位于 `@deepseek-ai/dsh-tool-skill`。
|
|
8
|
+
|
|
9
|
+
## 插件
|
|
10
|
+
|
|
11
|
+
需要 `ctx.skills`(`inject: ['skills']`)。
|
|
12
|
+
|
|
13
|
+
### 配置
|
|
14
|
+
|
|
15
|
+
| 字段 | 默认值 | 含义 |
|
|
16
|
+
|---|---|---|
|
|
17
|
+
| `providerName` | `claude-code` | 用于在 `ctx.skills` 上注册此 Provider 的唯一名称。 |
|
|
18
|
+
| `dshHome` | `$DSH_HOME` 或 `~/.dsh` | 由 [`@deepseek-ai/dsh-home-paths`](../../util/home-paths/README.md) 解析的 harness 主目录;将其下的 `skills` 作为 user 根扫描。 |
|
|
19
|
+
| `managedDir` | — | 可选的托管策略根,在所有默认根之前扫描。 |
|
|
20
|
+
| `additionalDirs` | `[]` | 在 project 与 user 根之后追加的附加 skill 根。 |
|
|
21
|
+
|
|
22
|
+
## 发现
|
|
23
|
+
|
|
24
|
+
按以下优先级顺序发现根(rank 越小越优先处理同名冲突):
|
|
25
|
+
|
|
26
|
+
| Rank | 来源 | 路径 |
|
|
27
|
+
|---|---|---|
|
|
28
|
+
| 100 | managed | `config.managedDir` |
|
|
29
|
+
| 200 | project | `<projectRoot>/.claude/skills` |
|
|
30
|
+
| 300 | user | `<dshHome>/skills` |
|
|
31
|
+
| 400 | additional | 每个 `config.additionalDirs` |
|
|
32
|
+
|
|
33
|
+
project 根是最近包含 `.git` 的祖先;若无则使用当前 cwd。skill 是目录包 `<name>/SKILL.md`;旧的 `.claude/commands/*.md` 文件也会被加载,并在元数据中标记为 `deprecated`。发现按真实路径去重,因此通过符号链接或重叠路径指向的同一文件只会被提供一次。
|
|
34
|
+
|
|
35
|
+
## Skill 格式
|
|
36
|
+
|
|
37
|
+
`SKILL.md` 被解析为与 Markdown 正文分离的 YAML frontmatter 文档。Provider 读取每个已知的 Claude Code 字段并容忍未知字段;已知字段的值无效时会在加载期响亮失败,而不是静默地错误激活。
|
|
38
|
+
|
|
39
|
+
支持的字段:`description`、`name`、`allowed-tools`、`argument-hint`、`arguments`、`when_to_use`、`version`、`model`(含 `inherit`)、`user-invocable`、`disable-model-invocation`、`context`(含 `fork`)、`agent`、`effort`、`shell`、`hooks` 与 `paths`。名称必须是 kebab-case 才能注册到注册表中。
|
|
40
|
+
|
|
41
|
+
## 语义翻译
|
|
42
|
+
|
|
43
|
+
Provider 原样解析并提供 Claude Code 字段;对大多数字段,在激活时将它们应用到 harness 接缝是消费方的职责(`paths` 是例外 —— 见[条件激活](#条件激活),由本 Provider 自行接线)。本包导出的翻译器:
|
|
44
|
+
|
|
45
|
+
- `ccRestriction(allowedTools)` — 将 `allowed-tools` 转成仅允许(allow-only)的 `tools.restrict()` 过滤器(`*` 或空列表给出 `undefined`,因此该 skill 继承调用方的表面)。
|
|
46
|
+
- `ccPathMatcher(patterns)` / `registerPathActivator(ctx, ...)` — 条件激活背后的低层原语(见下文)。
|
|
47
|
+
- `ccInvocation(parsed)` — 将 `disable-model-invocation` 与 `user-invocable` 解析为注册表的调用策略。
|
|
48
|
+
- `context: fork` — 以 `metadata.executionContext` 形式呈现;消费方将该 skill 与其渲染后的正文一起路由到 `ctx.subagents.start()`。
|
|
49
|
+
|
|
50
|
+
## 条件激活
|
|
51
|
+
|
|
52
|
+
frontmatter 声明了 `paths` 的 skill 是*条件* skill,与 Claude Code 语义一致:直到 Read/Write/Edit 工具触碰了匹配其 gitignore 风格、项目相对 `paths` 之一时,它才会被提供。Provider 在 `apply()` 时自行接线:
|
|
53
|
+
|
|
54
|
+
1. `list()` 解析每个候选;带 `paths` 门控的 skill 在激活前**从目录中排除**。
|
|
55
|
+
2. 在 `fs/observed` 上,`read`/`write`/`edit` actor 触碰项目内匹配路径时将激活该 skill(仅一次 —— 重复触碰是幂等的),随后调用 provider 控制的 `invalidate()`。消费方通过 `skills/change` 重新拉取目录,该 skill 随即出现。
|
|
56
|
+
3. `get()` 正常提供已激活的 skill。
|
|
57
|
+
|
|
58
|
+
这是 `registerPathActivator` 接在 provider 的按项目实时条件目录上(该辅助函数的静态 `projects` 形态无法表达按 skill 的动态模式,因此 Provider 自行持有监听器,同时复用 `ccPathMatcher`)。已在目录中的 skill 绝不重复通知。
|
|
59
|
+
|
|
60
|
+
## Bundled skill
|
|
61
|
+
|
|
62
|
+
Provider 随包提供一个 Claude Code 自带 bundled skills 的可移植子集,作为包内 `SKILL.md` 文档,直接提供(无需落盘)。当前子集:`debug`、`simplify`、`batch`。它们以 `source: 'bundled'`、`rank = BUNDLED_SKILL_RANK`(600)提供,正文可通过 `get()` 获取。由于 600 是本包范围内最大的 rank,任何同名 managed(100)、project(200)、user(300)或 additional(400)skill 都会在同名冲突中胜出 —— 与 Claude Code 本地 skill 覆盖内置内容的优先级一致。
|
|
63
|
+
|
|
64
|
+
CC 的 `verify` 与 `stuck` bundled skill **未移植**:两者都仅限 `USER_TYPE === 'ant'`,且 `verify` 的伴随正文/示例在 Claude Code 构建面中缺失,无法忠实复现。
|
|
65
|
+
|
|
66
|
+
## 渲染
|
|
67
|
+
|
|
68
|
+
`renderSkillBody` 替换 `$ARGUMENTS`、`$ARGUMENTS[n]`、`$n`、命名 `$name` 占位符以及 `${CLAUDE_SKILL_DIR}` / `${CLAUDE_SESSION_ID}`,并将内联 shell `` !`...` `` 命令分段供调用方执行(由 `allowInlineShell` 门控,MCP 来源的 skill 必须强制关闭)。`estimateFrontmatterTokens` 只统计 name、description 与 `when_to_use` —— 发现期间从不统计正文。
|
|
69
|
+
|
|
70
|
+
## 已知限制与待办
|
|
71
|
+
|
|
72
|
+
- **多数语义翻译在消费方完成** —— `allowed-tools`、`context: fork` 与 `argument-hint` 以元数据和辅助函数形式呈现,由消费方应用,因为 Provider 在加载时没有 agent 引用。`paths` 条件激活是例外,由本 Provider 应用。
|
|
73
|
+
- **本包不执行内联 shell** —— 命令被提取并返回,执行是调用方的职责。
|
|
74
|
+
- **单层发现** —— 仅识别 `<root>/<name>/SKILL.md` 与旧的顶层 `.claude/commands/*.md`。
|
|
75
|
+
- **Bundled 子集不完整** —— 省略 `verify` 与 `stuck`(ant-only / 内容缺失);`batch` 与 `debug` 的运行时注入值(工具名、日志路径)保留为其原文的占位符,而非在调用时解析。
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Ported Claude Code bundled `batch` skill.
|
|
3
|
+
*
|
|
4
|
+
* Source: `~/workspace/github.com/claude-code/skills/bundled/batch.ts`. The
|
|
5
|
+
* original `buildPrompt(instruction)` injects the user's argument at invocation;
|
|
6
|
+
* this port keeps the authored instruction body verbatim, leaving the runtime
|
|
7
|
+
* tool-name and argument placeholders (\${SKILL_TOOL_NAME}, \${ENTER_PLAN_MODE_TOOL_NAME},
|
|
8
|
+
* \${EXIT_PLAN_MODE_TOOL_NAME}, \${ASK_USER_QUESTION_TOOL_NAME}, \${AGENT_TOOL_NAME},
|
|
9
|
+
* \${instruction}) literal.
|
|
10
|
+
*
|
|
11
|
+
* @module
|
|
12
|
+
*/
|
|
13
|
+
export declare const name = "batch";
|
|
14
|
+
export declare const SKILL_MD = "---\nname: batch\ndescription: Research and plan a large-scale change, then execute it in parallel across 5\u201330 isolated worktree agents that each open a PR.\nwhen_to_use: Use when the user wants to make a sweeping, mechanical change across many files (migrations, refactors, bulk renames) that can be decomposed into independent parallel units.\nargument-hint: '<instruction>'\ndisable-model-invocation: true\nuser-invocable: true\n---\n\n# Batch: Parallel Work Orchestration\n\nYou are orchestrating a large, parallelizable change across this codebase.\n\n## User Instruction\n\n${instruction}\n\n## Phase 1: Research and Plan (Plan Mode)\n\nCall the ${ENTER_PLAN_MODE_TOOL_NAME} tool now to enter plan mode, then:\n\n1. **Understand the scope.** Launch one or more subagents (in the foreground \u2014 you need their results) to deeply research what this instruction touches. Find all the files, patterns, and call sites that need to change. Understand the existing conventions so the migration is consistent.\n\n2. **Decompose into independent units.** Break the work into 5\u201330 self-contained units. Each unit must:\n - Be independently implementable in an isolated git worktree (no shared state with sibling units)\n - Be mergeable on its own without depending on another unit's PR landing first\n - Be roughly uniform in size (split large units, merge trivial ones)\n\n Scale the count to the actual work: few files \u2192 closer to 5; hundreds of files \u2192 closer to 30. Prefer per-directory or per-module slicing over arbitrary file lists.\n\n3. **Determine the e2e test recipe.** Figure out how a worker can verify its change actually works end-to-end \u2014 not just that unit tests pass. Look for:\n - A browser-automation tool (for UI changes: click through the affected flow, screenshot the result)\n - A tmux or CLI-verifier skill (for CLI changes: launch the app interactively, exercise the changed behavior)\n - A dev-server + curl pattern (for API changes: start the server, hit the affected endpoints)\n - An existing e2e/integration test suite the worker can run\n\n If you cannot find a concrete e2e path, use the ${ASK_USER_QUESTION_TOOL_NAME} tool to ask the user how to verify this change end-to-end. Offer 2\u20133 specific options based on what you found. Do not skip this \u2014 the workers cannot ask the user themselves.\n\n Write the recipe as a short, concrete set of steps that a worker can execute autonomously. Include any setup (start a dev server, build first) and the exact command/interaction to verify.\n\n4. **Write the plan.** In your plan file, include:\n - A summary of what you found during research\n - A numbered list of work units \u2014 for each: a short title, the list of files/directories it covers, and a one-line description of the change\n - The e2e test recipe (or \"skip e2e because \u2026\" if the user chose that)\n - The exact worker instructions you will give each agent (the shared template)\n\n5. Call ${EXIT_PLAN_MODE_TOOL_NAME} to present the plan for approval.\n\n## Phase 2: Spawn Workers (After Plan Approval)\n\nOnce the plan is approved, spawn one background agent per work unit using the ${AGENT_TOOL_NAME} tool. **All agents must use `isolation: \"worktree\"` and `run_in_background: true`.** Launch them all in a single message block so they run in parallel.\n\nFor each agent, the prompt must be fully self-contained. Include:\n- The overall goal (the user's instruction)\n- This unit's specific task (title, file list, change description \u2014 copied verbatim from your plan)\n- Any codebase conventions you discovered that the worker needs to follow\n- The e2e test recipe from your plan (or \"skip e2e because \u2026\")\n- The worker instructions below, copied verbatim:\n\n```\nAfter you finish implementing the change:\n1. **Simplify** \u2014 Invoke the ${SKILL_TOOL_NAME} tool with `skill: \"simplify\"` to review and clean up your changes.\n2. **Run unit tests** \u2014 Run the project's test suite (check for package.json scripts, Makefile targets, or common commands like `npm test`, `bun test`, `pytest`, `go test`). If tests fail, fix them.\n3. **Test end-to-end** \u2014 Follow the e2e test recipe from the coordinator's prompt (below). If the recipe says to skip e2e for this unit, skip it.\n4. **Commit and push** \u2014 Commit all changes with a clear message, push the branch, and create a PR with `gh pr create`. Use a descriptive title. If `gh` is not available or the push fails, note it in your final message.\n5. **Report** \u2014 End with a single line: `PR: <url>` so the coordinator can track it. If no PR was created, end with `PR: none \u2014 <reason>`.\n```\n\nUse `subagent_type: \"general-purpose\"` unless a more specific agent type fits.\n\n## Phase 3: Track Progress\n\nAfter launching all workers, render an initial status table:\n\n| # | Unit | Status | PR |\n|---|------|--------|----|\n| 1 | <title> | running | \u2014 |\n| 2 | <title> | running | \u2014 |\n\nAs background-agent completion notifications arrive, parse the `PR: <url>` line from each agent's result and re-render the table with updated status (`done` / `failed`) and PR links. Keep a brief failure note for any agent that did not produce a PR.\n\nWhen all agents have reported, render the final table and a one-line summary (e.g., \"22/24 units landed as PRs\").\n";
|
|
15
|
+
//# sourceMappingURL=batch.d.ts.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"batch.d.ts","sourceRoot":"","sources":["../../src/bundled/batch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,eAAO,MAAM,IAAI,UAAU,CAAA;AAE3B,eAAO,MAAM,QAAQ,uwKAkFpB,CAAA"}
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Ported Claude Code bundled `batch` skill.
|
|
3
|
+
*
|
|
4
|
+
* Source: `~/workspace/github.com/claude-code/skills/bundled/batch.ts`. The
|
|
5
|
+
* original `buildPrompt(instruction)` injects the user's argument at invocation;
|
|
6
|
+
* this port keeps the authored instruction body verbatim, leaving the runtime
|
|
7
|
+
* tool-name and argument placeholders (\${SKILL_TOOL_NAME}, \${ENTER_PLAN_MODE_TOOL_NAME},
|
|
8
|
+
* \${EXIT_PLAN_MODE_TOOL_NAME}, \${ASK_USER_QUESTION_TOOL_NAME}, \${AGENT_TOOL_NAME},
|
|
9
|
+
* \${instruction}) literal.
|
|
10
|
+
*
|
|
11
|
+
* @module
|
|
12
|
+
*/
|
|
13
|
+
export const name = 'batch';
|
|
14
|
+
export const SKILL_MD = `---
|
|
15
|
+
name: batch
|
|
16
|
+
description: Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.
|
|
17
|
+
when_to_use: Use when the user wants to make a sweeping, mechanical change across many files (migrations, refactors, bulk renames) that can be decomposed into independent parallel units.
|
|
18
|
+
argument-hint: '<instruction>'
|
|
19
|
+
disable-model-invocation: true
|
|
20
|
+
user-invocable: true
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
# Batch: Parallel Work Orchestration
|
|
24
|
+
|
|
25
|
+
You are orchestrating a large, parallelizable change across this codebase.
|
|
26
|
+
|
|
27
|
+
## User Instruction
|
|
28
|
+
|
|
29
|
+
\${instruction}
|
|
30
|
+
|
|
31
|
+
## Phase 1: Research and Plan (Plan Mode)
|
|
32
|
+
|
|
33
|
+
Call the \${ENTER_PLAN_MODE_TOOL_NAME} tool now to enter plan mode, then:
|
|
34
|
+
|
|
35
|
+
1. **Understand the scope.** Launch one or more subagents (in the foreground — you need their results) to deeply research what this instruction touches. Find all the files, patterns, and call sites that need to change. Understand the existing conventions so the migration is consistent.
|
|
36
|
+
|
|
37
|
+
2. **Decompose into independent units.** Break the work into 5–30 self-contained units. Each unit must:
|
|
38
|
+
- Be independently implementable in an isolated git worktree (no shared state with sibling units)
|
|
39
|
+
- Be mergeable on its own without depending on another unit's PR landing first
|
|
40
|
+
- Be roughly uniform in size (split large units, merge trivial ones)
|
|
41
|
+
|
|
42
|
+
Scale the count to the actual work: few files → closer to 5; hundreds of files → closer to 30. Prefer per-directory or per-module slicing over arbitrary file lists.
|
|
43
|
+
|
|
44
|
+
3. **Determine the e2e test recipe.** Figure out how a worker can verify its change actually works end-to-end — not just that unit tests pass. Look for:
|
|
45
|
+
- A browser-automation tool (for UI changes: click through the affected flow, screenshot the result)
|
|
46
|
+
- A tmux or CLI-verifier skill (for CLI changes: launch the app interactively, exercise the changed behavior)
|
|
47
|
+
- A dev-server + curl pattern (for API changes: start the server, hit the affected endpoints)
|
|
48
|
+
- An existing e2e/integration test suite the worker can run
|
|
49
|
+
|
|
50
|
+
If you cannot find a concrete e2e path, use the \${ASK_USER_QUESTION_TOOL_NAME} tool to ask the user how to verify this change end-to-end. Offer 2–3 specific options based on what you found. Do not skip this — the workers cannot ask the user themselves.
|
|
51
|
+
|
|
52
|
+
Write the recipe as a short, concrete set of steps that a worker can execute autonomously. Include any setup (start a dev server, build first) and the exact command/interaction to verify.
|
|
53
|
+
|
|
54
|
+
4. **Write the plan.** In your plan file, include:
|
|
55
|
+
- A summary of what you found during research
|
|
56
|
+
- A numbered list of work units — for each: a short title, the list of files/directories it covers, and a one-line description of the change
|
|
57
|
+
- The e2e test recipe (or "skip e2e because …" if the user chose that)
|
|
58
|
+
- The exact worker instructions you will give each agent (the shared template)
|
|
59
|
+
|
|
60
|
+
5. Call \${EXIT_PLAN_MODE_TOOL_NAME} to present the plan for approval.
|
|
61
|
+
|
|
62
|
+
## Phase 2: Spawn Workers (After Plan Approval)
|
|
63
|
+
|
|
64
|
+
Once the plan is approved, spawn one background agent per work unit using the \${AGENT_TOOL_NAME} tool. **All agents must use \`isolation: "worktree"\` and \`run_in_background: true\`.** Launch them all in a single message block so they run in parallel.
|
|
65
|
+
|
|
66
|
+
For each agent, the prompt must be fully self-contained. Include:
|
|
67
|
+
- The overall goal (the user's instruction)
|
|
68
|
+
- This unit's specific task (title, file list, change description — copied verbatim from your plan)
|
|
69
|
+
- Any codebase conventions you discovered that the worker needs to follow
|
|
70
|
+
- The e2e test recipe from your plan (or "skip e2e because …")
|
|
71
|
+
- The worker instructions below, copied verbatim:
|
|
72
|
+
|
|
73
|
+
\`\`\`
|
|
74
|
+
After you finish implementing the change:
|
|
75
|
+
1. **Simplify** — Invoke the \${SKILL_TOOL_NAME} tool with \`skill: "simplify"\` to review and clean up your changes.
|
|
76
|
+
2. **Run unit tests** — Run the project's test suite (check for package.json scripts, Makefile targets, or common commands like \`npm test\`, \`bun test\`, \`pytest\`, \`go test\`). If tests fail, fix them.
|
|
77
|
+
3. **Test end-to-end** — Follow the e2e test recipe from the coordinator's prompt (below). If the recipe says to skip e2e for this unit, skip it.
|
|
78
|
+
4. **Commit and push** — Commit all changes with a clear message, push the branch, and create a PR with \`gh pr create\`. Use a descriptive title. If \`gh\` is not available or the push fails, note it in your final message.
|
|
79
|
+
5. **Report** — End with a single line: \`PR: <url>\` so the coordinator can track it. If no PR was created, end with \`PR: none — <reason>\`.
|
|
80
|
+
\`\`\`
|
|
81
|
+
|
|
82
|
+
Use \`subagent_type: "general-purpose"\` unless a more specific agent type fits.
|
|
83
|
+
|
|
84
|
+
## Phase 3: Track Progress
|
|
85
|
+
|
|
86
|
+
After launching all workers, render an initial status table:
|
|
87
|
+
|
|
88
|
+
| # | Unit | Status | PR |
|
|
89
|
+
|---|------|--------|----|
|
|
90
|
+
| 1 | <title> | running | — |
|
|
91
|
+
| 2 | <title> | running | — |
|
|
92
|
+
|
|
93
|
+
As background-agent completion notifications arrive, parse the \`PR: <url>\` line from each agent's result and re-render the table with updated status (\`done\` / \`failed\`) and PR links. Keep a brief failure note for any agent that did not produce a PR.
|
|
94
|
+
|
|
95
|
+
When all agents have reported, render the final table and a one-line summary (e.g., "22/24 units landed as PRs").
|
|
96
|
+
`;
|
|
97
|
+
//# sourceMappingURL=batch.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"batch.js","sourceRoot":"","sources":["../../src/bundled/batch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,MAAM,CAAC,MAAM,IAAI,GAAG,OAAO,CAAA;AAE3B,MAAM,CAAC,MAAM,QAAQ,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAkFvB,CAAA"}
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Ported Claude Code bundled `debug` skill.
|
|
3
|
+
*
|
|
4
|
+
* Source: `~/workspace/github.com/claude-code/skills/bundled/debug.ts`. The
|
|
5
|
+
* original resolves runtime values (the session debug-log path and its tail) at
|
|
6
|
+
* invocation; this port keeps the authored instruction body verbatim, leaving
|
|
7
|
+
* those runtime-injected fragments as literal placeholders for whichever
|
|
8
|
+
* consumer runs the skill.
|
|
9
|
+
*
|
|
10
|
+
* @module
|
|
11
|
+
*/
|
|
12
|
+
export declare const name = "debug";
|
|
13
|
+
export declare const SKILL_MD = "---\nname: debug\ndescription: Enable debug logging for this session and help diagnose issues\nallowed-tools: Read, Grep, Glob\nargument-hint: '[issue description]'\ndisable-model-invocation: true\nuser-invocable: true\n---\n\n# Debug Skill\n\nHelp the user debug an issue they're encountering in this current Claude Code session.\n\n## Session Debug Log\n\nThe debug log for the current session is at: `${debugLogPath}`.\n\nFor additional context, grep for [ERROR] and [WARN] lines across the full file.\n\n## Issue Description\n\n${issueDescription}\n\n## Settings\n\nRemember that settings are in:\n* user - ${userSettingsPath}\n* project - ${projectSettingsPath}\n* local - ${localSettingsPath}\n\n## Instructions\n\n1. Review the user's issue description\n2. Look for [ERROR] and [WARN] entries, stack traces, and failure patterns across the file\n3. Consider launching the `claude-code-guide` subagent to understand the relevant Claude Code features\n4. Explain what you found in plain language\n5. Suggest concrete fixes or next steps\n";
|
|
14
|
+
//# sourceMappingURL=debug.d.ts.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"debug.d.ts","sourceRoot":"","sources":["../../src/bundled/debug.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,eAAO,MAAM,IAAI,UAAU,CAAA;AAE3B,eAAO,MAAM,QAAQ,whCAqCpB,CAAA"}
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Ported Claude Code bundled `debug` skill.
|
|
3
|
+
*
|
|
4
|
+
* Source: `~/workspace/github.com/claude-code/skills/bundled/debug.ts`. The
|
|
5
|
+
* original resolves runtime values (the session debug-log path and its tail) at
|
|
6
|
+
* invocation; this port keeps the authored instruction body verbatim, leaving
|
|
7
|
+
* those runtime-injected fragments as literal placeholders for whichever
|
|
8
|
+
* consumer runs the skill.
|
|
9
|
+
*
|
|
10
|
+
* @module
|
|
11
|
+
*/
|
|
12
|
+
export const name = 'debug';
|
|
13
|
+
export const SKILL_MD = `---
|
|
14
|
+
name: debug
|
|
15
|
+
description: Enable debug logging for this session and help diagnose issues
|
|
16
|
+
allowed-tools: Read, Grep, Glob
|
|
17
|
+
argument-hint: '[issue description]'
|
|
18
|
+
disable-model-invocation: true
|
|
19
|
+
user-invocable: true
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
# Debug Skill
|
|
23
|
+
|
|
24
|
+
Help the user debug an issue they're encountering in this current Claude Code session.
|
|
25
|
+
|
|
26
|
+
## Session Debug Log
|
|
27
|
+
|
|
28
|
+
The debug log for the current session is at: \`\${debugLogPath}\`.
|
|
29
|
+
|
|
30
|
+
For additional context, grep for [ERROR] and [WARN] lines across the full file.
|
|
31
|
+
|
|
32
|
+
## Issue Description
|
|
33
|
+
|
|
34
|
+
\${issueDescription}
|
|
35
|
+
|
|
36
|
+
## Settings
|
|
37
|
+
|
|
38
|
+
Remember that settings are in:
|
|
39
|
+
* user - \${userSettingsPath}
|
|
40
|
+
* project - \${projectSettingsPath}
|
|
41
|
+
* local - \${localSettingsPath}
|
|
42
|
+
|
|
43
|
+
## Instructions
|
|
44
|
+
|
|
45
|
+
1. Review the user's issue description
|
|
46
|
+
2. Look for [ERROR] and [WARN] entries, stack traces, and failure patterns across the file
|
|
47
|
+
3. Consider launching the \`claude-code-guide\` subagent to understand the relevant Claude Code features
|
|
48
|
+
4. Explain what you found in plain language
|
|
49
|
+
5. Suggest concrete fixes or next steps
|
|
50
|
+
`;
|
|
51
|
+
//# sourceMappingURL=debug.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"debug.js","sourceRoot":"","sources":["../../src/bundled/debug.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,MAAM,CAAC,MAAM,IAAI,GAAG,OAAO,CAAA;AAE3B,MAAM,CAAC,MAAM,QAAQ,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqCvB,CAAA"}
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Bundled skills shipped with this compatible provider.
|
|
3
|
+
*
|
|
4
|
+
* A portable subset of Claude Code's own bundled skills (`~/workspace/github.com/claude-code/skills/bundled/`),
|
|
5
|
+
* authored as `SKILL.md` documents and served directly from this package — no
|
|
6
|
+
* disk extraction. They are provided with `source: 'bundled'` and the registry's
|
|
7
|
+
* `BUNDLED_SKILL_RANK`, so any project, user, managed, or additional skill of the
|
|
8
|
+
* same name wins the name conflict — matching Claude Code's precedence where
|
|
9
|
+
* local skills override built-ins.
|
|
10
|
+
*
|
|
11
|
+
* Only self-contained, harness-portable skills are included; ant-only skills
|
|
12
|
+
* (`verify`, `stuck`) and claude.ai/vendor-bound skills are excluded.
|
|
13
|
+
*
|
|
14
|
+
* @module
|
|
15
|
+
*/
|
|
16
|
+
import { type ParsedCcFrontmatter } from '../frontmatter.ts';
|
|
17
|
+
/** One parsed bundled skill with a stable locator for the provider. */
|
|
18
|
+
export interface BundledSkillFile {
|
|
19
|
+
/** Discriminator so the provider can tell bundled locators from `CcSkillFile`. */
|
|
20
|
+
readonly kind: 'bundled';
|
|
21
|
+
/** Kebab-case skill name, validated for the registry. */
|
|
22
|
+
readonly name: string;
|
|
23
|
+
/** Logical base directory string (in-package; not a real filesystem dir). */
|
|
24
|
+
readonly directory: string;
|
|
25
|
+
/** Human-readable source description for logs. */
|
|
26
|
+
readonly path: string;
|
|
27
|
+
/** Already-read Markdown body. */
|
|
28
|
+
readonly body: string;
|
|
29
|
+
/** Parsed frontmatter with a proven-valid registry name. */
|
|
30
|
+
readonly parsed: ParsedCcFrontmatter & {
|
|
31
|
+
name: string;
|
|
32
|
+
};
|
|
33
|
+
}
|
|
34
|
+
/** Parse the in-package bundled skill set once. Skills with missing or invalid names are skipped. */
|
|
35
|
+
export declare function discoverBundledSkills(): readonly BundledSkillFile[];
|
|
36
|
+
//# sourceMappingURL=index.d.ts.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/bundled/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AAGH,OAAO,EAGL,KAAK,mBAAmB,EACzB,MAAM,mBAAmB,CAAA;AAK1B,uEAAuE;AACvE,MAAM,WAAW,gBAAgB;IAC/B,kFAAkF;IAClF,QAAQ,CAAC,IAAI,EAAE,SAAS,CAAA;IACxB,yDAAyD;IACzD,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAA;IACrB,6EAA6E;IAC7E,QAAQ,CAAC,SAAS,EAAE,MAAM,CAAA;IAC1B,kDAAkD;IAClD,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAA;IACrB,kCAAkC;IAClC,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAA;IACrB,4DAA4D;IAC5D,QAAQ,CAAC,MAAM,EAAE,mBAAmB,GAAG;QAAE,IAAI,EAAE,MAAM,CAAA;KAAE,CAAA;CACxD;AAQD,qGAAqG;AACrG,wBAAgB,qBAAqB,IAAI,SAAS,gBAAgB,EAAE,CAiBnE"}
|