incitaciones 0.3.0 → 0.3.2
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/content/distilled/close/SKILL.md +3 -2
- package/content/distilled/implement-documentation/SKILL.md +29 -0
- package/content/distilled/implement-documentation/references/anti-patterns.md +35 -0
- package/content/distilled/implement-documentation/references/diataxis-implementation.md +31 -0
- package/content/distilled/implement-documentation/references/templates.md +115 -0
- package/content/distilled/implement-documentation/references/tooling-comparison.md +46 -0
- package/content/distilled/implement-documentation/references/versioning.md +31 -0
- package/content/distilled/park/SKILL.md +3 -2
- package/content/distilled/renew/SKILL.md +4 -3
- package/content/distilled/research-documentation/SKILL.md +29 -0
- package/content/distilled/research-documentation/references/checklist.md +58 -0
- package/content/distilled/research-documentation/references/llm-readiness.md +43 -0
- package/content/distilled/research-documentation/references/metrics.md +42 -0
- package/content/distilled/research-documentation/references/report-template.md +42 -0
- package/content/distilled/review-documentation/SKILL.md +49 -0
- package/content/distilled/review-documentation/references/ai-readiness-criteria.md +38 -0
- package/content/manifest.json +360 -11
- package/package.json +1 -1
- package/pi-package/skills/close/SKILL.md +3 -2
- package/pi-package/skills/implement-documentation/SKILL.md +18 -57
- package/pi-package/skills/implement-documentation/references/anti-patterns.md +35 -0
- package/pi-package/skills/implement-documentation/references/diataxis-implementation.md +31 -0
- package/pi-package/skills/implement-documentation/references/templates.md +115 -0
- package/pi-package/skills/implement-documentation/references/tooling-comparison.md +46 -0
- package/pi-package/skills/implement-documentation/references/versioning.md +31 -0
- package/pi-package/skills/park/SKILL.md +3 -2
- package/pi-package/skills/renew/SKILL.md +4 -3
- package/pi-package/skills/research-documentation/SKILL.md +19 -69
- package/pi-package/skills/research-documentation/references/checklist.md +58 -0
- package/pi-package/skills/research-documentation/references/llm-readiness.md +43 -0
- package/pi-package/skills/research-documentation/references/metrics.md +42 -0
- package/pi-package/skills/research-documentation/references/report-template.md +42 -0
- package/pi-package/skills/review-documentation/SKILL.md +45 -40
- package/pi-package/skills/review-documentation/references/ai-readiness-criteria.md +38 -0
- package/scripts/generate-pi-resources.mjs +122 -1
- package/content/distilled/implement-documentation.md +0 -68
- package/content/distilled/research-documentation.md +0 -79
- package/content/distilled/review-documentation.md +0 -44
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# AI-Readiness Criteria (Pass 5)
|
|
2
|
+
|
|
3
|
+
Deep checks for Pass 5. The basic pass (TL;DR present, headers unique, Answer First) catches surface issues; these checks catch whether the page is actually consumable by an AI agent. The canonical theory is `content/research-documentation-frameworks.md` (section "Machine Readability").
|
|
4
|
+
|
|
5
|
+
## LLM-friendly structure
|
|
6
|
+
|
|
7
|
+
- Is there a concise TL;DR (1-2 sentences) at the top suitable for context-window injection?
|
|
8
|
+
- Is the page free of navigation chrome when exported (menus, footers, ads) so the body text is clean?
|
|
9
|
+
- Is prose minimalist and high-signal? Verbose docs cost more and retrieve worse.
|
|
10
|
+
|
|
11
|
+
## RAG-compatible chunking
|
|
12
|
+
|
|
13
|
+
- Does the page cover one well-defined topic so it chunks cleanly for retrieval?
|
|
14
|
+
- Are section headings stable and unique so a chunk can be addressed precisely?
|
|
15
|
+
- Is there redundant cross-page duplication that would pollute retrieval results?
|
|
16
|
+
|
|
17
|
+
## Semantic headers
|
|
18
|
+
|
|
19
|
+
- Are headers descriptive of content, not generic ("Overview", "Details")?
|
|
20
|
+
- Are headers unique across the site so a model can disambiguate?
|
|
21
|
+
- Is front matter present (title, description, version, category) for indexing?
|
|
22
|
+
|
|
23
|
+
## Dual-audience precision
|
|
24
|
+
|
|
25
|
+
- Is language precise enough for a machine? Natural-language ambiguity a human resolves from context is opaque to an agent.
|
|
26
|
+
- Are error conditions and their meanings explicit?
|
|
27
|
+
- Are capability boundaries stated (what the tool/API can and cannot do)?
|
|
28
|
+
|
|
29
|
+
## Schema and spec sync (reference pages)
|
|
30
|
+
|
|
31
|
+
- For API reference: is it generated from or synchronized with a machine-readable spec (OpenAPI, AsyncAPI, JSDoc/TypeDoc, Sphinx autodoc)?
|
|
32
|
+
- For tool/agent docs: are MCP manifests and agent cards present with precise descriptions and JSON schemas for inputs/outputs?
|
|
33
|
+
- Are code examples complete and runnable? Agents execute what they read; partial snippets mislead.
|
|
34
|
+
|
|
35
|
+
## Site-level (flag only if the page is the canonical entry)
|
|
36
|
+
|
|
37
|
+
- Is a `llms.txt` present at the documentation root and does it reference this page where authoritative?
|
|
38
|
+
- Are canonical URLs set so a model retrieves the current stable version?
|
package/content/manifest.json
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"version": "2026-07-
|
|
2
|
+
"version": "2026-07-29",
|
|
3
3
|
"schema_version": "1.1",
|
|
4
4
|
"prompts": [
|
|
5
5
|
{
|
|
@@ -2223,17 +2223,137 @@
|
|
|
2223
2223
|
"title": "Research and Audit Documentation Architecture",
|
|
2224
2224
|
"description": "Audit existing documentation or plan a new suite using advanced frameworks",
|
|
2225
2225
|
"source": "content/prompt-task-research-documentation.md",
|
|
2226
|
-
"distilled": "content/distilled/research-documentation.md",
|
|
2226
|
+
"distilled": "content/distilled/research-documentation/SKILL.md",
|
|
2227
|
+
"skill_format": "progressive-disclosure",
|
|
2227
2228
|
"tags": [
|
|
2228
2229
|
"research",
|
|
2229
2230
|
"documentation",
|
|
2230
2231
|
"audit",
|
|
2231
|
-
"information-architecture"
|
|
2232
|
+
"information-architecture",
|
|
2233
|
+
"diataxis",
|
|
2234
|
+
"eppo",
|
|
2235
|
+
"llm-readiness"
|
|
2232
2236
|
],
|
|
2233
2237
|
"bundles": [
|
|
2234
2238
|
"documentation",
|
|
2235
2239
|
"research"
|
|
2236
|
-
]
|
|
2240
|
+
],
|
|
2241
|
+
"eval": {
|
|
2242
|
+
"task_types": [
|
|
2243
|
+
"research",
|
|
2244
|
+
"documentation",
|
|
2245
|
+
"audit"
|
|
2246
|
+
],
|
|
2247
|
+
"success_signals": [
|
|
2248
|
+
"core_assertion_stated",
|
|
2249
|
+
"every_doc_classified_to_one_quadrant",
|
|
2250
|
+
"frankenbooks_flagged",
|
|
2251
|
+
"eppo_compliance_checked",
|
|
2252
|
+
"ai_readiness_assessed",
|
|
2253
|
+
"measurement_signals_recommended",
|
|
2254
|
+
"report_produced"
|
|
2255
|
+
],
|
|
2256
|
+
"failure_signals": [
|
|
2257
|
+
"content_drafted",
|
|
2258
|
+
"stylistic_changes_suggested",
|
|
2259
|
+
"quadrant_overlap_unflagged",
|
|
2260
|
+
"missing_report"
|
|
2261
|
+
],
|
|
2262
|
+
"stages": [
|
|
2263
|
+
{
|
|
2264
|
+
"name": "define-scope",
|
|
2265
|
+
"hints": [
|
|
2266
|
+
"primary audience",
|
|
2267
|
+
"core assertion",
|
|
2268
|
+
"value proposition"
|
|
2269
|
+
]
|
|
2270
|
+
},
|
|
2271
|
+
{
|
|
2272
|
+
"name": "audit-content",
|
|
2273
|
+
"hints": [
|
|
2274
|
+
"references/checklist.md",
|
|
2275
|
+
"diataxis quadrant",
|
|
2276
|
+
"eppo status",
|
|
2277
|
+
"cognitive load"
|
|
2278
|
+
]
|
|
2279
|
+
},
|
|
2280
|
+
{
|
|
2281
|
+
"name": "map-snowflake",
|
|
2282
|
+
"hints": [
|
|
2283
|
+
"macro-expansion",
|
|
2284
|
+
"component list",
|
|
2285
|
+
"topic matrix"
|
|
2286
|
+
]
|
|
2287
|
+
},
|
|
2288
|
+
{
|
|
2289
|
+
"name": "identify-gaps",
|
|
2290
|
+
"hints": [
|
|
2291
|
+
"references/llm-readiness.md",
|
|
2292
|
+
"references/metrics.md",
|
|
2293
|
+
"quadrant imbalance",
|
|
2294
|
+
"llms.txt",
|
|
2295
|
+
"rag chunking"
|
|
2296
|
+
]
|
|
2297
|
+
},
|
|
2298
|
+
{
|
|
2299
|
+
"name": "produce-report",
|
|
2300
|
+
"hints": [
|
|
2301
|
+
"references/report-template.md",
|
|
2302
|
+
"final report"
|
|
2303
|
+
]
|
|
2304
|
+
}
|
|
2305
|
+
],
|
|
2306
|
+
"references": [
|
|
2307
|
+
{
|
|
2308
|
+
"id": "checklist",
|
|
2309
|
+
"path": "content/distilled/research-documentation/references/checklist.md",
|
|
2310
|
+
"purpose": "audit-checklist",
|
|
2311
|
+
"stage": "audit-content",
|
|
2312
|
+
"optional": false,
|
|
2313
|
+
"aliases": [
|
|
2314
|
+
"references/checklist.md",
|
|
2315
|
+
"checklist.md",
|
|
2316
|
+
"checklist"
|
|
2317
|
+
]
|
|
2318
|
+
},
|
|
2319
|
+
{
|
|
2320
|
+
"id": "llm-readiness",
|
|
2321
|
+
"path": "content/distilled/research-documentation/references/llm-readiness.md",
|
|
2322
|
+
"purpose": "gap-assessment",
|
|
2323
|
+
"stage": "identify-gaps",
|
|
2324
|
+
"optional": false,
|
|
2325
|
+
"aliases": [
|
|
2326
|
+
"references/llm-readiness.md",
|
|
2327
|
+
"llm-readiness.md",
|
|
2328
|
+
"llm readiness"
|
|
2329
|
+
]
|
|
2330
|
+
},
|
|
2331
|
+
{
|
|
2332
|
+
"id": "metrics",
|
|
2333
|
+
"path": "content/distilled/research-documentation/references/metrics.md",
|
|
2334
|
+
"purpose": "measurement-signals",
|
|
2335
|
+
"stage": "identify-gaps",
|
|
2336
|
+
"optional": false,
|
|
2337
|
+
"aliases": [
|
|
2338
|
+
"references/metrics.md",
|
|
2339
|
+
"metrics.md",
|
|
2340
|
+
"metrics"
|
|
2341
|
+
]
|
|
2342
|
+
},
|
|
2343
|
+
{
|
|
2344
|
+
"id": "report-template",
|
|
2345
|
+
"path": "content/distilled/research-documentation/references/report-template.md",
|
|
2346
|
+
"purpose": "output-template",
|
|
2347
|
+
"stage": "produce-report",
|
|
2348
|
+
"optional": false,
|
|
2349
|
+
"aliases": [
|
|
2350
|
+
"references/report-template.md",
|
|
2351
|
+
"report-template.md",
|
|
2352
|
+
"report template"
|
|
2353
|
+
]
|
|
2354
|
+
}
|
|
2355
|
+
]
|
|
2356
|
+
}
|
|
2237
2357
|
},
|
|
2238
2358
|
{
|
|
2239
2359
|
"name": "implement-documentation",
|
|
@@ -2241,15 +2361,152 @@
|
|
|
2241
2361
|
"title": "Implement High-Signal Documentation Topics",
|
|
2242
2362
|
"description": "Write documentation using Diátaxis, Info Mapping, and EPPO principles",
|
|
2243
2363
|
"source": "content/prompt-task-implement-documentation.md",
|
|
2244
|
-
"distilled": "content/distilled/implement-documentation.md",
|
|
2364
|
+
"distilled": "content/distilled/implement-documentation/SKILL.md",
|
|
2365
|
+
"skill_format": "progressive-disclosure",
|
|
2245
2366
|
"tags": [
|
|
2246
2367
|
"implementation",
|
|
2247
2368
|
"documentation",
|
|
2248
|
-
"technical-writing"
|
|
2369
|
+
"technical-writing",
|
|
2370
|
+
"diataxis",
|
|
2371
|
+
"info-mapping",
|
|
2372
|
+
"eppo",
|
|
2373
|
+
"versioning"
|
|
2249
2374
|
],
|
|
2250
2375
|
"bundles": [
|
|
2251
2376
|
"documentation"
|
|
2252
|
-
]
|
|
2377
|
+
],
|
|
2378
|
+
"eval": {
|
|
2379
|
+
"task_types": [
|
|
2380
|
+
"implementation",
|
|
2381
|
+
"documentation",
|
|
2382
|
+
"writing"
|
|
2383
|
+
],
|
|
2384
|
+
"success_signals": [
|
|
2385
|
+
"quadrant_identified",
|
|
2386
|
+
"matching_template_used",
|
|
2387
|
+
"context_block_present",
|
|
2388
|
+
"content_chunked_and_labeled",
|
|
2389
|
+
"tldr_present",
|
|
2390
|
+
"anti_patterns_avoided"
|
|
2391
|
+
],
|
|
2392
|
+
"failure_signals": [
|
|
2393
|
+
"mixed_intent",
|
|
2394
|
+
"missing_context_block",
|
|
2395
|
+
"generic_headers",
|
|
2396
|
+
"missing_tldr",
|
|
2397
|
+
"faq_antipattern_used"
|
|
2398
|
+
],
|
|
2399
|
+
"stages": [
|
|
2400
|
+
{
|
|
2401
|
+
"name": "quadrant-check",
|
|
2402
|
+
"hints": [
|
|
2403
|
+
"references/templates.md",
|
|
2404
|
+
"references/anti-patterns.md",
|
|
2405
|
+
"tutorial",
|
|
2406
|
+
"how-to",
|
|
2407
|
+
"reference",
|
|
2408
|
+
"explanation"
|
|
2409
|
+
]
|
|
2410
|
+
},
|
|
2411
|
+
{
|
|
2412
|
+
"name": "eppo-init",
|
|
2413
|
+
"hints": [
|
|
2414
|
+
"title",
|
|
2415
|
+
"context block",
|
|
2416
|
+
"prerequisites"
|
|
2417
|
+
]
|
|
2418
|
+
},
|
|
2419
|
+
{
|
|
2420
|
+
"name": "info-mapping",
|
|
2421
|
+
"hints": [
|
|
2422
|
+
"chunking",
|
|
2423
|
+
"labeling",
|
|
2424
|
+
"tables",
|
|
2425
|
+
"lists"
|
|
2426
|
+
]
|
|
2427
|
+
},
|
|
2428
|
+
{
|
|
2429
|
+
"name": "ai-polish",
|
|
2430
|
+
"hints": [
|
|
2431
|
+
"semantic headers",
|
|
2432
|
+
"tldr",
|
|
2433
|
+
"rag indexing"
|
|
2434
|
+
]
|
|
2435
|
+
},
|
|
2436
|
+
{
|
|
2437
|
+
"name": "setup-tooling",
|
|
2438
|
+
"hints": [
|
|
2439
|
+
"references/tooling-comparison.md",
|
|
2440
|
+
"references/versioning.md",
|
|
2441
|
+
"references/diataxis-implementation.md",
|
|
2442
|
+
"platform selection",
|
|
2443
|
+
"versioning strategy"
|
|
2444
|
+
]
|
|
2445
|
+
}
|
|
2446
|
+
],
|
|
2447
|
+
"references": [
|
|
2448
|
+
{
|
|
2449
|
+
"id": "templates",
|
|
2450
|
+
"path": "content/distilled/implement-documentation/references/templates.md",
|
|
2451
|
+
"purpose": "output-template",
|
|
2452
|
+
"stage": "quadrant-check",
|
|
2453
|
+
"optional": false,
|
|
2454
|
+
"aliases": [
|
|
2455
|
+
"references/templates.md",
|
|
2456
|
+
"templates.md",
|
|
2457
|
+
"templates"
|
|
2458
|
+
]
|
|
2459
|
+
},
|
|
2460
|
+
{
|
|
2461
|
+
"id": "anti-patterns",
|
|
2462
|
+
"path": "content/distilled/implement-documentation/references/anti-patterns.md",
|
|
2463
|
+
"purpose": "pitfall-catalog",
|
|
2464
|
+
"stage": "quadrant-check",
|
|
2465
|
+
"optional": false,
|
|
2466
|
+
"aliases": [
|
|
2467
|
+
"references/anti-patterns.md",
|
|
2468
|
+
"anti-patterns.md",
|
|
2469
|
+
"anti patterns"
|
|
2470
|
+
]
|
|
2471
|
+
},
|
|
2472
|
+
{
|
|
2473
|
+
"id": "tooling-comparison",
|
|
2474
|
+
"path": "content/distilled/implement-documentation/references/tooling-comparison.md",
|
|
2475
|
+
"purpose": "platform-selection",
|
|
2476
|
+
"stage": "setup-tooling",
|
|
2477
|
+
"optional": true,
|
|
2478
|
+
"aliases": [
|
|
2479
|
+
"references/tooling-comparison.md",
|
|
2480
|
+
"tooling-comparison.md",
|
|
2481
|
+
"tooling comparison"
|
|
2482
|
+
]
|
|
2483
|
+
},
|
|
2484
|
+
{
|
|
2485
|
+
"id": "versioning",
|
|
2486
|
+
"path": "content/distilled/implement-documentation/references/versioning.md",
|
|
2487
|
+
"purpose": "versioning-strategy",
|
|
2488
|
+
"stage": "setup-tooling",
|
|
2489
|
+
"optional": true,
|
|
2490
|
+
"aliases": [
|
|
2491
|
+
"references/versioning.md",
|
|
2492
|
+
"versioning.md",
|
|
2493
|
+
"versioning"
|
|
2494
|
+
]
|
|
2495
|
+
},
|
|
2496
|
+
{
|
|
2497
|
+
"id": "diataxis-implementation",
|
|
2498
|
+
"path": "content/distilled/implement-documentation/references/diataxis-implementation.md",
|
|
2499
|
+
"purpose": "rollout-guide",
|
|
2500
|
+
"stage": "setup-tooling",
|
|
2501
|
+
"optional": true,
|
|
2502
|
+
"aliases": [
|
|
2503
|
+
"references/diataxis-implementation.md",
|
|
2504
|
+
"diataxis-implementation.md",
|
|
2505
|
+
"diataxis implementation"
|
|
2506
|
+
]
|
|
2507
|
+
}
|
|
2508
|
+
]
|
|
2509
|
+
}
|
|
2253
2510
|
},
|
|
2254
2511
|
{
|
|
2255
2512
|
"name": "review-documentation",
|
|
@@ -2257,17 +2514,109 @@
|
|
|
2257
2514
|
"title": "Review Documentation Quality (Rule of 5)",
|
|
2258
2515
|
"description": "Iterative review of documentation for cognitive scannability and AI-readiness",
|
|
2259
2516
|
"source": "content/prompt-task-review-documentation.md",
|
|
2260
|
-
"distilled": "content/distilled/review-documentation.md",
|
|
2517
|
+
"distilled": "content/distilled/review-documentation/SKILL.md",
|
|
2518
|
+
"skill_format": "progressive-disclosure",
|
|
2261
2519
|
"tags": [
|
|
2262
2520
|
"review",
|
|
2263
2521
|
"documentation",
|
|
2264
2522
|
"technical-writing",
|
|
2265
|
-
"parallel-review"
|
|
2523
|
+
"parallel-review",
|
|
2524
|
+
"diataxis",
|
|
2525
|
+
"eppo",
|
|
2526
|
+
"info-mapping",
|
|
2527
|
+
"ai-readiness"
|
|
2266
2528
|
],
|
|
2267
2529
|
"bundles": [
|
|
2268
2530
|
"documentation",
|
|
2269
2531
|
"reviews"
|
|
2270
|
-
]
|
|
2532
|
+
],
|
|
2533
|
+
"eval": {
|
|
2534
|
+
"task_types": [
|
|
2535
|
+
"review",
|
|
2536
|
+
"documentation",
|
|
2537
|
+
"quality-assurance"
|
|
2538
|
+
],
|
|
2539
|
+
"success_signals": [
|
|
2540
|
+
"five_passes_completed_or_converged",
|
|
2541
|
+
"issues_cited_with_locations",
|
|
2542
|
+
"ai_readiness_deep_checked",
|
|
2543
|
+
"final_verdict_present"
|
|
2544
|
+
],
|
|
2545
|
+
"failure_signals": [
|
|
2546
|
+
"stage_skipping_without_convergence",
|
|
2547
|
+
"vague_findings_without_locations",
|
|
2548
|
+
"shallow_ai_pass_only",
|
|
2549
|
+
"missing_verdict"
|
|
2550
|
+
],
|
|
2551
|
+
"stages": [
|
|
2552
|
+
{
|
|
2553
|
+
"name": "pass-1-intent",
|
|
2554
|
+
"hints": [
|
|
2555
|
+
"pass 1",
|
|
2556
|
+
"diataxis intent",
|
|
2557
|
+
"leaked intents"
|
|
2558
|
+
]
|
|
2559
|
+
},
|
|
2560
|
+
{
|
|
2561
|
+
"name": "pass-2-eppo",
|
|
2562
|
+
"hints": [
|
|
2563
|
+
"pass 2",
|
|
2564
|
+
"standalone utility",
|
|
2565
|
+
"context"
|
|
2566
|
+
]
|
|
2567
|
+
},
|
|
2568
|
+
{
|
|
2569
|
+
"name": "pass-3-scan",
|
|
2570
|
+
"hints": [
|
|
2571
|
+
"pass 3",
|
|
2572
|
+
"scannability",
|
|
2573
|
+
"labels",
|
|
2574
|
+
"chunking"
|
|
2575
|
+
]
|
|
2576
|
+
},
|
|
2577
|
+
{
|
|
2578
|
+
"name": "pass-4-accuracy",
|
|
2579
|
+
"hints": [
|
|
2580
|
+
"pass 4",
|
|
2581
|
+
"whole game",
|
|
2582
|
+
"fail-states",
|
|
2583
|
+
"martini glass"
|
|
2584
|
+
]
|
|
2585
|
+
},
|
|
2586
|
+
{
|
|
2587
|
+
"name": "pass-5-ai-readiness",
|
|
2588
|
+
"hints": [
|
|
2589
|
+
"pass 5",
|
|
2590
|
+
"references/ai-readiness-criteria.md",
|
|
2591
|
+
"llms.txt",
|
|
2592
|
+
"rag chunking",
|
|
2593
|
+
"dual-audience"
|
|
2594
|
+
]
|
|
2595
|
+
},
|
|
2596
|
+
{
|
|
2597
|
+
"name": "final-report",
|
|
2598
|
+
"hints": [
|
|
2599
|
+
"severity totals",
|
|
2600
|
+
"top findings",
|
|
2601
|
+
"verdict"
|
|
2602
|
+
]
|
|
2603
|
+
}
|
|
2604
|
+
],
|
|
2605
|
+
"references": [
|
|
2606
|
+
{
|
|
2607
|
+
"id": "ai-readiness-criteria",
|
|
2608
|
+
"path": "content/distilled/review-documentation/references/ai-readiness-criteria.md",
|
|
2609
|
+
"purpose": "deep-ai-readiness-checks",
|
|
2610
|
+
"stage": "pass-5-ai-readiness",
|
|
2611
|
+
"optional": false,
|
|
2612
|
+
"aliases": [
|
|
2613
|
+
"references/ai-readiness-criteria.md",
|
|
2614
|
+
"ai-readiness-criteria.md",
|
|
2615
|
+
"ai readiness criteria"
|
|
2616
|
+
]
|
|
2617
|
+
}
|
|
2618
|
+
]
|
|
2619
|
+
}
|
|
2271
2620
|
},
|
|
2272
2621
|
{
|
|
2273
2622
|
"name": "red-team-review",
|
|
@@ -3315,4 +3664,4 @@
|
|
|
3315
3664
|
]
|
|
3316
3665
|
}
|
|
3317
3666
|
}
|
|
3318
|
-
}
|
|
3667
|
+
}
|
package/package.json
CHANGED
|
@@ -14,18 +14,19 @@ tools: Read, Write, Edit, Glob, Bash
|
|
|
14
14
|
|
|
15
15
|
End the current session: log what was done, update tasks, route durable knowledge to `~/.whisper/`, commit and push, clear context.
|
|
16
16
|
|
|
17
|
-
Uses `$JOURNAL_PATH` (defaults to `~/dev/status`) for the daily log, and `~/.whisper/` for accumulated operational knowledge.
|
|
17
|
+
Uses `$JOURNAL_PATH` (defaults to `~/dev/status`) for the daily log journal, and `~/.whisper/` for accumulated operational knowledge. The log subdirectory defaults to `log/`; set `$JOURNAL_LOG_SUBDIR` to override (e.g. `areas/log` for the JORNAL layout).
|
|
18
18
|
|
|
19
19
|
## Steps
|
|
20
20
|
|
|
21
21
|
1. Pull the journal repo:
|
|
22
22
|
```bash
|
|
23
23
|
JOURNAL="${JOURNAL_PATH:-$HOME/dev/status}"
|
|
24
|
+
LOG_SUBDIR="${JOURNAL_LOG_SUBDIR:-log}"
|
|
24
25
|
cd "$JOURNAL" && git pull
|
|
25
26
|
```
|
|
26
27
|
|
|
27
28
|
2. Get today's date and time (`date +%Y-%m-%d`, `date +%H:%M`).
|
|
28
|
-
Derive the log path: `$JOURNAL/
|
|
29
|
+
Derive the log path: `$JOURNAL/$LOG_SUBDIR/YYYY/YYYY-MM/YYYY-MM-DD.md`
|
|
29
30
|
|
|
30
31
|
3. If the log file does not exist, create it with the daily log template.
|
|
31
32
|
|
|
@@ -8,67 +8,28 @@ metadata:
|
|
|
8
8
|
|
|
9
9
|
Write a high-signal documentation topic using the Unified Frameworks for Technical Information Architecture.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Core Rules
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
13
|
+
- Establish context and prerequisites in the first two sentences (EPPO).
|
|
14
|
+
- Lead with the answer or primary assertion in the TL;DR and first paragraph (Pyramid Principle).
|
|
15
|
+
- Use explicit, semantic block labels (descriptive headers) for every 2-3 paragraphs (Info Mapping).
|
|
16
|
+
- Provide a clear "fail-state" or troubleshooting section (Minimalism).
|
|
17
|
+
- Do not mix intents: no deep theory in a How-to. If theory is required, use a Note or Deep Dive sidebar to maintain quadrant purity.
|
|
18
|
+
- Do not use "Next" or "Previous" as the only navigational cues (EPPO).
|
|
19
19
|
|
|
20
|
-
##
|
|
20
|
+
## Procedure
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
1. Quadrant check: identify the Diátaxis quadrant and follow its rhetorical rules. Use `references/templates.md` for the matching template (Tutorial, How-to, Reference, or Explanation). Use `references/anti-patterns.md` to avoid common failures for that quadrant.
|
|
23
|
+
2. EPPO initialization: every topic must stand alone. Start with a clear task- or concept-focused title and a context block ("This topic covers [X]. You should already understand [Y] and have [Z] installed.").
|
|
24
|
+
3. Information mapping: chunk the body into units under 7 items; label headers by result or content (e.g., "Configuring the API" not "Configuration"); convert complex comparisons or steps into tables and lists.
|
|
25
|
+
4. AI-first polish: ensure headers are descriptive for RAG indexing and provide a 1-2 sentence TL;DR at the top for LLM ingestion.
|
|
26
|
+
5. If setting up a new docs site or choosing tooling, use `references/tooling-comparison.md` for platform selection and `references/versioning.md` for versioning and changelog strategy. For a full Diátaxis rollout, use `references/diataxis-implementation.md`.
|
|
23
27
|
|
|
24
|
-
|
|
25
|
-
- **Tutorial:** Action-oriented, safe environment. Use the **Martini Glass** narrative pattern: Author-driven stem (guided context) → Reader-driven bowl (open exploration).
|
|
26
|
-
- **How-to:** Task-focused, assumes baseline competence, minimal theory.
|
|
27
|
-
- **Reference:** Fact-based, scannable tables, no narrative filler.
|
|
28
|
-
- **Explanation:** Theoretical, discusses "Why," maps concepts.
|
|
28
|
+
## Rules
|
|
29
29
|
|
|
30
|
-
|
|
30
|
+
- The canonical theory lives in `content/research-documentation-frameworks.md`; the references here are operational excerpts that link back to it.
|
|
31
31
|
|
|
32
|
-
|
|
33
|
-
- **Title:** Clear, task- or concept-focused.
|
|
34
|
-
- **Context Block:** "This topic covers [X]. You should already understand [Y] and have [Z] installed."
|
|
32
|
+
## Related Skills
|
|
35
33
|
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
Structure the body content:
|
|
39
|
-
- **Chunking:** Break large blocks into units of <7 items.
|
|
40
|
-
- **Labeling:** Use headers that describe the *result* or *content* (e.g., "Configuring the API" not just "Configuration").
|
|
41
|
-
- **Tables/Lists:** Convert complex comparisons or steps into visual structures.
|
|
42
|
-
|
|
43
|
-
### Step 4: AI-First Polish
|
|
44
|
-
|
|
45
|
-
- **Semantic Headers:** Ensure headers are descriptive for RAG indexing.
|
|
46
|
-
- **Compressed Summary:** Provide a 1-2 sentence "tl;dr" at the top for LLM ingestion.
|
|
47
|
-
|
|
48
|
-
## Template (How-to Guide)
|
|
49
|
-
|
|
50
|
-
```markdown
|
|
51
|
-
# [Task-Focused Title]
|
|
52
|
-
|
|
53
|
-
**TL;DR:** [1-sentence summary for human/AI]
|
|
54
|
-
|
|
55
|
-
## Context & Prerequisites
|
|
56
|
-
This guide explains how to [Goal]. Before starting, ensure you have:
|
|
57
|
-
- [Prerequisite 1]
|
|
58
|
-
- [Prerequisite 2]
|
|
59
|
-
|
|
60
|
-
## [Action Step 1: Specific Result]
|
|
61
|
-
[Chunked instructions]
|
|
62
|
-
|
|
63
|
-
## [Action Step 2: Specific Result]
|
|
64
|
-
[Chunked instructions]
|
|
65
|
-
|
|
66
|
-
## Troubleshooting: Common Fail-States
|
|
67
|
-
| Symptom | Cause | Fix |
|
|
68
|
-
| :--- | :--- | :--- |
|
|
69
|
-
| [Error] | [Reason] | [Solution] |
|
|
70
|
-
|
|
71
|
-
## Further Exploration
|
|
72
|
-
- [Lateral Link 1] (Subject affinity)
|
|
73
|
-
- [Lateral Link 2] (Subject affinity)
|
|
74
|
-
```
|
|
34
|
+
- `research-documentation` — audit before writing.
|
|
35
|
+
- `review-documentation` — review after writing.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# Documentation Anti-Patterns
|
|
2
|
+
|
|
3
|
+
Avoid these during Step 1 (quadrant check) and throughout writing. Source: `content/research-finding-library-docs-best-practices.md` (Section 1, Common Mistakes and Anti-Patterns).
|
|
4
|
+
|
|
5
|
+
## Leading with explanation instead of action
|
|
6
|
+
|
|
7
|
+
The engineer's impulse is to explain how a system works before showing how to use it. This is backwards for most users. Quickstart then how-to then reference is the ramp-up order. Fix: in Tutorials and How-tos, lead with a runnable result; move "how it works" to Explanation.
|
|
8
|
+
|
|
9
|
+
## One stream of text serving as THE DOCS
|
|
10
|
+
|
|
11
|
+
A single document trying to teach beginners, guide intermediate users, and serve as expert reference serves none of them. Fix: split by Diátaxis quadrant; each page has one intent.
|
|
12
|
+
|
|
13
|
+
## FAQ lists as an anti-pattern
|
|
14
|
+
|
|
15
|
+
An FAQ is "the box in the garage where you put things when you can't be bothered to put them in the right place." If information is in the right Diátaxis quadrant, it does not need repeating in an FAQ. Fix: place each answer where it belongs; delete the FAQ or keep only genuinely miscellaneous items.
|
|
16
|
+
|
|
17
|
+
## The curse of knowledge
|
|
18
|
+
|
|
19
|
+
Experts forget what it was like not to know. They skip "obvious" steps, use undefined jargon, assume context beginners lack. Fix: in Tutorials, state every prerequisite; define jargon on first use; have a non-expert read it.
|
|
20
|
+
|
|
21
|
+
## Stale documentation
|
|
22
|
+
|
|
23
|
+
Docs not embedded in the development workflow drift from the code. Incorrect docs are worse than missing docs — they waste time and erode trust. Fix: docs-as-code, docs-updated checkboxes in PRs, "you touch it, you document it."
|
|
24
|
+
|
|
25
|
+
## Knowledge silos
|
|
26
|
+
|
|
27
|
+
Scattered docs across wikis, READMEs, Confluence, Notion create a fragmented experience where users cannot find things and contributors do not know where to put new content. Fix: one canonical location, ideally in the same repo as the code.
|
|
28
|
+
|
|
29
|
+
## Partial coverage
|
|
30
|
+
|
|
31
|
+
Documenting some but not all of a feature or API creates a false sense of completeness — users assume the undocumented part does not exist or work. Fix: cover a concept fully or not at all; use the completeness checklist (in the `research-documentation` skill's `references/checklist.md`).
|
|
32
|
+
|
|
33
|
+
## Mixed-intent "Frankenbooks"
|
|
34
|
+
|
|
35
|
+
A page that starts as a tutorial, becomes reference, and ends as explanation. Fix: split into three focused pages; each keeps quadrant purity. Use a Note or Deep Dive sidebar only when a sliver of theory is required inside a task page.
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Diátaxis Implementation Guide
|
|
2
|
+
|
|
3
|
+
Six-step rollout for adopting Diátaxis on an existing or new documentation set. Use in Step 5 when the task is a full architecture rollout rather than a single topic. The Diátaxis framework theory is canonical in `content/research-documentation-frameworks.md`; these implementation steps are sourced from `content/research-finding-library-docs-best-practices.md` (Section 3, How to Implement Diátaxis in Practice).
|
|
4
|
+
|
|
5
|
+
## Step 1: Audit existing documentation
|
|
6
|
+
|
|
7
|
+
Catalog every existing document and classify it as Tutorial, How-to, Reference, or Explanation. The audit typically reveals that most docs are reference, with gaps in tutorials and explanation. (Use the `research-documentation` skill for this.)
|
|
8
|
+
|
|
9
|
+
## Step 2: Create a directory structure
|
|
10
|
+
|
|
11
|
+
Create four directories or sections: `tutorials/`, `how-to/` (or `guides/`), `reference/`, and `explanation/`. Apply title conventions per type: Explanation titles use "Understanding / Dive into / Introduction to..."; How-to titles start with "How to..."; Tutorial titles use "Getting started with...".
|
|
12
|
+
|
|
13
|
+
## Step 3: Assign content types and split mixed documents
|
|
14
|
+
|
|
15
|
+
Long mixed-topic documents become multiple short, focused documents. A document that is tutorial then reference then explanation becomes three separate documents, each in its quadrant directory.
|
|
16
|
+
|
|
17
|
+
## Step 4: Establish contribution guidelines
|
|
18
|
+
|
|
19
|
+
Document the framework for contributors so new docs land in the right place from the start. Without guidelines the four-directory structure fills with misclassified content. Keep the guidelines short: one sentence per quadrant on what belongs there.
|
|
20
|
+
|
|
21
|
+
## Step 5: Integrate with the development workflow
|
|
22
|
+
|
|
23
|
+
Add architecture specs to Reference alongside code changes. Add technical decision logs to Explanation during feature development. Docs-updated checkboxes in PR templates. This integration is what keeps docs current.
|
|
24
|
+
|
|
25
|
+
## Step 6: Use Diátaxis as an AI prompt template
|
|
26
|
+
|
|
27
|
+
The clear information patterns make effective AI prompt templates: ask a model to sort unstructured content into the four patterns to accelerate a first draft, then review and refine. (See `templates.md` for the per-quadrant output shapes.)
|
|
28
|
+
|
|
29
|
+
## Critiques to keep in mind
|
|
30
|
+
|
|
31
|
+
Diátaxis is a guide, not dogma. Forcing every artifact into four rigid buckets produces awkward docs. The terms overlap (tutorial vs. how-to needs editorial judgment). The framework does not address content reuse (DITA's conref may suit enterprise multi-output needs) nor finding aids. For early-stage projects, a single compelling quick start may suffice before the full suite.
|