@tanstack/intent 0.0.8 → 0.0.10
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/README.md +36 -13
- package/dist/cli.mjs +1 -1
- package/dist/intent-library.mjs +1 -1
- package/meta/domain-discovery/SKILL.md +21 -1
- package/meta/feedback-collection/SKILL.md +21 -0
- package/meta/generate-skill/SKILL.md +2 -2
- package/meta/templates/workflows/check-skills.yml +2 -2
- package/meta/tree-generator/SKILL.md +20 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -2,15 +2,21 @@
|
|
|
2
2
|
|
|
3
3
|
Ship compositional knowledge for AI coding agents alongside your npm packages.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
## The problem
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
Your docs are good. Your types are solid. Your agent still gets it wrong.
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
Docs target humans who browse. Types check individual API calls but can't encode intent. Training data snapshots the ecosystem as it _was_, mixing versions without flagging which applies. Once a breaking change ships, models contain _both_ versions forever with no way to disambiguate.
|
|
10
10
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
11
|
+
The ecosystem already moves toward agent-readable knowledge — Cursor rules, CLAUDE.md files, skills directories. But delivery is stuck in copy-paste: hunt for a community-maintained rules file, paste it into your config, repeat for every tool. No versioning, no update path, no staleness signal.
|
|
12
|
+
|
|
13
|
+
## Skills: the fourth artifact
|
|
14
|
+
|
|
15
|
+
You ship code, docs, and types. Skills are the fourth artifact — knowledge encoded for the thing writing most of your code.
|
|
16
|
+
|
|
17
|
+
Skills are npm packages of knowledge — encoding how tools compose, which patterns fit which goals, and what to avoid. When a library ships skills using `@tanstack/intent`, that knowledge travels with the tool via `npm update` — not the model's training cutoff. Versioned knowledge the maintainer owns, updated when the package updates.
|
|
18
|
+
|
|
19
|
+
Each skill declares its source docs. When those docs change, the CLI flags the skill for review. One source of truth, one derived artifact that stays in sync.
|
|
14
20
|
|
|
15
21
|
## Quick Start
|
|
16
22
|
|
|
@@ -19,35 +25,51 @@ pnpm add -D @tanstack/intent
|
|
|
19
25
|
Set up skill-to-task mappings in your project's agent config files (CLAUDE.md, .cursorrules, etc.):
|
|
20
26
|
|
|
21
27
|
```bash
|
|
22
|
-
npx intent install
|
|
28
|
+
npx @tanstack/intent install
|
|
23
29
|
```
|
|
24
30
|
|
|
31
|
+
No per-library setup. No hunting for rules files. Install the package, run `intent install`, and the agent understands the tool. Update the package, and skills update too.
|
|
32
|
+
|
|
25
33
|
List available skills from installed packages:
|
|
26
34
|
|
|
27
35
|
```bash
|
|
28
|
-
npx intent list
|
|
36
|
+
npx @tanstack/intent list
|
|
29
37
|
```
|
|
30
38
|
|
|
31
39
|
### For library maintainers
|
|
32
40
|
|
|
33
|
-
Generate skills for your library
|
|
41
|
+
Generate skills for your library by telling your AI coding agent to run:
|
|
34
42
|
|
|
35
43
|
```bash
|
|
36
|
-
npx intent scaffold
|
|
44
|
+
npx @tanstack/intent scaffold
|
|
37
45
|
```
|
|
38
46
|
|
|
47
|
+
This prints a prompt that walks the agent through domain discovery, skill tree generation, and skill creation — one step at a time with your review at each stage.
|
|
48
|
+
|
|
39
49
|
Validate your skill files:
|
|
40
50
|
|
|
41
51
|
```bash
|
|
42
|
-
npx intent validate
|
|
52
|
+
npx @tanstack/intent validate
|
|
43
53
|
```
|
|
44
54
|
|
|
45
|
-
|
|
55
|
+
Check for skills that have fallen behind their sources:
|
|
46
56
|
|
|
47
57
|
```bash
|
|
48
|
-
npx intent
|
|
58
|
+
npx @tanstack/intent stale
|
|
49
59
|
```
|
|
50
60
|
|
|
61
|
+
Copy CI workflow templates into your repo so validation and staleness checks run on every push:
|
|
62
|
+
|
|
63
|
+
```bash
|
|
64
|
+
npx @tanstack/intent setup
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
## Keeping skills current
|
|
68
|
+
|
|
69
|
+
The real risk with any derived artifact is staleness. `intent stale` flags skills whose source docs have changed, and CI templates catch drift before it ships.
|
|
70
|
+
|
|
71
|
+
The feedback loop runs both directions. `intent feedback` lets users submit structured reports when a skill produces wrong output — which skill, which version, what broke. That context flows back to the maintainer, and the fix ships to everyone on the next `npm update`.
|
|
72
|
+
|
|
51
73
|
## CLI Commands
|
|
52
74
|
|
|
53
75
|
| Command | Description |
|
|
@@ -59,6 +81,7 @@ npx intent setup
|
|
|
59
81
|
| `intent validate [dir]` | Validate SKILL.md files |
|
|
60
82
|
| `intent setup` | Copy CI templates, generate shim, create labels |
|
|
61
83
|
| `intent stale [--json]` | Check skills for version drift |
|
|
84
|
+
| `intent feedback` | Submit skill feedback |
|
|
62
85
|
|
|
63
86
|
## License
|
|
64
87
|
|
package/dist/cli.mjs
CHANGED
|
@@ -57,7 +57,7 @@ async function cmdList(args) {
|
|
|
57
57
|
console.log();
|
|
58
58
|
}
|
|
59
59
|
console.log(`Feedback:`);
|
|
60
|
-
console.log(`
|
|
60
|
+
console.log(` Submit feedback on skill usage to help maintainers improve the skills.`);
|
|
61
61
|
console.log(` Load: node_modules/@tanstack/intent/meta/feedback-collection/SKILL.md`);
|
|
62
62
|
console.log();
|
|
63
63
|
if (result.warnings.length > 0) {
|
package/dist/intent-library.mjs
CHANGED
|
@@ -43,7 +43,7 @@ async function cmdList() {
|
|
|
43
43
|
console.log();
|
|
44
44
|
}
|
|
45
45
|
console.log(`Feedback:`);
|
|
46
|
-
console.log(`
|
|
46
|
+
console.log(` Submit feedback on skill usage to help maintainers improve the skills.`);
|
|
47
47
|
console.log(` Load: node_modules/@tanstack/intent/meta/feedback-collection/SKILL.md`);
|
|
48
48
|
console.log();
|
|
49
49
|
if (result.warnings.length > 0) {
|
|
@@ -31,7 +31,8 @@ before launch"). Domains are an intermediate conceptual grouping you use
|
|
|
31
31
|
during analysis; the final skills emerge from the intersection of domains
|
|
32
32
|
and developer tasks.
|
|
33
33
|
|
|
34
|
-
There are five phases. Always run them in order
|
|
34
|
+
There are five phases. Always run them in order — unless the lightweight
|
|
35
|
+
path applies (see below).
|
|
35
36
|
|
|
36
37
|
1. **Quick scan** — orient yourself (autonomous)
|
|
37
38
|
2. **High-level interview** — extract the maintainer's task map
|
|
@@ -39,6 +40,25 @@ There are five phases. Always run them in order.
|
|
|
39
40
|
4. **Detail interview** — gap-targeted questions, AI-agent failures
|
|
40
41
|
5. **Finalize artifacts**
|
|
41
42
|
|
|
43
|
+
### Lightweight path (small libraries)
|
|
44
|
+
|
|
45
|
+
After Phase 1, if the library has **fewer than 5 client-facing skill
|
|
46
|
+
areas** (e.g. a focused utility library, a single-purpose tool, or a
|
|
47
|
+
library with only 2–3 distinct developer tasks), use a compressed flow:
|
|
48
|
+
|
|
49
|
+
1. **Phase 1** — Quick scan (same as full flow)
|
|
50
|
+
2. **Phase 2+4 combined** — Single interview round. Combine the
|
|
51
|
+
high-level task map questions (Phase 2) with gap-targeted and
|
|
52
|
+
AI-agent-specific questions (Phase 4) into one interview session
|
|
53
|
+
of 4–8 questions total. Skip the draft-review step since the skill
|
|
54
|
+
set is small enough to confirm in one pass.
|
|
55
|
+
3. **Phase 3** — Deep read (same as full flow, but scope is smaller)
|
|
56
|
+
4. **Phase 5** — Finalize artifacts (same as full flow)
|
|
57
|
+
|
|
58
|
+
The lightweight path produces identical output artifacts (domain_map.yaml
|
|
59
|
+
and skill_spec.md). It just avoids two separate interview rounds when the
|
|
60
|
+
library is small enough that one round covers everything.
|
|
61
|
+
|
|
42
62
|
---
|
|
43
63
|
|
|
44
64
|
## Phase 1 — Quick scan (autonomous, ~10 minutes)
|
|
@@ -145,6 +145,27 @@ Determine the target repo from the skill's package. The repo is typically
|
|
|
145
145
|
derivable from the `repository` field in the package's `package.json`, or
|
|
146
146
|
from the `sources` field in the SKILL.md frontmatter.
|
|
147
147
|
|
|
148
|
+
### Privacy check
|
|
149
|
+
|
|
150
|
+
Before submitting, determine whether the user's project is public or private.
|
|
151
|
+
Check with `gh repo view --json visibility` or look for a `private` field in
|
|
152
|
+
the project's `package.json`. If you can't determine visibility, assume private.
|
|
153
|
+
|
|
154
|
+
**Private repos:** Feedback is submitted to a public issue tracker, so it must
|
|
155
|
+
not contain project-specific details. Before submission:
|
|
156
|
+
|
|
157
|
+
1. Strip any project-specific code, file paths, internal API names, service
|
|
158
|
+
URLs, or business logic from all fields
|
|
159
|
+
2. Rewrite the "Task" field to describe the _type_ of task generically
|
|
160
|
+
(e.g. "set up authenticated data fetching" not "set up auth for our
|
|
161
|
+
internal billing API at api.acme.corp/billing")
|
|
162
|
+
3. Rewrite "What Failed" and "Missing" entries to reference only the
|
|
163
|
+
skill's own APIs and patterns, not the user's code
|
|
164
|
+
4. Show the sanitized feedback to the user and ask them to confirm it's
|
|
165
|
+
safe to submit before proceeding
|
|
166
|
+
|
|
167
|
+
**Public repos:** No sanitization needed. Proceed directly to submission.
|
|
168
|
+
|
|
148
169
|
### If `gh` CLI is available
|
|
149
170
|
|
|
150
171
|
Submit directly as a GitHub issue:
|
|
@@ -356,9 +356,9 @@ updates preserve review effort and reduce diff noise.
|
|
|
356
356
|
|
|
357
357
|
| Rule | Detail |
|
|
358
358
|
|------|--------|
|
|
359
|
-
|
|
|
359
|
+
| Match the library's framework support | Generate framework skills only for adapters the library actually provides. If the library supports only React, only generate React examples. If it supports multiple frameworks, generate one skill per adapter. |
|
|
360
360
|
| All imports use real package names | `@tanstack/react-query`, not `react-query` |
|
|
361
|
-
| No placeholder code | No `// ...`, `[your value]`, or `...rest` |
|
|
361
|
+
| No placeholder code | No `// ...`, `[your value]`, or `...rest`. Idiomatic framework patterns like `{children}` or `{props.title}` in JSX are not placeholders — they are real code and are acceptable. |
|
|
362
362
|
| Agent-first writing | Only write what the agent cannot already know |
|
|
363
363
|
| Examples are minimal | No unnecessary boilerplate or wrapper components |
|
|
364
364
|
| Failure modes are high-value | Focus on plausible-but-broken, not obvious errors |
|
|
@@ -41,7 +41,7 @@ jobs:
|
|
|
41
41
|
- name: Check staleness
|
|
42
42
|
id: stale
|
|
43
43
|
run: |
|
|
44
|
-
OUTPUT=$(npx intent stale --json 2>&1) || true
|
|
44
|
+
OUTPUT=$(npx @tanstack/intent stale --json 2>&1) || true
|
|
45
45
|
echo "$OUTPUT"
|
|
46
46
|
|
|
47
47
|
# Check if any skills need review
|
|
@@ -89,7 +89,7 @@ jobs:
|
|
|
89
89
|
'1. Read the current SKILL.md file',
|
|
90
90
|
'2. Check what changed in the library since the skill was last updated',
|
|
91
91
|
'3. Update the skill content to reflect current APIs and behavior',
|
|
92
|
-
'4. Run \`npx intent validate\` to verify the updated skill',
|
|
92
|
+
'4. Run \`npx @tanstack/intent validate\` to verify the updated skill',
|
|
93
93
|
].join('\n');
|
|
94
94
|
|
|
95
95
|
// Write outputs
|
|
@@ -124,6 +124,24 @@ package directory (e.g. `packages/client/skills/core/SKILL.md`). Set the
|
|
|
124
124
|
`package` field so generate-skill knows where to write the file. The domain
|
|
125
125
|
map artifacts stay at the repo root.
|
|
126
126
|
|
|
127
|
+
### Minimal library fast path
|
|
128
|
+
|
|
129
|
+
If the domain map contains **fewer than 5 skills** and no framework
|
|
130
|
+
adapter packages, skip the core overview + sub-skill registry pattern.
|
|
131
|
+
Instead:
|
|
132
|
+
|
|
133
|
+
- Use **flat structure** — each skill gets its own `skills/[skill-name]/SKILL.md`
|
|
134
|
+
- **No router skill** — the intent CLI `list` command is sufficient for discovery
|
|
135
|
+
- **No core overview skill** — go directly to individual skill files
|
|
136
|
+
- Each skill is type `core` (not `sub-skill`) and stands alone without
|
|
137
|
+
a parent registry
|
|
138
|
+
- Skip Step 2 (core overview) and Step 3 (sub-skills) — go directly to
|
|
139
|
+
writing individual skills as standalone core skills using Step 3's body
|
|
140
|
+
format
|
|
141
|
+
|
|
142
|
+
This avoids unnecessary scaffolding for focused libraries where the
|
|
143
|
+
overhead of a hierarchical skill tree exceeds the navigation benefit.
|
|
144
|
+
|
|
127
145
|
### Step 1 — Plan the file tree
|
|
128
146
|
|
|
129
147
|
From the domain map, each entry in the `skills` list becomes a SKILL.md
|
|
@@ -229,7 +247,8 @@ table) is optional. If the intent CLI provides `list` and `show`
|
|
|
229
247
|
commands, agents can discover skills directly without a router. Only
|
|
230
248
|
create a router skill if the skill set is large enough (15+) that
|
|
231
249
|
browsing the list is insufficient, or if the nested structure needs
|
|
232
|
-
an entry point to guide agents to the right sub-skill.
|
|
250
|
+
an entry point to guide agents to the right sub-skill. Libraries with
|
|
251
|
+
fewer than 5 skills should never have a router skill.
|
|
233
252
|
|
|
234
253
|
**Source repository layout for npm distribution:**
|
|
235
254
|
|