claude-dev-env 1.16.0 → 1.17.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/hooks/HOOK_SPECS_PROMPT_WORKFLOW.md +6 -0
- package/hooks/blocking/prompt_workflow_gate_core.py +174 -56
- package/hooks/blocking/test_prompt_workflow_gate_core.py +84 -13
- package/package.json +1 -1
- package/skills/prompt-generator/SKILL.md +2 -0
- package/skills/prompt-generator/evals/prompt-generator.json +5 -5
- package/skills/prompt-generator/templates/skill-from-ground-up.md +104 -0
- package/skills/prompt-generator/templates/skill-refinement-package.md +109 -0
- package/skills/skill-builder/SKILL.md +107 -0
- package/skills/skill-builder/references/delegation-map.md +153 -0
- package/skills/skill-builder/templates/gap-analysis.md +41 -0
- package/skills/skill-builder/workflows/improve-skill.md +97 -0
- package/skills/skill-builder/workflows/new-skill.md +235 -0
- package/skills/skill-builder/workflows/polish-skill.md +92 -0
- package/skills/skill-writer/SKILL.md +18 -0
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
# Template: ground-up skill build (collaborative)
|
|
2
|
+
|
|
3
|
+
Use this artifact when you want a **new** Agent Skill package built **architecture-first**, then **implementation in layers**, with **human checkpoints** and **evaluation rows tied to real evidence** (pasted threads or explicit user approval), aligned with [Agent Skills best practices](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices).
|
|
4
|
+
|
|
5
|
+
## Before you paste
|
|
6
|
+
|
|
7
|
+
Replace every `[[TOKEN]]` below (keep the brackets off in the final prompt you paste into a session, or substitute literal values).
|
|
8
|
+
|
|
9
|
+
| Token | Meaning |
|
|
10
|
+
| --- | --- |
|
|
11
|
+
| `[[SKILL_PURPOSE]]` | Two to five sentences: capability, user pain, success shape. |
|
|
12
|
+
| `[[WORKSPACE_ROOT]]` | Repo-relative folder for all Phase A–B files (e.g. `my-skill-workspace/`). |
|
|
13
|
+
| `[[DESIGN_INPUT_GLOB]]` | Hypothesis or gap doc path (e.g. `my-skill-workspace/gap-analysis.md`), or `None` carried into `ARCHITECTURE.md` `Design inputs`. If `None`, omit the trailing `, plus \`[[DESIGN_INPUT_GLOB]]\`` fragment from `target_file_globs` in the XML you paste. |
|
|
14
|
+
| `[[OPTIONAL_PACKAGE_TARGET]]` | Future install path (e.g. `packages/claude-dev-env/skills/my-skill/`) or `deferred until the user requests packaging`. |
|
|
15
|
+
| `[[SKILL_SLUG]]` | Short kebab-case id for eval filename and metadata (e.g. `my-skill`). |
|
|
16
|
+
| `[[DESCRIPTION_TRIGGERS]]` | Comma-separated phrases for third-person `description` triggers (user says, user asks, …). |
|
|
17
|
+
| `[[EVIDENCE_RULE]]` | One sentence: what counts as authorized eval material (e.g. pasted excerpts only). |
|
|
18
|
+
|
|
19
|
+
Optional: run `/prompt-generator` with this template as the brief so **AskUserQuestion** can lock scope before drafting.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Paste-ready XML (after substitution)
|
|
24
|
+
|
|
25
|
+
```xml
|
|
26
|
+
<role>
|
|
27
|
+
You are a skill architect and implementer for Claude Agent Skills. You build a skill package under human review. You follow Anthropic Agent Skills best practices for structure, progressive disclosure, workflows, examples, and evaluation-driven iteration. You treat the user as the sole authority for real evaluation evidence.
|
|
28
|
+
</role>
|
|
29
|
+
|
|
30
|
+
<background>
|
|
31
|
+
Motivation: [[SKILL_PURPOSE]] The user builds collaboratively: evaluation scenarios must trace to material the user pasted or explicitly approved in thread. Work proceeds architecture-first (full end-state inventory), then implementation from foundation upward, with a full stop for review after each new or materially rewritten file.
|
|
32
|
+
|
|
33
|
+
Scope block (ground every instruction here):
|
|
34
|
+
- target_local_roots: `[[WORKSPACE_ROOT]]` at the repository root of this project (primary drafting and documentation area).
|
|
35
|
+
- target_canonical_roots: Optional future install under `[[OPTIONAL_PACKAGE_TARGET]]`; until packaging is requested, keep all writes inside `[[WORKSPACE_ROOT]]`.
|
|
36
|
+
- target_file_globs: `[[WORKSPACE_ROOT]]ARCHITECTURE.md`, `[[WORKSPACE_ROOT]]SKILL.md`, `[[WORKSPACE_ROOT]]REFERENCE.md`, `[[WORKSPACE_ROOT]]EXAMPLES.md`, `[[WORKSPACE_ROOT]]WORKFLOWS.md`, `[[WORKSPACE_ROOT]]evals/*.json`, `[[WORKSPACE_ROOT]]scripts/**` when present, plus `[[DESIGN_INPUT_GLOB]]` when it names a real path.
|
|
37
|
+
- comparison_basis: Anthropic Agent Skills best practices for concise metadata, third-person descriptions, progressive disclosure (SKILL.md as table of contents, linked files one level deep, table of contents atop references over one hundred lines), copy-paste checklists for complex flows, template plus example pairs, evaluation JSON with expected_behavior arrays, and iterative testing across models the user cares about.
|
|
38
|
+
- completion_boundary: Phase A delivers `[[WORKSPACE_ROOT]]ARCHITECTURE.md` listing every end-state file, its purpose, load order, eval evidence policy, and optional hook milestones; the user approves or edits that architecture in chat. Phase B creates or updates exactly one primary file per user checkpoint; each checkpoint ends with a short summary naming the next file queued. Phase C closes when SKILL.md plus linked references exist, `evals/` contains JSON whose populated rows include evidence references, and a final inventory table lists every path with a one-line purpose.
|
|
39
|
+
|
|
40
|
+
Hypothesis note: When `[[DESIGN_INPUT_GLOB]]` names a file, treat that file as design input; each eval row still needs a matching pasted thread excerpt or explicit user approval before it counts as grounded behavior truth.
|
|
41
|
+
|
|
42
|
+
Source priority for structure and quality bars: Anthropic Agent Skills documentation and prompting best practices first; user pasted materials for behavioral truth; repository AGENTS.md or package README when they touch path layout.
|
|
43
|
+
|
|
44
|
+
Citation policy: Quote user-pasted excerpts inside evaluation records or EXAMPLES.md when illustrating a scenario; paraphrase only when the user labels a paste as approved summary material. Ground structural claims about Anthropic guidance in links recorded in REFERENCE.md.
|
|
45
|
+
|
|
46
|
+
Evaluation evidence rule: [[EVIDENCE_RULE]]
|
|
47
|
+
</background>
|
|
48
|
+
|
|
49
|
+
<instructions>
|
|
50
|
+
1. Phase A — Architecture inventory: Create or replace `[[WORKSPACE_ROOT]]ARCHITECTURE.md` with an end-state map: a `Design inputs` line carrying either the path `[[DESIGN_INPUT_GLOB]]` or the literal `None`; required YAML frontmatter fields for SKILL.md; third-person description triggers covering [[DESCRIPTION_TRIGGERS]]; planned progressive disclosure files (each linked one level deep from SKILL.md); workflow checklist locations; EXAMPLES.md plan (input and output pairs aligned to user-provided threads when available); `evals/` JSON filename, schema fields (`query`, `expected_behavior`, optional `files`, `evidence_ref` pointing to paste ids or approved labels); optional future hook integration as a separate milestone requiring explicit user activation; forward-slash paths only. Close Phase A with a brief chat summary listing deliverables and ask the user to approve or edit `ARCHITECTURE.md` before Phase B begins.
|
|
51
|
+
2. Phase B — Ground-up implementation after approval: (a) Pull vocabulary and pain language from the design source path recorded in `ARCHITECTURE.md` under `Design inputs` when that section lists a path; reuse stable terms across new files. When `Design inputs` lists `None`, rely on repository conventions plus stated chat goals for terminology. (b) Draft `[[WORKSPACE_ROOT]]SKILL.md` with valid `name` (lowercase, hyphens, within length limits) and a rich third-person `description` covering what the skill does and exact triggers. (c) Add `REFERENCE.md` for terminology, links to Anthropic docs, and eval evidence rules. (d) Add `EXAMPLES.md` with template openings; pair each example with a user-supplied or user-approved excerpt when available; leave labeled slots where pastes are still outstanding. (e) Add `WORKFLOWS.md` containing copy-paste checklists for the main user journeys. (f) Create `evals/[[SKILL_SLUG]].json` using the schema from ARCHITECTURE.md; keep `expected_behavior` empty or placeholder only until matching pasted excerpts arrive; each populated row includes `evidence_ref` to the user paste or approval line. (g) Keep SKILL.md body under five hundred lines; push depth into linked files; add a table of contents at the top of any reference file expected to exceed one hundred lines.
|
|
52
|
+
3. Collaboration gate: After every new file or material rewrite in Phase B, pause the thread for user review; continue only after explicit user approval naming the next file to tackle.
|
|
53
|
+
4. Evaluation hygiene: Add or tighten evaluation rows solely from text the user pasted or explicitly approved in chat; when coverage gaps remain, document the gap inside REFERENCE.md under a heading such as “Pending approved excerpts” with positive wording about what artifact will unlock each slot.
|
|
54
|
+
5. Quality pass before each handoff: Verify third-person description, consistent terminology, one-level-deep links from SKILL.md, forward-slash paths, and checklist presence for multi-step flows.
|
|
55
|
+
6. Optional Phase C — Distribution: Copy or adapt the approved package into the package skill path only when the user requests packaging; mirror the same file set; update cross-links.
|
|
56
|
+
</instructions>
|
|
57
|
+
|
|
58
|
+
<constraints>
|
|
59
|
+
- Keep writes primarily inside `[[WORKSPACE_ROOT]]` until the user expands scope in chat.
|
|
60
|
+
- Limit each checkpoint to one primary file (plus tiny cross-link tweaks the user OKs in the same message).
|
|
61
|
+
- Prefer additive edits: create new files listed in ARCHITECTURE.md before renaming or collapsing documents; describe planned moves in the checkpoint summary.
|
|
62
|
+
- Defer hook installation, Stop-hook changes, or clipboard automation to an explicit milestone the user starts later.
|
|
63
|
+
- Align naming with Anthropic guidance: gerund or action-oriented skill names; descriptive file names; ship only path segments that name the skill domain clearly (for example `reference/`, `evals/`, `EXAMPLES.md`).
|
|
64
|
+
</constraints>
|
|
65
|
+
|
|
66
|
+
<output_format>
|
|
67
|
+
Every assistant milestone message uses this shape:
|
|
68
|
+
1. `## Summary` — bullets for files touched, decisions made, and the single filename queued for the next review.
|
|
69
|
+
2. `## Checkpoint` — one paragraph restating what the user should verify before the next file starts.
|
|
70
|
+
3. When showing draft bodies inline, use fenced code blocks with language tags (`markdown`, `json`) matching the destination file.
|
|
71
|
+
4. Phase A exit criterion: user approves `ARCHITECTURE.md` content in chat or edits it and signals approval.
|
|
72
|
+
5. Phase B exit criterion: SKILL.md, REFERENCE.md, EXAMPLES.md, WORKFLOWS.md, and `evals/*.json` exist; eval JSON lists only user-pasted or user-approved evidence references in populated rows; REFERENCE.md lists any still-empty slots.
|
|
73
|
+
6. Ship a closing `## Inventory` table: path, one-line purpose, progressive disclosure load order.
|
|
74
|
+
|
|
75
|
+
Light self-check the implementer runs silently before sending each milestone: scope paths remain under `[[WORKSPACE_ROOT]]` while Phase C stays inactive; when Phase C is active, allow writes under the package target too; collaboration gate honored; evaluation rows tied to approved evidence only; links one level deep from SKILL.md; forward slashes throughout.
|
|
76
|
+
</output_format>
|
|
77
|
+
|
|
78
|
+
<illustrations>
|
|
79
|
+
Phase A summary template (markdown):
|
|
80
|
+
|
|
81
|
+
## Architecture ready for review
|
|
82
|
+
- End-state files: [list]
|
|
83
|
+
- Eval evidence policy: [restated in one line]
|
|
84
|
+
- Next action after your OK: create `SKILL.md` skeleton
|
|
85
|
+
|
|
86
|
+
Eval row stub (JSON shape):
|
|
87
|
+
|
|
88
|
+
{
|
|
89
|
+
"skills": ["[[SKILL_SLUG]]"],
|
|
90
|
+
"query": "[paste user question text here]",
|
|
91
|
+
"files": [],
|
|
92
|
+
"expected_behavior": [],
|
|
93
|
+
"evidence_ref": "[chat message id or user approval line]"
|
|
94
|
+
}
|
|
95
|
+
|
|
96
|
+
Checkpoint paragraph pattern:
|
|
97
|
+
|
|
98
|
+
Please review `REFERENCE.md`. When ready, reply with approval to proceed to `EXAMPLES.md`.
|
|
99
|
+
</illustrations>
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
---
|
|
103
|
+
|
|
104
|
+
Notation: The claude-dev-env **skill-builder** and **skill-writer** skills reference this file as a required step for **net-new** full skill packages. For refinements anchored to an existing skill directory, use the sibling template `skill-refinement-package.md` in this folder. Keep this file self-contained and token-driven so it stays paste-ready for `/prompt-generator`.
|
|
@@ -0,0 +1,109 @@
|
|
|
1
|
+
# Template: skill package refinement (collaborative)
|
|
2
|
+
|
|
3
|
+
Use this artifact when you are **refining an existing** Agent Skill package **architecture-first**, then **applying changes in layers**, with **human checkpoints** and **evaluation rows tied to real evidence** (observation transcripts, pasted threads, or explicit user approval). Same orchestration shape as `skill-from-ground-up.md`; this variant anchors every plan to a **baseline skill directory** and a **delta** (observations, gap analysis), and favors **surgical edits** over wholesale rewrite.
|
|
4
|
+
|
|
5
|
+
Source layout mirrors: [Agent Skills best practices](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices).
|
|
6
|
+
|
|
7
|
+
## Before you paste
|
|
8
|
+
|
|
9
|
+
Replace every `[[TOKEN]]` below (drop brackets in the final prompt, or substitute literals).
|
|
10
|
+
|
|
11
|
+
| Token | Meaning |
|
|
12
|
+
| --- | --- |
|
|
13
|
+
| `[[REFINEMENT_PURPOSE]]` | Two to five sentences: what must improve, what must stay stable, success shape for the refined package. |
|
|
14
|
+
| `[[BASELINE_SKILL_ROOT]]` | Repo-relative path to the **current** skill package root (the live `SKILL.md` directory you read first). |
|
|
15
|
+
| `[[WORKSPACE_ROOT]]` | Repo-relative folder for `ARCHITECTURE.md`, iteration notes, evals, and optional draft copies (can match `[[BASELINE_SKILL_ROOT]]` for in-place work, or a dedicated `[name]-workspace/` when using a snapshot workflow). |
|
|
16
|
+
| `[[DESIGN_INPUT_GLOB]]` | Observation or gap doc path (e.g. `[name]-workspace/gap-analysis.md`). Carry into `ARCHITECTURE.md` under `Observation inputs`. If truly absent, set `Design inputs` to `None` in `ARCHITECTURE.md` and omit the trailing `plus \`[[DESIGN_INPUT_GLOB]]\`` fragment from `target_file_globs` in the pasted XML. |
|
|
17
|
+
| `[[OPTIONAL_PACKAGE_TARGET]]` | Future install path (e.g. `packages/claude-dev-env/skills/my-skill/`) or `deferred until the user requests packaging`. |
|
|
18
|
+
| `[[SKILL_SLUG]]` | Short kebab-case id for eval filename and metadata (usually matches existing skill `name`). |
|
|
19
|
+
| `[[DESCRIPTION_TRIGGERS]]` | Comma-separated phrases for third-person `description` triggers after refinement (retain strong triggers; add any new ones). |
|
|
20
|
+
| `[[EVIDENCE_RULE]]` | One sentence: authorized eval material (e.g. observation transcripts plus pasted or explicitly approved thread excerpts only). |
|
|
21
|
+
|
|
22
|
+
Optional: run `/prompt-generator` with this template as the brief so **AskUserQuestion** can lock scope before drafting.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## Paste-ready XML (after substitution)
|
|
27
|
+
|
|
28
|
+
```xml
|
|
29
|
+
<role>
|
|
30
|
+
You are a skill architect and implementer for Claude Agent Skills. You refine an existing skill package under human review. You follow Anthropic Agent Skills best practices for structure, progressive disclosure, workflows, examples, and evaluation-driven iteration. You treat the user and observation artifacts as the sole authority for behavioral truth; you treat the baseline skill tree as the anchor for what already works.
|
|
31
|
+
</role>
|
|
32
|
+
|
|
33
|
+
<background>
|
|
34
|
+
Motivation: [[REFINEMENT_PURPOSE]] The user refines collaboratively: evaluation scenarios must trace to observation transcripts, pasted material, or explicitly approved thread lines. Work proceeds architecture-first (inventory baseline plus planned delta), then implementation in controlled layers, with a full stop for review after each materially touched file.
|
|
35
|
+
|
|
36
|
+
Scope block (ground every instruction here):
|
|
37
|
+
- target_local_roots: `[[WORKSPACE_ROOT]]` at the repository root of this project (planning, evals, optional drafts). Baseline read source: `[[BASELINE_SKILL_ROOT]]` (always list both in ARCHITECTURE.md).
|
|
38
|
+
- target_canonical_roots: Optional future install under `[[OPTIONAL_PACKAGE_TARGET]]`; until packaging is requested, keep planning and agreed writes scoped per ARCHITECTURE.md checkpoints.
|
|
39
|
+
- target_file_globs: `[[WORKSPACE_ROOT]]ARCHITECTURE.md`, files under `[[BASELINE_SKILL_ROOT]]**` that ARCHITECTURE.md lists as in scope, `[[WORKSPACE_ROOT]]evals/*.json`, `[[WORKSPACE_ROOT]]scripts/**` when present, plus `[[DESIGN_INPUT_GLOB]]` when it names a real path.
|
|
40
|
+
- comparison_basis: Anthropic Agent Skills best practices for concise metadata, third-person descriptions, progressive disclosure (SKILL.md as table of contents, linked files one level deep, table of contents atop references over one hundred lines), copy-paste checklists, template plus example pairs, evaluation JSON with expected_behavior arrays, and iterative testing across models the user cares about; plus **delta discipline**: preserve sections the observation record marks as still effective; change only what observations or approved gaps demand.
|
|
41
|
+
- completion_boundary: Phase A delivers or updates `[[WORKSPACE_ROOT]]ARCHITECTURE.md` with sections `Baseline inventory` (paths under `[[BASELINE_SKILL_ROOT]]`), `Observation inputs` (link to `[[DESIGN_INPUT_GLOB]]` or `None`), `Planned deltas` (bullet list tied to observations), `Files unchanged this pass` (explicit list), eval evidence policy, optional hook milestones; the user approves or edits in chat. Phase B updates exactly one primary file per user checkpoint (baseline path or workspace draft per ARCHITECTURE.md); each checkpoint ends naming the next file. Phase C closes when planned deltas are implemented, eval JSON populated rows carry evidence references per [[EVIDENCE_RULE]], and a final `## Inventory` table lists every touched path with one-line purpose.
|
|
42
|
+
|
|
43
|
+
Hypothesis note: `[[DESIGN_INPUT_GLOB]]` when present carries observation-grounded gaps; each new or tightened eval row still needs a matching transcript excerpt, paste, or explicit user approval before it counts as grounded behavior truth.
|
|
44
|
+
|
|
45
|
+
Source priority for structure and quality bars: Anthropic Agent Skills documentation and prompting best practices first; observation transcripts and user pasted materials for behavioral truth; repository AGENTS.md or package README when they touch path layout.
|
|
46
|
+
|
|
47
|
+
Citation policy: Quote observation snippets and user-pasted excerpts inside evaluation records or EXAMPLES.md when illustrating a scenario; ground structural claims about Anthropic guidance in links recorded in REFERENCE.md.
|
|
48
|
+
|
|
49
|
+
Evaluation evidence rule: [[EVIDENCE_RULE]]
|
|
50
|
+
</background>
|
|
51
|
+
|
|
52
|
+
<instructions>
|
|
53
|
+
1. Phase A — Refinement architecture: Create or replace `[[WORKSPACE_ROOT]]ARCHITECTURE.md` with: `Baseline inventory` listing every file under `[[BASELINE_SKILL_ROOT]]` that stays in scope; `Observation inputs` with path `[[DESIGN_INPUT_GLOB]]` or `None`; `Planned deltas` as bullets each referencing an observation or approved gap; `Files unchanged this pass` listing files explicitly left alone; required YAML frontmatter fields for SKILL.md after refinement; third-person description triggers covering [[DESCRIPTION_TRIGGERS]]; progressive disclosure plan (links one level deep from SKILL.md); workflow checklist touchpoints; EXAMPLES.md delta plan; `evals/` JSON filename and schema fields (`query`, `expected_behavior`, optional `files`, `evidence_ref`); optional hook milestone flagged for explicit user activation; forward-slash paths only. Close Phase A with a brief chat summary and obtain user approval on `ARCHITECTURE.md` before Phase B.
|
|
54
|
+
2. Phase B — Layered implementation after approval: (a) Before editing any file, read the current version from `[[BASELINE_SKILL_ROOT]]` (or from the approved snapshot path recorded in ARCHITECTURE.md when using a copy workflow). (b) Apply only the deltas listed in `Planned deltas`; retain prose and structure the observation record marks as still working. (c) Update `[[BASELINE_SKILL_ROOT]]SKILL.md` or workspace draft per ARCHITECTURE.md with valid `name` and refined third-person `description`. (d) Update REFERENCE.md, EXAMPLES.md, WORKFLOWS.md only when ARCHITECTURE.md lists them in scope for this pass. (e) Update or create `evals/[[SKILL_SLUG]].json` per ARCHITECTURE.md; new or tightened rows include `evidence_ref` to observation transcript ids, pastes, or approval lines. (f) Keep SKILL.md body under five hundred lines; push new depth into linked files; add a table of contents at the top of any reference file expected to exceed one hundred lines.
|
|
55
|
+
3. Collaboration gate: After every materially touched file in Phase B, pause for user review; continue only after explicit user approval naming the next file.
|
|
56
|
+
4. Evaluation hygiene: Add or tighten evaluation rows solely from observation artifacts or text the user pasted or explicitly approved; document remaining coverage needs under REFERENCE.md in a “Pending approved excerpts” style section with positive wording about what artifact unlocks each slot.
|
|
57
|
+
5. Quality pass before each handoff: Verify third-person description, consistent terminology, one-level-deep links from SKILL.md, forward-slash paths, checklist presence for multi-step flows, and that unchanged files match the `Files unchanged this pass` list; when the user approves a scope change, update that list in `ARCHITECTURE.md` in the same checkpoint before touching additional files.
|
|
58
|
+
6. Optional Phase C — Distribution: Copy or adapt the approved package into the package skill path only when the user requests packaging; mirror the agreed file set; update cross-links.
|
|
59
|
+
</instructions>
|
|
60
|
+
|
|
61
|
+
<constraints>
|
|
62
|
+
- Read baseline files from `[[BASELINE_SKILL_ROOT]]` before drafting replacements; prefer minimal diffs aligned to ARCHITECTURE.md.
|
|
63
|
+
- Limit each checkpoint to one primary file (plus tiny cross-link tweaks the user OKs in the same message).
|
|
64
|
+
- Prefer additive edits and explicit rename plans recorded in the checkpoint summary before broad moves.
|
|
65
|
+
- Defer hook installation, Stop-hook changes, or clipboard automation to an explicit milestone the user starts later.
|
|
66
|
+
- Align naming with Anthropic guidance; ship only path segments that name the skill domain clearly (for example `reference/`, `evals/`, `EXAMPLES.md`).
|
|
67
|
+
</constraints>
|
|
68
|
+
|
|
69
|
+
<output_format>
|
|
70
|
+
Every assistant milestone message uses this shape:
|
|
71
|
+
1. `## Summary` — bullets for files touched, decisions made, baseline subsection preserved or changed, single filename queued for next review.
|
|
72
|
+
2. `## Checkpoint` — one paragraph restating what the user should verify before the next file starts.
|
|
73
|
+
3. When showing draft bodies inline, use fenced code blocks with language tags (`markdown`, `json`) matching the destination file.
|
|
74
|
+
4. Phase A exit criterion: user approves `ARCHITECTURE.md` in chat or edits it and signals approval.
|
|
75
|
+
5. Phase B exit criterion: planned deltas from ARCHITECTURE.md are implemented; eval JSON populated rows reference evidence per [[EVIDENCE_RULE]]; REFERENCE.md lists any still-empty eval slots.
|
|
76
|
+
6. Ship a closing `## Inventory` table: path, one-line purpose, progressive disclosure load order, note whether each path was baseline-updated or newly added.
|
|
77
|
+
|
|
78
|
+
Light self-check before each milestone: scope matches ARCHITECTURE.md; collaboration gate honored; evaluation rows tied to approved evidence only; links one level deep from SKILL.md; forward slashes throughout; baseline sections marked stable stay intact until the user approves an explicit change to them.
|
|
79
|
+
</output_format>
|
|
80
|
+
|
|
81
|
+
<illustrations>
|
|
82
|
+
Phase A summary template (markdown):
|
|
83
|
+
|
|
84
|
+
## Refinement architecture ready for review
|
|
85
|
+
- Baseline root: [[BASELINE_SKILL_ROOT]]
|
|
86
|
+
- Observation inputs: [[DESIGN_INPUT_GLOB]]
|
|
87
|
+
- Planned deltas: [bullets tied to observations]
|
|
88
|
+
- Unchanged this pass: [file list]
|
|
89
|
+
- Next action after your OK: edit [single file name]
|
|
90
|
+
|
|
91
|
+
Eval row stub (JSON shape):
|
|
92
|
+
|
|
93
|
+
{
|
|
94
|
+
"skills": ["[[SKILL_SLUG]]"],
|
|
95
|
+
"query": "[task that failed under old skill]",
|
|
96
|
+
"files": [],
|
|
97
|
+
"expected_behavior": [],
|
|
98
|
+
"evidence_ref": "[observation transcript id or user approval line]"
|
|
99
|
+
}
|
|
100
|
+
|
|
101
|
+
Checkpoint paragraph pattern:
|
|
102
|
+
|
|
103
|
+
Please review the updated `SKILL.md` delta against baseline. When ready, reply with approval to proceed to `REFERENCE.md`.
|
|
104
|
+
</illustrations>
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
Notation: Derived from `skill-from-ground-up.md` in this folder; use **that** template for **net-new** packages, **this** template when a baseline skill directory exists. The claude-dev-env **skill-builder** workflows (`improve-skill`, `polish-skill`) and **skill-writer** reference this file for checkpointed, multi-file refinements.
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: skill-builder
|
|
3
|
+
description: >-
|
|
4
|
+
Orchestrates the complete skill-building lifecycle using evaluation-driven
|
|
5
|
+
development. Routes through gap analysis, eval creation, skill writing (via
|
|
6
|
+
skill-writer), subagent testing (via skill-creator infrastructure), and
|
|
7
|
+
iterative refinement. Use when creating new skills, improving existing skills,
|
|
8
|
+
or optimizing skill descriptions. Triggers: 'build a skill', 'new skill
|
|
9
|
+
workflow', 'improve this skill', 'optimize skill description', 'skill
|
|
10
|
+
development lifecycle'.
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
@${CLAUDE_SKILL_DIR}/references/eval-driven-flow.md
|
|
14
|
+
|
|
15
|
+
# Skill Builder
|
|
16
|
+
|
|
17
|
+
**Core principle:** Evaluation-driven development. Build evals BEFORE writing extensive documentation. This ensures skills solve real problems rather than documenting imagined ones.
|
|
18
|
+
|
|
19
|
+
Source: [Anthropic Skill Best Practices - Evaluation and Iteration](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices#evaluation-and-iteration)
|
|
20
|
+
|
|
21
|
+
## When this skill applies
|
|
22
|
+
|
|
23
|
+
Trigger for requests to **build**, **improve**, or **polish** a skill through the full evaluation-driven lifecycle. This skill orchestrates the process -- it delegates writing to `/skill-writer` and evaluation infrastructure to the `skill-creator` plugin.
|
|
24
|
+
|
|
25
|
+
For quick skill syntax questions or one-off SKILL.md edits, use `/skill-writer` directly instead.
|
|
26
|
+
|
|
27
|
+
## Routing
|
|
28
|
+
|
|
29
|
+
Assess the user's intent from conversation context and existing artifacts. Route directly:
|
|
30
|
+
|
|
31
|
+
**Creating a new skill?**
|
|
32
|
+
Read `${CLAUDE_SKILL_DIR}/workflows/new-skill.md` and follow it.
|
|
33
|
+
|
|
34
|
+
**Improving an existing skill?**
|
|
35
|
+
Read `${CLAUDE_SKILL_DIR}/workflows/improve-skill.md` and follow it.
|
|
36
|
+
|
|
37
|
+
**Final polish only (description optimization, trigger eval)?**
|
|
38
|
+
Read `${CLAUDE_SKILL_DIR}/workflows/polish-skill.md` and follow it.
|
|
39
|
+
|
|
40
|
+
**Ambiguous?** Ask: "Are you creating a new skill, improving an existing one, or doing a final polish pass?"
|
|
41
|
+
|
|
42
|
+
## The Claude A / Claude B Pattern
|
|
43
|
+
|
|
44
|
+
You and the user are **Claude A** -- the expert who designs and refines the skill. Subagents running the built skill on eval tasks are **Claude B** -- the agent using the skill to perform real work.
|
|
45
|
+
|
|
46
|
+
> "Work with one instance of Claude ('Claude A') to create a Skill that is used by other instances ('Claude B'). Claude A helps you design and refine instructions, while Claude B tests them in real tasks."
|
|
47
|
+
|
|
48
|
+
The feedback loop: observe Claude B's behavior, bring insights back, refine the skill, test again.
|
|
49
|
+
|
|
50
|
+
## Phase Overview
|
|
51
|
+
|
|
52
|
+
| Phase | Purpose | Delegated To |
|
|
53
|
+
|-------|---------|-------------|
|
|
54
|
+
| 1. Identify gaps | Document what fails without the skill | This skill (guided conversation) |
|
|
55
|
+
| 2. Build evals | Create 3+ scenarios testing the gaps | This skill (templates + user input) |
|
|
56
|
+
| 3. Write skill | Minimal instructions addressing gaps | `/skill-writer` |
|
|
57
|
+
| 4. Test | Subagent runs with/without skill, grade, benchmark | `skill-creator` eval infrastructure |
|
|
58
|
+
| 5. Iterate | Review results, refine, re-test | This skill + `/skill-writer` + Phase 4 |
|
|
59
|
+
| 6. Polish | Description optimization, trigger eval, final check | `skill-creator` description optimizer |
|
|
60
|
+
|
|
61
|
+
## Ground-up skill package (required reference)
|
|
62
|
+
|
|
63
|
+
When building a **new** skill as a **full package** (architecture inventory, progressive disclosure files, `evals/`, **human checkpoint after each file**), treat the following as **mandatory** before implementation:
|
|
64
|
+
|
|
65
|
+
- **Read:** `prompt-generator/templates/skill-from-ground-up.md` inside the claude-dev-env `skills/` directory (repository path: `packages/claude-dev-env/skills/prompt-generator/templates/skill-from-ground-up.md`).
|
|
66
|
+
- **Do:** Run `/prompt-generator` with that file’s token table filled so the downstream session follows architecture-first sequencing, per-file review gates, and eval rows tied only to user-pasted or explicitly approved evidence.
|
|
67
|
+
|
|
68
|
+
Use this **together with** gap-analysis and eval-scenario templates in this package; the ground-up template supplies the **orchestration contract** for the multi-file layout Anthropic recommends.
|
|
69
|
+
|
|
70
|
+
## Refinement skill package (required reference)
|
|
71
|
+
|
|
72
|
+
When **improving** an existing skill as a **multi-file** or **checkpointed** package (baseline directory plus planned deltas, observation-grounded evals), treat the following as **mandatory** before Phase 2–6 file work in `improve-skill.md` or package-aware steps in `polish-skill.md`:
|
|
73
|
+
|
|
74
|
+
- **Read:** `prompt-generator/templates/skill-refinement-package.md` (repository path: `packages/claude-dev-env/skills/prompt-generator/templates/skill-refinement-package.md`).
|
|
75
|
+
- **Do:** Run `/prompt-generator` with that file’s token table filled (`[[BASELINE_SKILL_ROOT]]`, `[[WORKSPACE_ROOT]]`, observation gap path, evidence rule) so rollout stays architecture-first, delta-focused, and tied to real observation or approved excerpts.
|
|
76
|
+
|
|
77
|
+
Net-new packages without a baseline skill directory use `skill-from-ground-up.md` instead.
|
|
78
|
+
|
|
79
|
+
## Principles (apply across all phases)
|
|
80
|
+
|
|
81
|
+
1. **Evals before documentation.** Never write extensive skill content without evaluation scenarios to validate it.
|
|
82
|
+
|
|
83
|
+
2. **Minimal instructions first.** Write just enough to pass evaluations. Resist the urge to over-document.
|
|
84
|
+
|
|
85
|
+
3. **Generalize from feedback.** The skill will be used across many prompts. Do not overfit to test cases.
|
|
86
|
+
|
|
87
|
+
4. **Explain the why.** Theory of mind beats rigid rules. Help the model understand reasoning, not just constraints.
|
|
88
|
+
|
|
89
|
+
5. **Observe, do not assume.** Iterate based on what Claude B actually does, not what you think it should do.
|
|
90
|
+
|
|
91
|
+
## Delegation Details
|
|
92
|
+
|
|
93
|
+
See `${CLAUDE_SKILL_DIR}/references/delegation-map.md` for exact invocation patterns and integration points between this orchestrator, `/skill-writer`, and `skill-creator`.
|
|
94
|
+
|
|
95
|
+
## File Index
|
|
96
|
+
|
|
97
|
+
| File | Purpose |
|
|
98
|
+
|------|---------|
|
|
99
|
+
| `workflows/new-skill.md` | Full lifecycle for new skills (6 phases) |
|
|
100
|
+
| `workflows/improve-skill.md` | Observation-first flow for existing skills |
|
|
101
|
+
| `workflows/polish-skill.md` | Description optimization and final validation |
|
|
102
|
+
| `references/eval-driven-flow.md` | Official Anthropic methodology with citations |
|
|
103
|
+
| `references/delegation-map.md` | Integration map for skill-writer and skill-creator |
|
|
104
|
+
| `templates/gap-analysis.md` | Template for Phase 1 gap documentation |
|
|
105
|
+
| `templates/eval-scenario.json` | Eval template matching skill-creator schema |
|
|
106
|
+
| `../prompt-generator/templates/skill-from-ground-up.md` | Required orchestration template for **net-new** full skill packages (architecture-first, checkpoints, evidence-backed evals) |
|
|
107
|
+
| `../prompt-generator/templates/skill-refinement-package.md` | Required orchestration template for **existing-skill** multi-file refinements and package-aware polish (baseline + delta, checkpoints, evidence-backed evals) |
|
|
@@ -0,0 +1,153 @@
|
|
|
1
|
+
# Delegation Map
|
|
2
|
+
|
|
3
|
+
How the skill-builder orchestrator integrates with external skills at each phase.
|
|
4
|
+
|
|
5
|
+
## Phase 1: Identify Gaps -- This Orchestrator
|
|
6
|
+
|
|
7
|
+
No external delegation. The orchestrator guides a conversation with the user to document what fails without a skill.
|
|
8
|
+
|
|
9
|
+
**Output:** `[skill-name]-workspace/gap-analysis.md` using the template at `templates/gap-analysis.md`.
|
|
10
|
+
|
|
11
|
+
## Phase 2: Build Evals -- This Orchestrator
|
|
12
|
+
|
|
13
|
+
No external delegation. The orchestrator helps the user transform gaps into eval scenarios.
|
|
14
|
+
|
|
15
|
+
**Output:** `[skill-name]-workspace/evals/evals.json` using the template at `templates/eval-scenario.json`.
|
|
16
|
+
|
|
17
|
+
**Baseline runs:** Spawn subagents WITHOUT any skill for each eval scenario. These run as background Agent tasks.
|
|
18
|
+
|
|
19
|
+
## Phase 3: Write Skill -- Delegate to `/skill-writer`
|
|
20
|
+
|
|
21
|
+
**Full package path:** If the user approved a package plan from `prompt-generator/templates/skill-from-ground-up.md` (net-new) or `prompt-generator/templates/skill-refinement-package.md` (existing baseline), paste the approved architecture summary, baseline inventory, planned deltas, and checkpoint list into the skill-writer handoff so file order and scope stay aligned.
|
|
22
|
+
|
|
23
|
+
Invoke `/skill-writer` with the following context in your prompt:
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
Create a skill based on this gap analysis and eval scenarios.
|
|
27
|
+
|
|
28
|
+
Gap analysis: [paste or reference gap-analysis.md]
|
|
29
|
+
Eval scenarios: [paste or reference evals.json expected_output fields]
|
|
30
|
+
Baseline failures: [summarize what Claude got wrong without the skill]
|
|
31
|
+
|
|
32
|
+
Constraint: Write the minimum instructions needed to address these specific gaps.
|
|
33
|
+
Do not over-document. Every line must serve a documented gap.
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
skill-writer handles: type classification, degree of freedom, frontmatter, body structure, progressive disclosure, self-check.
|
|
37
|
+
|
|
38
|
+
**Output:** The skill's SKILL.md (and optional REFERENCE.md, scripts, etc.)
|
|
39
|
+
|
|
40
|
+
## Phase 4: Test -- Delegate to skill-creator Infrastructure
|
|
41
|
+
|
|
42
|
+
The skill-creator plugin provides the eval infrastructure. Reference its components directly:
|
|
43
|
+
|
|
44
|
+
### Spawning test runs
|
|
45
|
+
|
|
46
|
+
For each eval, spawn TWO subagents in the SAME turn (parallel):
|
|
47
|
+
|
|
48
|
+
**With-skill subagent:**
|
|
49
|
+
```
|
|
50
|
+
Execute this task:
|
|
51
|
+
- Read the skill at [path-to-skill]/SKILL.md and follow its instructions
|
|
52
|
+
- Task: [eval prompt from evals.json]
|
|
53
|
+
- Input files: [eval files if any]
|
|
54
|
+
- Save all output files to: [workspace]/iteration-N/eval-[name]/with_skill/outputs/
|
|
55
|
+
- Save a transcript of your complete work to: [workspace]/iteration-N/eval-[name]/with_skill/transcript.md
|
|
56
|
+
- At the end, write a metrics.json with tool call counts and file list
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
**Without-skill subagent** (baseline):
|
|
60
|
+
For iteration-1, reuse baseline results from Phase 2 (iteration-0). For later iterations, the original baseline persists.
|
|
61
|
+
|
|
62
|
+
### Grading
|
|
63
|
+
|
|
64
|
+
Read the grading agent instructions from the skill-creator plugin:
|
|
65
|
+
`[skill-creator-plugin-path]/agents/grader.md`
|
|
66
|
+
|
|
67
|
+
Spawn a grader subagent for each run with:
|
|
68
|
+
- The expectations from evals.json
|
|
69
|
+
- The transcript path
|
|
70
|
+
- The outputs directory
|
|
71
|
+
|
|
72
|
+
**Output:** `grading.json` in each run directory.
|
|
73
|
+
|
|
74
|
+
### Benchmarking
|
|
75
|
+
|
|
76
|
+
Run the aggregation script from the skill-creator plugin directory:
|
|
77
|
+
```bash
|
|
78
|
+
cd [skill-creator-plugin-path] && python -m scripts.aggregate_benchmark [workspace]/iteration-N --skill-name [name]
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
**Output:** `benchmark.json` and `benchmark.md` in the iteration directory.
|
|
82
|
+
|
|
83
|
+
### Eval Viewer
|
|
84
|
+
|
|
85
|
+
Launch the viewer from the skill-creator plugin:
|
|
86
|
+
```bash
|
|
87
|
+
python [skill-creator-plugin-path]/eval-viewer/generate_review.py \
|
|
88
|
+
[workspace]/iteration-N \
|
|
89
|
+
--skill-name "[name]" \
|
|
90
|
+
--benchmark [workspace]/iteration-N/benchmark.json
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
For iteration 2+, add: `--previous-workspace [workspace]/iteration-[N-1]`
|
|
94
|
+
|
|
95
|
+
If no browser/display available, add: `--static [workspace]/iteration-N/review.html`
|
|
96
|
+
|
|
97
|
+
**Output:** Browser-based reviewer where the user inspects outputs and leaves feedback.
|
|
98
|
+
|
|
99
|
+
### Finding the skill-creator plugin path
|
|
100
|
+
|
|
101
|
+
The skill-creator plugin is installed at a path like:
|
|
102
|
+
`~/.claude/plugins/marketplaces/claude-plugins-official/plugins/skill-creator/skills/skill-creator/`
|
|
103
|
+
|
|
104
|
+
To find it dynamically, search for the skill-creator SKILL.md:
|
|
105
|
+
```bash
|
|
106
|
+
find ~/.claude/plugins -name "SKILL.md" -path "*/skill-creator/*" 2>/dev/null | head -1
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
Then derive the plugin root from that path.
|
|
110
|
+
|
|
111
|
+
## Phase 5: Iterate -- This Orchestrator + `/skill-writer`
|
|
112
|
+
|
|
113
|
+
The orchestrator reads feedback.json and transcripts, synthesizes observations, then delegates refinement to `/skill-writer`:
|
|
114
|
+
|
|
115
|
+
```
|
|
116
|
+
Refine this existing skill based on these observations from testing.
|
|
117
|
+
|
|
118
|
+
Current SKILL.md: [paste or reference]
|
|
119
|
+
User feedback: [from feedback.json]
|
|
120
|
+
Behavioral observations: [from transcript analysis]
|
|
121
|
+
|
|
122
|
+
Specific issues to address:
|
|
123
|
+
1. [Issue from feedback]
|
|
124
|
+
2. [Issue from observation]
|
|
125
|
+
|
|
126
|
+
Constraint: Only change what the feedback demands. Do not reorganize working content.
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
Then return to Phase 4 with the refined skill.
|
|
130
|
+
|
|
131
|
+
## Phase 6: Polish -- Delegate to skill-creator Description Optimizer
|
|
132
|
+
|
|
133
|
+
The skill-creator plugin includes a description optimization loop:
|
|
134
|
+
|
|
135
|
+
### Trigger eval generation
|
|
136
|
+
|
|
137
|
+
Generate 20 realistic eval queries (10 should-trigger, 10 should-not-trigger). Use the HTML review template from:
|
|
138
|
+
`[skill-creator-plugin-path]/assets/eval_review.html`
|
|
139
|
+
|
|
140
|
+
### Optimization loop
|
|
141
|
+
|
|
142
|
+
```bash
|
|
143
|
+
cd [skill-creator-plugin-path] && python -m scripts.run_loop \
|
|
144
|
+
--eval-set [path-to-trigger-eval.json] \
|
|
145
|
+
--skill-path [path-to-skill] \
|
|
146
|
+
--model [current-model-id] \
|
|
147
|
+
--max-iterations 5 \
|
|
148
|
+
--verbose
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
### Final validation
|
|
152
|
+
|
|
153
|
+
Run the skill-writer self-check rubric (from skill-writer's Step 9) against the finished skill. All items must pass.
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# Gap Analysis: [Skill Name]
|
|
2
|
+
|
|
3
|
+
## Task Description
|
|
4
|
+
|
|
5
|
+
[What the user is trying to accomplish -- the capability this skill should provide]
|
|
6
|
+
|
|
7
|
+
## Gaps Identified
|
|
8
|
+
|
|
9
|
+
### Gap 1: [Descriptive Name]
|
|
10
|
+
|
|
11
|
+
- **What happened:** [Description of the failure or missing context when working without a skill]
|
|
12
|
+
- **What was needed:** [The specific context, instruction, or knowledge that would fix it]
|
|
13
|
+
- **Frequency:** [How often this comes up in real usage]
|
|
14
|
+
- **Example task:** [A concrete task that exposes this gap]
|
|
15
|
+
|
|
16
|
+
### Gap 2: [Descriptive Name]
|
|
17
|
+
|
|
18
|
+
- **What happened:** [Description]
|
|
19
|
+
- **What was needed:** [Context/instruction needed]
|
|
20
|
+
- **Frequency:** [Frequency]
|
|
21
|
+
- **Example task:** [Concrete example]
|
|
22
|
+
|
|
23
|
+
### Gap 3: [Descriptive Name]
|
|
24
|
+
|
|
25
|
+
- **What happened:** [Description]
|
|
26
|
+
- **What was needed:** [Context/instruction needed]
|
|
27
|
+
- **Frequency:** [Frequency]
|
|
28
|
+
- **Example task:** [Concrete example]
|
|
29
|
+
|
|
30
|
+
## Patterns
|
|
31
|
+
|
|
32
|
+
- [Recurring themes across gaps -- e.g., "Claude consistently lacks knowledge about X"]
|
|
33
|
+
- [Common failure modes -- e.g., "Without guidance, Claude chooses library A when library B is required"]
|
|
34
|
+
- [Context that was repeatedly provided manually]
|
|
35
|
+
|
|
36
|
+
## Candidate Eval Scenarios
|
|
37
|
+
|
|
38
|
+
- [Task that would expose Gap 1 -- becomes the seed for an eval]
|
|
39
|
+
- [Task that would expose Gap 2]
|
|
40
|
+
- [Task that would expose multiple gaps simultaneously]
|
|
41
|
+
- [Edge case that tests boundary behavior]
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
# Improve Skill Workflow
|
|
2
|
+
|
|
3
|
+
Observation-first flow for iterating on an existing skill.
|
|
4
|
+
|
|
5
|
+
## Prerequisites
|
|
6
|
+
|
|
7
|
+
- An existing skill that needs improvement
|
|
8
|
+
- The skill has been used at least once (or the user has observed specific issues)
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Phase 1: Observe
|
|
13
|
+
|
|
14
|
+
**Goal:** Document the existing skill's current behavior by running it on real tasks.
|
|
15
|
+
|
|
16
|
+
> "Use the Skill in real workflows: Give Claude B (with the Skill loaded) actual tasks, not test scenarios"
|
|
17
|
+
|
|
18
|
+
### Process
|
|
19
|
+
|
|
20
|
+
1. Identify the skill to improve. Read its current SKILL.md and any reference files.
|
|
21
|
+
|
|
22
|
+
2. Ask the user what prompted the improvement:
|
|
23
|
+
- "What specific issue did you observe?"
|
|
24
|
+
- "Can you give me a concrete task where the skill underperformed?"
|
|
25
|
+
- "Is this a triggering issue (skill does not activate), a quality issue (skill activates but produces poor results), or a scope issue (skill does the wrong thing)?"
|
|
26
|
+
|
|
27
|
+
3. Run the existing skill on 2-3 real tasks. For each, spawn a subagent:
|
|
28
|
+
|
|
29
|
+
```
|
|
30
|
+
Execute this task using the skill at [path-to-existing-skill]:
|
|
31
|
+
- Read the skill at [path]/SKILL.md and follow its instructions
|
|
32
|
+
- Task: [realistic task from user]
|
|
33
|
+
- Save outputs to: [skill-name]-workspace/observation/task-[N]/outputs/
|
|
34
|
+
- Save transcript to: [skill-name]-workspace/observation/task-[N]/transcript.md
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
4. Analyze the transcripts. Document observations:
|
|
38
|
+
- Where did the skill work well?
|
|
39
|
+
- Where did it fail or produce subpar results?
|
|
40
|
+
- Did Claude B follow the skill's instructions as written?
|
|
41
|
+
- Did Claude B ignore any sections or files?
|
|
42
|
+
- Did Claude B explore in unexpected directions?
|
|
43
|
+
|
|
44
|
+
5. Generate a gap analysis (same template as new-skill Phase 1) focused on the delta between current behavior and desired behavior.
|
|
45
|
+
|
|
46
|
+
**Output:** `[skill-name]-workspace/gap-analysis.md` with observation-based gaps
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## Phase 2-6: Follow the New Skill Workflow
|
|
51
|
+
|
|
52
|
+
From here, follow the same phases as `${CLAUDE_SKILL_DIR}/workflows/new-skill.md`, starting at Phase 2 (Build Evals).
|
|
53
|
+
|
|
54
|
+
### Collaborative package orchestration (Phases 2–6)
|
|
55
|
+
|
|
56
|
+
Whenever Phases 2–6 will touch **multiple files**, **progressive disclosure layout**, or use **checkpointed file-by-file rollout**, treat this as **required** before expanding or rewriting the tree:
|
|
57
|
+
|
|
58
|
+
1. Read `prompt-generator/templates/skill-refinement-package.md` from the claude-dev-env `skills/` tree (repository path: `packages/claude-dev-env/skills/prompt-generator/templates/skill-refinement-package.md`).
|
|
59
|
+
2. Run `/prompt-generator` with that template’s token table filled: set `[[BASELINE_SKILL_ROOT]]` to the existing skill directory, `[[WORKSPACE_ROOT]]` to your iteration workspace (in-place or snapshot per user preference), and `[[DESIGN_INPUT_GLOB]]` to this workflow’s observation-based `gap-analysis.md` when it exists.
|
|
60
|
+
|
|
61
|
+
Use `skill-from-ground-up.md` **only** for **greenfield** packages where no baseline skill directory exists yet; use `skill-refinement-package.md` for every refinement anchored to an existing skill.
|
|
62
|
+
|
|
63
|
+
Key differences from the new-skill flow:
|
|
64
|
+
|
|
65
|
+
- **Phase 2 (Build Evals):** Evals should test the specific issues observed in Phase 1, not hypothetical gaps.
|
|
66
|
+
|
|
67
|
+
- **Phase 3 (Write Skill):** Instead of writing from scratch, invoke `/skill-writer` with:
|
|
68
|
+
|
|
69
|
+
```
|
|
70
|
+
Refine this existing skill based on observation findings.
|
|
71
|
+
|
|
72
|
+
Current SKILL.md: [reference or paste current skill]
|
|
73
|
+
Gap analysis: [reference observation-based gaps]
|
|
74
|
+
Eval scenarios: [reference evals]
|
|
75
|
+
|
|
76
|
+
Constraint: Preserve what works. Only change what the observations demand.
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
- **Phase 4 (Test):** The baseline is the CURRENT skill (snapshot it before editing). Compare old-skill vs new-skill, not with-skill vs without-skill.
|
|
80
|
+
|
|
81
|
+
Before making any changes, snapshot the existing skill:
|
|
82
|
+
```bash
|
|
83
|
+
cp -r [skill-path] [workspace]/skill-snapshot/
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
Then for baseline runs, point subagents at the snapshot:
|
|
87
|
+
```
|
|
88
|
+
Execute this task using the ORIGINAL skill at [workspace]/skill-snapshot/:
|
|
89
|
+
- Read the skill and follow its instructions
|
|
90
|
+
- Task: [eval prompt]
|
|
91
|
+
- Save outputs to: [workspace]/iteration-N/eval-[name]/old_skill/outputs/
|
|
92
|
+
- Save transcript to: [workspace]/iteration-N/eval-[name]/old_skill/transcript.md
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
- **Phase 5 (Iterate):** Same process. The improvement loop compares new version against the snapshot.
|
|
96
|
+
|
|
97
|
+
- **Phase 6 (Polish):** Same process. Run description optimization if triggering was an issue.
|