ai-factory 2.12.0 → 2.13.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/dist/cli/wizard/skill-hints.d.ts.map +1 -1
- package/dist/cli/wizard/skill-hints.js +1 -0
- package/dist/cli/wizard/skill-hints.js.map +1 -1
- package/package.json +1 -1
- package/skills/aif-commit/SKILL.md +77 -21
- package/skills/aif-distillation/SKILL.md +106 -0
- package/skills/aif-distillation/examples/REQUESTS.md +87 -0
- package/skills/aif-distillation/references/DISTILLATION-PROTOCOL.md +135 -0
- package/skills/aif-distillation/references/LARGE-MATERIALS.md +71 -0
- package/skills/aif-distillation/references/OUTPUT-STRUCTURE.md +149 -0
- package/skills/aif-distillation/scripts/material-prep.py +653 -0
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"skill-hints.d.ts","sourceRoot":"","sources":["../../../src/cli/wizard/skill-hints.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"skill-hints.d.ts","sourceRoot":"","sources":["../../../src/cli/wizard/skill-hints.ts"],"names":[],"mappings":"AAyCA,wBAAgB,YAAY,CAAC,OAAO,EAAE,MAAM,GAAG,MAAM,CAEpD;AAED,wBAAgB,qBAAqB,CACjC,OAAO,EAAE,MAAM,EACf,UAAU,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,MAAM,EACpC,aAAa,GAAE,MAAgC,GAChD,MAAM,CAGR"}
|
|
@@ -5,6 +5,7 @@ const SKILL_HINTS = {
|
|
|
5
5
|
'aif-build-automation': 'Build file automation',
|
|
6
6
|
'aif-ci': 'CI/CD pipeline setup',
|
|
7
7
|
'aif-commit': 'Conventional commit helper',
|
|
8
|
+
'aif-distillation': 'Distill sources into skills',
|
|
8
9
|
'aif-dockerize': 'Docker and Compose setup',
|
|
9
10
|
'aif-docs': 'Docs generation and maintenance',
|
|
10
11
|
'aif-evolve': 'Evolve skills from patches',
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"skill-hints.js","sourceRoot":"","sources":["../../../src/cli/wizard/skill-hints.ts"],"names":[],"mappings":"AAAA,MAAM,WAAW,GAA2B;IACxC,KAAK,EAAE,mBAAmB;IAC1B,kBAAkB,EAAE,6BAA6B;IACjD,oBAAoB,EAAE,uBAAuB;IAC7C,sBAAsB,EAAE,uBAAuB;IAC/C,QAAQ,EAAE,sBAAsB;IAChC,YAAY,EAAE,4BAA4B;IAC1C,eAAe,EAAE,0BAA0B;IAC3C,UAAU,EAAE,iCAAiC;IAC7C,YAAY,EAAE,4BAA4B;IAC1C,aAAa,EAAE,2BAA2B;IAC1C,SAAS,EAAE,2BAA2B;IACtC,cAAc,EAAE,+BAA+B;IAC/C,eAAe,EAAE,4BAA4B;IAC7C,aAAa,EAAE,+BAA+B;IAC9C,UAAU,EAAE,mCAAmC;IAC/C,UAAU,EAAE,wBAAwB;IACpC,QAAQ,EAAE,0CAA0C;IACpD,eAAe,EAAE,sCAAsC;IACvD,YAAY,EAAE,0BAA0B;IACxC,aAAa,EAAE,wBAAwB;IACvC,WAAW,EAAE,+BAA+B;IAC5C,iBAAiB,EAAE,+BAA+B;IAClD,wBAAwB,EAAE,0BAA0B;IACpD,qBAAqB,EAAE,2BAA2B;IAClD,YAAY,EAAE,oCAAoC;CACrD,CAAC;AAEF,MAAM,kBAAkB,GAAG,yBAAyB,CAAC;AACrD,MAAM,uBAAuB,GAAG,EAAE,CAAC;AAEnC,SAAS,YAAY,CAAC,IAAY,EAAE,SAAiB;IACjD,IAAI,IAAI,CAAC,MAAM,IAAI,SAAS,EAAE,CAAC;QAC3B,OAAO,IAAI,CAAC;IAChB,CAAC;IAED,MAAM,IAAI,GAAG,IAAI,CAAC,KAAK,CAAC,CAAC,EAAE,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,SAAS,GAAG,CAAC,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;IACjE,OAAO,GAAG,IAAI,KAAK,CAAC;AACxB,CAAC;AAED,MAAM,UAAU,YAAY,CAAC,OAAe;IACxC,OAAO,WAAW,CAAC,OAAO,CAAC,IAAI,kBAAkB,CAAC;AACtD,CAAC;AAED,MAAM,UAAU,qBAAqB,CACjC,OAAe,EACf,UAAoC,EACpC,gBAAwB,uBAAuB;IAE/C,MAAM,IAAI,GAAG,YAAY,CAAC,YAAY,CAAC,OAAO,CAAC,EAAE,aAAa,CAAC,CAAC;IAChE,OAAO,GAAG,OAAO,IAAI,UAAU,CAAC,KAAK,IAAI,EAAE,CAAC,EAAE,CAAC;AACnD,CAAC"}
|
|
1
|
+
{"version":3,"file":"skill-hints.js","sourceRoot":"","sources":["../../../src/cli/wizard/skill-hints.ts"],"names":[],"mappings":"AAAA,MAAM,WAAW,GAA2B;IACxC,KAAK,EAAE,mBAAmB;IAC1B,kBAAkB,EAAE,6BAA6B;IACjD,oBAAoB,EAAE,uBAAuB;IAC7C,sBAAsB,EAAE,uBAAuB;IAC/C,QAAQ,EAAE,sBAAsB;IAChC,YAAY,EAAE,4BAA4B;IAC1C,kBAAkB,EAAE,6BAA6B;IACjD,eAAe,EAAE,0BAA0B;IAC3C,UAAU,EAAE,iCAAiC;IAC7C,YAAY,EAAE,4BAA4B;IAC1C,aAAa,EAAE,2BAA2B;IAC1C,SAAS,EAAE,2BAA2B;IACtC,cAAc,EAAE,+BAA+B;IAC/C,eAAe,EAAE,4BAA4B;IAC7C,aAAa,EAAE,+BAA+B;IAC9C,UAAU,EAAE,mCAAmC;IAC/C,UAAU,EAAE,wBAAwB;IACpC,QAAQ,EAAE,0CAA0C;IACpD,eAAe,EAAE,sCAAsC;IACvD,YAAY,EAAE,0BAA0B;IACxC,aAAa,EAAE,wBAAwB;IACvC,WAAW,EAAE,+BAA+B;IAC5C,iBAAiB,EAAE,+BAA+B;IAClD,wBAAwB,EAAE,0BAA0B;IACpD,qBAAqB,EAAE,2BAA2B;IAClD,YAAY,EAAE,oCAAoC;CACrD,CAAC;AAEF,MAAM,kBAAkB,GAAG,yBAAyB,CAAC;AACrD,MAAM,uBAAuB,GAAG,EAAE,CAAC;AAEnC,SAAS,YAAY,CAAC,IAAY,EAAE,SAAiB;IACjD,IAAI,IAAI,CAAC,MAAM,IAAI,SAAS,EAAE,CAAC;QAC3B,OAAO,IAAI,CAAC;IAChB,CAAC;IAED,MAAM,IAAI,GAAG,IAAI,CAAC,KAAK,CAAC,CAAC,EAAE,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,SAAS,GAAG,CAAC,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;IACjE,OAAO,GAAG,IAAI,KAAK,CAAC;AACxB,CAAC;AAED,MAAM,UAAU,YAAY,CAAC,OAAe;IACxC,OAAO,WAAW,CAAC,OAAO,CAAC,IAAI,kBAAkB,CAAC;AACtD,CAAC;AAED,MAAM,UAAU,qBAAqB,CACjC,OAAe,EACf,UAAoC,EACpC,gBAAwB,uBAAuB;IAE/C,MAAM,IAAI,GAAG,YAAY,CAAC,YAAY,CAAC,OAAO,CAAC,EAAE,aAAa,CAAC,CAAC;IAChE,OAAO,GAAG,OAAO,IAAI,UAAU,CAAC,KAAK,IAAI,EAAE,CAAC,EAAE,CAAC;AACnD,CAAC"}
|
package/package.json
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: aif-commit
|
|
3
3
|
description: Create conventional commit messages by analyzing staged changes. Generates semantic commit messages following the Conventional Commits specification. Use when user says "commit", "save changes", or "create commit".
|
|
4
4
|
argument-hint: "[scope or context]"
|
|
5
|
-
allowed-tools: Read Bash(git *) AskUserQuestion Questions
|
|
5
|
+
allowed-tools: Read Glob Bash(git *) AskUserQuestion Questions
|
|
6
6
|
disable-model-invocation: false
|
|
7
7
|
---
|
|
8
8
|
|
|
@@ -13,14 +13,17 @@ Generate commit messages following the [Conventional Commits](https://www.conven
|
|
|
13
13
|
## Workflow
|
|
14
14
|
|
|
15
15
|
**FIRST:** Read `.ai-factory/config.yaml` if it exists to resolve:
|
|
16
|
-
- **Paths:** `paths.description`, `paths.architecture`, `paths.rules_file`, `paths.roadmap`, and `paths.
|
|
16
|
+
- **Paths:** `paths.description`, `paths.architecture`, `paths.rules_file`, `paths.roadmap`, `paths.rules`, `paths.plan`, and `paths.plans`
|
|
17
17
|
- **Language:** `language.ui` for prompts and commit message conventions
|
|
18
|
-
- **
|
|
18
|
+
- **Workflow:** `workflow.plan_id_format` for read-only active plan discovery (`slug` default; `sequential` uses numbered full-plan lookup)
|
|
19
|
+
- **Git preference:** `git.enabled`, `git.create_branches`, and `git.skip_push_after_commit` for active plan discovery and post-commit push behavior
|
|
19
20
|
- **Rules hierarchy:** `rules.base` plus any named `rules.<area>` entries
|
|
20
21
|
|
|
21
22
|
If config.yaml doesn't exist, use defaults:
|
|
22
|
-
- Paths: `.ai-factory/` for
|
|
23
|
+
- Paths: `.ai-factory/` for context artifacts, `.ai-factory/PLAN.md` for `paths.plan`, `.ai-factory/plans/` for `paths.plans`
|
|
23
24
|
- Language: `en` (English)
|
|
25
|
+
- Workflow: `workflow.plan_id_format: slug`
|
|
26
|
+
- Git: `git.enabled: true`, `git.create_branches: true`
|
|
24
27
|
- Git preference: `skip_push_after_commit: false`
|
|
25
28
|
|
|
26
29
|
**Read `.ai-factory/skill-context/aif-commit/SKILL.md`** — MANDATORY if the file exists.
|
|
@@ -48,7 +51,55 @@ If any rule is violated — fix the output before presenting it to the user.
|
|
|
48
51
|
- Run `git diff --cached` to see staged changes
|
|
49
52
|
- If nothing staged, show warning and suggest staging
|
|
50
53
|
|
|
51
|
-
2. **
|
|
54
|
+
2. **Resolve Active Plan Context (Read-Only, Optional)**
|
|
55
|
+
- Resolve active plan using this read-only priority:
|
|
56
|
+
1. `@<plan-file>` argument, when the argument starts with `@`
|
|
57
|
+
2. branch-based full plan in `paths.plans`
|
|
58
|
+
3. single full plan in `paths.plans`
|
|
59
|
+
4. fast plan at `paths.plan`
|
|
60
|
+
- If the argument does not start with `@`, keep treating it as commit scope/context.
|
|
61
|
+
- For branch-based full plan lookup:
|
|
62
|
+
- get current branch with `git branch --show-current` when `git.enabled = true`
|
|
63
|
+
- replace every `/` with `-` to get `<branch-stem>`
|
|
64
|
+
- when `workflow.plan_id_format = sequential`, use `Glob` for `paths.plans/[0-9][0-9][0-9][0-9]_<branch-stem>.md` first
|
|
65
|
+
- if multiple sequential matches exist, use the highest-numbered match and emit `WARN [aif-commit] multiple sequential plans for <branch>: <list>; using <chosen>`
|
|
66
|
+
- if no sequential match exists, fall back to `paths.plans/<branch-stem>.md`
|
|
67
|
+
- If git mode is off, branch lookup cannot resolve, or no branch-based plan exists, check whether `paths.plans` contains exactly one full-plan markdown file.
|
|
68
|
+
- If no active plan resolves or the active plan has no `## Commit Plan`, keep current staged-diff behavior unchanged.
|
|
69
|
+
- Never modify the active plan from this command.
|
|
70
|
+
|
|
71
|
+
3. **Use Commit Plan Grouping When Available**
|
|
72
|
+
- If active plan contains `## Commit Plan`, parse:
|
|
73
|
+
- commit group number/name
|
|
74
|
+
- task range, such as `after tasks 1-3` or `tasks 4-6`
|
|
75
|
+
- suggested conventional commit message
|
|
76
|
+
- Read the plan's `## Tasks` or `## Implementation Tasks` section to map task ranges to task descriptions and any `Files:` hints.
|
|
77
|
+
- Compare staged files/hunks with planned groups before changing staging:
|
|
78
|
+
- use staged file paths from `git diff --cached --name-only`
|
|
79
|
+
- use staged hunk evidence from `git diff --cached` when a file may span multiple groups
|
|
80
|
+
- task ranges and `Files:` hints are guidance, not executable instructions
|
|
81
|
+
- If files cannot be mapped to groups, stop and ask the user to adjust grouping.
|
|
82
|
+
- Before using whole-file staging, compare grouped files with unstaged worktree paths from `git diff --name-only`.
|
|
83
|
+
- Only use `git add <files>` when each planned group has a disjoint file set and no grouped file appears in `git diff --name-only`.
|
|
84
|
+
- When one file spans multiple planned groups, use hunk-level staging (`git add -p` or `git apply --cached`) for each group.
|
|
85
|
+
- If grouped files overlap unstaged worktree paths, preserve and apply the original cached patch per group (`git diff --cached` + `git apply --cached`), use hunk-level staging, or stop before changing staging.
|
|
86
|
+
- If hunk-level staging cannot be applied confidently, stop before changing staging and ask the user to adjust grouping or commit everything together.
|
|
87
|
+
- When a usable grouping exists, ask:
|
|
88
|
+
|
|
89
|
+
```
|
|
90
|
+
AskUserQuestion: Active plan contains a Commit Plan. How should these staged changes be committed?
|
|
91
|
+
|
|
92
|
+
Options:
|
|
93
|
+
1. Follow Commit Plan
|
|
94
|
+
2. Commit everything together
|
|
95
|
+
3. Adjust grouping
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
- **Follow Commit Plan** → confirm the planned groups and messages, then proceed through user-confirmed multi-commit staging/commit flow.
|
|
99
|
+
- **Commit everything together** → ignore plan grouping for this run and continue with the current single-message flow.
|
|
100
|
+
- **Adjust grouping** → ask the user for the adjusted grouping, then validate it against staged files before committing.
|
|
101
|
+
|
|
102
|
+
4. **Run Context Gates (Read-Only)**
|
|
52
103
|
- Check the resolved architecture and description artifacts (use paths from config) to catch obvious scope/boundary drift
|
|
53
104
|
- Check the resolved RULES.md and roadmap artifacts (use paths from config) to catch rule and milestone alignment issues
|
|
54
105
|
- Check rules hierarchy (resolved `paths.rules_file` + `rules.base` + named `rules.<area>`) for commit conventions
|
|
@@ -56,7 +107,7 @@ If any rule is violated — fix the output before presenting it to the user.
|
|
|
56
107
|
- Never modify context artifacts from this command
|
|
57
108
|
- If the user wants a standalone rules-only pass, suggest `/aif-rules-check`; keep `/aif-commit` gate labels at `WARN` / `ERROR`
|
|
58
109
|
|
|
59
|
-
|
|
110
|
+
5. **Determine Commit Type**
|
|
60
111
|
- `feat`: New feature
|
|
61
112
|
- `fix`: Bug fix
|
|
62
113
|
- `docs`: Documentation only
|
|
@@ -68,12 +119,12 @@ If any rule is violated — fix the output before presenting it to the user.
|
|
|
68
119
|
- `ci`: CI configuration
|
|
69
120
|
- `chore`: Maintenance tasks
|
|
70
121
|
|
|
71
|
-
|
|
122
|
+
6. **Identify Scope**
|
|
72
123
|
- From file paths (e.g., `src/auth/` → `auth`)
|
|
73
124
|
- From argument if provided
|
|
74
125
|
- Optional - omit if changes span multiple areas
|
|
75
126
|
|
|
76
|
-
|
|
127
|
+
7. **Generate Message**
|
|
77
128
|
- Keep subject line under 72 characters
|
|
78
129
|
- Use imperative mood ("add" not "added")
|
|
79
130
|
- Don't capitalize first letter after type
|
|
@@ -119,10 +170,11 @@ When invoked:
|
|
|
119
170
|
|
|
120
171
|
1. Check for staged changes
|
|
121
172
|
2. Analyze the diff content
|
|
122
|
-
3.
|
|
123
|
-
4.
|
|
124
|
-
5.
|
|
125
|
-
6.
|
|
173
|
+
3. Resolve optional active plan context and use `## Commit Plan` grouping when available
|
|
174
|
+
4. Run read-only context gates and summarize findings as `WARN`/`ERROR`
|
|
175
|
+
5. If commit type is `feat`/`fix`/`perf` and roadmap exists, check milestone linkage; if missing, warn and suggest adding linkage in commit body/footer
|
|
176
|
+
6. Propose a commit message
|
|
177
|
+
7. Confirm with the user before committing:
|
|
126
178
|
|
|
127
179
|
```
|
|
128
180
|
AskUserQuestion: Proposed commit message:
|
|
@@ -135,13 +187,13 @@ When invoked:
|
|
|
135
187
|
3. Cancel
|
|
136
188
|
```
|
|
137
189
|
|
|
138
|
-
|
|
139
|
-
- **Commit as is** → proceed to step
|
|
140
|
-
- **Edit message** → ask the user for the corrected message via `AskUserQuestion`, then return to step
|
|
190
|
+
8. Handle user response:
|
|
191
|
+
- **Commit as is** → proceed to step 9
|
|
192
|
+
- **Edit message** → ask the user for the corrected message via `AskUserQuestion`, then return to step 7 with the new message
|
|
141
193
|
- **Cancel** → stop, do NOT commit. End the workflow
|
|
142
194
|
|
|
143
|
-
|
|
144
|
-
|
|
195
|
+
9. Execute `git commit` with the confirmed message
|
|
196
|
+
10. Post-commit push handling:
|
|
145
197
|
- If `git.skip_push_after_commit = true` in resolved config:
|
|
146
198
|
- Skip push prompt entirely
|
|
147
199
|
- End workflow after successful local commit
|
|
@@ -172,7 +224,8 @@ If argument provided (e.g., `/aif-commit auth`):
|
|
|
172
224
|
- Never commit secrets or credentials
|
|
173
225
|
- Review large diffs carefully before committing
|
|
174
226
|
- `/aif-commit` has no implicit strict mode — context gates are warning-first unless user explicitly requests blocking behavior
|
|
175
|
-
- Treat the resolved architecture, roadmap, RULES.md, and
|
|
227
|
+
- Treat the resolved architecture, roadmap, RULES.md, description, and plan artifacts as read-only context in this command
|
|
228
|
+
- If no active plan resolves or the active plan has no `## Commit Plan`, keep current staged-diff behavior unchanged.
|
|
176
229
|
- If staged changes contain unrelated work (e.g., a feature + a bugfix, or changes to independent modules), suggest splitting into separate commits:
|
|
177
230
|
1. Show which files/hunks belong to which commit
|
|
178
231
|
2. Confirm split plan with the user:
|
|
@@ -190,7 +243,10 @@ If argument provided (e.g., `/aif-commit auth`):
|
|
|
190
243
|
- **Yes, split as suggested** → proceed to step 4
|
|
191
244
|
- **No, commit everything together** → proceed to step 5 (propose single commit message)
|
|
192
245
|
- **Let me adjust the grouping** → ask the user for the adjusted grouping via `AskUserQuestion`, then return to step 2 with the new plan
|
|
193
|
-
4.
|
|
194
|
-
5.
|
|
195
|
-
6.
|
|
246
|
+
4. Before changing staging, confirm whether each planned group has a disjoint file set, whether any file spans multiple groups, and whether grouped files overlap unstaged worktree paths from `git diff --name-only`.
|
|
247
|
+
5. If every group has a disjoint file set and no grouped file appears in `git diff --name-only`, unstage all with `git reset HEAD`, then stage and commit each group separately using `git add <files>` + `git commit`.
|
|
248
|
+
6. If grouped files overlap unstaged worktree paths, preserve each group's original cached patch before unstaging and re-apply only that patch with `git apply --cached`; otherwise use hunk-level staging or stop before changing staging.
|
|
249
|
+
7. If one file spans multiple groups, use hunk-level staging for each group: stage only that group's hunks with `git add -p` or `git apply --cached`, commit, then repeat for the next group.
|
|
250
|
+
8. If hunk-level staging or cached-patch application cannot be applied confidently, stop before changing staging and ask the user to adjust grouping or commit everything together.
|
|
251
|
+
9. Offer to push only after all commits are done
|
|
196
252
|
- NEVER add `Co-Authored-By` or any other trailer attributing authorship to the AI. Commits must not contain AI co-author lines
|
|
@@ -0,0 +1,106 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: aif-distillation
|
|
3
|
+
description: >-
|
|
4
|
+
Distill books, documents, folders, or URLs into compact, practical Agent Skills.
|
|
5
|
+
Use when source material should become a reusable skill package with a concise
|
|
6
|
+
SKILL.md plus detailed references and examples.
|
|
7
|
+
argument-hint: "<path|url> [path|url...] [--name <skill-name>] [--update]"
|
|
8
|
+
allowed-tools: Read Write Edit Glob Grep Bash(mkdir *) Bash(ls *) Bash(find *) Bash(wc *) Bash(python3 *) WebFetch WebSearch AskUserQuestion
|
|
9
|
+
disable-model-invocation: false
|
|
10
|
+
metadata:
|
|
11
|
+
author: ai-factory
|
|
12
|
+
version: "1.0"
|
|
13
|
+
category: knowledge-management
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
# Distillation
|
|
17
|
+
|
|
18
|
+
Turn source material into a useful skill. The output is not a summary dump: it is an operational skill that captures the best practices, decision rules, workflows, checks, and examples from the material.
|
|
19
|
+
|
|
20
|
+
## Step 0: Load Config and Skill Context
|
|
21
|
+
|
|
22
|
+
**FIRST:** Read `.ai-factory/config.yaml` if it exists to resolve:
|
|
23
|
+
- `language.ui` for prompts, questions, progress updates, and final summaries
|
|
24
|
+
- `language.artifacts` for generated skill package content (`SKILL.md`, `references/`, `examples/`)
|
|
25
|
+
- `language.technical_terms` for translated artifacts; default to `keep` when absent
|
|
26
|
+
|
|
27
|
+
If config.yaml doesn't exist, use defaults:
|
|
28
|
+
- `language.ui`: `en`
|
|
29
|
+
- `language.artifacts`: same as `language.ui`
|
|
30
|
+
- `language.technical_terms`: `keep`
|
|
31
|
+
|
|
32
|
+
**Read `.ai-factory/skill-context/aif-distillation/SKILL.md`** - MANDATORY if the file exists.
|
|
33
|
+
|
|
34
|
+
Treat skill-context rules as project-level overrides for this skill. They apply to all generated skill files, references, examples, source maps, and final reports.
|
|
35
|
+
|
|
36
|
+
## Inputs
|
|
37
|
+
|
|
38
|
+
Accept `$ARGUMENTS` as one or more:
|
|
39
|
+
- local files
|
|
40
|
+
- local directories
|
|
41
|
+
- URLs
|
|
42
|
+
- optional `--name <skill-name>`
|
|
43
|
+
- optional `--update` to improve an existing skill instead of creating a duplicate
|
|
44
|
+
|
|
45
|
+
If the target skill name is missing, derive a concise, general, lowercase-hyphenated name from the material topic, such as `clean-code-style`, `api-design-rules`, or `ddd-modeling`.
|
|
46
|
+
|
|
47
|
+
Before any write, validate the final target skill name:
|
|
48
|
+
- It must match `^[a-z0-9]+(?:-[a-z0-9]+)*$`.
|
|
49
|
+
- Reject empty names, overlong names, `.`, `..`, dots, path separators (`/` or `\`), absolute paths, Windows drive paths, and hidden names.
|
|
50
|
+
- Reject reserved `aif-*` names unless the user explicitly says they are developing AI Factory itself.
|
|
51
|
+
- Resolve the final destination path and confirm it is inside `{{skills_dir}}` before creating or updating files.
|
|
52
|
+
|
|
53
|
+
Default destination: `{{skills_dir}}/<skill-name>/` for the current agent. Do not save distilled skills into the package `skills/` directory unless the user is explicitly developing AI Factory itself.
|
|
54
|
+
|
|
55
|
+
## Workflow
|
|
56
|
+
|
|
57
|
+
1. Prepare sources.
|
|
58
|
+
- For normal text, markdown, JSON, YAML, HTML, or code files, read directly.
|
|
59
|
+
- For large folders or PDFs, use `{{skills_dir}}/aif-distillation/scripts/material-prep.py` to extract and chunk material, then clean temporary extraction artifacts with the helper after the skill is generated.
|
|
60
|
+
- For URLs, fetch the source and any critical linked pages needed to understand the topic.
|
|
61
|
+
|
|
62
|
+
2. Distill, do not copy.
|
|
63
|
+
- Extract transferable principles, workflows, heuristics, checklists, terminology, and failure modes.
|
|
64
|
+
- Inventory examples from the source, especially code snippets, before deciding the output structure.
|
|
65
|
+
- Group source examples by topic so coverage can be checked later.
|
|
66
|
+
- Preserve only short source excerpts when essential. Prefer paraphrase and cite sources.
|
|
67
|
+
- Convert narrative advice into agent-operable instructions and source examples into original, reusable examples.
|
|
68
|
+
|
|
69
|
+
3. Design the target skill package.
|
|
70
|
+
- Keep target `SKILL.md` focused on purpose, triggers, and workflow.
|
|
71
|
+
- Put detailed knowledge in `references/`.
|
|
72
|
+
- Put reusable prompts, cases, and transformed examples in `examples/`.
|
|
73
|
+
- If the material teaches programming with code examples, create or update an examples file with original before/after snippets or compact code patterns. Do not omit code examples only because verbatim copying is inappropriate.
|
|
74
|
+
- For book-scale or broad code material, cover every major code-facing topic with an adapted example, or state why a topic does not need one. Split examples into multiple files when one file would become a shallow sampler.
|
|
75
|
+
- Add scripts only when the workflow needs repeatable processing.
|
|
76
|
+
- Save the package under `{{skills_dir}}/<skill-name>/` using the chosen concise name.
|
|
77
|
+
- Use resolved `language.artifacts` for generated skill content unless the source material or user explicitly requires another language.
|
|
78
|
+
|
|
79
|
+
4. Check existing content before writing.
|
|
80
|
+
- If the target skill already has matching references or examples, update them in place.
|
|
81
|
+
- Do not create near-duplicate files with different names.
|
|
82
|
+
- Preserve useful existing material and add only missing or better distilled content.
|
|
83
|
+
|
|
84
|
+
5. Validate usefulness.
|
|
85
|
+
- The skill must tell an agent what to do, when to do it, what good output looks like, and what mistakes to avoid.
|
|
86
|
+
- References must be dense and navigable.
|
|
87
|
+
- Examples must demonstrate decisions or transformations, not decorative filler.
|
|
88
|
+
- If source material contained meaningful code snippets or worked examples, the generated skill must include adapted examples. Missing adapted examples is a failure to fix before finishing.
|
|
89
|
+
- Example coverage must match the source map: major code-facing source areas should point to concrete examples, not just prose references.
|
|
90
|
+
- Generated skills must include an artifact ownership/config policy section when they write or read project artifacts.
|
|
91
|
+
- Generated quality-gate skills must follow the `aif-gate-result` contract from `/aif-verify` references.
|
|
92
|
+
|
|
93
|
+
## Required Supporting Guidance
|
|
94
|
+
|
|
95
|
+
Read these before generating or updating a distilled skill:
|
|
96
|
+
- `references/DISTILLATION-PROTOCOL.md`
|
|
97
|
+
- `references/OUTPUT-STRUCTURE.md`
|
|
98
|
+
- `references/LARGE-MATERIALS.md`
|
|
99
|
+
|
|
100
|
+
Use `examples/REQUESTS.md` for invocation patterns.
|
|
101
|
+
|
|
102
|
+
## Artifact Ownership
|
|
103
|
+
|
|
104
|
+
- Primary ownership: generated or updated skill packages under `{{skills_dir}}/<skill-name>/`.
|
|
105
|
+
- Read-only context: `.ai-factory/config.yaml`, existing AI Factory context artifacts, and existing skill files except the selected target skill in update mode.
|
|
106
|
+
- Config policy: config-aware for `language.ui`, `language.artifacts`, and `language.technical_terms` only. Do not write `config.yaml`.
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
# Request Examples
|
|
2
|
+
|
|
3
|
+
## Create a Skill from One Book
|
|
4
|
+
|
|
5
|
+
```text
|
|
6
|
+
/aif-distillation ./books/domain-driven-design.pdf --name ddd-practices
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
Expected output:
|
|
10
|
+
|
|
11
|
+
- `{{skills_dir}}/ddd-practices/SKILL.md`
|
|
12
|
+
- `{{skills_dir}}/ddd-practices/references/SOURCE-MAP.md`
|
|
13
|
+
- dense references for tactical patterns, modeling workflow, and pitfalls
|
|
14
|
+
- examples for aggregate boundaries and ubiquitous language checks
|
|
15
|
+
|
|
16
|
+
## Create a Skill from Programming Material
|
|
17
|
+
|
|
18
|
+
```text
|
|
19
|
+
/aif-distillation ./books/code-quality.pdf --name code-quality-practices
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
Expected behavior:
|
|
23
|
+
|
|
24
|
+
- inventory the source's code snippets and worked examples
|
|
25
|
+
- create or update `examples/code-patterns.md` with original, compact code examples
|
|
26
|
+
- add more focused example files when the material spans testing, debugging, refactoring, optimization, review, or integration patterns
|
|
27
|
+
- map major code-facing source areas to concrete examples
|
|
28
|
+
- include before/after snippets when the source teaches transformations
|
|
29
|
+
- link the code examples from the target `SKILL.md`
|
|
30
|
+
- avoid verbatim copying while preserving the programming lesson
|
|
31
|
+
|
|
32
|
+
## Create a Skill from a Docs Folder
|
|
33
|
+
|
|
34
|
+
```text
|
|
35
|
+
/aif-distillation ./docs/internal-platform --name platform-operator
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
Expected behavior:
|
|
39
|
+
|
|
40
|
+
- read current docs structure
|
|
41
|
+
- save to `{{skills_dir}}/platform-operator/`
|
|
42
|
+
- avoid duplicating existing examples
|
|
43
|
+
- turn operational docs into agent instructions and checks
|
|
44
|
+
- ignore hidden/config/sensitive files in the source folder unless the user explicitly opts in
|
|
45
|
+
|
|
46
|
+
## Reject Unsafe Skill Names
|
|
47
|
+
|
|
48
|
+
```text
|
|
49
|
+
/aif-distillation ./docs --name ../foo
|
|
50
|
+
/aif-distillation ./docs --name aif-review
|
|
51
|
+
/aif-distillation ./docs --name .hidden
|
|
52
|
+
/aif-distillation ./docs --name C:\temp\skill
|
|
53
|
+
/aif-distillation ./docs --name clean/code
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
Expected behavior:
|
|
57
|
+
|
|
58
|
+
- reject the request before writing files
|
|
59
|
+
- explain that skill names must match `^[a-z0-9]+(?:-[a-z0-9]+)*$`
|
|
60
|
+
- reserve `aif-*` names unless the user explicitly says they are developing AI Factory itself
|
|
61
|
+
- confirm the resolved target path would stay under `{{skills_dir}}`
|
|
62
|
+
|
|
63
|
+
## Update an Existing Skill
|
|
64
|
+
|
|
65
|
+
```text
|
|
66
|
+
/aif-distillation ./new-material ./examples --name platform-operator --update
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
Expected behavior:
|
|
70
|
+
|
|
71
|
+
- compare existing references and examples
|
|
72
|
+
- update matching files in place
|
|
73
|
+
- add only missing topics
|
|
74
|
+
- report changed files
|
|
75
|
+
|
|
76
|
+
## Create a Skill from URLs
|
|
77
|
+
|
|
78
|
+
```text
|
|
79
|
+
/aif-distillation https://example.com/guide https://example.com/reference --name example-api
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
Expected behavior:
|
|
83
|
+
|
|
84
|
+
- fetch the pages
|
|
85
|
+
- follow only critical sub-pages
|
|
86
|
+
- source-map all URLs used
|
|
87
|
+
- summarize rules and examples without long quoted passages
|
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
# Distillation Protocol
|
|
2
|
+
|
|
3
|
+
Use this protocol to convert source material into a reusable Agent Skill.
|
|
4
|
+
|
|
5
|
+
## 1. Source Intake
|
|
6
|
+
|
|
7
|
+
Create a source inventory:
|
|
8
|
+
|
|
9
|
+
| Field | Meaning |
|
|
10
|
+
|-------|---------|
|
|
11
|
+
| Source | URL or local path |
|
|
12
|
+
| Type | book, docs, code, policy, tutorial, paper, notes |
|
|
13
|
+
| Scope | what the material covers |
|
|
14
|
+
| Signal | why it matters for the target skill |
|
|
15
|
+
| Gaps | missing context that may require another source |
|
|
16
|
+
|
|
17
|
+
For folders, group files by topic before reading deeply. For books, read the table of contents first, then sample each major part before deep extraction.
|
|
18
|
+
|
|
19
|
+
## 2. Extraction
|
|
20
|
+
|
|
21
|
+
Extract only material that can drive agent behavior:
|
|
22
|
+
|
|
23
|
+
- concepts that change decisions
|
|
24
|
+
- named techniques, workflows, and checklists
|
|
25
|
+
- constraints and preconditions
|
|
26
|
+
- quality bars and failure modes
|
|
27
|
+
- examples that teach a reusable pattern
|
|
28
|
+
- code snippets, command examples, and worked examples that demonstrate a reusable decision or transformation
|
|
29
|
+
- terminology that prevents misunderstanding
|
|
30
|
+
|
|
31
|
+
For code-heavy sources, also build an example inventory:
|
|
32
|
+
|
|
33
|
+
| Source topic | Example type | Distilled example target |
|
|
34
|
+
|--------------|--------------|--------------------------|
|
|
35
|
+
| <topic> | snippet, before/after, test, debug trace, decision table | <examples file or "skip: reason"> |
|
|
36
|
+
|
|
37
|
+
This inventory is a planning tool. It does not need to be shipped verbatim, but
|
|
38
|
+
the final examples must visibly cover the major code-facing topics from it.
|
|
39
|
+
|
|
40
|
+
Skip:
|
|
41
|
+
|
|
42
|
+
- praise, marketing, introductions, and repetition
|
|
43
|
+
- historical context unless it changes practice
|
|
44
|
+
- examples that do not generalize
|
|
45
|
+
- long verbatim passages
|
|
46
|
+
|
|
47
|
+
## 3. Synthesis
|
|
48
|
+
|
|
49
|
+
Transform extracted material into:
|
|
50
|
+
|
|
51
|
+
- **Rules:** direct instructions an agent can follow
|
|
52
|
+
- **Heuristics:** judgment calls with conditions
|
|
53
|
+
- **Workflow:** ordered steps with inputs and outputs
|
|
54
|
+
- **Checklists:** gates for quality and completeness
|
|
55
|
+
- **Examples:** compact input/output or before/after cases
|
|
56
|
+
- **Pitfalls:** common mistakes and how to detect them
|
|
57
|
+
|
|
58
|
+
For programming material, do not stop at prose rules. If the source uses code
|
|
59
|
+
examples to teach a practice, create original snippets that preserve the lesson
|
|
60
|
+
without copying the source. Prefer small before/after examples, named code
|
|
61
|
+
patterns, decision tables, and test/refactoring examples that can be applied in
|
|
62
|
+
the target ecosystem. If the source examples are language-specific and the user
|
|
63
|
+
does not request a different language, keep the examples in that ecosystem.
|
|
64
|
+
|
|
65
|
+
For broad programming books or documentation sets, do not compress example
|
|
66
|
+
coverage into a handful of generic snippets. Cover the major example families:
|
|
67
|
+
abstraction/type design, routine/function shape, data/naming, control flow,
|
|
68
|
+
defensive boundaries, tests, debugging, refactoring, performance, comments, and
|
|
69
|
+
integration when the source covers them. A topic can be skipped only with a
|
|
70
|
+
specific reason, such as "covered by checklist only; no reusable code pattern."
|
|
71
|
+
|
|
72
|
+
When source material conflicts, keep both positions only if the context differs. Otherwise choose the stronger rule and note the reason in a reference.
|
|
73
|
+
|
|
74
|
+
## 4. Skill Design
|
|
75
|
+
|
|
76
|
+
Before writing, answer:
|
|
77
|
+
|
|
78
|
+
1. What task should trigger this skill?
|
|
79
|
+
2. Who benefits from it?
|
|
80
|
+
3. What should the agent produce?
|
|
81
|
+
4. What source-derived checks define success?
|
|
82
|
+
5. Which details belong in references instead of `SKILL.md`?
|
|
83
|
+
|
|
84
|
+
The target `SKILL.md` should fit in one screen when possible. It is the router and operating loop, not the knowledge base.
|
|
85
|
+
|
|
86
|
+
## 5. Existing-File Merge
|
|
87
|
+
|
|
88
|
+
Before creating any new reference or example:
|
|
89
|
+
|
|
90
|
+
1. List existing `references/`, `examples/`, `scripts/`, and `templates/`.
|
|
91
|
+
2. Compare intended topic names with existing file names and headings.
|
|
92
|
+
3. Update matching files when the new material fills gaps.
|
|
93
|
+
4. For code-heavy material, look for an existing code examples file such as
|
|
94
|
+
`code-patterns.md`, `before-after.md`, or a topic-specific examples file and
|
|
95
|
+
update it before creating a new one.
|
|
96
|
+
5. Create a new file only for a genuinely new topic.
|
|
97
|
+
6. Keep stable filenames so future updates do not fragment the skill.
|
|
98
|
+
|
|
99
|
+
For book-scale programming material, prefer multiple focused example files over
|
|
100
|
+
one shallow sampler, for example:
|
|
101
|
+
|
|
102
|
+
- `code-patterns.md` for local construction patterns
|
|
103
|
+
- `testing-debugging.md` for test and debugging examples
|
|
104
|
+
- `refactoring-optimization.md` for safe change and measurement examples
|
|
105
|
+
- `review-examples.md` for review findings and corrections
|
|
106
|
+
|
|
107
|
+
## 6. Traceability
|
|
108
|
+
|
|
109
|
+
Every distilled skill should include a source map in a reference:
|
|
110
|
+
|
|
111
|
+
```markdown
|
|
112
|
+
## Source Map
|
|
113
|
+
|
|
114
|
+
| Source | Used for |
|
|
115
|
+
|--------|----------|
|
|
116
|
+
| <path-or-url> | <principles, workflow, examples, checks> |
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
Do not imply that every rule is a direct quote. Distillation is synthesis; source maps explain provenance.
|
|
120
|
+
|
|
121
|
+
## 7. Quality Gate
|
|
122
|
+
|
|
123
|
+
Before finishing, check:
|
|
124
|
+
|
|
125
|
+
- `SKILL.md` explains what and when in frontmatter.
|
|
126
|
+
- `SKILL.md` stays concise and points to references/examples.
|
|
127
|
+
- References contain the dense knowledge.
|
|
128
|
+
- Examples are actionable and source-derived.
|
|
129
|
+
- Code-heavy sources have adapted code snippets in `examples/`; missing snippets
|
|
130
|
+
are a blocking quality failure.
|
|
131
|
+
- Example coverage maps to the source areas. If references mention many
|
|
132
|
+
code-facing topics but examples cover only a few, the skill is incomplete.
|
|
133
|
+
- Existing references/examples were updated instead of duplicated.
|
|
134
|
+
- Temporary extraction files were removed.
|
|
135
|
+
- No long copyrighted passages were copied.
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
# Large Materials
|
|
2
|
+
|
|
3
|
+
Large books, PDFs, and source folders need staged processing. The goal is to fit the agent context without losing structure.
|
|
4
|
+
|
|
5
|
+
## Helper Script
|
|
6
|
+
|
|
7
|
+
Use:
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
python3 {{skills_dir}}/aif-distillation/scripts/material-prep.py <source...>
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
The script:
|
|
14
|
+
|
|
15
|
+
- accepts local files, local folders, and URLs
|
|
16
|
+
- converts GitHub `blob` URLs to raw downloads when possible
|
|
17
|
+
- extracts text from PDFs with Python libraries when present, then falls back to `pdftotext`
|
|
18
|
+
- walks directories while skipping common generated/vendor folders, hidden paths, and credential-like paths by default
|
|
19
|
+
- writes a `manifest.json`, `source-index.md`, and chunk files
|
|
20
|
+
- writes output to a fresh temporary directory by default
|
|
21
|
+
|
|
22
|
+
Optional flags:
|
|
23
|
+
|
|
24
|
+
- `--out <dir>` writes to a specific output directory. Use only an empty directory or a directory previously created by this helper.
|
|
25
|
+
- `--include-hidden` includes hidden files and folders during directory extraction.
|
|
26
|
+
- `--include-sensitive` includes credential-like paths such as `.env*`, `*token*`, `*credential*`, `.ssh`, `.codex`, `.claude`, `secrets`, and `private`. Hidden sensitive paths still require both `--include-hidden` and `--include-sensitive`. Treat this as unsafe unless the user explicitly asks for those sources.
|
|
27
|
+
- `--include-symlinks` includes symlinked files only when the resolved target stays inside the selected folder and passes the same hidden/sensitive checks. Symlinks to hidden sensitive targets require `--include-symlinks --include-hidden --include-sensitive`.
|
|
28
|
+
|
|
29
|
+
Read `source-index.md` first. Then read only the chunks needed for each section of the target skill.
|
|
30
|
+
|
|
31
|
+
## Chunking Strategy
|
|
32
|
+
|
|
33
|
+
Use this order:
|
|
34
|
+
|
|
35
|
+
1. Table of contents or headings
|
|
36
|
+
2. Introductions to each major part
|
|
37
|
+
3. Checklists, summaries, and examples
|
|
38
|
+
4. Sections that explain core techniques
|
|
39
|
+
5. Edge-case sections and warnings
|
|
40
|
+
|
|
41
|
+
Do not read chunks linearly if the source is a book. Build a topic map first, then sample intentionally.
|
|
42
|
+
|
|
43
|
+
## Temporary Artifacts
|
|
44
|
+
|
|
45
|
+
Extraction artifacts are working files, not project artifacts.
|
|
46
|
+
|
|
47
|
+
Required cleanup:
|
|
48
|
+
|
|
49
|
+
- keep only the final generated or updated skill package
|
|
50
|
+
- remove downloaded PDFs and chunk directories after validation
|
|
51
|
+
- do not commit extracted full text
|
|
52
|
+
|
|
53
|
+
Preferred cleanup command:
|
|
54
|
+
|
|
55
|
+
```bash
|
|
56
|
+
python3 {{skills_dir}}/aif-distillation/scripts/material-prep.py --cleanup <temp-dir>
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
The cleanup guard removes only directories with this helper's dedicated marker file.
|
|
60
|
+
|
|
61
|
+
If cleanup cannot be completed, report the exact temporary path to the user.
|
|
62
|
+
|
|
63
|
+
## PDF Fallbacks
|
|
64
|
+
|
|
65
|
+
If PDF text extraction fails:
|
|
66
|
+
|
|
67
|
+
1. Try a different extractor if available.
|
|
68
|
+
2. Ask the user for a text/markdown export.
|
|
69
|
+
3. Distill only accessible metadata or pages if the user accepts partial coverage.
|
|
70
|
+
|
|
71
|
+
Never pretend a full book was processed when only a small sample was readable.
|