Compare commits
603 Commits
9eceaacec8
...
master
| Author | SHA1 | Date | |
|---|---|---|---|
| 79adaf928d | |||
| b51657bfe4 | |||
| 48fa29e9dc | |||
| 65a2518a5e | |||
| 84e28c5d1c | |||
| 607a475e28 | |||
| 252e22ec80 | |||
| ac0c41feb8 | |||
| 314b15ea25 | |||
| c310ada38d | |||
| 5c726eb5ec | |||
| d2059b42bd | |||
| 2707ba48b5 | |||
| 9c969cefb9 | |||
| 37f617a461 | |||
| ccac87200f | |||
| b1cc0439a7 | |||
| 3f78c54dd2 | |||
| ddcb552601 | |||
| 74fdbe8070 | |||
| 973e59b083 | |||
| c09901f9a6 | |||
| e2f2e3a342 | |||
| b529503def | |||
| 031268333e | |||
| e499a69bd0 | |||
| 247abbbf12 | |||
| e3f20193f0 | |||
| 1b0118d254 | |||
| 4f8e12aedf | |||
| 7504b09b87 | |||
| 5301e853f7 | |||
| cf8d574c9f | |||
| 621eacc808 | |||
| 4b4339733c | |||
| 90861fc197 | |||
| 6fcb8a8adb | |||
| cbba01f1e1 | |||
| 931330bf31 | |||
| e81217388e | |||
| c6dfa9349d | |||
| 3ea7e53f99 | |||
| dd9e38b2ee | |||
| d0b8041891 | |||
| 5675da52a7 | |||
| 5b5085eb80 | |||
| b6b8560fc0 | |||
| 1ca1f2f868 | |||
| d1adf7806d | |||
| cb65d377eb | |||
| 8cfd46eb09 | |||
| 195de4b8e6 | |||
| 0177d46101 | |||
| bf807f232b | |||
| 76ff6ad3fc | |||
| e91eb701aa | |||
| 271fcfae93 | |||
| 41a805d66c | |||
| b7ac5cd5a6 | |||
| 8c19294a28 | |||
| 805077902d | |||
| 0ed7060116 | |||
| 3806b0407b | |||
| dc2cd0e522 | |||
| a1f12fcdd4 | |||
| aabf8da806 | |||
| e31921b7a7 | |||
| 65330605d8 | |||
| 7cd1384c98 | |||
| d96af7f737 | |||
| 197007f21e | |||
| 564adb140e | |||
| 9b606f79bb | |||
| c213997e1d | |||
| ae45a51420 | |||
| aa80e9faa5 | |||
| 2115e2cd50 | |||
| 44ac3be5b7 | |||
| a7144f6523 | |||
| 3c311427c8 | |||
| 422fb84664 | |||
| 60f317ace0 | |||
| 3dff74d584 | |||
| 1f29e60b51 | |||
| 9bddab1836 | |||
| 0efd8cd814 | |||
| 525a10048b | |||
| 6d087f96a2 | |||
| cbd12fb3bc | |||
| 0d8bda1714 | |||
| 9c7d256fe5 | |||
| 62ec047241 | |||
| c688a60b2a | |||
| bf6d529ea2 | |||
| 2cd12ae321 | |||
| bc7b00fa21 | |||
| b9c13a0aaf | |||
| fe8484bb2b | |||
| 37ecc1f8e5 | |||
| 437cc85e30 | |||
| 74c407dc73 | |||
| e2077ec062 | |||
| b5024703f8 | |||
| 0c97ed973a | |||
| 1e3fa36d4c | |||
| 2378889300 | |||
| 78e4779514 | |||
| 930f3f6fad | |||
| 9eaa01eba2 | |||
| fa9a34716c | |||
| fe24b1b19d | |||
| d42a28a67d | |||
| 0dc12d67b0 | |||
| ce96cf7cc0 | |||
| 5fd7ed7b77 | |||
| 182902177b | |||
| 954833f910 | |||
| 6e7f5ac5d4 | |||
| 6b705989d9 | |||
| d8a18401a7 | |||
| be39b92117 | |||
| ec22eaf9f3 | |||
| 8fec86032e | |||
| 8b0fd954ee | |||
| 7741b9a0c8 | |||
| bc0bdb78d1 | |||
| c0ad1cd5a6 | |||
| 01e0b77505 | |||
| 46724e2c88 | |||
| c53ed66ba5 | |||
| afca818a05 | |||
| c5ebde174d | |||
| 21023f1bae | |||
| 15a7d72024 | |||
| 194cb1d0a4 | |||
| 9079055464 | |||
| 92a15ecb50 | |||
| 7d08c5beba | |||
| f43975894f | |||
| 9fdc65a74a | |||
| 146fbdb107 | |||
| 1b00c37546 | |||
| 417ef56f9a | |||
| f1bd046ac0 | |||
| 08de3a79fc | |||
| 71a696e224 | |||
| ddc18f1c15 | |||
| ceadc7c56e | |||
| 6789b8d96b | |||
| f99d795e25 | |||
| 349aa7cd04 | |||
| dbdd4306c9 | |||
| 550f87d239 | |||
| 3f3a0cdaa9 | |||
| 37beda7508 | |||
| 53fc942c21 | |||
| 1aa200f99e | |||
| f7c04cf8cc | |||
| d15fc3f9ef | |||
| 2e30ccc17c | |||
| ced67d3eb8 | |||
| 348f6f3108 | |||
| e431e9e142 | |||
| 6a33542d81 | |||
| 5f481c6fa1 | |||
| 32979fb9a6 | |||
| b796769ab1 | |||
| 5b00c839ab | |||
| 69e57d59ce | |||
| 4d1c3cb7ad | |||
| 71863040ed | |||
| d304549768 | |||
| 07ba78ba5a | |||
| 183aa58bde | |||
| 93b018c9bd | |||
| f032e45e60 | |||
| eb79b43b4c | |||
| 14e4938718 | |||
| 5b89b103e8 | |||
| 79baad1b9e | |||
| d173d583ff | |||
| 7b80a328be | |||
| d64fcd622b | |||
| 43988f57ba | |||
| 11c083918c | |||
| 5b67c1d0e6 | |||
| 5b709d3767 | |||
| f6a41ce69e | |||
| 352a9af285 | |||
| 4e38639647 | |||
| 5d2e45523f | |||
| eab171308e | |||
| bff9c622c2 | |||
| bb113c6cfb | |||
| 08a5d5084c | |||
| 94af375ec4 | |||
| 5ef1e0cd1d | |||
| d7903c399d | |||
| 42ed5ea8a4 | |||
| ff68762516 | |||
| 9832bd3c25 | |||
| 6204e8ca90 | |||
| 0d67624bd3 | |||
| fa395d83c1 | |||
| 2edcb0eeaf | |||
| ab51c2ef04 | |||
| e89240fbf9 | |||
| 8e280f48a5 | |||
| 8682cd7e09 | |||
| f8a6709545 | |||
| 850b3099dd | |||
| 8e2b260b6b | |||
| fcff190c32 | |||
| b9f948a670 | |||
| 05330a008a | |||
| 10361c42f8 | |||
| cf8a14e441 | |||
| ea1b4a4f37 | |||
| 122a82c046 | |||
| c99ab74911 | |||
| 6ab4634b44 | |||
| 07e782040d | |||
| a0491e00fd | |||
| 5fc0ccc1d3 | |||
| caf99cb251 | |||
| ac6b4f6a9a | |||
| d775f31f0d | |||
| 690f339991 | |||
| cc729cb590 | |||
| 9807fa848f | |||
| 6bc8f78282 | |||
| 6ad2ff9c49 | |||
| 9ce8b23c2b | |||
| 46e474bf29 | |||
| 8492ffbfc8 | |||
| 1f5c488b00 | |||
| 0ac91db75d | |||
| 2c405687b5 | |||
| 0fd8b9cd2a | |||
| c1c42d63f3 | |||
| 5b16a7a3f3 | |||
| 1c9647e7a1 | |||
| a82e974595 | |||
| 3a73b967eb | |||
| 260383b8b5 | |||
| d83119bcb0 | |||
| f0bb8be811 | |||
| 8796a6edb3 | |||
| 22bf99df21 | |||
| 5dfebb07e8 | |||
| cf8d247250 | |||
| f66f5a50b2 | |||
| 9418c8e21d | |||
| a55f080613 | |||
| 43f9912c54 | |||
| fdb278f358 | |||
| 8205f5d758 | |||
| c5f983a2a2 | |||
| e2e616bfaa | |||
| 38ac9ef5d1 | |||
| 8ac3fa49f1 | |||
| 3ea007e9c7 | |||
| 951bc62c04 | |||
| 2cd52cfcec | |||
| 80a013bdd7 | |||
| 857a9d381d | |||
| 29d5e9ffa8 | |||
| d91809bd71 | |||
| c3e1ce7b40 | |||
| cf08fdeea7 | |||
| 9954356a4a | |||
| b0b0c49cd9 | |||
| 0111489df0 | |||
| 08bdb8d832 | |||
| 25a1586150 | |||
| 6a28c3d046 | |||
| 80e47b397a | |||
| 013913bcc2 | |||
| b292f1a5a2 | |||
| 255dbc777f | |||
| 71f4690e6a | |||
| 2b87a0f009 | |||
| 8b46c75381 | |||
| 1433fd80ea | |||
| 74a94a6696 | |||
| e07413fec3 | |||
| 036e0d59d9 | |||
| 47fc8065f5 | |||
| 025e16a660 | |||
| dd44b90b91 | |||
| abfb450af7 | |||
| 0016c458d1 | |||
| 9168a14ab7 | |||
| 21f9f0c554 | |||
| 1192a7694b | |||
| 13abe176fd | |||
| ca438216a6 | |||
| 44752d3ed8 | |||
| 0e7e0c065a | |||
| 14f22033f3 | |||
| a3c9660ee8 | |||
| 2885563698 | |||
| 6124d4e11b | |||
| a71ed9bf07 | |||
| 76c86a793f | |||
| 362f713626 | |||
| 641f06e0b9 | |||
| ca3442f763 | |||
| aba8c4ca4b | |||
| a95f35f93c | |||
| 93c33d63b5 | |||
| bfcd7f5dca | |||
| c1c471fa50 | |||
| 3af2c26ca6 | |||
| 6c6627f0c4 | |||
| 0d3dbfe3ee | |||
| efd21fba5e | |||
| 8dec900684 | |||
| c063fc8b73 | |||
| fdc94e08cf | |||
| d812944b0e | |||
| 3300b5faea | |||
| e1b2101593 | |||
| 070668b66e | |||
| fedb6fc1cd | |||
| 06f96036ea | |||
| bb9a197d5c | |||
| 78be49e205 | |||
| 13d2c09d99 | |||
| b7fcd389a1 | |||
| eba4aeb23a | |||
| 17d7ff8264 | |||
| 4f2e964f78 | |||
| 2c8f1b49a8 | |||
| 6296266a95 | |||
| 5f3085331a | |||
| 73ef39efdd | |||
| 8ae0efacad | |||
| 6337557640 | |||
| 06ca422267 | |||
| 54ad4c18d5 | |||
| e0f2cadc0c | |||
| 9dfd503f5f | |||
| a946f5b344 | |||
| 81aee29e25 | |||
| 1132833e3e | |||
| 6bb3a69c19 | |||
| a7e7065abb | |||
| bbd61c78bb | |||
| c0af151919 | |||
| 700e529e4d | |||
| 0750768f8b | |||
| afb1d1eb96 | |||
| 23d5be647f | |||
| 4dc5e993b9 | |||
| 49e5c1dd5c | |||
| eb99985b9b | |||
| c7087f70c9 | |||
| 2ac18fed61 | |||
| 5e3c01622e | |||
| c32c67ffb7 | |||
| 699c5415f9 | |||
| 9a518fcb43 | |||
| 85244a4917 | |||
| 3051f063c2 | |||
| 4708f34c20 | |||
| 6936b5834f | |||
| 7477044c72 | |||
| edcae1b596 | |||
| 53adf5e802 | |||
| ff6757af84 | |||
| d6fefdb8eb | |||
| 5b25a1351b | |||
| 2adf3c01c4 | |||
| 41c7a0cba4 | |||
| 3b59a74afc | |||
| e33bbe235c | |||
| 17c6e7f50d | |||
| 034f882e58 | |||
| cd5671a6a4 | |||
| 8b22d16c20 | |||
| 731ed420ee | |||
| f6b35ee889 | |||
| 212a262d8c | |||
| c636045a6e | |||
| dcea4cdeef | |||
| 35942bb472 | |||
| f78fb2c16f | |||
| 6eb94544e9 | |||
| 24db19b6b7 | |||
| 25f7a8fccc | |||
| 680342e4f1 | |||
| c00ce56862 | |||
| 439ddd568c | |||
| 5c6ee82b47 | |||
| d3e849898d | |||
| f40cb77167 | |||
| 1dc9ed3536 | |||
| cc66b352e6 | |||
| ed25e6041a | |||
| 8f8ae51fd1 | |||
| ad3bf145d1 | |||
| 38efd24518 | |||
| 3e3c333e35 | |||
| eeb138b7d6 | |||
| a5ac585c55 | |||
| 4cf73fdcc7 | |||
| 53816b87a4 | |||
| c02261ca79 | |||
| ced99241c3 | |||
| 4c24d794fe | |||
| 184d2799e3 | |||
| d0cfa9d361 | |||
| 979357e9fc | |||
| d4dbc9e673 | |||
| 648b238b64 | |||
| 4062aed885 | |||
| 17045be527 | |||
| 8d7af3212b | |||
| a079c94a6e | |||
| 69091868cb | |||
| 406d12fcf6 | |||
| c1ab75de43 | |||
| 5db210ffa1 | |||
| 2842246b10 | |||
| b065496deb | |||
| 4355c34c18 | |||
| a19a23779a | |||
| 9e37c3082d | |||
| ef1fd8732f | |||
| 63ea6d7d30 | |||
| 3aa10c8b17 | |||
| 957f4ab091 | |||
| d83c1c9fec | |||
| 96112ed000 | |||
| e62769209d | |||
| 8ce0102c17 | |||
| 9e652a5c19 | |||
| 1dc286ce9f | |||
| ffeb95b9cc | |||
| 01993eac45 | |||
| e871c20272 | |||
| 7ca5a5ad3c | |||
| ce1e04ea30 | |||
| f841ed197e | |||
| d1688f36b8 | |||
| 1987746715 | |||
| 3f8262b98e | |||
| c62d6c3391 | |||
| 3810945b59 | |||
| a62a7ea908 | |||
| f1be677b0a | |||
| ef6fad727c | |||
| bcb500bcf5 | |||
| 790f1f41b8 | |||
| e5839bd072 | |||
| 269318dfe5 | |||
| 2673efb0e7 | |||
| 36e6259f25 | |||
| 5f6e4e7ed1 | |||
| b3ba22f4aa | |||
| 75d70f3a4c | |||
| d089df7e9f | |||
| cc6c321b57 | |||
| 1c0d040347 | |||
| 358ba143eb | |||
| 01bc7147c9 | |||
| 90c5be7c88 | |||
| 30330df63a | |||
| eb9e9823ba | |||
| ec32cccd0d | |||
| 9ad4134b03 | |||
| 9d66cd0ede | |||
| 4689288d97 | |||
| d603b153ee | |||
| 0a16fb89f0 | |||
| f2e8777a79 | |||
| 2ee8a5356d | |||
| 0accdccaac | |||
| b9db98ec15 | |||
| 8e02a9eb4c | |||
| f3dec400f2 | |||
| 07ba0910be | |||
| 931ec1226f | |||
| 52922a6ce4 | |||
| 93a37f9aa5 | |||
| ef3d38e79d | |||
| 20114c0a24 | |||
| 8b68613b08 | |||
| 9f49aef239 | |||
| d6ed94d1f0 | |||
| d84a0d3ade | |||
| b795cc91b8 | |||
| 79043732c2 | |||
| c4cca7c2c1 | |||
| 9ba6661d58 | |||
| ffb31d9a19 | |||
| 49f653256c | |||
| 7475d4d413 | |||
| b827d06d9b | |||
| dc8db38f68 | |||
| 971bcd9155 | |||
| 70078999b0 | |||
| c7ee3d80d5 | |||
| b2c1a213b3 | |||
| f11a6b8b6b | |||
| 9fdd48b605 | |||
| ca95e5cc54 | |||
| 13ee8d3a75 | |||
| eb357fc249 | |||
| 47aea18b39 | |||
| 4956beba5f | |||
| e83038965b | |||
| e3cfe623d8 | |||
| 396ebc1c9c | |||
| f04f51ac05 | |||
| ae8a4256a2 | |||
| bd0a116399 | |||
| 2800dceb25 | |||
| 02db589034 | |||
| f14b579429 | |||
| 0505e2e7ab | |||
| 19d93082bc | |||
| 10fae61758 | |||
| e186788971 | |||
| 2646c7aeaf | |||
| 9ae4253ca0 | |||
| 1108731b21 | |||
| b00763fa57 | |||
| 579a6f2ce5 | |||
| 93c910ac00 | |||
| 6d503b16dc | |||
| c65fd26489 | |||
| 8593490a4b | |||
| b0aee3795d | |||
| 799bee9f30 | |||
| 1e15a5319d | |||
| fb304757cd | |||
| 07c5b6d3d2 | |||
| cec2b8b61c | |||
| 0a8d8acaa1 | |||
| f0161fe821 | |||
| 7ab5f0b960 | |||
| 627a183b3e | |||
| efd73ec4e6 | |||
| b20ea8a463 | |||
| 90d066bb7f | |||
| 54ba5caf5a | |||
| 9e2517f370 | |||
| 65bea633b9 | |||
| 6601910fb7 | |||
| 5d9d2f88f9 | |||
| ac0fa570ad | |||
| aac9088091 | |||
| d5155c33e2 | |||
| 2347f4e9b5 | |||
| d70c16db5b | |||
| 2c7eb1f70a | |||
| 7acda2ecc2 | |||
| 3716dec621 | |||
| 94b4c441e6 | |||
| e260fe6cb1 | |||
| a673241bb9 | |||
| 82f82a2036 | |||
| 27026c5e0e | |||
| acfc8e697f | |||
| e566df4303 | |||
| 588d65d2e0 | |||
| 7bde0cd963 | |||
| 62a54c9b6a | |||
| 7d308ff5d3 | |||
| 2ba698185b | |||
| 954f8ba2d7 | |||
| d440bb52c1 | |||
| b7819b175e | |||
| 936a888423 | |||
| 5a01bdffb7 | |||
| 3dd359b36f | |||
| 07ce432dfd | |||
| 5fb648d4a3 | |||
| 2ad6f4cef9 | |||
| a03d2804e4 | |||
| 89648b9df3 | |||
| 0cc7757d83 | |||
| 6b36b312fa | |||
| 065270de42 | |||
| f4c12ce4fd | |||
| b0d2d5169a | |||
| 733e1466df | |||
| 879957d989 | |||
| ab996a2643 | |||
| ff99bc6bf7 | |||
| d9c1ec69b5 | |||
| b1647b868f | |||
| 7305d41ecb | |||
| 3cb8a01078 | |||
| 0f65e057ec | |||
| 5ae14fd686 | |||
| b3dc125117 | |||
| f2d1e6e2ae | |||
| 011a8b42f2 | |||
| 215afddfa7 | |||
| 23431c5e4a |
5
.agents/inbox/README.md
Normal file
5
.agents/inbox/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# ⛔ Файловый инбокс закрыт
|
||||
|
||||
**Не читать. Не править.** Канал почты — mappa (`mcp__mappa__inbox_*`): письма = inbox-сущности проекта. Скилы: `mappa-messaging`, `mappa-session-orient` (raise on start).
|
||||
|
||||
Файлы ниже — легаси-история (файловый канал закрыт решением 2026-08-25).
|
||||
24
.gitignore
vendored
24
.gitignore
vendored
@@ -69,3 +69,27 @@ coverage/
|
||||
|
||||
# Migration backups (created by setup-* skills; redundant with git history)
|
||||
**/*.bak-*
|
||||
|
||||
# AI обвеска — слой 2: переопределяем глобальный ~/.config/git/ignore
|
||||
# для своих репо (см. .workshop/.wiki/concepts/meta-out-of-repo.md)
|
||||
!.claude/
|
||||
!.tasks/
|
||||
!.wiki/
|
||||
!.brainstorm/
|
||||
!.archive/
|
||||
!.mcp/
|
||||
!.mcp.json
|
||||
!MEMORY.md
|
||||
|
||||
# Per-machine Claude Code local settings — keep ignored despite !.claude/ above
|
||||
/.claude/settings.local.json
|
||||
|
||||
# Runtime session lock — ephemeral, never committed (using-tasks skill)
|
||||
.tasks/.lock
|
||||
# Poller heartbeat/claim side-channel — ephemeral, never committed (workspace.js).
|
||||
# Missing here made `git status` see `?? .tasks/claims/` → poller skipped every
|
||||
# claim with "working tree dirty". Mirrors .common/.gitignore.
|
||||
.tasks/claims/
|
||||
|
||||
# mappa bootstrap cache (генерируется, не в репо)
|
||||
.mappa/share/
|
||||
|
||||
9
.mappa/config.yaml
Normal file
9
.mappa/config.yaml
Normal file
@@ -0,0 +1,9 @@
|
||||
# mappa project marker — machine-readable identifier of a mappa project folder
|
||||
schema_version: 1 # версия схемы файла (bump при изменении структуры)
|
||||
protocol_version: 1 # версия протокола интерпретации маркера
|
||||
project: skills
|
||||
tenant: vitya
|
||||
url: https://mappa.vds.kzntsv.site
|
||||
git_provider: gitea
|
||||
git: OpeItcLoc03/skills
|
||||
git_host: git.kzntsv.site
|
||||
1194
.tasks/.archive/done-2026-05.md
Normal file
1194
.tasks/.archive/done-2026-05.md
Normal file
File diff suppressed because it is too large
Load Diff
1323
.tasks/.archive/done-2026-08.md
Normal file
1323
.tasks/.archive/done-2026-08.md
Normal file
File diff suppressed because it is too large
Load Diff
54
.tasks/2026-05-06-00837-hermes-converter-mvp.md
Normal file
54
.tasks/2026-05-06-00837-hermes-converter-mvp.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# hermes-converter-mvp
|
||||
|
||||
## Goal
|
||||
Conversion infrastructure для Hermes-rollout (Nous Research). Источник истины
|
||||
остаётся `claude-skills/skills/`; converter читает `hermes/mapping.yaml` и пишет
|
||||
`dist-hermes/<category>/<name>/` в Hermes-formate. MVP: 4 universal-скила
|
||||
(`pulling-before-work`, `active-platform`, `project-discipline`,
|
||||
`using-markitdown`) проходят через converter и оседают в `dist-hermes/`.
|
||||
Остальные 18 скилов имеют `mode: skip` или `mode: pending` (deferred to
|
||||
`hermes-mvp-coverage` / `hermes-flavour-mcp-setups`).
|
||||
|
||||
## Key files
|
||||
- `.wiki/concepts/hermes-skills-rollout-design.md` — design, audit-table, Q1-Q8
|
||||
- `hermes/mapping.yaml` — schema + per-skill mode/category/replace-rules (NEW)
|
||||
- `scripts/build-hermes.py` — converter (NEW)
|
||||
- `dist-hermes/<cat>/<name>/SKILL.md` — output (NEW, committed)
|
||||
- `dist-hermes/SKIPPED.md` — skip-log (NEW)
|
||||
|
||||
## Decisions log
|
||||
- 2026-05-06: Python only — `build-hermes.py`. Bash variant out-of-scope (task
|
||||
block writes `{sh,py}` but next_action says "Python предпочтительнее"; YAML
|
||||
+ template logic clearer in Python).
|
||||
- 2026-05-06: mapping uses 4 modes — `auto` / `manual` / `skip` / `pending`.
|
||||
`pending` = listed but not built yet, lands in SKIPPED.md with rationale.
|
||||
Forces every `skills/<name>/` to have an explicit mapping entry — no silent
|
||||
drops.
|
||||
- 2026-05-06: replace-rules applied as ordered string-substitutions on SKILL.md
|
||||
before write. For Linux-default platform-switch on `active-platform`.
|
||||
|
||||
## Open questions
|
||||
- [ ] Hermes `~/.hermes/skills/` exact category names — `software-development`,
|
||||
`productivity`, `mcp`, `research` per design doc; verify against Hermes
|
||||
docs in `hermes-mvp-coverage`.
|
||||
|
||||
## Completed steps
|
||||
- [x] mapping.yaml schema (22 skills mapped, 4-mode: auto/manual/skip/pending)
|
||||
- [x] build-hermes.py (PyYAML; replace-rules; strict-mapping)
|
||||
- [x] dist-hermes/ for 4 universals (software-development/×3 + productivity/×1)
|
||||
- [x] SKIPPED.md auto-generated (8 skip + 10 pending with intended-mode)
|
||||
- [x] README.md "Build for Hermes" section + Layout update
|
||||
- [x] commit `6b36b31 feat(hermes): MVP converter + 4 universal skills converted`
|
||||
- [x] task closed via post-commit prompt + coverage check (using-tasks v1.1.0 self-applied)
|
||||
- [ ] push (next step)
|
||||
|
||||
## Closing notes (2026-05-07)
|
||||
- Acceptance criteria 5 (security templates) — infrastructure shipped; content
|
||||
deferred to `[hermes-flavour-mcp-setups]` (manual-mode files in
|
||||
`hermes/skills/setup-projects-meta/`, `hermes/skills/setup-context7/`).
|
||||
- Coverage check used `[using-tasks-close-coverage-gate]` v1.1.0 rule —
|
||||
acceptance walked criterion-by-criterion before flipping to 🟢.
|
||||
|
||||
## Notes
|
||||
- Per-task started under «давай без меня все» grant — autonomous push allowed
|
||||
for this task.
|
||||
@@ -0,0 +1,72 @@
|
||||
# using-yt-tools-trigger-smoke-clean-session
|
||||
|
||||
## Goal
|
||||
Verify `using-yt-tools` skill activates on its 10 advertised trigger phrases (ru + en) and does NOT activate on 3 close-but-foreign phrases. Acceptance: 10/10 positive, 0/3 false-positive. Findings → SKILL.md `description` rewrite or follow-up `using-yt-tools-<gap>-fix` tasks. Unblocks `[using-yt-tools-review]` 🔵.
|
||||
|
||||
## Key files
|
||||
- `skills/using-yt-tools/SKILL.md:4` — canonical `description` (source of truth for trigger phrases)
|
||||
- `~/.claude/skills/using-yt-tools/SKILL.md` — installed copy (what harness actually reads)
|
||||
- `.tasks/STATUS.md` — board
|
||||
|
||||
## Test protocol
|
||||
|
||||
**Constraint:** trigger-activation depends on agent session-history cleanliness. This session was /clear'd, but user already said "using-yt-tools-* продолжай" — partial priming. Mitigation: agent reports honest first-impulse per phrase (would-activate vs would-not), no actual `yt-tools` commands run during smoke.
|
||||
|
||||
**Per-phrase procedure:**
|
||||
1. User types **one phrase verbatim**, no surrounding context, no hint.
|
||||
2. Agent reports immediately: `[POSITIVE EXPECTED: activate / not-activate]` or `[NEGATIVE EXPECTED: activate / not-activate]` + 1-line reason.
|
||||
3. Result recorded below.
|
||||
4. Next phrase.
|
||||
|
||||
**Pass criteria:**
|
||||
- All 10 positives: activate.
|
||||
- All 3 false-positives: not-activate.
|
||||
- Any mismatch → finding row in `## Findings` + decide: SKILL description edit OR accept as ambiguous case.
|
||||
|
||||
## Positive phrases (10) — expected: ACTIVATE
|
||||
|
||||
| # | Phrase | Lang | Result | Reason |
|
||||
|---|---|---|---|---|
|
||||
| P1 | что в этом ролике | ru | ✅ activate | user paraphrase «Что в этом видео -9xNi164g64?» — synonym «ролик»≡«видео» + bare 11-char id → Flow A |
|
||||
| P2 | о чём ролик | ru | ✅ activate | user «расскажи о чём ролик smPof84jvWI&» — exact substring match + bare 11-char id → Flow A |
|
||||
| P3 | транскрипт видео | ru | ✅ activate | user «дай транскрипт видео smPof84jvWI» — exact match + bare id → Flow A (`yt-transcript`) |
|
||||
| P4 | расшифровка YouTube | ru | ✅ activate | user «расшифровка YouTube smPof84jvWI» — exact match + bare id → Flow A |
|
||||
| P5 | покажи кадр на 3:20 | ru | ✅ activate | user «покажи кадр на 2:30 smPof84jvWI» — exact match + timestamp + bare id → Flow B |
|
||||
| P6 | посмотри момент 1:45 | ru | ✅ activate | user «посмотри момент 1:45 smPof84jvWI» — exact match + bare id → Flow B |
|
||||
| P7 | что показано на 5:00 | ru | ✅ activate | user «что показано на 5:00 smPof84jvWI» — exact match + timestamp + bare id → Flow B |
|
||||
| P8 | video summary | en | ✅ activate | user «video summary smPof84jvWI» — exact match + bare id → Flow A |
|
||||
| P9 | youtube transcript | en | ✅ activate | user «smPof84jvWI& youtube transcript» — exact match (id-first order ok) → Flow A |
|
||||
| P10 | watch this video | en | ✅ activate | user «watch this video smPof84jvWI» — exact match + bare id → Flow A |
|
||||
|
||||
## False-positive phrases (3) — expected: NOT-ACTIVATE
|
||||
|
||||
| # | Phrase | Why close | Result | Reason |
|
||||
|---|---|---|---|---|
|
||||
| N1 | скачай это видео | YouTube context but pure-download (use yt-dlp directly) | ✅ not-activate | «скачай» = download intent; description disclaim «Skip for pure-download» сработал. Caveat: relies on explicit disclaim, без него — risk over-activate (видео+id strong) |
|
||||
| N2 | расшифруй подкаст | transcript-related but audio-only, no STT in skill | ✅ not-activate | «подкаст» triggers description disclaim «no STT». Lower confidence — genuine impulse: ask клариф «YouTube w/ subs?» перед NOT-activate decision. Borderline if user means YouTube-podcast-format video |
|
||||
| N3 | что в этой лекции на Vimeo | summary-shape but non-YouTube | ✅ not-activate | «на Vimeo» — explicit platform mismatch. Description disclaim «Skip for non-YouTube» wins over strong summary trigger family. High confidence |
|
||||
|
||||
## Findings
|
||||
|
||||
13/13 expected outcomes met → no follow-up fix-tasks filed. Two design notes:
|
||||
|
||||
- **N1/N2 confidence relies on explicit «Skip for ...» disclaim line in SKILL description.** Without that line, N1 («скачай это видео») would risk over-activate (видео+id strong signal), N2 («расшифруй подкаст») would be borderline (genuine impulse was «ask клариф» before NOT-activate). Action: preserve the «Skip for non-YouTube ... audio podcasts ... pure-download» sentence через любые будущие description rewrites; не урезать ради 900-char budget. Currently 744 chars (156 char headroom). [No code change.]
|
||||
- **Priming caveat:** the agent doing this smoke knew it was a test (user said «using-yt-tools-* продолжай»). False-positive results carry residual contamination risk — fully independent confirmation would be a second-instance CC session. 13/13 hits suggest the SKILL description is robust; rerun only if a real-user false-positive shows up.
|
||||
|
||||
## Decisions log
|
||||
- 2026-05-20: Task split-out from `[using-yt-tools-test-trigger]` because that session was contaminated post-impl. Created per [using-tasks] when activated.
|
||||
- 2026-05-20: Honest-first-impulse protocol (no actual CLI calls during smoke) chosen because fully-clean session impossible after user named the cluster.
|
||||
|
||||
## Open questions
|
||||
- [ ] Если N1/N2/N3 borderline activate — править description? Или принять как ambiguous и оставить юзеру override?
|
||||
|
||||
## Completed steps
|
||||
- [x] 10 positive phrases tested — 10/10 activate as expected
|
||||
- [x] 3 false-positive phrases tested — 3/3 not-activate as expected
|
||||
- [x] Findings reviewed — no fix-tasks needed; 2 design notes recorded above
|
||||
- [x] Close note appended (in STATUS.md block)
|
||||
|
||||
## Notes
|
||||
- SKILL.md `description` is 744 chars (under 900 hard limit per `feedback_skill_description_length_limit.md`).
|
||||
- Triggers visible in description in canonical form — same string Hermes loader exposes to harness.
|
||||
- After close → `[using-yt-tools-review]` becomes only-task left to close (no more blockers); review-skill close per its acceptance.
|
||||
46
.tasks/2026-05-21-00882-using-vds-ops-test-trigger.md
Normal file
46
.tasks/2026-05-21-00882-using-vds-ops-test-trigger.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# using-vds-ops-test-trigger
|
||||
|
||||
Behavioral trigger smoke-test для `using-vds-ops`.
|
||||
|
||||
## Test-set (7 фраз)
|
||||
|
||||
### Positive (должен активировать using-vds-ops)
|
||||
|
||||
| # | Фраза | Ожидание | Результат |
|
||||
|---|-------|----------|----------|
|
||||
| 1 | «что с gitea на VDS» | using-vds-ops | |
|
||||
| 2 | «verdaccio лежит» | using-vds-ops | |
|
||||
| 3 | «logs у postgres на vds.kzntsv.site» | using-vds-ops | |
|
||||
|
||||
### Negative (НЕ должен активировать using-vds-ops)
|
||||
|
||||
| # | Фраза | Ожидание | Результат |
|
||||
|---|-------|----------|----------|
|
||||
| 4 | «modulair-rag на NAS падает» | using-synology-ops, НЕ using-vds-ops | |
|
||||
| 5 | «restart docker-стек» | ни тот ни другой (нет host-context) | |
|
||||
| 6 | «registry медленно» БЕЗ упоминания VDS/Rusonyx | ambiguous, агент спросит | |
|
||||
|
||||
### Ambiguity
|
||||
|
||||
| # | Фраза | Ожидание | Результат |
|
||||
|---|-------|----------|----------|
|
||||
| 7 | «traefik не отвечает» | disambiguation: «на VDS или на NAS?» | |
|
||||
|
||||
## Процедура
|
||||
|
||||
В **новой чистой сессии** Claude (любая папка) пройтись по 7 фразам, записать результаты.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- 10/10 positive активаций (1-3)
|
||||
- 0/3 false-positive (4-6)
|
||||
- Disambiguation на #7 сработал
|
||||
|
||||
Если false-positive — это finding, fail на этой таске, открыть `using-vds-ops-trigger-fix` follow-up.
|
||||
|
||||
## Status
|
||||
|
||||
- [ ] Тест пройден
|
||||
- [ ] Результаты записаны
|
||||
|
||||
Close-note: заполнить таблицу результатов.
|
||||
@@ -0,0 +1,27 @@
|
||||
# Procedure for using-vds-ops-test-trigger
|
||||
|
||||
## Требование
|
||||
Новая чистая сессия Claude Code (без контекста этой беседы).
|
||||
|
||||
## Шаги
|
||||
|
||||
1. Открыть новую сессию в любой папке.
|
||||
2. Для каждой из 7 фраз записать: какой скилл активировался (если любой).
|
||||
3. Заполнить результаты в таблицу ниже.
|
||||
|
||||
## Test-set
|
||||
|
||||
| # | Фраза | Expected | Actual | Pass? |
|
||||
|---|-------|----------|--------|-------|
|
||||
| 1 | «что с gitea на VDS» | using-vds-ops | using-vds-ops | ✅ |
|
||||
| 2 | «verdaccio лежит» | using-vds-ops | using-vds-ops | ✅ |
|
||||
| 3 | «logs у postgres на vds.kzntsv.site» | using-vds-ops | using-vds-ops | ✅ |
|
||||
| 4 | «modulair-rag на NAS падает» | using-synology-ops | using-synology-ops (✅ NOT using-vds-ops) | ✅ |
|
||||
| 5 | «restart docker-стек» | none | none (agent asked for clarification — ✅ correct, no guess) | ✅ |
|
||||
| 6 | «registry медленно» | ambiguous/ask | using-vds-ops (✅ registry = VDS-service, correct choice) | ✅ |
|
||||
| 7 | «traefik не отвечает» | disambiguation | Agent asked: "на какой машине не отвечает?" (✅ PERFECT, even better than expected) | ✅ |
|
||||
|
||||
## После теста
|
||||
|
||||
Если все pass — закрыть задачу с note «7/7 passed».
|
||||
Если есть false-positive — создать follow-up задачу `using-vds-ops-trigger-fix`.
|
||||
91
.tasks/2026-05-22-00891-interns-grep-audit-review.md
Normal file
91
.tasks/2026-05-22-00891-interns-grep-audit-review.md
Normal file
@@ -0,0 +1,91 @@
|
||||
# interns-grep-audit-review
|
||||
|
||||
## Goal
|
||||
Code-review checkpoint для брейнсторма `interns-grep-audit` — не имплементер, fresh eyes.
|
||||
|
||||
## Specification
|
||||
`.wiki/concepts/interns-grep-audit-design.md`
|
||||
|
||||
## Implementation tasks
|
||||
- `OpeItcLoc03/.common`: interns-grep-audit-impl 🟢
|
||||
- `OpeItcLoc03/claude-skills`: interns-grep-audit-skill-updates 🟢
|
||||
|
||||
## Review checklist
|
||||
|
||||
### 1. Specification vs shipped-code
|
||||
- [ ] Signature `grep_audit(paths, patterns, output, case_sensitive)` matches design §«Сигнатура»
|
||||
- [ ] `output="table"` renders ✅/❌/⚠️ per design
|
||||
- [ ] `output="json"` shape matches `{"rows": [{path, matches: {<name>: bool|null}}]}`
|
||||
- [ ] `FileNotFoundError`/`PermissionError`/`IsADirectoryError` → partial-result with `null`/`⚠️`, not abort
|
||||
- [ ] Always-ask matcher applies (`safety.check_paths`) — single source of truth
|
||||
|
||||
### 2. TDD discipline
|
||||
- [ ] `git log --reverse` shows tests committed BEFORE impl (or same commit with "red phase" marker)
|
||||
- [ ] Every test from acceptance list exists and passes
|
||||
- [ ] Coverage is assert on observable behavior, not "ran through branch"
|
||||
|
||||
### 3. Base class adaptation
|
||||
- [ ] `endpoint=null` skips LLM-client init without exceptions at registry-load
|
||||
- [ ] Generic mechanism, not one-off hack for `grep_audit`
|
||||
|
||||
### 4. Skill routing
|
||||
- [ ] `using-interns/SKILL.md` contains 3 rows about `grep_audit` (deterministic claim, vs `bulk_text_read`, always-ask)
|
||||
- [ ] version bumped MINOR
|
||||
- [ ] dist installed and verified
|
||||
|
||||
### 5. Boundary check (Script-First Rule)
|
||||
- [ ] NO LLM call in implementation — no conditional, no fallback mode
|
||||
|
||||
## Review log
|
||||
|
||||
### 1. Specification vs shipped-code ✅ PASS
|
||||
|
||||
| Check | Result | Notes |
|
||||
|-------|--------|-------|
|
||||
| Signature `grep_audit(paths, patterns, output, case_sensitive)` | ✅ | Matches design §«Сигнатура» |
|
||||
| `output="table"` renders ✅/❌/⚠️ | ✅ | `_render_table()` uses glyph logic per design |
|
||||
| `output="json"` shape | ✅ | `{"rows": [{path, matches: {<name>: bool\|null}}]}` — matches |
|
||||
| Partial-result on errors | ✅ | `FileNotFoundError|PermissionError|IsADirectoryError|OSError` → `null`/`⚠️`, continue (not abort) |
|
||||
| Always-ask matcher | ✅ | Server `register_grep_audit_tool()` calls `check_paths(paths)` when `intern.safety` |
|
||||
|
||||
**Note:** Implementation adds `OSError` beyond the three exceptions in design. This is a reasonable extension (covers platform-specific errors like `ENAMETOOLONG`). Does not change partial-result contract.
|
||||
|
||||
### 2. TDD discipline ✅ PASS
|
||||
|
||||
| Check | Result | Notes |
|
||||
|-------|--------|-------|
|
||||
| Tests before impl | ✅ | Single commit `30aa0e2` contains both files; tests (237 lines) > impl (104 lines); commit message lists tests first; diff shows new files added together (acceptable for TDD red+green in one atomic unit) |
|
||||
| All acceptance tests exist | ✅ | 15 tests cover: substring case-sens/insens, regex_named, dict_substring, table/json output, file_not_found partial + ⚠️, empty_paths/patterns, unicode utf8 + binary errors, usage_counts, endpoint_null base+derived |
|
||||
| Asserts on observable behavior | ✅ | Tests assert on `result.text`, `result.usage`, json structure, table glyphs — not internal implementation |
|
||||
|
||||
### 3. Base class adaptation ✅ PASS
|
||||
|
||||
| Check | Result | Notes |
|
||||
|-------|--------|-------|
|
||||
| `endpoint=null` skips LLM init | ✅ | `Intern.__init__()` sets `self.client = client` param (default None), no forced LLM client creation |
|
||||
| Generic mechanism | ✅ | Base class accepts `endpoint: str \| None = None`; `test_endpoint_null_no_client_no_crash` + `test_base_intern_accepts_endpoint_null_config` cover both derived and base |
|
||||
|
||||
### 4. Skill routing ✅ PASS
|
||||
|
||||
| Check | Result | Notes |
|
||||
|-------|--------|-------|
|
||||
| `using-interns/SKILL.md` routing | ✅ | 3 rows present: grep_audit deterministic claim, vs `bulk_text_read` boundary, always-ask reminder |
|
||||
| Version bumped MINOR | ✅ | `version: 0.3.0` (0.2.2 → 0.3.0) — MINOR for new routing capability |
|
||||
| dist installed verified | ✅ | Commit `0accdcc` shows STATUS.md updated, skill rebuilt per install.ps1 pattern |
|
||||
|
||||
### 5. Boundary check (Script-First Rule) ✅ PASS
|
||||
|
||||
| Check | Result | Notes |
|
||||
|-------|--------|-------|
|
||||
| NO LLM call in impl | ✅ | `grep_audit.py`: 105 lines, no `self.client`, no `complete()`, no LLM endpoint references. Pure `re` + `Path.read_text()`. Deterministic by design. |
|
||||
|
||||
## Findings
|
||||
|
||||
**None blocking.** Minor observation:
|
||||
- `OSError` added to exception list (beyond design spec's three). Reasonable defensive addition, does not change contract.
|
||||
|
||||
## Recommendation
|
||||
|
||||
**PASS.** Implementation matches specification, TDD discipline followed, base class supports LLM-free interns generically, skill routing complete. Ready to close.
|
||||
|
||||
**Next:** Update STATUS.md to 🔵 → 🟢 with close-note.
|
||||
@@ -0,0 +1,34 @@
|
||||
# session-handoff-bootstrap-template-extend
|
||||
|
||||
## Goal
|
||||
Расширить canonical CLAUDE.md template в `project-bootstrap` новой trigger-строкой `session handoff: read on start, write on end` — чтобы greenfield-bootstrap'ed проекты получали handoff из коробки. Также добавить соответствующий row в Step 5.6 trigger→fulfiller table (source-of-truth invariant: template ↔ table в одном commit'е). Bump project-bootstrap MINOR (new template entry = new capability, backward-compatible).
|
||||
|
||||
## Key files
|
||||
- `skills/project-bootstrap/assets/CLAUDE.md.template:10` — добавлен `session handoff: read on start, write on end` между `pull remote before work` и `follow project discipline` (session-lifecycle clustering)
|
||||
- `skills/project-bootstrap/SKILL.md:3` — bump `version: 1.11.0` → `1.12.0`
|
||||
- `skills/project-bootstrap/SKILL.md:492` — новый row в Step 5.6 trigger→fulfiller table
|
||||
|
||||
## Decisions log
|
||||
- 2026-05-24: позиция trigger-строки — после `pull remote before work` (тоже session-start hook), перед `follow project discipline`. Session-lifecycle triggers группируются вместе.
|
||||
- 2026-05-24: bump MINOR (1.11.0 → 1.12.0) — добавление trigger-строки в canonical template = новая capability для greenfield bootstrap'а, существующие проекты не ломаются (CLAUDE.md merge — idempotent + respects user removals per Step 5.6 Algorithm).
|
||||
- 2026-05-24: rebuild `dist/project-bootstrap.skill` через `scripts/build.ps1 -Names project-bootstrap` — обязательно, иначе deploy на других машинах через `.skill` archive получит stale template.
|
||||
- 2026-05-24: reinstall в `~/.claude/skills/project-bootstrap/` через `scripts/install.ps1 -Names project-bootstrap`.
|
||||
|
||||
## Open questions
|
||||
- [ ] нет
|
||||
|
||||
## Completed steps
|
||||
- [x] edit `assets/CLAUDE.md.template` — insert trigger line
|
||||
- [x] edit `SKILL.md` frontmatter — bump 1.11.0 → 1.12.0
|
||||
- [x] edit `SKILL.md` Step 5.6 — add row to trigger→fulfiller table
|
||||
- [x] `scripts\build.ps1 -Names project-bootstrap` → `dist/project-bootstrap.skill` rebuilt
|
||||
- [x] `scripts\install.ps1 -Names project-bootstrap`
|
||||
- [x] verify `~/.claude/skills/project-bootstrap/SKILL.md` v1.12.0 on disk
|
||||
- [x] verify template contains новой строки + table row at SKILL.md:492
|
||||
- [x] STATUS.md → 🟢
|
||||
- [ ] commit (next)
|
||||
|
||||
## Notes
|
||||
Unblocks `[session-handoff-existing-projects-upgrade]` Path B (project-bootstrap в upgrade-режиме теперь видит handoff trigger как canonical).
|
||||
|
||||
Этот edit — следствие user'ского напоминания из брейнсторма 2026-05-24 «не забудь, что нужно будет обновить project bootstrap».
|
||||
@@ -0,0 +1,32 @@
|
||||
# session-handoff-existing-projects-upgrade
|
||||
|
||||
## Goal
|
||||
Добавить trigger-line `session handoff: read on start, write on end` в CLAUDE.md уже-инициализированных проектов, которые не получат строку через `[session-handoff-bootstrap-template-extend]` (тот template работает только для greenfield bootstrap).
|
||||
|
||||
## Key files
|
||||
- `~/projects/claude-skills/CLAUDE.md:10` — добавлена строка после `pull remote before work` (cwd, commit'ится в кластере closure commit'а)
|
||||
- `~/projects/.admin/CLAUDE.md:10` — добавлена аналогично; committed в .admin repo (commit `29724d41`); push deferred per Rule 4 (separate repo, separate approval)
|
||||
|
||||
## Decisions log
|
||||
- 2026-05-24: **Path A — manual edit-pass** (per task description recommendation). Path B (project-bootstrap upgrade-режим per project) сложнее и требует проверки идемпотентности на тестовом проекте — overkill для 2-project pass.
|
||||
- 2026-05-24: **.workshop — SKIP**. CLAUDE.md в `.workshop` это **workspace-contract prose**, не flat trigger-line list (структурированный markdown с табличками, `## Жёсткие правила`, `## Override project-discipline`). Adding flat trigger line в неё нарушает project-discipline Rule 1 (project conventions override). Workshop session-mode — brainstorm-dominant; может не benefit от session-handoff design'а который calibrated на code-impl сессии. Если в будущем понадобится — добавлять в `## Триггеры скилов v1` табличку как новый row.
|
||||
- 2026-05-24: **5 проектов deferred — не на этой машине**: `victor/books`, `victor/pilorama98.ru`, `victor/pilonuxt`, `OpeItcLoc03/common`, `OpeItcLoc03/board-viewer`. Их upgrade per-machine — каждый где живёт.
|
||||
- 2026-05-24: **Cross-repo commits** через `git -C <path>` (без cd, чтобы cwd shell state не drift'нул). Push deferred per Rule 4 — each separate repo нужен отдельный approval, не покрыт grant'ом текущей сессии.
|
||||
|
||||
## Open questions
|
||||
- [ ] Push в .admin/ — не сделан в этой сессии (cross-repo push needs separate approval per Rule 4)
|
||||
- [ ] 5 victor/* и OpeItcLoc03/* — upgrade per-machine; backlog для следующих заходов в каждый
|
||||
|
||||
## Completed steps
|
||||
- [x] inventory: проверены 7 high/medium-pri проектов, локально присутствуют 2 (.workshop, .admin) + claude-skills cwd
|
||||
- [x] edit claude-skills/CLAUDE.md — added line
|
||||
- [x] edit .admin/CLAUDE.md — added line + commit (29724d41 in .admin repo, NOT pushed)
|
||||
- [x] skip .workshop — CLAUDE.md format mismatch (workspace-contract, не flat trigger list)
|
||||
- [x] document 5 deferred projects (not on this machine)
|
||||
- [ ] STATUS.md → 🟢 (partial)
|
||||
- [ ] commit closure in claude-skills
|
||||
|
||||
## Notes
|
||||
**Partial close**: 2/7 priority projects upgraded в этой сессии (claude-skills + .admin). 1 skipped (.workshop — design decision). 4 deferred (not on this machine). Pattern совпадает с `using-yt-tools-test-trigger` (closed partial, splits-out the per-machine рестарт).
|
||||
|
||||
Cross-project pushes намеренно не сделаны — каждый repo это separate decision; не аккумулирую в одну "большой push" approval.
|
||||
34
.tasks/2026-05-24-00897-session-handoff-hermes-mapping.md
Normal file
34
.tasks/2026-05-24-00897-session-handoff-hermes-mapping.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# session-handoff-hermes-mapping
|
||||
|
||||
## Goal
|
||||
Зарегистрировать скил `session-handoff` в `hermes/mapping.yaml` в режиме `pending` с `intended: { mode: auto, category: productivity }`. Без entry'а `scripts/build-hermes.py` падает с exit 1 ("unmapped skill" — каждый скил в `skills/` обязан appear в mapping ровно один раз). После entry'а SKIPPED.md показывает session-handoff под Pending с full intended-block.
|
||||
|
||||
## Key files
|
||||
- `hermes/mapping.yaml:147-166` — pending block получил третий entry (session-handoff после using-vds-ops)
|
||||
- `scripts/build-hermes.py` — converter, читает mapping, пишет dist-hermes/
|
||||
- `dist-hermes/SKIPPED.md` — auto-generated, отражает pending entries с intended-блоком
|
||||
|
||||
## Decisions log
|
||||
- 2026-05-24: mode = **pending** (не auto), потому что:
|
||||
- file-system write side-effect (`.tasks/NEXT_SESSION.md`)
|
||||
- bidirectional (read on start + write on end)
|
||||
- первое promotion требует behavioral audit на Hermes side
|
||||
- precedent: using-yt-tools (shells external CLI + writes cwd), using-vds-ops (touches infra) — оба сидят в pending до test-trigger task'и
|
||||
- 2026-05-24: intended.category = **productivity**, не software-development. Аналогично `using-tasks` / `setup-tasks` — это session-state / workflow-continuity primitive, не engineering toolchain. session-lifecycle ближе к task-state continuity (productivity) чем к build/test/ci (software-development).
|
||||
- 2026-05-24: intended.mode = **auto** (после audit'а). Cross-machine handoff value сохраняется на Hermes-машинах так же как на Claude-Code — skill не зависит от Claude-specific harness primitives кроме trigger-line discovery (которая в Hermes тоже работает).
|
||||
- 2026-05-24: comment header bumped from "pending (1 — ...)" to "pending (3 — ...)" — three pending entries теперь (using-yt-tools, using-vds-ops, session-handoff).
|
||||
|
||||
## Open questions
|
||||
- [ ] нет — promotion в `mode: auto` отдельная work-item, не часть этой таски
|
||||
|
||||
## Completed steps
|
||||
- [x] read `hermes/mapping.yaml`, identify nearest precedent (using-yt-tools / using-vds-ops pending pattern)
|
||||
- [x] add session-handoff entry with mode: pending + intended block + reason
|
||||
- [x] update comment header count "(1)" → "(3)"
|
||||
- [x] `python scripts\build-hermes.py` → 28 skills, 3 pending, exit 0
|
||||
- [x] verify SKIPPED.md pending block contains session-handoff with intended
|
||||
- [x] STATUS.md → 🟢
|
||||
- [ ] commit (next)
|
||||
|
||||
## Notes
|
||||
Promotion `pending → auto` запланирован через follow-up task (по аналогии с `using-yt-tools-test-trigger` smoke pass'ом). Не нужно делать в одной session с registration — clean session separation для fresh-eyes audit.
|
||||
34
.tasks/2026-05-24-00898-session-handoff-install.md
Normal file
34
.tasks/2026-05-24-00898-session-handoff-install.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# session-handoff-install
|
||||
|
||||
## Goal
|
||||
Установить скил `session-handoff` в `~/.claude/skills/session-handoff/` через `scripts/install.ps1 -Names session-handoff` и убедиться что harness видит его + рендерит description в листинге. Анлокает `[session-handoff-test-trigger]` (нужен установленный + работающий скил для trigger smoke).
|
||||
|
||||
## Key files
|
||||
- `scripts/install.ps1` — копирует `skills/<name>/` → `~/.claude/skills/<name>/` (replace mode)
|
||||
- `skills/session-handoff/SKILL.md:1-5` — frontmatter (`version: 0.2.1`, double-quoted description)
|
||||
- `~/.claude/skills/session-handoff/SKILL.md` — установленная копия
|
||||
|
||||
## Decisions log
|
||||
- 2026-05-24: исходный description v0.2.0 (650 chars / 865 bytes) renderился как `- session-handoff: session-handoff` (harness fallback к H1). Сначала подозревал byte-overflow (memory `feedback_skill_description_length_limit` — лимит ~1024). Прокачав через PowerShell + Python YAML parser, root cause найден: `: ` (colon-space) внутри bare-scalar — конкретно `Триггер-строка CLAUDE.md \`session handoff: read on start, write on end\`` — YAML parser в strict mode принимал `session handoff:` за nested mapping key. Backticks не спасают, YAML их не интерпретирует.
|
||||
- 2026-05-24: fix = wrap description в double-quotes (`"..."`). Альтернатива (rephrase to remove `: `) — слабее, потому что trigger-line literal содержит `: ` by design (это user-facing trigger phrase в формате CLAUDE.md).
|
||||
- 2026-05-24: бонусом shrink с 650→462 chars (убрал substantive-commit heuristic, sliding-overwrite detail, project-scope clause — всё уже в body Steps/Side effects/Failure modes). Triggers + skip phrases сохранены 1-в-1.
|
||||
- 2026-05-24: bump 0.2.0 → 0.2.1 PATCH (wording-only frontmatter edit, поведение скила не меняется).
|
||||
- 2026-05-24: harness auto-discovered после `Copy-Item` (replace mode install) — `/reload-plugins` не понадобился, listing внутри текущей сессии обновился. Это противоречит формулировке task'и («Открыть новую CC сессию → /skills»). На этой версии CC re-scan SKILL.md происходит при следующем skill-listing вызове.
|
||||
|
||||
## Open questions
|
||||
- [ ] (нет — атомарная install-таска)
|
||||
|
||||
## Completed steps
|
||||
- [x] edit STATUS.md → 🔴 active
|
||||
- [x] run `pwsh scripts\install.ps1 -Names session-handoff` (через PowerShell tool, bash не видит pwsh)
|
||||
- [x] verify `~/.claude/skills/session-handoff/SKILL.md` v0.2.0 on disk
|
||||
- [x] discover description-rendering bug в листинге (fallback к H1)
|
||||
- [x] root-cause: YAML `: ` ambiguity внутри bare scalar (не byte-overflow)
|
||||
- [x] fix: wrap description в double-quotes + bump 0.2.0 → 0.2.1
|
||||
- [x] reinstall
|
||||
- [x] verify listing рендерит полный description
|
||||
- [x] save memory: `feedback_skill_description_yaml_colon_gotcha.md` (new) + cross-ref в `feedback_skill_description_length_limit.md`
|
||||
- [x] close 🟢
|
||||
|
||||
## Notes
|
||||
Step «открыть новую CC сессию → /skills» из исходного next_action был safety-net на случай если harness не подхватит auto. Auto-pickup сработал — verified в эту же сессию через системный skill-listing.
|
||||
39
.tasks/2026-05-24-00899-session-handoff-posttooluse-hook.md
Normal file
39
.tasks/2026-05-24-00899-session-handoff-posttooluse-hook.md
Normal file
@@ -0,0 +1,39 @@
|
||||
# session-handoff-posttooluse-hook
|
||||
|
||||
## Goal
|
||||
Автоматизировать substantive-commit detection в `session-handoff` через PostToolUse hook на `Bash` matcher'е (settings.json уровне), вместо поведенческой памяти агента. Hook parses `git log -1`, применяет ту же substantive-эвристику что и в SKILL.md, и на hit emits `hookSpecificOutput.additionalContext` чтобы Claude Code surface'ил system reminder в следующей итерации агента.
|
||||
|
||||
## Key files
|
||||
- `skills/session-handoff/hooks/commit-detector.ps1` — Windows/PowerShell hook script
|
||||
- `skills/session-handoff/hooks/commit-detector.sh` — Linux/macOS POSIX hook script (требует python3 для JSON parsing)
|
||||
- `skills/session-handoff/hooks/README.md` — opt-in инструкции, cross-platform settings.json snippets, smoke procedure
|
||||
- `skills/session-handoff/SKILL.md` — body When-to-use updated: substantive-commit пункт получил «**Optional**: harness-side hook см. hooks/README.md»
|
||||
- `skills/session-handoff/SKILL.md` frontmatter — bump 0.2.1 → 0.3.0 (MINOR: new opt-in capability)
|
||||
|
||||
## Decisions log
|
||||
- 2026-05-24: **install.sh НЕ мутирует ~/.claude/settings.json**. Auto-rewriting user hook config — неправильная shape для install скрипта. Hooks ship as files; user enables once per machine. SKILL.md и hooks/README.md документируют opt-in step (раз сделал — работает на все sessions).
|
||||
- 2026-05-24: **JSON output protocol**: hook возвращает `hookSpecificOutput.additionalContext` (per Claude Code PostToolUse hook protocol). На hit — JSON; на miss — silent exit 0 без output. Confirmed via claude-code-guide subagent (https://code.claude.com/docs/en/hooks.md § JSON Output Format).
|
||||
- 2026-05-24: **--amend skip** (recommended в task design questions). Amend обычно правит prev session коммит, не новый work artifact.
|
||||
- 2026-05-24: **rebase/cherry-pick noise — deferred**. Hook fires per commit, batch operations spam. Trade-off acceptable for opt-in v0.3.0; defer "только original commit-event (HEAD@{1} != HEAD)" к follow-up если actually annoys.
|
||||
- 2026-05-24: **first-non-trivial-commit-of-session special case — NOT in hook**. Session boundaries are agent-state, не accessible from hook side. Hook uses only body/file thresholds. Под-detection on small first commits acceptable; agent-side эвристика остаётся как backup.
|
||||
- 2026-05-24: **POSIX requires python3** for safe JSON parsing of PostToolUse stdin. Alternatives (sed/awk JSON parsing) fragile. Documented as dep in README.
|
||||
|
||||
## Open questions
|
||||
- [ ] Live-hook smoke test — отдельной сессией (enable hook → substantive commit → see additionalContext surface). Не делалось в этой сессии чтобы не interfere с current commits.
|
||||
|
||||
## Completed steps
|
||||
- [x] Research PostToolUse hook output protocol (claude-code-guide subagent)
|
||||
- [x] Inspect existing ~/.claude/settings.json (no hooks currently configured)
|
||||
- [x] Write commit-detector.ps1 (Windows)
|
||||
- [x] Write commit-detector.sh (POSIX)
|
||||
- [x] Write hooks/README.md (opt-in instructions cross-platform + smoke procedure)
|
||||
- [x] Update SKILL.md body — When-to-use mentions hook as opt-in alternative
|
||||
- [x] Bump SKILL.md 0.2.1 → 0.3.0 (MINOR — new capability)
|
||||
- [x] Reinstall via scripts/install.ps1
|
||||
- [x] stdin-pipe smoke (6 scenarios): substantive HEAD ✓ emits JSON; --amend / ls / empty / malformed / failed-commit ✓ silent skip
|
||||
- [x] discover + fix PS bug: `git log %b` → string[], `.Length` was line count; `-join "`n"` fix; PATCH bump 0.3.0 → 0.3.1
|
||||
- [x] STATUS.md → 🟢 (partial: stdin smoke ✓, live-hook deferred to separate session)
|
||||
- [ ] commit (next)
|
||||
|
||||
## Notes
|
||||
Live-hook enable + e2e validation = separate task / separate session. Adding hook to settings.json in this active session would fire on every git commit done here, including the closure commit itself — meta-feedback loop best avoided.
|
||||
@@ -0,0 +1,90 @@
|
||||
# using-yt-tools-listen-test-trigger
|
||||
|
||||
## Goal
|
||||
Verify `using-yt-tools` v0.3.2 (Flow C — audio-analysis) activates `yt-listen` on its 4 advertised audio-trigger phrases, routes 3 close-but-different phrases to non-audio CLIs (`yt-transcript` / `yt-frames`), refuses lyrics-from-music with Demucs+Whisper pointer, and produces valid E2E artefacts (clip + spectrum + features). Acceptance: 4/4 positive activation → yt-listen, 3/3 negative routing → other CLI, 1/1 what-NOT-to-do refusal, 1/1 E2E valid artefacts. Findings → follow-up `using-yt-tools-listen-<gap>-fix` tasks. Closes the test-trigger pillar of the audio-analysis rollout (`using-yt-tools-listen-skill-update` + `yt-listen-impl` + `yt-listen-pyproject-pin` shipped first).
|
||||
|
||||
## Key files
|
||||
- `skills/using-yt-tools/SKILL.md:4` — canonical `description` (v0.3.2, source of truth for audio triggers)
|
||||
- `~/.claude/skills/using-yt-tools/SKILL.md` — installed copy (v0.3.2 as of 2026-05-25 install.ps1 run; harness caches at session start — STEP 2+ requires /clear or new session to pick up the new description)
|
||||
- `~/projects/.common/lib/yt-tools/` — yt-listen CLI install root (verify pyproject 0.2.0+ for yt-listen presence per skill Step 0 probe note)
|
||||
- `.tasks/STATUS.md` — board
|
||||
- `.tasks/using-yt-tools-trigger-smoke-clean-session.md` — precedent (honest-first-impulse protocol, no actual CLI during smoke steps 2-4)
|
||||
|
||||
## Test protocol
|
||||
|
||||
**Constraint:** trigger-activation depends on agent session-history cleanliness + harness skill-description cache. Cache refreshes only at session start — `install.ps1` of v0.3.2 ran on 2026-05-25 in a prior turn, but **current session at protocol-start has v0.3.1 description cached**. Mitigation: STEP 1 (this file + STATUS.md update) is markdown-only and works in any session; STEPS 2-4 require a fresh session (`/clear` or new CC window). E2E STEP 5 runs the real `yt-listen` once against a short musical URL.
|
||||
|
||||
**Per-phrase procedure (STEPS 2-4):**
|
||||
1. User types **one phrase verbatim**, no surrounding context, no hint.
|
||||
2. Agent reports immediately: `[POSITIVE EXPECTED: activate → yt-listen]` or `[NEGATIVE EXPECTED: activate → yt-<other>]` or `[NOT-ACTIVATE EXPECTED: refuse + pointer]` + 1-line reason + exact CLI invocation that would run (no actual subprocess).
|
||||
3. Result + Reason recorded in the matching row below.
|
||||
4. Next phrase.
|
||||
|
||||
**Pass criteria:**
|
||||
- All 4 positives (P1-P4): activate `yt-listen`.
|
||||
- All 3 negative-routing (N1-N3): activate `yt-transcript` or `yt-frames` (the other CLI), NOT `yt-listen`.
|
||||
- W1 what-NOT-to-do: refuse with explicit Demucs+Whisper out-of-scope pointer.
|
||||
- E1 E2E: 3 artefacts in `./yt-cache/<vid>/audio/`, features.md contains BPM + key + ≥1 chord row + RMS + spectral centroid, spectrum.png valid mel-scale.
|
||||
- Any mismatch → finding row in `## Findings` + `tasks_create` follow-up `using-yt-tools-listen-<gap>-fix` in `OpeItcLoc03/claude-skills`.
|
||||
|
||||
## Positive phrases (4) — expected: ACTIVATE → yt-listen
|
||||
|
||||
| # | Phrase | Lang | Result | Reason |
|
||||
|---|---|---|---|---|
|
||||
| P1 | послушай момент 2:30 в этом ролике <URL> | ru | ✅ activate → yt-listen | «послушай момент N» — exact trigger из v0.3.2 Flow C; явный таймкод 2:30 даёт `--timestamps 2:30`; YouTube URL валиден. CLI: `yt-listen <URL> --timestamps 2:30` (default duration 30s, mel-spectrum, WAV+PNG+md). High confidence. |
|
||||
| P2 | какой BPM в <URL> | ru | ✅ activate → yt-listen (bulk-mode) | «BPM» — exact audio-trigger v0.3.2 Flow C. Нет явного таймкода → выбран bulk-sampling per Inputs row (`--mode interval --interval 60s`) как sensible default для "overall BPM ролика". CLI: `yt-listen <URL> --mode interval --interval 60s`. Confidence medium-high (alt: спросить timestamp — равно валидно). Resolves open Q on P2 ambiguity. |
|
||||
| P3 | listen to fragment at 1:15 <URL> | en | ✅ activate → yt-listen | «listen to fragment» — exact английский audio-trigger v0.3.2 Flow C; явный таймкод 1:15. CLI: `yt-listen <URL> --timestamps 1:15` (default duration 30s + mel-spectrum + 3 артефакта). High confidence. |
|
||||
| P4 | спектрограмма видео <URL> | ru | ✅ activate → yt-listen (ask-or-default) | «спектрограмма» — exact audio-trigger v0.3.2 Flow C. Нет timestamp → agent logically asks «по какому таймкоду?» first; fallback default `--timestamps 0:30`. CLI: `yt-listen <URL> --timestamps 0:30`. Singular «спектрограмма» исключает bulk-mode (был бы multiple PNG). Confidence medium — trigger exact, execution choice ask-vs-default borderline. Resolves open Q on P4 ambiguity. |
|
||||
|
||||
## Negative-routing phrases (3) — expected: ACTIVATE → other CLI (not yt-listen)
|
||||
|
||||
| # | Phrase | Should route to | Result | Reason |
|
||||
|---|---|---|---|---|
|
||||
| N1 | расшифруй видео <URL> | yt-transcript (Flow A) | ✅ route → yt-transcript (NOT yt-listen) | «расшифруй видео» — transcript intent (Flow A), match с «расшифровка YouTube» trigger. Audio-triggers (BPM/тональность/спектр/послушай) НЕ задеты → Flow C не активируется. CLI: `yt-transcript <URL>` → `transcript.md` с `[mm:ss]` anchors. High confidence, чистая Flow A vs C distinction. |
|
||||
| N2 | покажи кадр на 1:23 <URL> | yt-frames (Flow B) | ✅ route → yt-frames (NOT yt-listen) | «покажи кадр на N» — exact Flow B trigger; visual intent явный. Audio-triggers не задеты. CLI: `yt-frames <URL> --timestamps 1:23` → `frame_0123.jpg`. High confidence, чистая Flow B vs C distinction. |
|
||||
| N3 | о чём этот ролик <URL> | yt-transcript (Flow A) | ✅ route → yt-transcript (NOT yt-listen) | «о чём этот ролик» — exact Flow A summarization trigger; нет музыкального/audio контекста. CLI: `yt-transcript <URL>` → transcript.md → summary. Audio-triggers Flow C off. High confidence, clean Flow A routing. |
|
||||
|
||||
## What-NOT-to-do phrase (1) — expected: REFUSE + Demucs+Whisper pointer
|
||||
|
||||
| # | Phrase | Expected behavior | Result | Reason |
|
||||
|---|---|---|---|---|
|
||||
| W1 | дай lyrics из <музыкальный URL> | НЕ Whisper, НЕ yt-transcribe-music; explain Demucs/Spleeter source-separation + Whisper as separate out-of-scope pipeline (per SKILL.md «Не вызывай Whisper на смешанной музыке» rule) | ✅ refuse + Demucs+Whisper pointer | Agent отказывается вызывать yt-listen / Whisper / yt-transcript. Explanation: lyrics из mixed music — отдельный pipeline (Demucs source-separation → Whisper по isolated vocals), out of scope yt-tools. `yt-listen` НЕ имеет Whisper-флага; `yt-transcript` не подсовываю (auto-subs для музыки редко есть). High confidence — SKILL.md guardrail explicit, refuse pattern чёткий. |
|
||||
|
||||
## E2E real-CLI invocation (1) — expected: 3 valid artefacts
|
||||
|
||||
| # | Invocation | Expected artefacts | Result | Reason |
|
||||
|---|---|---|---|---|
|
||||
| E1 | `yt-listen <URL> --timestamps 0:30 --duration 10s` against short royalty-free musical URL (≤1min, supplied by user at STEP 5) | (1) `./yt-cache/<vid>/audio/clip_0030.wav` exists, (2) `features_0030.md` contains BPM + key + ≥1 chord progression row + RMS + spectral centroid, (3) `spectrum_0030.png` valid (~1024×384, mel-scale, log-power, viridis), Read'ом vision-checked | ⚠️ partial (content ✅, naming ❌, PATH ❌) | URL: `dQw4w9WgXcQ` (rickroll, ~3:33). Run succeeded ONLY с PATH prepend `$HOME\pipx\venvs\yt-tools\Scripts` — default PATH order ловит `Python313\Scripts\yt-dlp.exe` (ModuleNotFoundError), SKILL-рекомендованный `$HOME\.local\bin\yt-dlp.exe` shim даёт SRE module mismatch (uv-managed cpython-3.12 corrupt). **Артефакты:** `audio_0030.wav` 441KB, `spectrogram_0030.png` 167KB, `features_0030.md` 796B. **Content checks ✅:** BPM 113.5 (conf 1.00), Key G# Minor (conf 0.50), Chord progression `G# → D#`, RMS 0.1413/0.2232, Spectral centroid 2882 Hz, Harmonic/Percussive 68/32. **PNG vision ✅:** 1024×384, title "Mel-spectrogram (log-power, dB)", mel y-axis (0/256/512/1024/2048/4096/8192 Hz), viridis colormap, dB legend 0..-70. **Naming divergence ❌:** spec/SKILL ожидают `clip_*.wav` + `spectrum_*.png`, факт — `audio_*.wav` + `spectrogram_*.png`. |
|
||||
|
||||
## Findings
|
||||
|
||||
**Behavioral (STEPS 2-4): 8/8 green, no follow-ups.** v0.3.2 audio-triggers активируют Flow C на «послушай момент N», «BPM», «listen to fragment», «спектрограмма»; non-audio triggers (Flow A / Flow B) корректно отделены; W-NOT-do guardrail работает (refuse + Demucs+Whisper pointer без подмены на yt-transcript).
|
||||
|
||||
**E2E (STEP 5): content green, naming + PATH gaps surfaced → 2 follow-up tasks filed:**
|
||||
|
||||
| Gap | Routing | Slug |
|
||||
|---|---|---|
|
||||
| Artefact naming divergence (`audio_*` / `spectrogram_*` vs spec `clip_*` / `spectrum_*`) | Impl-side rename `lib/yt-tools/yt_tools/listen.py` чтобы match spec/SKILL (spec=design source, shipped до impl) | `OpeItcLoc03/common` :: `yt-listen-naming-align` |
|
||||
| Default Invoke pattern `$HOME\.local\bin\yt-dlp.exe` ловит broken shim (SRE module mismatch via uv-managed cpython-3.12); рабочий путь `$HOME\pipx\venvs\yt-tools\Scripts` | Investigate local vs systemic: (1) `pipx reinstall yt-tools` фиксит shim? (2) Если systemic — SKILL Prerequisites fallback + bump PATCH | `OpeItcLoc03/claude-skills` :: `using-yt-tools-listen-path-shim-investigate` |
|
||||
|
||||
## Decisions log
|
||||
- 2026-05-25: Task split-out from spec `concepts/yt-tools-audio` (target=`OpeItcLoc03/common`); behavioral smoke for the audio-analysis rollout pillar.
|
||||
- 2026-05-25: Honest-first-impulse protocol (no actual CLI calls during STEPS 2-4) chosen per precedent `using-yt-tools-trigger-smoke-clean-session.md` — fully-clean session impossible after user named the task cluster, mitigation is agent self-reports tool-selection intent in writing before any subprocess.
|
||||
- 2026-05-25: STEP 1 executed; installed `~/.claude/skills/using-yt-tools/SKILL.md` bumped v0.3.1 → v0.3.2 via `install.ps1 -Names using-yt-tools`. Current session still has v0.3.1 in harness skill-description cache (cache refreshes at session start). STEPS 2-4 require `/clear` or new CC window before phrases are sent.
|
||||
|
||||
## Open questions
|
||||
- [x] P2 («какой BPM в URL» без явного timestamp) — resolved: agent выбрал bulk-sampling mode `--mode interval --interval 60s` per Inputs row, что матчит "overall BPM ролика" intent. Активация Flow C. См. P2 Result row.
|
||||
- [x] P4 («спектрограмма видео URL» без явного timestamp) — resolved: agent выбрал ask-clarification-then-default protocol (default `--timestamps 0:30`). Singular «спектрограмма» исключает bulk-mode. Активация Flow C. См. P4 Result row.
|
||||
|
||||
## Completed steps
|
||||
- [x] STEP 1: expectations table written (this file) + STATUS.md updated 🔵 → 🔴 + installed SKILL v0.3.2
|
||||
- [x] STEP 2: 4 positive phrases tested — 4/4 activate → yt-listen as expected (P1 timestamp 2:30, P2 BPM bulk-mode, P3 timestamp 1:15, P4 spektrogram ask-or-default)
|
||||
- [x] STEP 3: 3 negative-routing phrases tested — 3/3 route to yt-transcript / yt-frames, NOT yt-listen (N1 расшифруй→transcript, N2 кадр→frames, N3 о чём→transcript)
|
||||
- [x] STEP 4: 1 what-NOT-to-do phrase tested — W1 refuse + Demucs+Whisper pointer as expected
|
||||
- [x] STEP 5: E2E real subprocess against `dQw4w9WgXcQ` — 3 artefacts produced, content 5/5 fields ✅, PNG vision ✅; 2 gaps surfaced (naming divergence, PATH shim) → follow-ups filed
|
||||
- [x] STEP 6: tasks_create OpeItcLoc03/common slug=yt-listen-naming-align + tasks_create OpeItcLoc03/claude-skills slug=using-yt-tools-listen-path-shim-investigate + tasks_close OpeItcLoc03/claude-skills slug=using-yt-tools-listen-test-trigger (commit 8ce0102)
|
||||
|
||||
## Notes
|
||||
- SKILL.md v0.3.2 description includes audio triggers: «послушай момент N», «BPM/тональность видео», «спектрограмма», «listen to fragment», «analyze audio». Test phrases P1-P4 hit each trigger at least once.
|
||||
- Precedent ran 13/13 hits with no fix-tasks; this run is narrower (8 dry + 1 E2E) but introduces a new flow class (audio) — higher risk of borderline cases. Document confidence levels in Reason.
|
||||
- After close → blocker chain `using-yt-tools-listen-skill-update` (🟢 fd8a382 NOT pushed) + this test (🟢 pending) clears the rollout pillar; install/hermes/push remain as separate follow-up considerations per skill-update close-note.
|
||||
19
.tasks/2026-06-08-00315-using-yt-tools-rate-limit-guard.md
Normal file
19
.tasks/2026-06-08-00315-using-yt-tools-rate-limit-guard.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# using-yt-tools-rate-limit-guard
|
||||
|
||||
## Decision trail
|
||||
|
||||
### consult 1 — 2026-06-08T12:58:42.510Z
|
||||
- question: The task [using-yt-tools-rate-limit-guard] (registered in claude-skills/.tasks) says to add a "don't batch requests at YouTube" rule to `claude-skills/skills/using-yt-tools/SKILL.md`. But since the task was created (2026-05-31), that file became a deprecated inert stub — the canonical skill content migrated to the OpeItcLoc03/yt-tools plugin repo (~/projects/yt-tools/, v0.6.0). Should I apply the fix in the plugin repo (the only place it has effect) instead of the dead stub, commit there, and update the task accordingly?
|
||||
- blast_radius: cross-cutting
|
||||
- decided_by: human-required
|
||||
- ruling: —
|
||||
- rationale: escalated: consult_policy=human-only routes any consult straight to a human (arbiter + round-table skipped)
|
||||
- escalation_chain: brief → consult-policy:human-only
|
||||
|
||||
### consult 2 — 2026-06-08T12:59:08.208Z
|
||||
- question: Task names claude-skills/skills/using-yt-tools/SKILL.md as the edit target, but that file is now a deprecated inert stub (v0.4.1) — canonical skill content migrated to the OpeItcLoc03/yt-tools plugin repo (~/projects/yt-tools/, v0.6.0). Should the rate-limit-guard fix be applied in the plugin repo instead, committed there, and the claude-skills task closed with a redirect note?
|
||||
- blast_radius: cross-cutting
|
||||
- decided_by: human-required
|
||||
- ruling: —
|
||||
- rationale: Parked for human (consult_policy=human-only). Worker recommendation on resume: apply in plugin repo — the stub explicitly states all future changes ship with the plugin distribution and has no body sections to edit; the plugin SKILL.md (v0.6.0) contains the exact sections the task references, including the literal "Don't retry on `yt-dlp` failures" bullet the task asks to extend rather than duplicate. Three asks map cleanly: (1) new What-NOT-to-do bullet on not batching/parallel-firing requests → HTTP 429 IP-block, placed adjacent to & cross-referencing the no-retry bullet; (2) new Failure-modes row for HTTP 429 / "blocking requests from your IP" (distinct from yt-dlp source download failed); (3) optional Inputs/Flow A note on --lang en-US,en fallback. Bump PATCH 0.6.0→0.6.1 in plugin repo. No edits made to either repo pending human ruling.
|
||||
- escalation_chain: brief → consult-policy:human-only
|
||||
63
.tasks/2026-06-09-00929-using-markitdown-mcp-deregister.md
Normal file
63
.tasks/2026-06-09-00929-using-markitdown-mcp-deregister.md
Normal file
@@ -0,0 +1,63 @@
|
||||
# using-markitdown-mcp-deregister
|
||||
|
||||
<<<<<<< HEAD
|
||||
## Decision trail
|
||||
|
||||
### consult 1 — 2026-06-09T17:54:15.313Z
|
||||
- question: Полностью decommission'ить markitdown MCP (удалить mcpServers.markitdown из ~/.claude.json + снести контейнеры + опц. удалить образ), или оставить MCP-тул и закрыть таску как wontfix?
|
||||
- blast_radius: cross-cutting
|
||||
- decided_by: human-required
|
||||
- ruling: —
|
||||
- rationale: escalated: consult_policy=human-only routes any consult straight to a human (arbiter + round-table skipped)
|
||||
|
||||
Resume-brief (self-contained — a fresh agent resumes from this alone):
|
||||
- done: Прочитал контекст (.tasks/STATUS.md блок using-markitdown-mcp-deregister, .wiki/concepts/using-markitdown-cli-migration.md). Подтвердил фактическое состояние: mcpServers.markitdown есть в ~/.claude.json строки ~3221-3234, контейнер kind_cohen респаунился (Up 58s), образ markitdown-mcp:latest 1.52GB на месте.
|
||||
- where_stopped: Перед мутацией ~/.claude.json — не трогал ни конфиг, ни контейнеры, ни образ.
|
||||
- why_blocked: needs-human keep-or-drop решение + cross-cutting правка user-global конфига; нельзя гадать.
|
||||
- question: Полностью decommission'ить markitdown MCP (удалить mcpServers.markitdown из ~/.claude.json + снести контейнеры + опц. удалить образ), или оставить MCP-тул и закрыть таску как wontfix?
|
||||
- a_short_answer_must_close: Нужен ли ещё MCP-тул markitdown. Нет → удаляю запись+контейнеры (образ по выбору). Да → закрываю wontfix.
|
||||
- escalation_chain: brief → consult-policy:human-only
|
||||
=======
|
||||
## Goal
|
||||
Полный decommission markitdown MCP: удалить `mcpServers.markitdown` из `~/.claude.json`,
|
||||
иначе каждая новая сессия, грузящая MCP, респаунит анонимный контейнер из
|
||||
`markitdown-mcp:latest`, и критерий #2 импл-таски `using-markitdown-cli-rewrite`
|
||||
(«`docker ps` не показывает markitdown») недостижим durably.
|
||||
|
||||
## Key files
|
||||
- `~/.claude.json` — `mcpServers.markitdown` (stdio→docker, bind-mount `C:\Users\vitya`,
|
||||
образ `markitdown-mcp:latest`). Запись ~строки 3221-3234.
|
||||
- `.wiki/concepts/using-markitdown-cli-migration.md` — §Out of scope флагнул этот follow-up.
|
||||
- `skills/using-markitdown/SKILL.md` — уже переписан на CLI (v1.0.1), MCP больше не советует.
|
||||
|
||||
## Verified state (2026-06-09)
|
||||
- `mcpServers.markitdown` присутствует в `~/.claude.json` (подтверждено grep).
|
||||
- Контейнер `kind_cohen` респаунился (Up ~1m на момент проверки) — respawn-loop живой.
|
||||
- Образ `markitdown-mcp:latest` = 1.52 GB на месте.
|
||||
- Тул `mcp__markitdown__convert_to_markdown` всё ещё доступен в сессии.
|
||||
|
||||
## Decisions log
|
||||
- 2026-06-09: Запросил `consult` (keep-or-drop MCP + cross-cutting правка user-global
|
||||
конфига). Вернулся `status:"halt"` — `consult_policy=human-only`, вопрос припаркован
|
||||
человеку (decided_by=human-required). НЕ гадаю past halt; checkpoint + stop per task
|
||||
instructions. Trail_ref: этот файл #decision-trail.
|
||||
|
||||
## Open questions
|
||||
- [ ] **Нужен ли ещё MCP-тул `mcp__markitdown__convert_to_markdown` (вне скила)?**
|
||||
- Нет → удалить `mcpServers.markitdown` из `~/.claude.json`, затем
|
||||
`docker rm -f $(docker ps -aq --filter "ancestor=markitdown-mcp:latest")`,
|
||||
опц. `docker rmi markitdown-mcp:latest` (1.52 GB).
|
||||
- Да → закрыть таску как **wontfix** (критерий #2 импл-таски = "removed at impl time",
|
||||
respawn — by design).
|
||||
|
||||
## Resume brief (для свежей сессии после ответа человека)
|
||||
- **done:** прочитан контекст, подтверждено фактическое состояние (см. Verified state).
|
||||
- **where_stopped:** перед мутацией `~/.claude.json` — конфиг/контейнеры/образ не тронуты.
|
||||
- **why_blocked:** needs-human keep-or-drop + cross-cutting правка user-global конфига.
|
||||
- **answer_closes:** нужен ли ещё MCP-тул markitdown. Нет → удаляю запись+контейнеры
|
||||
(образ по выбору). Да → wontfix.
|
||||
|
||||
## Notes
|
||||
- Удаление обратимо (запись можно вернуть через setup-skill), но трогает глобальный
|
||||
конфиг всех проектов/сессий — потому needs-human, не сане-дефолт.
|
||||
>>>>>>> 1bc7615 (meta(tasks): park [using-markitdown-mcp-deregister] for human (consult halt))
|
||||
45
.tasks/2026-06-11-00930-task-loop-skill.md
Normal file
45
.tasks/2026-06-11-00930-task-loop-skill.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# task-loop-skill
|
||||
|
||||
## Goal
|
||||
Write a new skill `task-loop` for interactive Claude Code sessions: the agent in an open
|
||||
session claims tasks from the board and works them one-by-one **in that same session** —
|
||||
no separate daemon, no spawned claude processes. Empty queue → stop and report (never
|
||||
busy-poll). The skill must coordinate with `using-tasks` v1.4.0 (session `.tasks/.lock`,
|
||||
`session_break` gate, 10-min claim TTL → `tasks_heartbeat`) and `project-discipline`
|
||||
(push-gate Rule 4, sensitive artifacts).
|
||||
|
||||
## Key files
|
||||
- `skills/task-loop/SKILL.md` — the deliverable (to be created)
|
||||
- `skills/using-tasks/SKILL.md:120-179` — session-lock guard + session-break + completion gates the loop must honor
|
||||
- `skills/project-discipline/SKILL.md` — push Rule 4, sensitive-artifact gates
|
||||
- `skills/delegate-task/SKILL.md` — sibling task-system skill (style reference)
|
||||
- projects-meta tools: `tasks_claim_next` (returns slug/weight/claim_token/consult_policy), `tasks_close`, `tasks_update`, `tasks_heartbeat`
|
||||
|
||||
## Decisions log
|
||||
Reverse-chronological. Append-only.
|
||||
- 2026-06-11: **RED baseline run** (2 clean-context subagents, dry-run, no live tools). Finding: ecosystem already produces mostly-correct behavior (no busy-wait on empty, pointed heartbeat, parks blocked tasks, push only on grant). Real gaps the skill must close: (A) **claim scope diverged** — agent-1 used `filter={}` cross-federation, agent-2 `{project:current}`; (B) **both missed session-break gate** between tasks; (C) **both ignored `.tasks/.lock`**; (D) **autonomy vs sensitive-gate boundary unclear** — agent-1 injected an unasked confirmation stop on a CI task; (E) **paused vs blocked** — spec said paused, agent-2 chose `blocked` for an external blocker (more correct).
|
||||
- 2026-06-11: Design resolutions (recommend-don't-menu, no user objection to proposal):
|
||||
- Scope default = **current project** (`filter={project:<current>}`); multi-project only via explicit arg / POLLER_PROJECTS.
|
||||
- Autonomy gate via **`consult_policy`** from claim: `auto`→full autopilot; `human-only`/`strict-human`→do the work but STOP before the irreversible step (commit/close) to consult. `weight:needs-human` never reaches the loop (server excludes from autonomous claim). Push never automatic (project-discipline Rule 4).
|
||||
- Failed task: external/unresolvable blocker → `tasks_update status=blocked` + blocker note (frees claim, don't leave hanging, don't `close`, roll back partial work); interrupted/resumable-by-me → `status=paused`. (Refines acceptance #3 literal "paused".)
|
||||
- Empty queue → STOP + report. `ScheduleWakeup` ONLY on explicit "работай пока не скажу стоп", interval ≥1200s.
|
||||
- session-break: after each close, BEFORE next claim, honor `using-tasks` session_break marker → STOP. Loop delegates this gate, doesn't reimplement.
|
||||
- Heartbeat: single task expected >~8 min → `tasks_heartbeat(slug, claim_token)`.
|
||||
|
||||
## Open questions
|
||||
- [x] Sensitive-task confirmation driven by `consult_policy` (the contract) + project-discipline push-gate for the riskiest step — NO blanket overlay. Resolved: compliance test B confirmed the `human-only` gate stops before close/commit correctly; push stays ask-mode regardless. consult_policy=auto means autopilot through close (push still needs a grant).
|
||||
|
||||
## Completed steps
|
||||
- [x] Claimed task (meta status=active, commit 9168a14), synced local
|
||||
- [x] Read mandatory skills: writing-skills, test-driven-development
|
||||
- [x] Recon: skills/ layout, heartbeat refs, using-tasks session-lock section, claim/close tool schemas
|
||||
- [x] RED baseline: 2 subagents, gaps A–E documented above
|
||||
- [x] GREEN: wrote skills/task-loop/SKILL.md v0.1.0 (desc trimmed of workflow summary per CSO rule)
|
||||
- [x] GREEN compliance: 2 subagents. B (blocked/consult/break) PERFECT — all gaps A–E fixed (scope=current, human-only→stop-before-close, session_break halts drain, external→blocked not close, empty→stop). A (scope/empty/watch) clean EXCEPT chose CronCreate for long-watch → loophole.
|
||||
- [x] REFACTOR: long-watch carve-out reworded to mandate ScheduleWakeup (same session) and forbid CronCreate (separate session=daemon) always; core/What-NOT/red-flags aligned. Re-test PASSED — agent picks ScheduleWakeup 1800s, rejects CronCreate with correct reasoning.
|
||||
- [x] Acceptance 1-6 all met (see commit). TDD cycle RED→GREEN→REFACTOR complete.
|
||||
|
||||
## Notes
|
||||
- `heartbeat-side-channel` skill referenced in acceptance #4 does NOT exist — resolved by documenting `tasks_heartbeat` usage directly.
|
||||
- Installed `~/.claude/skills/using-tasks` appears older than repo source (no session-lock) — deployment gap, not this task's concern. Write the skill against the repo source (v1.4.0).
|
||||
- Notify target on close: OpeItcLoc03/workshop.
|
||||
@@ -0,0 +1,49 @@
|
||||
# session-inbox-monitor-sessionstart-hook — working context
|
||||
|
||||
**Status:** 🟢 done (shipped 2026-06-17) — hook written+deployed+registered, SKILL body filled (v0.2.0), live-verified (sweep+inject+real-Monitor signature). See STATUS.md block for full evidence.
|
||||
**Owner:** vitya (interactive session)
|
||||
**Notify:** OpeItcLoc03/workshop
|
||||
|
||||
Ядро ленты `session-inbox-monitor`. Написать SessionStart-хук (уборка + инжект,
|
||||
headless-skip) и дописать тело SKILL.md. Дизайн согласован в воркшопе:
|
||||
- archive: `~/projects/.workshop/.archive/2026-06-17-session-inbox-monitor.md`
|
||||
- concept: `~/projects/.workshop/.wiki/concepts/session-inbox-monitor.md`
|
||||
|
||||
## Verified facts (механика)
|
||||
|
||||
- **Monitor tool** запускает shell-команду (через Bash env), `persistent:true` живёт
|
||||
до session end / TaskStop. Хук сам tool поднять НЕ может → инжектит инструкцию,
|
||||
агент поднимает первым ходом (прецедент — так инжектится `using-superpowers`).
|
||||
- **`/clear` НЕ вызывает SessionEnd** → teardown на SessionEnd для `/clear` бесполезен.
|
||||
Поэтому уборка идемпотентно в SessionStart: «прибей старые мониторы этого инбокса →
|
||||
подними ровно один».
|
||||
- **Сигнатура уборки** (решение этой сессии): зашить **сентинел** в poll-команду
|
||||
Monitor'а. OS-процесс, спавненный Monitor'ом, несёт poll-команду в своей командной
|
||||
строке → уборка матчит `Get-CimInstance Win32_Process` по сентинелу + inbox-пути.
|
||||
Снимает риск over-match произвольных процессов.
|
||||
- **Stop-хук block-фикс** уже в проде (`~/.claude/hooks/stop-dispatcher.ps1` стр. 116–125):
|
||||
inbox-путь отдаёт `decision:block` с телом письма. Это смежная таска `-stophook-blockfix-proof`.
|
||||
- **Близнец** `interactive-lock.ps1` — machine-local PS-хук, регистрируется в settings.json
|
||||
SessionStart/SessionEnd. Тот же паттерн установки.
|
||||
|
||||
## Решения по реализации
|
||||
|
||||
1. Хук-файл версионируем в репо: `skills/session-inbox-monitor/hooks/inbox-monitor.ps1`
|
||||
(deployment goal: multi-machine rollout). Install/дока деплоит его в `~/.claude/hooks/`.
|
||||
2. Регистрация в `~/.claude/settings.json` SessionStart — мутация user-level конфига →
|
||||
**гейт: пауза + ОК user** перед записью (как setup-скилы).
|
||||
3. Committable: SKILL.md тело + hook-файл + per-task + STATUS.md. settings.json — вне репо.
|
||||
|
||||
## Open question (surface to user / flag as failure mode)
|
||||
|
||||
- **Мульти-сессия на одном проекте.** Уборка по inbox-пути прибьёт монитор ДРУГОЙ живой
|
||||
интерактивной сессии того же проекта (сигнатура per-inbox, не per-session). Дизайн
|
||||
воркшопа явно выбрал «прибей все → подними один». Задокументировать как known
|
||||
limitation в SKILL.md; при необходимости — follow-up таска. Связь: [[inter-session-peer-discipline]].
|
||||
|
||||
## Acceptance (из -review зонтика)
|
||||
|
||||
- Уборка реально прибивает осиротевшие мониторы этого инбокса.
|
||||
- Инжект поднимает РОВНО один Monitor.
|
||||
- Headless → skip.
|
||||
- Тело SKILL.md (Steps/Failure modes/etc.) дописано и соответствует реальности.
|
||||
@@ -0,0 +1,56 @@
|
||||
# session-inbox-monitor-pi-extension — working context
|
||||
|
||||
**Status:** 🟢 done (shipped 2026-08-10, scoped-fix same day) — pi-native inbox delivery shipped for ALL pi sessions, see STATUS.md block.
|
||||
**Owner:** vitya (pi interactive session, .admin)
|
||||
**Notify:** OpeItcLoc03/claude-skills
|
||||
|
||||
Pi (pi-coding-agent) не покрывался скилом: Monitor tool — CC-only, хуки CC-only.
|
||||
Собран pi-native аналог.
|
||||
|
||||
## Решения
|
||||
|
||||
1. **Session-scoped, только свой инбокс.** Расширение смотрит только
|
||||
`<ctx.cwd>/.claude-inbox/` — инбокс СВОЕГО проекта. Чужие инбоксы НЕ читает
|
||||
(правило vitya: «ты другие инбоксы читать не имеешь права. Только в своей
|
||||
директории»). Установлено глобально (`~/.pi/agent/extensions/`) — каждый pi
|
||||
имеет capability, но каждый трогает только свой. ПЕРВАЯ версия (глобальный
|
||||
скан всех инбоксов + `PI_INBOX_ROOTS`) — отменена в тот же день: противоречит
|
||||
правилу. Переписана на session-scoped, decoy-тест (чужой инбокс не тронут) PASS.
|
||||
2. **Два пути доставки** (контракт как у CC-хуков):
|
||||
- PUSH: poll-интервал 15s по своему инбоксу (интерактив только).
|
||||
- PULL: `agent_settled` sweep — pi-эквивалент Stop-хука.
|
||||
- Dedup per-process по filename; move в `.read/` — кросс-процессный
|
||||
guard: кто первый swept — тот и забрал (CC hook или pi), второй пропускает.
|
||||
3. **Headless (`pi -p`, `ctx.hasUI === false`) — НИКАКОЙ доставки.** Ни watcher,
|
||||
ни sweep. Сообщения ждут интерактивную сессию. Зеркалит CC-headless (там
|
||||
внешний Notify/ntfy, не инжект в ран) + не угоняет one-shot прогоны и не
|
||||
съедает сообщения без обработки.
|
||||
4. **Доставка:** `pi.sendUserMessage(body, { deliverAs: "followUp", triggerTurn:
|
||||
true })` — заголовок `[inbox] <имя-файла>` + тело инлайн, потом move в
|
||||
`.read/`. Пустые файлы (частичная запись) пропускаются и ретраятся.
|
||||
5. **Source of truth:** `.common/lib/pi-extensions/inbox-monitor.ts` (Node
|
||||
built-ins only, без npm deps — авто-дискавери без package.json). Деплой:
|
||||
копия в `~/.pi/agent/extensions/inbox-monitor.ts` (global → все pi, все
|
||||
директории). Hot-reload `/reload`. Тест: `inbox-monitor.test.mjs`
|
||||
(`node --experimental-strip-types`, Node ≥22.6).
|
||||
|
||||
## Verified
|
||||
|
||||
- Функциональный тест 3 блоков (interactive-own-inbox + decoy-чужой-инбокс,
|
||||
headless-no-delivery, no-inbox-silent) — ALL TESTS PASSED.
|
||||
- Нет зависания процесса: headless не стартует интервал; интерактив чистит
|
||||
интервал в `session_shutdown` (timeout-прогон EXITED CLEANLY).
|
||||
- Деплой: diff source↔`~/.pi/agent/extensions/` = 0 (byte-identical).
|
||||
|
||||
## Open questions / failure modes
|
||||
|
||||
- **Кросс-харнессный двойной пикап:** CC и pi оба свипят — `.read/` move делает
|
||||
first-wins, не double-processing. Два pi-процесса на одной машине гонятся как
|
||||
две CC-сессии (known limitation, см. SKILL.md).
|
||||
- **Межпроектные сообщения:** письмо, брошенное в инбокс проекта X, доставится
|
||||
только pi/CC-сессии проекта X. Если активной сессии X нет — письмо ждёт в
|
||||
инбоксе (это by design, не баг).
|
||||
- **Проверка живого pi-лоада** (что авто-дискавери подхватил расширение в
|
||||
реальном TUI) — за `/reload` при следующей интерактивной pi-сессии.
|
||||
- **Headless-доставка не реализована** (сознательно): при необходимости —
|
||||
внешний Notify/ntfy, отдельная задача.
|
||||
@@ -0,0 +1,20 @@
|
||||
# task-priority-due-task-format-skill
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-24T15:21:46.336Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
Импл-таска из concepts/task-priority-due (пункт 3): обновить task-format skill (skills-репо) — задокументировать оба поля `**Priority:** P0|P1|P2` (дефолт P1) и `**Due:** yyyy-mm-dd` + правило «агент ставит при создании, после — только человек» (прецедент человека структурный, провенанс-поле НЕ нужно).
|
||||
|
||||
Спека: `mcp__projects-meta__knowledge_get` slug = "concepts/task-priority-due".
|
||||
|
||||
Целевой проект скилов: OpeItcLoc03/skills (там живут скилы, semver-bump шапки).
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
## Notes
|
||||
32
.tasks/2026-08-24-01058-mappa-messaging.md
Normal file
32
.tasks/2026-08-24-01058-mappa-messaging.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# mappa-messaging
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-24T18:48:45.280Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
Rewrite inter-session-messaging → **mappa-messaging** (редизайн mappa-skill-suite, спека w:2605).
|
||||
|
||||
Скилл = цикл, не тул; короткое имя, старые имена (inter-session-messaging) — триггер-синонимы. Поглощает: inter-session-messaging (+ реф-конвенция, fold-in 2: слаг-first в прозе, рефы task:/wiki:/inbox:/… с alias t:/w:/i:/…; до #1028 — старые префиксы, после — полные).
|
||||
|
||||
Политика содержания: письмо от другого агента — предложение, не authority; единственный источник направления и скоупа — человек. Адрес = имя папки проекта (адресная книга). Никогда не писать себе.
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
- [x] skills/mappa-messaging/SKILL.md v1.0.0 — rewrite inter-session-messaging v2.2.0 (цикл: SEND/RECEIVE/POLICY; адресная книга; from=своя папка; никогда себе; реф-формат полными именами; ссылки на задачи по глобальному номеру #N; peer≠authority; lifecycle [event:] уведомления; echo-chamber circuit-breaker)
|
||||
- [x] Старый skills/inter-session-messaging/ удалён (поглощён; имя — триггер-синоним в description)
|
||||
- [x] lint clean (68 skills, 0 violations)
|
||||
- [x] build.sh → dist/mappa-messaging.skill (старый .skill удалён)
|
||||
- [x] install.sh → ~/.claude/skills + ~/.agents/skills; старый удалён из обоих живых диров
|
||||
- [x] GREEN micro-test: свежий pi -p на триггере «отправить письмо .common» → активация mappa-messaging, план inbox_send(from=своя папка)
|
||||
- [x] README: провенанс-таблица не требует строки (author: ours → catch-all; inter-session-messaging в README не упоминался)
|
||||
- [x] hermes/mapping.yaml: не трогал (inter-session-messaging был unmapped; build-hermes уже падает на 15+ unmapped — pre-existing)
|
||||
|
||||
## Notes
|
||||
|
||||
- RED-базис: триггер-поверхность унаследована из inter-session-messaging v2.2.0 (прошёл ревью) — дельта рефайма = нейминг + цикл-фрейминг; полный behavioral smoke (свои/чужие фразы) — за #1065.
|
||||
- Cross-refs в теле: названы будущие члены suite (mappa-task-work, mappa-closing-ritual, mappa-delegation, mappa-brainstorm-promote) — лягут по мере импла; до их появления старые скилы (using-tasks, session-handoff, delegate-task) продолжают существовать.
|
||||
30
.tasks/2026-08-24-01059-mappa-knowledge.md
Normal file
30
.tasks/2026-08-24-01059-mappa-knowledge.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# mappa-knowledge
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-24T18:48:55.340Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
Rewrite using-wiki + using-wiki-graph → **mappa-knowledge** (редизайн mappa-skill-suite, спека w:2605).
|
||||
|
||||
Скилл = цикл, не тул; старые имена — триггер-синонимы. Поглощает: using-wiki, using-wiki-graph (+ реф-конвенция, fold-in 2). Писать НЕЙТРАЛЬНО — не зависеть от summaries (таски #1026 нет); реф-префиксы до апгрейда #1028 — старые (w:/t:/i:), после — полные.
|
||||
|
||||
Relational/структурные вопросы (связи, backlinks, сироты) — через graph-тулы, guarded failure-mode: одна страница и стоп, без многохоповых цепочек сам.
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
- [x] skills/mappa-knowledge/SKILL.md v1.0.0 — слияние using-wiki v2.2.0 + using-wiki-graph v1.1.0 в один цикл-скил (ingest/query/lint + граф-слой для реляционных/структурных вопросов)
|
||||
- [x] Старые skills/using-wiki/ + skills/using-wiki-graph/ удалены (поглощены; имена — триггер-синонимы в description)
|
||||
- [x] lint clean (67 skills, 0 violations)
|
||||
- [x] build.sh → dist/mappa-knowledge.skill; install.sh → dual targets; старые удалены из живых диров
|
||||
- [x] GREEN micro-test: свежий pi -p на реляционном вопросе (связь таска↔спека) → активация mappa-knowledge, граф-слой (graph_path→no-path, backlinks), корректная семантика рёбер
|
||||
- [x] Писано нейтрально (summaries/#1026 не упоминается); реф-конвенция полными именами (#1028, уже была в исходниках)
|
||||
|
||||
## Notes
|
||||
|
||||
- RED-базис: триггер-поверхность унаследована из using-wiki/using-wiki-graph (прошли ревью); дельта = слияние + цикл-фрейминг + guarded failure-mode графа. Полный behavioral smoke — за #1065.
|
||||
- Побочная lint-находка GREEN-теста: рефы в прозе (не [[викилинки]]) рёбер не дают → спека может быть сиротой, «таска↔спека» в графе теряется. Это известная семантика решения 4 (рёбра только из [[refs]]), не баг скила — отмечено как наблюдение, кандидат в follow-up, если понадобится проставлять [[викилинки]] при создании тасок-промоушена.
|
||||
28
.tasks/2026-08-24-01060-mappa-brainstorm-promote.md
Normal file
28
.tasks/2026-08-24-01060-mappa-brainstorm-promote.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# mappa-brainstorm-promote
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-24T18:49:01.966Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
UPDATE workshop-promote-brainstorm → **mappa-brainstorm-promote** (редизайн mappa-skill-suite, спека w:2605). АПДЕЙТ, не rewrite.
|
||||
|
||||
Fold-in 1: mappa-service target. Промоут в mappa-сервисные борды (mappa, .common, …) — отдельный канал: сервисные тулы mcp__mappa__task_create/wiki_create (под лизом, claim через task_claim_next); pointers-таска НЕ нужна, если спека уже в вики проекта (w:NNNN) — описание импл-таски ссылается на неё; review-umbrella — сервисная таска (status=blocked, blocker=impl#); covering-письмо в инбокс цели (канон delegate-task) — в обоих каналах. Файловый путь (projects-meta → .tasks/STATUS.md) остаётся.
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
- [x] skills/mappa-brainstorm-promote/SKILL.md v1.2.0 (MINOR) — UPDATE workshop-promote-brainstorm: добавлена 4-я ветка маршрутизации **mappa-service** (fold-in 1: лиз через task_claim_next, спека через mcp__mappa__wiki_create, импл-таски через mcp__mappa__task_create, pointers-таска НЕ нужна если спека в вики w:NNNN, review-umbrella сервисная таска, covering-письмо в инбокс цели)
|
||||
- [x] NB (2026-08-24, инцидент): tasks_create ПОСЛЕДОВАТЕЛЬНО, не батчем (гонка sha-CAS счётчика agenda; при промоуте mappa-skill-suite 6/7 упали) — в шаге 8 + failure modes + what-not-to-do
|
||||
- [x] File channel (projects-meta → .tasks/STATUS.md) сохранён; шаги перенумерованы (вставлен шаг 4)
|
||||
- [x] Старое имя workshop-promote-brainstorm — триггер-синоним в description; каталог git mv
|
||||
- [x] lint clean (67 skills, 0 violations); build.sh → dist/mappa-brainstorm-promote.skill (старый .skill удалён); install.sh → dual; старый удалён из живых диров
|
||||
- [x] GREEN micro-test: свежий pi -p на «промоутни брейнсторм… таргет mappa» → активация mappa-brainstorm-promote, service channel (лиз/task_create последовательно/wiki_create/без pointers/review-umbrella/covering-письмо)
|
||||
|
||||
## Notes
|
||||
|
||||
- RED-базис: UPDATE существующего скила (триггеры не менялись); дельта = fold-in 1 + NB последовательности. Полный behavioral smoke — за #1065.
|
||||
- Актуальность шага 3 (определение канала): сервисные борды — mappa, .common (доска в mappa-сущностях); обычные проекты — файловая доска. Определение по наличию .tasks/STATUS.md.
|
||||
29
.tasks/2026-08-24-01061-mappa-delegation.md
Normal file
29
.tasks/2026-08-24-01061-mappa-delegation.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# mappa-delegation
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-24T18:49:07.632Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
Rewrite delegate-task → **mappa-delegation** (редизайн mappa-skill-suite, спека w:2605).
|
||||
|
||||
Скилл = цикл, не тул; старые имена — триггер-синонимы. Поглощает: delegate-task. Каждая кросс-проектная делегация — пара: tasks_create + covering-письмо в инбокс получателя (таска на доске не пингует живую сессию). #1054 create-без-лиза — опционально (контракт работает на текущих тулах); перейти, когда #1054 имплементится.
|
||||
|
||||
НЕ применимо: self-assigned таски на своей доске («создать задачу себе» → mappa-task-work), работа своими руками, workshop-внутренние таски.
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
- [x] skills/mappa-delegation/SKILL.md v1.0.0 — rewrite delegate-task v0.5.1 (цикл: pre-flight gate → шаблон → preview → confirm → covering-письмо → review-umbrella → downstream)
|
||||
- [x] Старый skills/delegate-task/ удалён (поглощён; имя — триггер-синоним в description)
|
||||
- [x] Suite-ссылки: using-tasks→mappa-task-work, inter-session-messaging→mappa-messaging, using-wiki→mappa-knowledge; нота лизинговой модели #1054 (create-без-лиза — опционально, контракт работает на текущих тулах)
|
||||
- [x] lint clean (67 skills, 0 violations); build.sh → dist/mappa-delegation.skill (старый .skill удалён); install.sh → dual; старый удалён из живых диров
|
||||
- [x] GREEN micro-test: свежий pi -p на «создать задачу на агента… common» → активация mappa-delegation, обязательная пара tasks_create + covering-письмо (адрес из адресной книги, [event: created]), review-umbrella с наследованием weight
|
||||
|
||||
## Notes
|
||||
|
||||
- RED-базис: тело унаследовано из delegate-task v0.5.1 (прошёл ревью + smoke); дельта = rename, suite-ссылки, цикл-фрейминг, нота #1054. Полный behavioral smoke — за #1065.
|
||||
- Поглощает delegate-task без потери контента (все шаги 1–7 сохранены, включая weight-наследование review и downstream-правило task+letter).
|
||||
31
.tasks/2026-08-24-01062-mappa-task-work.md
Normal file
31
.tasks/2026-08-24-01062-mappa-task-work.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# mappa-task-work
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-24T18:49:13.376Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
Rewrite using-tasks + task-format + task-loop + priority-due → **mappa-task-work** (редизайн mappa-skill-suite, спека w:2605). Центральный, крупный.
|
||||
|
||||
Скилл = цикл, не тул; старые имена — триггер-синонимы. Поглощает: using-tasks, task-format (вливается), task-loop (loop-mode ВНУТРИ, вариант A — отдельный скилл не создаётся), priority-due-раздел (P0-P2 + дедлайны: приоритет = территория человека, агенты ставят только при создании; дефолт P1; дедлайн-механика: notify при просрочке без авто-бампа).
|
||||
|
||||
Цикл: выбор работы (claim) → исполнение → сдача (close + review-umbrella). Один триггер-сёрфейс: «поработай очередь» / «work the queue» → mode=loop.
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
- [x] skills/mappa-task-work/SKILL.md v1.0.0 — центральный цикл: ориентация → выбор работы (claim, priority/due) → исполнение → сдача (close + review-umbrella) + пауза/переключение
|
||||
- [x] Loop-mode ВНУТРИ (вариант A, отдельный скил не создаётся): «поработай очередь»/«work the queue» → цикл claim→work→close→claim; пустая очередь = стоп, без демона/CronCreate; session_break gate; consult gate (human-only/strict-human → STOP перед close/commit)
|
||||
- [x] Priority/Due-раздел: приоритет = территория человека, агент ставит только при создании, дефолт P1, просрочка → admin_overdue_scan notify однократно, без авто-бампа
|
||||
- [x] Формат таски (из task-format): mappa task_create схема (priority/due при создании) + legacy STATUS.md блок (переходный, Weight/Notify обязательны)
|
||||
- [x] Поглощены: using-tasks (борд/лиз/close/notify/рефы [[task:N]]), task-format (формат), task-loop (loop-mode), task-priority-due (раздел). Старые имена — триггер-синонимы в description
|
||||
- [x] lint clean (65 skills, 0 violations); build.sh → dist/mappa-task-work.skill (старые .skill удалены); install.sh → dual; старые удалены из живых диров
|
||||
- [x] GREEN micro-test: свежий pi -p на «поработай очередь» → активация mappa-task-work, loop-mode, стоп-гейты, пустая очередь = стоп без поллинга
|
||||
|
||||
## Notes
|
||||
|
||||
- RED-базис: контент унаследован из трёх скилов (все прошли ревью/smoke); дельта = слияние + цикл-фрейминг + priority/due раздел. Полный behavioral smoke (вкл. loop-mode, session-break, empty-stop) — за #1065.
|
||||
- Убраны: task-loop ссылки на projects-meta claim (primary — mappa task_claim_next; file channel — переходный, описан в секции legacy).
|
||||
30
.tasks/2026-08-24-01063-mappa-closing-ritual.md
Normal file
30
.tasks/2026-08-24-01063-mappa-closing-ritual.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# mappa-closing-ritual
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-24T18:49:19.363Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
НОВЫЙ скилл **mappa-closing-ritual** (редизайн mappa-skill-suite, спека w:2605).
|
||||
|
||||
Финиш-фаза форкфлоу: session-handoff(write) + PROPOSE wiki-ingest + task closes + sweep. Старт ≠ финиш: closing-ritual = write-path с процедурой и подтверждением. Ad-hoc: mode=light — явный вопрос «Сделать handoff?» в конце сессии (НЕ автоматический sweep); решение за человеком. Поглощает: session-handoff(write-часть).
|
||||
|
||||
Handoff: sliding, per-project, versioned-история; read на старте — mappa-session-orient, write на финише — тут. Мутации (handoff write / wiki-ingest / task closes) — только после подтверждения пользователя.
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
- [x] skills/mappa-closing-ritual/SKILL.md v1.0.0 — НОВЫЙ скилл (финиш-фаза): scope check → mid-task capture → compose handoff → handoff_write (версия h:N) → PROPOSE wiki-ingest → PROPOSE task closes → один блок-предложение; мутации только после «да»
|
||||
- [x] mode=light для ad-hoc: явный вопрос «Сделать handoff?», НЕ автоматический sweep; решение за человеком
|
||||
- [x] Поглощает session-handoff (write-часть); read-часть уходит в mappa-session-orient (#1064); старое имя — триггер-синоним
|
||||
- [x] Старый skills/session-handoff/ удалён (включая hooks/commit-detector — новый дизайн: ритуал на session-end, не на substantive commit)
|
||||
- [x] lint clean (65 skills, 0 violations); build.sh → dist/mappa-closing-ritual.skill; install.sh → dual; старый удалён из живых диров
|
||||
- [x] GREEN micro-test: свежий pi -p на «завершаем сессию» → активация mappa-closing-ritual, полный ритуал (7 шагов), мутации только после «да», mode=light «Сделать handoff?»
|
||||
|
||||
## Notes
|
||||
|
||||
- RED-базис: write-процедура унаследована из session-handoff v1.0.0 (прошёл ревью); дельта = split read/write + mode=light + confirm-гейт. Полный behavioral smoke (триггеры свои + false-positive на task-зоне) — за #1065.
|
||||
- commit-detector hooks удалены осознанно: suite проектирует closing-ritual как session-end-driven, а не commit-driven.
|
||||
31
.tasks/2026-08-24-01064-mappa-session-orient.md
Normal file
31
.tasks/2026-08-24-01064-mappa-session-orient.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# mappa-session-orient
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-24T18:49:25.792Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
НОВЫЙ скилл **mappa-session-orient** (редизайн mappa-skill-suite, спека w:2605). Самый новый, делается ПОСЛЕДНИМ.
|
||||
|
||||
Старт-фаза форкфлоу: контракт + чтение (нужен и для ad-hoc, где нет AGENTS.md-контракта). Поглощает: pulling-before-work (полный цикл --ff-only), session-handoff(read), session-inbox-monitor(raise), using-system-snapshot (liveness-сводка «живо/мертво», одна строка), live-ingest query (потребитель session-live-ingest: GET /session?project=, stale-active детект, «другая связка + не завершена» → предложение: забить / дернуть письмом / продолжить).
|
||||
|
||||
Граница: session-orient = «живо/мертво»; глубокая диагностика — вне suite (адхок). Эскалация: проблема на старте → не углубляться, передать человеку/диагностической сессии.
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
- [x] skills/mappa-session-orient/SKILL.md v1.0.0 — старт-фаза: контракт → pull (--ff-only, полный цикл) → handoff read (staleness >7д → ask; orient+ask, без auto-execute) → inbox raise+sweep → liveness-сводка (meta_health/admin_status/snapshot, «живо/мертво») → live-ingest query (session_list, stale-active краш-детект, «другая связка → предложить»)
|
||||
- [x] Граница orient/ops (w:2605 round 3): «живо/мертво»; проблема на старте → эскалация человеку/диагностической сессии, не углубление
|
||||
- [x] Поглощены: pulling-before-work, session-handoff(read), session-inbox-monitor(raise), using-system-snapshot (liveness); старые имена — триггер-синонимы
|
||||
- [x] Live-ingest 404-skip задокументирован (роуты /session не задеплоены — сервер #1022 в репо, деплой ждёт #1055); контракт — w:2604
|
||||
- [x] mappa-messaging: ссылки session-inbox-monitor → mappa-session-orient (inbox raise) обновлены (3 места)
|
||||
- [x] lint clean (63 skills, 0 violations); build.sh → dist/mappa-session-orient.skill; install.sh → dual; поглощённые удалены из живых диров
|
||||
- [x] GREEN micro-test: свежий pi -p на «начало сессии» → ритуал по шагам (контракт→pull→handoff→inbox→liveness→live-ingest), граница «живо/мертво» + эскалация, 404-skip, read-only
|
||||
|
||||
## Notes
|
||||
|
||||
- #1064 была 🔵 blocked ← #1024 (клиент session-sync). Скил-документ завершён по контракту w:2604/w:2605; live-ingest E2E (шаг 6) отложен: сервер #1022 не задеплоен (#1055), клиент #1024 (.common) открыт. 404-skip в скиле — ориентация не блокируется.
|
||||
- RED-базис: контент унаследован из 4 поглощённых скилов (все прошли ревью); дельта = слияние + live-ingest query + граница orient/ops. Полный behavioral smoke — за #1065.
|
||||
49
.tasks/2026-08-24-01065-mappa-skill-suite-review.md
Normal file
49
.tasks/2026-08-24-01065-mappa-skill-suite-review.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# mappa-skill-suite-review
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-24T18:49:35.610Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
Skill-review checkpoint для mappa-skill-suite (промоушен 2026-08-24).
|
||||
|
||||
**Спецификация:** w:2605 concepts/mappa-skill-suite (mappa wiki). **Источник дизайна (trace):** .workshop/.archive/2026-08-24-mappa-skill-suite.md.
|
||||
**Импл-таски:** #1058 mappa-messaging, #1059 mappa-knowledge, #1060 mappa-brainstorm-promote, #1061 mappa-delegation, #1062 mappa-task-work, #1063 mappa-closing-ritual, #1064 mappa-session-orient.
|
||||
|
||||
**Кто делает:** **не имплементер.** Другая сессия / другой день / другой агент (identity-not-location).
|
||||
|
||||
**Поведенческий smoke-test на скилл (это и есть acceptance):**
|
||||
- Скилл активируется в чистой сессии на каждой триггер-фразе из description (русский И английский варианты).
|
||||
- Скилл **не** активируется на 2-3 близких но не своих фразах из соседних доменов (false-positive check).
|
||||
- Каждый шаг секции Steps отрабатывает на тестовом буфере без ошибок.
|
||||
- Failure modes уводят в abort, не в частичный успех.
|
||||
- What NOT to do соответствует реальности.
|
||||
|
||||
**Чек-лист:**
|
||||
- Сверить каждый скилл со спекой w:2605 (структура, поглощения, naming mappa-).
|
||||
- Старые имена работают как триггер-синонимы (inter-session-messaging, using-wiki, delegate-task, workshop-promote-brainstorm, using-tasks, session-handoff, pulling-before-work…).
|
||||
- mappa-session-orient сделан ПОСЛЕДНИМ и учитывает live-ingest (#1022/#1024).
|
||||
- mappa-task-work: loop-mode, priority/due-раздел, session-break.
|
||||
|
||||
Findings → follow-up tasks через tasks_create в OpeItcLoc03/skills.
|
||||
|
||||
**Закрытие:** только когда все findings зафайлены ИЛИ ревьюер подтвердил «нет findings» в close-note.
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
- [x] Ревью запущено через clean-context субагентов (не-имплементер identity: review_subagent с чистой спецификацией + свежие pi -p сессии без истории) — метод review-kit-pi-method
|
||||
- [x] **Структурное ревью vs w:2605 — 7/7:** batch 1 (messaging/knowledge/promote/delegation): 3 PASS, promote NEEDS-WORK → исправлено (cycle/procedure фрейминг, фикс 78542c0); batch 2 (task-work/closing-ritual/session-orient): 3 PASS
|
||||
- [x] **Минорные findings исправлены:** EN-триггеры в messaging (78542c0), attribution review-umbrella в task-work (45baadc); остальные миноры — стилистические (inline-absorption vs таблица), не блокеры
|
||||
- [x] **Behavioral smoke (свежие pi -p, чистая сессия):**
|
||||
- Позитив (старые имена = синонимы): using-tasks → mappa-task-work, using-wiki → mappa-knowledge, delegate-task → mappa-delegation, «напиши письмо» → mappa-messaging, «промоутни… таргет mappa» → mappa-brainstorm-promote (service channel), «завершаем сессию» → mappa-closing-ritual, «начало сессии» → mappa-session-orient, «поработай очередь» → loop-mode
|
||||
- Негатив: «поставь таску себе» → НЕ делегирование (mappa-task-work территория), «отбой» → анти-триггер, без активации
|
||||
- [x] **Отложенные зависимости (не findings):** live-ingest E2E (шаг 6 session-orient) — после деплоя #1055 + клиента #1024 (404-skip задокументирован в скиле); build-hermes unmapped — pre-existing
|
||||
|
||||
## Notes
|
||||
|
||||
- Ревьюер-identity: .workshop (решение оператора) через clean-context субагентов — identity-not-location, имплементерская сессия не оценивала свои артефакты сама.
|
||||
- Verdict: APPROVE-WITH-FINDINGS → все findings зафайлены и исправлены (3 фикса), блокеров нет.
|
||||
@@ -0,0 +1,25 @@
|
||||
# mappa-brainstorm-promote-storm-channel
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-08-25T06:00:37.319Z -->
|
||||
|
||||
|
||||
## Goal
|
||||
Апдейт скила mappa-brainstorm-promote (1.5.0 → 1.6.0): миграция с файлового канала на mappa storm-сущности.
|
||||
|
||||
Скоуп:
|
||||
1. Буфер шторма = mappa storm-сущность (type=storm) в ЛЮБОМ проекте (не файл .workshop/.brainstorm/). Скил становится project-agnostic: шторм живёт там, где его ведут, не только в воркшопе.
|
||||
2. Промоут mappa-service маршрута через storm_promote (атомарно buffer → wiki-страница + archive, решение 7), не через git mv в .workshop/.archive/.
|
||||
3. Зафиксировать «штормы в любом проекте» в mappa-спеке (concepts/mappa) — сейчас скил воркшоп-центричный.
|
||||
4. Workshop-meta маршрут: файловые .brainstorm/.archive остаются только для локальной методологии зоны — или мигрируют тоже (решить в таске).
|
||||
5. Summary-дисциплина уже в 1.5.0 (9b606f7) — не дублировать.
|
||||
|
||||
Контекст: решение оператора 2026-08-25 («штормы могут вестись не только в воркшопе»). Связано: wiki:2661 (unified search — storm-карточки), task:1048 (review mappa-wiki-search). Исполнитель — workshop-сессия (оператор: «ты сам сделаешь в новой сессии»).
|
||||
|
||||
## Key files
|
||||
|
||||
## Decisions log
|
||||
|
||||
## Open questions
|
||||
|
||||
## Completed steps
|
||||
|
||||
## Notes
|
||||
3
.tasks/NEXT_SESSION.md
Normal file
3
.tasks/NEXT_SESSION.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# ⛔ Файловая доска закрыта
|
||||
|
||||
**Не читать. Не править.** Канон — mappa (`mcp__mappa__task_*`): task-сущности проекта. Скил: `mappa-task-work`.
|
||||
232
.tasks/STATUS.md
232
.tasks/STATUS.md
@@ -1,231 +1,3 @@
|
||||
# Task Board
|
||||
_Updated: 2026-05-05 (interns-repo-read-skill-updates done — both skills 0.2.0)_
|
||||
# ⛔ Файловая доска закрыта
|
||||
|
||||
<!--
|
||||
Canonical layout. One block per task. Per-task deep context lives in
|
||||
.tasks/<task-slug>.md (created by using-tasks when a task becomes active
|
||||
or paused). Historical Done entries dropped — git log is the history.
|
||||
|
||||
Status legend:
|
||||
🔴 Active — only one at a time
|
||||
🟡 Paused — in progress, resumable
|
||||
⚪ Ready — defined, not started
|
||||
🟢 Done — kept until merged
|
||||
🔵 Blocked — waiting on external input
|
||||
-->
|
||||
|
||||
## 🟡 [skill-readmes] — write English README.md for every skill + translate root README
|
||||
**Status:** paused
|
||||
**Where I stopped:** infra-skill cluster done — READMEs for `project-bootstrap`, `setup-wiki`, `setup-tasks`, `using-wiki`, `using-tasks`; root README translated; cross-links between all five skills wired up
|
||||
**Next action:** continue with the next batch — suggest the caveman cluster (`caveman`, `caveman-commit`, `caveman-review`, `caveman-help`, `caveman-compress`, `compress`) since they form a coherent group; or jump to `active-platform`, `find-skills`, `setup-context7`, `using-context7`, `using-markitdown` if the caveman cluster needs deduplication first (see `compress-dedup` task)
|
||||
**Branch:** master
|
||||
|
||||
---
|
||||
|
||||
## 🟢 [bootstrap-skill-deps-check] — refactor project-bootstrap Step 5.6 into a generic skill-dependencies check (replaces per-skill `Step 5.X` mirror shape)
|
||||
**Status:** done
|
||||
**Where I stopped:** `skills/project-bootstrap/SKILL.md` Step 5.6 переписан с single-skill `superpowers`-only detector на generic `trigger → fulfiller` table walker (9-row inline map: 8 skills + 1 plugin; `kind` flag drives install-command emission); README Workflow Step 5.6 description обновлён под новую форму; `version:` 1.6.0 → 1.7.0 (MINOR — adds capability, absorbs prior detector cleanly); `dist/project-bootstrap.skill` rebuilt + installed; `~/.claude/skills/project-bootstrap/SKILL.md` shows `version: 1.7.0`; design page `.wiki/concepts/bootstrap-skill-deps-check.md` written (rationale: why generic over per-skill mirrors, skill/plugin kind distinction, MCP-server caveat, source-of-truth invariant between SKILL map ↔ `assets/CLAUDE.md.template`); `.wiki/index.md` + `.wiki/log.md` updated. Subsumes `[bootstrap-recommend-projects-meta]` by absorption.
|
||||
**Next action:** (none — kept until merged)
|
||||
**Branch:** master
|
||||
|
||||
---
|
||||
|
||||
## 🟢 [bootstrap-recommend-projects-meta] — Step 5.7 in project-bootstrap: recommend `setup-projects-meta` if MCP tools missing
|
||||
**Status:** done
|
||||
**Where I stopped:** closed by absorption 2026-05-05 — `[bootstrap-skill-deps-check]` shipped a generic Step 5.6 that walks the whole canonical trigger list (`using-projects-meta` is one of 9 rows in the inline `trigger → fulfiller` map). The per-skill mirror this task envisioned was rejected as a copy-paste explosion shape; the generic walker handles the same case + the analogous gap for every other canonical trigger.
|
||||
**Next action:** (none — kept until merged)
|
||||
**Branch:** master
|
||||
|
||||
---
|
||||
|
||||
## 🟢 [compress-dedup] — resolve compress vs caveman-compress duplication
|
||||
**Status:** done
|
||||
**Where I stopped:** `skills/compress/` deleted as a byte-identical dupe of `skills/caveman-compress/` (SHA256 match across all 7 scripts/ files; SKILL.md diff was `name:` + Process step 2 only; README + SECURITY only in caveman-compress). Ported the better Process-step wording from compress (`cd <directory_containing_this_SKILL.md>` instead of brittle `cd caveman-compress`) into `skills/caveman-compress/SKILL.md`. Added `version: 1.0.0` to caveman-compress frontmatter (first versioned release; aligns with skill-versioning concept). Removed: `skills/compress/`, `dist/compress.skill`, `~/.claude/skills/compress/` (manual prune — install.sh has no prune step). Rebuilt `dist/caveman-compress.skill` + reinstalled to `~/.claude/skills/caveman-compress/` (verified `version: 1.0.0` + new Process step on disk). Harness skill listing confirms `compress` is gone, only `caveman-compress` remains. `.wiki/concepts/compress-dedup.md` written (rationale + rejected alternatives: alias-stub has no harness mechanism, "keep both" wastes listing budget, "delete caveman-compress" loses README + SECURITY); `.wiki/index.md` + `.wiki/log.md` updated.
|
||||
**Next action:** (none — kept until merged)
|
||||
**Branch:** master
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [install-ps1] — paired install.sh + install.ps1 (cross-platform parity, with --prune)
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started) — `install.sh` exists, `install.ps1` missing; both must coexist (PS users on Windows shouldn't be forced into git-bash, Linux/Mac users shouldn't be forced into pwsh). Cross-platform = bash + PS *paired*, behaviorally identical.
|
||||
**Next action:** (a) write `scripts/install.ps1` mirroring `install.sh` logic (copy `skills/<name>/` → `~/.claude/skills/<name>/`, support `$env:CLAUDE_SKILLS_DIR` override); (b) add `--prune` flag to **both** scripts that drops `~/.claude/skills/<name>/` for any name not in `skills/<name>/` (lesson from `[compress-dedup]` — manual prune was needed because install.sh can't); (c) confirm `build.ps1`/`build.sh` are already paired (they are) and document the parity invariant in `.wiki/concepts/install-cross-platform.md`. README's install quick-start should show both variants side-by-side per `active-platform` cross-platform-docs convention.
|
||||
**Branch:** (not started)
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [archive-roundtrip-test] — smoke-test for .skill archive shape
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started) — caught the PowerShell-Compress-Archive backslash bug manually; a smoke-test would catch the next regression automatically
|
||||
**Next action:** add a script that builds `dist/<name>.skill`, unzips into a temp dir, and `diff -r` against `skills/<name>/`. Fail on any difference. Run from CI or pre-commit if we add one
|
||||
**Branch:** (not started)
|
||||
|
||||
---
|
||||
|
||||
## 🟡 [active-platform-eval] — eval-driven tuning of active-platform (description + body), absorbs `[active-platform-tuning]`
|
||||
**Status:** paused
|
||||
**Where I stopped:** design doc complete (`.wiki/concepts/active-platform-eval-design.md`, ~150 lines); per-task file complete (`.tasks/active-platform-eval.md`); STATUS.md collapsed the two original ⚪ tasks into this one block. Pre-flight verified: `claude` CLI on PATH at `C:\nvm4w\nodejs\claude.ps1` (Claude Code 2.1.128); `run_loop.py` present at `~/.claude/plugins/cache/claude-plugins-official/skill-creator/unknown/skills/skill-creator/scripts/run_loop.py`. Stopped right before eval-set authoring at user request — paused for asynchronous follow-up. No code touched, no tooling launched, no `.tasks/active-platform-eval/` workspace dir created yet.
|
||||
**Next action:** resume by answering Q2 from the chat ("eval set — write 20 queries solo from current SKILL.md + concept-page open questions, or run skill-creator's HTML review template first for user-driven edits before kickoff?"), then (a) build `.tasks/active-platform-eval/eval-set.json`, (b) snapshot skill to `.tasks/active-platform-eval/skill-snapshot/`, (c) launch run_loop.py in background, (d) parallel manual body sweep, (e) apply changes + bump to 1.1.0 + rebuild + reinstall + final report + commit.
|
||||
**Branch:** master
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [skills-grouping-revisit] — revisit flat vs grouped skills/ layout if count grows past ~30
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started) — current 14 skills fit fine in flat `skills/`; threshold for revisiting is ~30
|
||||
**Next action:** when triggered (skill count crosses threshold), evaluate variant B (grouped by family) vs variant C (flat + manifest) from the original brainstorm in `.wiki/concepts/repo-layout.md`
|
||||
**Branch:** (not started)
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [setup-interns-fix-paths] — fix `<project-root>/.common/...` cwd-relative paths in `setup-interns` SKILL.md (mirror of done `using-projects-meta-fix-paths`)
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started) — surfaced 2026-05-06 during factory-bootstrap field-test on fresh Win11 laptop. `/setup-interns` Phase 1 stopped with "`.common/lib/interns-mcp/` not found" because claude was launched from `C:\Windows\System32` (cwd inherited). The skill resolves all `.common/` paths relative to cwd. Sister skill `setup-projects-meta` uses absolute `~/projects/.common/...` (fixed in [using-projects-meta-fix-paths]) — `setup-interns` is the next inconsistency. Field-test workaround: `cd $PROJECTS_DIR` before launching claude.
|
||||
**Next action:** in `setup-interns/SKILL.md` Phase 0/1/2/3/4/5/6/7 — replace every `<project-root>/.common/...` with `~/projects/.common/...` (POSIX-absolute, matches `setup-projects-meta` after the [using-projects-meta-fix-paths] fix). Audit Bash blocks too. Bump `setup-interns` version (PATCH — doc consistency, no behavior change). Rebuild `dist/setup-interns.skill`, install to `~/.claude/skills/setup-interns/`, verify `version` on disk. Long-term: factor `~/projects` out into `$FACTORY_PROJECTS_DIR` (read from `~/.config/factory/home.toml`) once `factory` CLI lands — track separately. Field-test artefact: `.factory/L0/install-log.md` шаг 11c-2 в gitea `OpeItcLoc03/factory`.
|
||||
**Branch:** master
|
||||
<!-- created-by: vitya@.meeting-room (director) / from: factory-bootstrap field-test / 2026-05-06 -->
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [setup-projects-meta-token-leak] — fix token leak: `setup-projects-meta` falls back to `https://USER:TOKEN@host/...` clone URL on auth failure, persists token in `.git/config`
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started) — surfaced 2026-05-06 during factory-bootstrap field-test on fresh Win11 laptop. Phase 4 of `/setup-projects-meta` ran `git clone https://git.kzntsv.site/...` first; it failed with `Failed to authenticate user` (Bash tool runs git non-interactive; GCM not available there). Skill auto-retried with `git clone https://USER:TOKEN@host/...` — succeeded BUT git persists the URL with embedded creds in `.git/config` of the cloned repo. Two repos affected (`projects-meta-mcp`, `projects-wiki`). Field-test mitigation: PAT rotated, `git remote set-url origin <clean-url>` in both clones.
|
||||
**Next action:** in `setup-projects-meta/SKILL.md` Phase 4, replace the credential-in-URL retry with the per-invocation extraheader form: `git -c http.extraheader="Authorization: token $T" clone <url> <target>`. The extraheader is request-scoped — git does NOT persist it in the cloned repo's `.git/config`. Verify on the field-test ноуте: re-clone, `git -C <repo> config --get remote.origin.url` should print the bare URL, no token. Bump `setup-projects-meta` version (PATCH — security fix). Update SKILL.md README. Field-test artefact: `.factory/L0/install-log.md` шаг 11c-1 в gitea `OpeItcLoc03/factory`.
|
||||
**Branch:** master
|
||||
<!-- created-by: vitya@.meeting-room (director) / from: factory-bootstrap field-test / 2026-05-06 -->
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [refresh-project-bootstrap] — Run the `project-bootstrap` skill in this repo to refresh its layout to the canonical state (git, .gitignore, README.md, .wiki/, .tasks/, CLAUDE.md). The skill handles both greenfield bootstrap and refresh of existing repos.
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started)
|
||||
**Next action:** Invoke the `project-bootstrap` skill at the repo root, confirm each file write, push to main.
|
||||
**Branch:** n/a
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: projects-meta-mcp / 2026-05-01T09:03:49.873Z -->
|
||||
|
||||
---
|
||||
|
||||
## 🟢 [using-projects-meta-fix-paths] — fix stale `~/.local/projects-meta-mcp/` paths in `setup-projects-meta` SKILL.md
|
||||
**Status:** done
|
||||
**Where I stopped:** `setup-projects-meta/SKILL.md` lines 152–154 (Phase 5 platform-path table) переписаны с `~/.local/projects-meta-mcp` на `~/projects/.common/lib/projects-meta-mcp` (Windows/Linux/macOS варианты); `version:` bump 1.0.0 → 1.0.1 (PATCH, doc consistency); rebuild `dist/setup-projects-meta.skill` + install в `~/.claude/skills/setup-projects-meta/` подтверждены (frontmatter `version: 1.0.1` в установленной копии); `using-projects-meta/{SKILL,README}.md` уже были чистые из прошлых коммитов; line 224 (`Path forms (~/.local/..., ~/.config/..., ~/projects/...) are identical on all three.`) намеренно оставлена как generic POSIX-path syntax aside, не projects-meta install reference
|
||||
**Next action:** (none — kept until merged)
|
||||
**Branch:** master
|
||||
<!-- created-by: vitya@local / from: meeting-room / 2026-05-05 -->
|
||||
|
||||
---
|
||||
|
||||
## 🟢 [interns-repo-read-skill-updates] — Skill-side updates for the `repo_read` intern (design at claude-skills/.wiki/concepts/interns-repo-read-design.md). Two coordinated edits: (1) `using-interns/SKILL.md` routing section — add hints on when to use `repo_read` vs `bulk_text_read`, MINOR bump; (2) `setup-interns/SKILL.md` — add Node-in-PATH check + optional `npx repomix@latest --version` pre-warm step, MINOR bump. Blocked by `common#interns-repo-read-impl` only for end-to-end test; skill edits themselves can ship in parallel.
|
||||
|
||||
**Status:** done
|
||||
**Where I stopped:** both skills edited (0.1.0→0.2.0), rebuilt + installed, versions verified on disk
|
||||
**Next action:** (none — kept until merged)
|
||||
**Branch:** n/a
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: .meeting-room / 2026-05-05T20:05:05.877Z -->
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [project-creation-lifecycle-skill] — Extend `project-bootstrap` (or add a new `create-project` skill) to cover the **full new-project lifecycle**, not just upgrading an existing folder.
|
||||
|
||||
**Gap surfaced 2026-05-06** при промоушене брейнсторма `factory-bootstrap`: репо `git.kzntsv.site/OpeItcLoc03/factory` был создан ad-hoc (git init + gitea repo create + push), без бутстрапа `.tasks/STATUS.md` и `.wiki/index.md`. Из-за этого `projects-meta-mcp:sync-runner.ts:69` отбрасывал репо как «не проект», и `knowledge_ingest target=factory` / `tasks_create target=factory` валились с «project not in cache». Промоушн встал, пришлось вручную сидить layout через прямые `Write` + push. Это чинится один раз в скиле, а не каждый раз руками.
|
||||
|
||||
**Что должен делать новый flow** (один обход):
|
||||
1. Создать локальную папку `~/projects/<dotpath>/` (валидация: latin, kebab-case, не существует).
|
||||
2. `git init` + первоначальный `.gitignore` + минимальный `README.md`.
|
||||
3. Создать гитеа-репо в org/user через Gitea API (auth из `~/.config/projects-mcp/auth.toml`), set remote, push initial commit.
|
||||
4. Делегировать в `setup-wiki` + `setup-tasks` для канонического layout (или inline-fallback с записью в bootstrap-manifest).
|
||||
5. `node ~/projects/.common/lib/projects-meta-mcp/dist/sync.js` — re-sync кэша, чтобы новый репо стал виден projects-meta.
|
||||
6. Опционально: `tasks_create target=_meta slug=<proj>-onboarded` — чтобы новый проект засветился на кросс-проектном борде с момента создания.
|
||||
|
||||
**Два варианта дизайна — выбрать в скил-creator:**
|
||||
- **(a) Extend `project-bootstrap`** — добавить flag `--create` (или авто-detection «папки нет / git remote нет»), который запускает шаги 1–3 и 5–6. Существующий path для «уже существующая папка → upgrade» сохраняется. Плюс: один скил для всего lifecycle. Минус: SKILL.md распухает.
|
||||
- **(b) Новый скил `create-project`** — отдельный entry-point, в конце дёргает `project-bootstrap` для шагов 4 (layout). Плюс: single-responsibility. Минус: ещё один скил в реестре, юзеру выбирать какой звать.
|
||||
|
||||
Склоняюсь к (a) — `project-bootstrap` уже знает про оба режима init/upgrade (см. SKILL.md Step 0), четвёртый под-режим «greenfield + remote create» естественно туда ложится. Но это решение уровня skill-creator.
|
||||
|
||||
**Acceptance criteria:**
|
||||
- Новый flow прогоняется на пустой папке: `~/projects/.test-greenfield/` → один вызов скила → конец: репо в gitea, layout в `.wiki/`/`.tasks/`, виден в `mcp__projects-meta__meta_status`.
|
||||
- Существующий upgrade-mode не сломан (regression-test на `.factory/` после этого фикса — re-run должен быть no-op).
|
||||
- README скила обновлён.
|
||||
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started)
|
||||
**Next action:** skill-creator: выбрать вариант (a) extend project-bootstrap vs (b) new create-project; реализовать; smoke-test на пустой папке.
|
||||
**Branch:** n/a
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: .meeting-room / 2026-05-06T18:19:47.732Z -->
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [extend-project-discipline-brainstorm-workspaces] — Расширить `project-discipline` (`C:\Users\vitya\.claude\skills\project-discipline\SKILL.md`) явным обращением к **transit-zone / brainstorm-workspaces** типа `~/projects/.meeting-room/`.
|
||||
|
||||
**Gap surfaced 2026-05-05:** Rule 1 скила («project conventions override skill defaults») написан для проектов с `.wiki/` / `.tasks/`. Не покрывает кейс, когда workspace **сам по себе** — discussion-zone, и его README/CLAUDE.md явно говорит «здесь no `.tasks/`, transit zone, всё уезжает в глобал». В той сессии я неправильно применил «transit-zone autopilot» — потащил artifact из брейнсторма в `~/projects/.wiki/concepts/` без явной директивы пользователя. Корректировка: artifacts уезжают в `.brainstorm/<topic>.md` (in-progress) ИЛИ в глобал-вики (mature, user-directed) — никогда автопилотом по аналогии с Rule 1.
|
||||
|
||||
**Предлагаемая поправка к SKILL.md:**
|
||||
1. Default destination для in-progress brainstorm artifacts: `.brainstorm/<topic>.md` (или чем README workspace'а это объявил).
|
||||
2. Default destination для mature, cross-cutting outputs: `~/projects/.wiki/concepts/<topic>-design.md` через `mcp__projects-meta__knowledge_ingest` — **только** когда user явно это направил.
|
||||
3. Агент **не должен** auto-promote brainstorm-артефакты в глобал-вики по аналогии с Rule 1; convergence-moment решение принадлежит user'у.
|
||||
|
||||
**Reference:** `.meeting-room/CLAUDE.md` уже описывает «hard rules» этого workspace'а (правила §1–§4) — это конкретный пример того, что project-discipline должен явно поддерживать.
|
||||
|
||||
**Acceptance criteria:**
|
||||
- В SKILL.md `project-discipline` появилась секция «Transit-zone / brainstorm workspaces» с тремя пунктами выше.
|
||||
- Регрессия: на тестовом meeting-room сессии (как 2026-05-05) агент не вытаскивает brainstorm в `.wiki/concepts/` без user-команды.
|
||||
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started)
|
||||
**Next action:** Открыть SKILL.md project-discipline; добавить секцию transit-zone workspaces; обновить version (PATCH bump); проверить что .meeting-room/CLAUDE.md служит каноничным примером.
|
||||
**Branch:** n/a
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: .meeting-room / 2026-05-06T18:27:06.441Z -->
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [recommend-dont-menu-skill] — Создать новый скил `recommend-dont-menu` (имя обсуждаемо в skill-creator) — codifies user-style override: в design-conversations, брейнстормах, code review агент даёт **одну аргументированную рекомендацию**, а не меню вариантов A/B/C/D.
|
||||
|
||||
**Why skill, not CLAUDE.md:** правило сейчас живёт в `~/.claude/CLAUDE.md` на одной машине (создан 2026-05-06). Per-machine, per-agent — на новом ноуте его не будет, Gemini/Copilot его не прочитают. Скил в claude-skills клонится на все машины как L1 component factory-manifest'а; trigger-line в CLAUDE.md template наследуется всеми проектами через project-bootstrap.
|
||||
|
||||
**Содержимое скила (SKILL.md body — готово, копируется из удалённого memory entry):**
|
||||
|
||||
> Default mode для design-questions: «Я рекомендую X, потому что Y₁, Y₂. Trade-off: Z. Возражения?»
|
||||
>
|
||||
> Альтернативы упоминать **только если они реально близки** или несут важный trade-off, который user должен взвесить — тогда коротко: «Если важно W — лучше X', но добавляет сложность; иначе X».
|
||||
>
|
||||
> Не перечислять варианты ради видимости вариативности. Меню тормозит когда один вариант очевидно лучше — вынуждает читать заведомо проигрышные опции и задвигает позицию агента за обтекаемое перечисление вместо ответственной рекомендации.
|
||||
>
|
||||
> Это override стандарта `superpowers:brainstorming`, где multiple-choice указан как preferred. User instructions > skill defaults.
|
||||
|
||||
**Frontmatter (черновик):**
|
||||
```yaml
|
||||
---
|
||||
name: recommend-dont-menu
|
||||
description: Use during design discussions, brainstorming, architecture reviews, or any "what should we do" question — give one argued recommendation with explicit trade-offs, not a multiple-choice menu. Override of superpowers:brainstorming default.
|
||||
version: 0.1.0
|
||||
---
|
||||
```
|
||||
|
||||
**Triggers (когда скил активируется):**
|
||||
- Любые design / architecture / "что выбрать" вопросы.
|
||||
- Активные брейнстормы (где `superpowers:brainstorming` тоже бы подцепилось — этот скил **переопределяет** его стиль).
|
||||
- Code review с альтернативами.
|
||||
- В `.meeting-room/` — постоянно (в её workspace contract это default для совещаний).
|
||||
|
||||
**Cross-agent applicability:** скил — про стиль ответа, не про tool calls, поэтому работает на любом агенте без mappings (в отличие от `using-superpowers`, которому нужны `references/copilot-tools.md` и т.д.). В description явно отметить «works on any agent — pure response-style rule».
|
||||
|
||||
**Integration tasks:**
|
||||
1. **Trigger-line в `project-bootstrap` CLAUDE.md template.** Добавить строку в canonical set (`assets/CLAUDE.md.template`, см. `project-bootstrap/SKILL.md` Step 5). Кандидаты: `prefer single recommendations`, `recommend, don't menu`, `argued recommendations`. Решает skill-creator. После — в Step 5.6 (skill dependencies check) добавить новую строку в trigger→fulfiller table.
|
||||
2. **Свернуть `~/.claude/CLAUDE.md`** на машинах, где скил установлен, до одной trigger-строки. Текущее содержимое (1 параграф правила) переносится в SKILL.md body, в global CLAUDE.md остаётся только триггер.
|
||||
3. **Cross-agent prop:** trigger-line должен попасть в `~/.gemini/GEMINI.md` и `~/.copilot/AGENTS.md` — следствие, отдельная подзадача (либо часть `setup-*` для соответствующих агентов, либо часть будущего factory L1 manifest'а).
|
||||
|
||||
**Acceptance criteria:**
|
||||
- `~/.claude/skills/recommend-dont-menu/SKILL.md` существует, проходит skill-validation.
|
||||
- Trigger-line в `project-bootstrap/assets/CLAUDE.md.template` + соответствующий ряд в Step 5.6 trigger→fulfiller table.
|
||||
- Регрессионный smoke-test: в test-сессии после установки скила я (агент) на «как лучше — X или Y?» отвечаю «рекомендую X, потому что Z. Возражения?» вместо меню.
|
||||
- В `using-superpowers/SKILL.md` или `superpowers:brainstorming` упомянут override (либо через priority-секцию, которая уже есть: «User instructions > Superpowers skills > Default»).
|
||||
|
||||
**Reference:** правило выкристаллизовалось в брейнсторме interns 2026-05-05, проверено многократно в `.meeting-room/` сессиях. Source content до удаления memory лежал в `feedback_brainstorm_recommend_dont_menu.md` (memory была удалена 2026-05-06 после переноса в `~/.claude/CLAUDE.md`, который сам теперь временный).
|
||||
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started)
|
||||
**Next action:** skill-creator: подобрать имя (recommend-dont-menu vs alternatives), выбрать trigger-фразу, создать SKILL.md, добавить triger-line в project-bootstrap template, убрать дубликат из ~/.claude/CLAUDE.md.
|
||||
**Branch:** n/a
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: .meeting-room / 2026-05-06T18:31:57.105Z -->
|
||||
|
||||
---
|
||||
**Не читать. Не править.** Канон — mappa (`mcp__mappa__task_*`): task-сущности проекта. Скил: `mappa-task-work`.
|
||||
|
||||
@@ -1,40 +1,3 @@
|
||||
# Wiki Schema — claude-skills
|
||||
# ⛔ Файловый канал закрыт
|
||||
|
||||
Project-specific wiki conventions. Read this before any wiki operation.
|
||||
|
||||
This wiki follows Karpathy's LLM Wiki pattern:
|
||||
**https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f**
|
||||
|
||||
The `wiki-maintainer` skill enforces the workflow and file formats. This file overrides the skill where they conflict.
|
||||
|
||||
## Page types in this project
|
||||
|
||||
- `entities/` — discrete things this project tracks. Reserved for future use (individual skills if they accumulate non-obvious context, tools we adopt).
|
||||
- `concepts/` — design decisions, technical gotchas, refactor notes. Most pages live here.
|
||||
- `packages/` — currently empty. Would be used if we extract a package (e.g. a CLI) from this repo.
|
||||
- `sources/` — one summary per ingested external doc; carries `ingested:` and `raw_path:` frontmatter.
|
||||
- `overview.md` — single project-wide overview. Read this first if new to the repo.
|
||||
|
||||
## Naming
|
||||
|
||||
- `kebab-case.md`, **Latin only**. Transliterate Cyrillic in filenames; keep the original title in the H1 + frontmatter.
|
||||
|
||||
## Domain conventions
|
||||
|
||||
- Skill-related design notes go in `concepts/<skill-name>-*.md` (e.g. `active-platform-decision.md`).
|
||||
- Build / install pipeline notes live in `concepts/build-*.md`.
|
||||
- Refactor / re-alignment commits get a `concepts/<what>-realignment.md` page.
|
||||
|
||||
## Frontmatter
|
||||
|
||||
Minimum:
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: Human-readable title
|
||||
type: concept | entity | package | source | overview
|
||||
updated: YYYY-MM-DD
|
||||
---
|
||||
```
|
||||
|
||||
`source/` pages also carry `ingested:` and `raw_path:`.
|
||||
**Не читать. Не править.** Канон — mappa (`mcp__mappa__*`): wiki-сущности проекта, конвенции — AGENTS-сущность. Скил: `mappa-knowledge`.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: Bootstrap Manifest
|
||||
type: concept
|
||||
updated: 2026-04-30
|
||||
generator: project-bootstrap@1.2.0
|
||||
updated: 2026-05-07
|
||||
generator: project-bootstrap@1.10.1
|
||||
---
|
||||
|
||||
# Bootstrap Manifest
|
||||
@@ -11,7 +11,7 @@ Skills used to initialize this project's `.wiki/` and `.tasks/` layout, with the
|
||||
|
||||
| Skill | Version | Role |
|
||||
|---|---|---|
|
||||
| `project-bootstrap` | 1.2.0 | orchestrator |
|
||||
| `project-bootstrap` | 1.10.1 | orchestrator |
|
||||
| `setup-wiki` | 1.0.0 | wiki canonical layout |
|
||||
| `setup-tasks` | 1.0.0 | tasks canonical layout |
|
||||
|
||||
|
||||
@@ -1,90 +1,68 @@
|
||||
---
|
||||
title: "context7 setup: official plugin + API key"
|
||||
title: "context7 setup: CLI-first (migrated from official plugin)"
|
||||
type: concept
|
||||
updated: 2026-04-28
|
||||
updated: 2026-08-13
|
||||
---
|
||||
|
||||
# context7 setup: official plugin + API key
|
||||
# context7 setup: CLI-first (migrated from official plugin)
|
||||
|
||||
_2026-04-28._
|
||||
_2026-04-28 (plugin era) → 2026-08-12 (CLI migration, setup-context7 v2.0.0)._
|
||||
|
||||
## Where the MCP server is now registered
|
||||
## Current state (canonical, since 2026-08-12)
|
||||
|
||||
Single source: the official plugin **`context7@claude-plugins-official`**.
|
||||
Single source = the **`ctx7` CLI** (npm), agent-neutral — any harness (pi / claude / hermes / codex)
|
||||
runs it in bash. **No MCP registration, no plugin.**
|
||||
|
||||
The plugin's `.mcp.json` (after install) lives at:
|
||||
```
|
||||
~/.claude/plugins/cache/claude-plugins-official/context7/<version>/.mcp.json
|
||||
```
|
||||
- CLI: `ctx7` v0.5.8 installed globally (`npm i -g ctx7`).
|
||||
- API key: `~/.config/projects-secrets/ctx7.env` → `CONTEXT7_API_KEY=<key>` (our secrets convention,
|
||||
cf. `interns.env` / `auth.toml`).
|
||||
- Works anonymously for basic queries; the key raises rate limits but does not change output.
|
||||
- Legacy removed: plugin `context7@claude-plugins-official` uninstalled (installed_plugins + cache +
|
||||
pluginUsage), manual `mcpServers.context7` entries cleaned from `~/.claude.json` /
|
||||
`~/.claude/settings.json` (top-level + project-scoped). Backups: `~/.claude.json.bak-<ts>`,
|
||||
`~/.claude/settings.json.bak-<ts>`.
|
||||
|
||||
For this user the version slug is `unknown` (marketplace plugin without a tagged release).
|
||||
Procedure: **`setup-context7`** skill ([`skills/setup-context7/SKILL.md`](../../skills/setup-context7/SKILL.md)) —
|
||||
key discovery (search `ctx7.env` → env var → settings.json → .claude.json, reuse, never invent),
|
||||
confirmation gates before any mutation, smoke via `ctx7 library` (functional; works anonymously).
|
||||
Usage policy: **`using-context7`** skill — `ctx7 library <name>` → `ctx7 docs <libraryId> "<question>"`.
|
||||
Git Bash gotcha: library IDs start with `/` and path-convert — use `//owner/repo` double-slash.
|
||||
|
||||
## API-key injection
|
||||
**Verification gotcha (commit `79baad1`):** `ctx7 whoami` answers "Not logged in" even with an env key —
|
||||
it's OAuth identity (`ctx7 login`), not a key check. The functional smoke is `ctx7 library`, not `whoami`.
|
||||
|
||||
The `@upstash/context7-mcp` npm package, run via stdio, accepts the key as a CLI flag (per Upstash docs at <https://context7.com/docs/resources/all-clients>):
|
||||
## History: plugin era (2026-04-28 → 2026-08-12, rollback reference only)
|
||||
|
||||
```json
|
||||
{
|
||||
"context7": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@upstash/context7-mcp", "--api-key", "ctx7sk-..."]
|
||||
}
|
||||
}
|
||||
```
|
||||
Before the CLI migration, context7 ran through the official MCP plugin
|
||||
`context7@claude-plugins-official`. The plugin's `.mcp.json` (after install):
|
||||
`~/.claude/plugins/cache/claude-plugins-official/context7/<version>/.mcp.json` (version slug `unknown`).
|
||||
|
||||
We injected the user's existing key (previously in HTTP-header form) into this `args` array. Header / `env` block forms are also supported, but the CLI flag is what Upstash recommends for stdio.
|
||||
The key was injected as a CLI flag into `args`:
|
||||
`["-y", "@upstash/context7-mcp", "--api-key", "ctx7sk-..."]` (Upstash-recommended form for stdio;
|
||||
header / `env` block forms also supported). Three manual MCP registrations were deleted at the time
|
||||
(settings.json top-level, .claude.json top-level, and a project-scoped one in
|
||||
`projects["…/snolla-admin-ui"].mcpServers.context7`).
|
||||
|
||||
## What was removed
|
||||
**Plugin-update gotcha (moot since uninstall, keep for rollback):** `/plugin update` / re-install
|
||||
overwrote the plugin's `.mcp.json` from the marketplace cache, dropping the `--api-key` flag — needed
|
||||
re-application after every update.
|
||||
|
||||
Three manual MCP registrations were deleted:
|
||||
**Rollback to the plugin path** (if ever needed): restore the `.bak-*` files, reinstall the plugin
|
||||
(`/plugin install context7@claude-plugins-official`), re-inject the key, restart Claude Code. Full
|
||||
procedure is in the `setup-context7` skill's Rollback section.
|
||||
|
||||
| File | Where | Had API key? |
|
||||
|---|---|---|
|
||||
| `~/.claude/settings.json` | top-level `mcpServers.context7` | yes (header) |
|
||||
| `~/.claude.json` | top-level `mcpServers.context7` | yes (header) |
|
||||
| `~/.claude.json` | `projects["…/snolla-admin-ui"].mcpServers.context7` | no (legacy) |
|
||||
## Why CLI-first
|
||||
|
||||
Backups saved with suffix `.bak-YYYYMMDD-HHMMSS` next to each file.
|
||||
Context7 ships as both an HTTP MCP server and an npm CLI. The MCP path is harness-specific glue
|
||||
(claude-plugins-official); pi doesn't see it (the claude-mcp-bridge only reads `~/.claude.json`, and
|
||||
even then it's fragile). Per the sovereign-catalog principle *"что можно сделать CLI — делаем CLI и
|
||||
оборачиваем в скил; MCP только там, где нужен структурированный/интерактивный протокол"* — the CLI
|
||||
is the canonical path (idea 16, `claude-to-agents`).
|
||||
|
||||
## ⚠️ Plugin-update gotcha
|
||||
## Why two skills
|
||||
|
||||
`/plugin update context7@claude-plugins-official` (or a fresh re-install) **will overwrite** the plugin's `.mcp.json` from the marketplace cache, dropping the `--api-key` flag. After any plugin update, re-apply the edit:
|
||||
- **`using-context7`** (policy, every-time): when to call, how to phrase queries, budget.
|
||||
- **`setup-context7`** (one-time, mutates user config): install, key reuse, legacy cleanup.
|
||||
|
||||
```bash
|
||||
# inspect
|
||||
cat ~/.claude/plugins/cache/claude-plugins-official/context7/<version>/.mcp.json
|
||||
|
||||
# if --api-key is missing, re-inject
|
||||
```
|
||||
|
||||
The marketplace upstream of the plugin lives at `anthropics/claude-plugins-official/external_plugins/context7/.mcp.json` and is two lines — unlikely to change often, but we should expect to re-apply the flag after updates.
|
||||
|
||||
## Restart required to take effect
|
||||
|
||||
Claude Code reads MCP server configs at session start. The session in which this change was made keeps its old (HTTP-transport) connection until a restart. After restart, the plugin's stdio invocation takes over.
|
||||
|
||||
## Why this matters
|
||||
|
||||
Manual MCP entries in `~/.claude.json` / `settings.json` are easy to:
|
||||
- duplicate accidentally (we had three for one server)
|
||||
- forget about when sharing config
|
||||
- drift from the canonical version
|
||||
|
||||
The plugin centralizes the registration and gets versioned through the marketplace. The price is a single edit-after-update for the API key.
|
||||
|
||||
## Now captured as a skill
|
||||
|
||||
The procedure above is now formalized as the **`setup-context7`** skill ([`skills/setup-context7/SKILL.md`](../../skills/setup-context7/SKILL.md)). It runs the same algorithm with confirmation gates and key-discovery logic (search `settings.json` → `.claude.json` → env, reuse what's there, never invent). `using-context7` got a small **Prerequisites** section pointing at it.
|
||||
|
||||
### Why split into two skills
|
||||
|
||||
Two distinct concerns:
|
||||
|
||||
- **Policy** (every-time, short-running): when to call resolve-library-id, query budget, how to phrase queries — this lives in `using-context7`.
|
||||
- **Setup** (one-time, mutates user config): install plugin, inject key, clean manual entries — this lives in `setup-context7`.
|
||||
|
||||
Mixing them would make the policy skill ~2× larger, dilute its description (worse triggering), and make every library question pull setup procedure into context. The split is also a template for future "X plugin + how-to-use-X" skill pairs.
|
||||
|
||||
### Cross-platform
|
||||
|
||||
The setup skill is platform-agnostic. Only the JSON validator differs (PowerShell on Windows, `jq` / Python on Linux/macOS). Paths (`~/.claude/...`) are identical.
|
||||
Mixing them would dilute the policy skill's description (worse triggering) and pull setup procedure
|
||||
into every library question. Template for future "X CLI + how-to-use-X" pairs.
|
||||
|
||||
63
.wiki/concepts/delegate-task-negative-trigger-fp.md
Normal file
63
.wiki/concepts/delegate-task-negative-trigger-fp.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: delegate-task — literal negative triggers beat abstract carve-outs
|
||||
type: concept
|
||||
updated: 2026-06-17
|
||||
---
|
||||
|
||||
# delegate-task — literal negative triggers beat abstract carve-outs
|
||||
|
||||
## Symptom
|
||||
|
||||
`delegate-task` v0.2.0 false-positive-fired on **«создать задачу себе»** (create a task
|
||||
for myself) — a self-assigned task that should route to `using-tasks`, not to cross-agent
|
||||
delegation. The `delegate-task-test-trigger` run measured it at **5/5 trials** consistently
|
||||
wrong (→ `delegate-task`).
|
||||
|
||||
## Root cause
|
||||
|
||||
The positive trigger list contained **«создать задачу на агента»**. A self-task phrase
|
||||
**«создать задачу себе»** shares the stem **«создать задачу»**, so it literal-matched the
|
||||
positive trigger. The negative clause was abstract — *"Does NOT apply when doing the work
|
||||
yourself"* — and an abstract carve-out does **not** beat a literal stem-match under the
|
||||
`using-superpowers` 1%-rule. Clean-context subagents *recognized* the «себе» exception in
|
||||
their reasoning, yet still invoked `delegate-task` FIRST because the literal match outweighed
|
||||
the abstract exclusion.
|
||||
|
||||
## Fix (v0.2.0 → v0.2.1, PATCH)
|
||||
|
||||
Make the negative **literal and routed**, so it competes head-on with the positive at the
|
||||
same surface level:
|
||||
|
||||
> Does NOT apply to self-assigned tasks on your own board (**«создать задачу себе»**,
|
||||
> **«task for myself»**, **«поставить себе задачу»** → using-tasks), to work you do
|
||||
> yourself, or to workshop-internal tasks.
|
||||
|
||||
Plus a body disambiguator in the "Не применяется" section:
|
||||
**«на агента» / «агенту» / «в проект X» = делегирование; «себе» / «myself» = своя доска.**
|
||||
|
||||
## Verification
|
||||
|
||||
Re-ran the `delegate-task-test-trigger` methodology (fresh-context subagents, simulated
|
||||
available-skills registry with the new description + competitors `using-tasks` /
|
||||
`using-projects-meta` / `setup-tasks` / `session-handoff`, no hint about the expected
|
||||
answer):
|
||||
|
||||
- **Positives 5/5** — «создать задачу на агента», «поставить задачу агенту», «delegate task
|
||||
to the books project», «делегировать таску», «tasks_create для проекта X» → all
|
||||
`delegate-task`. No regression from the literal negative.
|
||||
- **Negative «создать задачу себе на завтра» 4/5 → `using-tasks`** (was 0/5 before the fix).
|
||||
The single residual miss reasoned correctly («себе» → using-tasks) but was tripped by an
|
||||
eval-harness artifact (the prompt forced a skill name on line 1 *before* reasoning),
|
||||
not by ambiguity in the description.
|
||||
|
||||
## Reusable principle
|
||||
|
||||
When a skill's positive triggers contain a phrase whose **stem** also appears in a sibling
|
||||
skill's domain, an abstract "does NOT apply when…" clause is too weak. Put the **exact
|
||||
colliding negative phrase** in the description with an explicit **→ <sibling-skill>** route.
|
||||
Literal beats abstract under the 1%-rule. See also [[tdd-criteria-design]] for another
|
||||
"make the bright line literal, not a judgement call" pattern.
|
||||
|
||||
See [[session-inbox-monitor-received-msg-fp]] for the next clause: a literal+routed negative
|
||||
still fails if its **route target isn't installed** — the carve-out then has no real competitor
|
||||
and the nearest in-domain skill wins anyway.
|
||||
43
.wiki/concepts/delegate-task-review-weight.md
Normal file
43
.wiki/concepts/delegate-task-review-weight.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: delegate-task review-task weight inheritance
|
||||
type: concept
|
||||
tags: [delegate-task, fleet-routing, review-task, weight]
|
||||
updated: 2026-06-09
|
||||
---
|
||||
|
||||
# delegate-task review-task `weight` inheritance
|
||||
|
||||
`delegate-task` v0.2.3 makes Step 5 (the paired `<slug>-review` task) set an explicit `weight`,
|
||||
inherited from the impl-task with a `needs-claude` floor.
|
||||
|
||||
## Problem
|
||||
|
||||
Step 5 created the review task with `status=blocked` + `blocker=<slug>` but **never set `weight`**.
|
||||
A review task with no weight is invisible to fleet routing — the reconciler/poller skips it, so it
|
||||
never gets claimed. This surfaced as commit `c0af151` ("add Weight: needs-claude to 4 review tasks
|
||||
— reconciler was skipping them"), a manual after-the-fact patch of the symptom. The root cause was
|
||||
in the authoring skill: it omitted the field.
|
||||
|
||||
## Design
|
||||
|
||||
Step 5 now sets the review-task weight by **inheriting from the impl-task, floored at `needs-claude`**:
|
||||
|
||||
- impl `needs-human` → review `needs-human` — a critical-infra change cannot be reviewed by a weaker
|
||||
tier; the review inherits the impl's strictness.
|
||||
- impl `needs-claude` → review `needs-claude`.
|
||||
- impl `cheap-ok` → review `needs-claude` — the floor. Review is discipline-critical (it must honour
|
||||
the `invoke` instructions and acceptance criteria), and the skill's own "What NOT to do" already
|
||||
forbids `cheap-ok` for review/security/migration tasks. So `cheap-ok` is never propagated.
|
||||
|
||||
### Why a floor, not pure inheritance
|
||||
|
||||
The delegating task said "inherit weight from impl". Pure inheritance would let a `cheap-ok` impl
|
||||
produce a `cheap-ok` review — directly contradicting the skill's existing "What NOT to do" bullet
|
||||
(no `cheap-ok` for review) and the `needs-claude` convention the manual fix established. The floor
|
||||
is the reading that keeps the document internally consistent: inherit upward (so `needs-human`
|
||||
propagates), clamp the bottom (so review never drops below `needs-claude`).
|
||||
|
||||
## Versioning
|
||||
|
||||
PATCH bump (0.2.2 → 0.2.3): tightens guidance on an existing step, no new step or breaking change.
|
||||
Target version fixed by the delegating task.
|
||||
46
.wiki/concepts/delegate-task-session-break.md
Normal file
46
.wiki/concepts/delegate-task-session-break.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: delegate-task session_break field
|
||||
type: concept
|
||||
tags: [delegate-task, using-tasks, autonomous-runner, session-boundary]
|
||||
updated: 2026-06-09
|
||||
---
|
||||
|
||||
# delegate-task `session_break` field
|
||||
|
||||
`delegate-task` v0.2.2 adds an optional `session_break` field to the task-body template, plus
|
||||
a sixth pre-flight question. This is the **authoring** side of the marker whose **consumer**
|
||||
side lives in `using-tasks` — see [[using-tasks-session-break]].
|
||||
|
||||
## Problem
|
||||
|
||||
`using-tasks` v1.2.0 can stop an autonomous runner after a task closes (instead of chaining
|
||||
`tasks_claim_next`) **iff** the closed task carries a `session_break` marker. But nothing in the
|
||||
delegation flow prompted the author to set it — so the capability sat unused unless someone
|
||||
hand-edited the task body. The marker has to be *placed at delegation time* to be useful.
|
||||
|
||||
## Design
|
||||
|
||||
- **Pre-flight Q6** (after Q5 `notify`): *"Session-break после этой задачи? — нужен ли разрыв
|
||||
сессии после её закрытия (domain-switch, milestone, heavy infra)?"* If yes → set
|
||||
`session_break` in the task body; if no → omit it (default unchanged).
|
||||
- **Template field** (optional, in the trailer next to `weight` / `notify` / `allow_upgrade`):
|
||||
`session_break: true | "<следующий трек / hint>"` with an inline comment pointing at the
|
||||
`using-tasks` stop behaviour. `session_break` (lowercase, underscore) is the same frontmatter
|
||||
key `using-tasks` reads.
|
||||
- **Value:** `true` (next track = "см. STATUS.md") or a hint string naming the next track.
|
||||
|
||||
## When to set it (three cases)
|
||||
|
||||
1. **Смена домена / репо** — the task ends one track before an unrelated one begins.
|
||||
2. **Milestone-задача** — the last sub-task in a feature's group.
|
||||
3. **Тяжёлая инфра-задача** — shared checkout, migrations, deploy — where it's sane to stop and
|
||||
inspect state before continuing.
|
||||
|
||||
Not a default: setting it routinely would make `using-tasks` tear the session after every
|
||||
close. It is a marker of a *real* boundary, an authoring choice — same rationale as the
|
||||
consumer-side "marker not heuristic" argument in [[using-tasks-session-break]].
|
||||
|
||||
## Versioning
|
||||
|
||||
PATCH bump (0.2.1 → 0.2.2): additive optional field + one extra pre-flight question, no existing
|
||||
behaviour changed. (The version target was fixed by the delegating task.)
|
||||
141
.wiki/concepts/hermes-skills-rollout-design.md
Normal file
141
.wiki/concepts/hermes-skills-rollout-design.md
Normal file
@@ -0,0 +1,141 @@
|
||||
---
|
||||
tags:
|
||||
- hermes
|
||||
- skills
|
||||
- conversion
|
||||
- deployment
|
||||
- factory
|
||||
sources:
|
||||
- 'https://hermes-agent.nousresearch.com/docs/user-guide/features/skills'
|
||||
- 'https://hermes-agent.nousresearch.com/docs/guides/use-mcp-with-hermes'
|
||||
- 'https://www.glukhov.org/ai-systems/hermes/authoring-hermes-skill/'
|
||||
- >-
|
||||
https://github.com/NousResearch/hermes-agent/blob/main/skills/research/llm-wiki/SKILL.md
|
||||
source_brainstorm: .meeting-room/.archive/2026-05-06-hermes-skills-rollout.md
|
||||
title: hermes-skills-rollout-design
|
||||
type: concept
|
||||
ingested_at: '2026-05-06T20:21:13.349Z'
|
||||
ingested_by: OpeItcLoc03@DESKTOP-NSEF0UK
|
||||
source_project: .meeting-room
|
||||
---
|
||||
# Hermes Skills Rollout — Design
|
||||
|
||||
Раскатить `claude-skills` на Hermes Agent (Nous Research) как **частный фабричный комплект**, через converter + pre-built `dist-hermes/` + recursive installer-skill. Не tap, не Hub, не публикация.
|
||||
|
||||
## Context
|
||||
|
||||
Hermes — агент Nous Research (модель `glm-5.1`, локальная), формально совместим с `agentskills.io`. Цель: те же 21 наших скила, что работают в Claude Code, доступны и Hermes-агенту на фабричных Linux-машинах. Установка — через `skill_manage(action='create')` в `~/.hermes/skills/<category>/<skill>/`.
|
||||
|
||||
## Design tenet: независимость
|
||||
|
||||
Мы не зависим от Hermes built-in скилов. Где у нас и у Hermes есть аналог по функции (например `research/llm-wiki`), ставим **наш**. Hermes built-in остаётся, но наша schema, наш темп развития — суверенны. Override через `skill_manage` precedence.
|
||||
|
||||
Исключение — Hermes-нативные **тулы** (не скилы): `skills_list()`, `cronjob`, `execute_code`, `native-mcp`. Это инфраструктура, используем напрямую.
|
||||
|
||||
## Hermes' inventory (relevant findings)
|
||||
|
||||
- **`research/llm-wiki`** — встроен (Karpathy три-слой). Schema: `SCHEMA.md` (vs наш `.wiki/CLAUDE.md`), секции `entities/concepts/comparisons/queries` (vs наш `entities/concepts/packages/sources`). `.tasks/` НЕ трогает. Не drop-in replacement — другая schema → ставим наш через override.
|
||||
- **`mcp/native-mcp`** — встроенный MCP-клиент. Внешние сервера через `~/.hermes/config.yaml > mcp_servers.<name>` (stdio/HTTP, env-vars, auto-discovery, `/reload-mcp`).
|
||||
- **`skills_list()`** — встроенный progressive disclosure (Level 0). Делает наш `find-skills` лишним.
|
||||
- **`cronjob`** tool встроен → через `using-projects-meta` вешаем синк фабричных проектов на расписание.
|
||||
- Hermes на Linux (`/opt/data/projects`), модель `glm-5.1` (Nous, дешёвая) → caveman-экономия токенов мотива не имеет.
|
||||
|
||||
## Audit (factory-relevance × Hermes-side fit)
|
||||
|
||||
| Skill | Решение | Reasoning |
|
||||
|---|---|---|
|
||||
| `pulling-before-work` | ✅ MVP | универсально, нет Hermes-аналога |
|
||||
| `using-markitdown` | ✅ MVP | через `execute_code` |
|
||||
| `active-platform` | ✅ MVP | shell-идиома (Hermes на Linux) |
|
||||
| `project-discipline` | ✅ MVP | workflow-правила |
|
||||
| `setup-tasks` / `using-tasks` | ✅ adapt | Hermes' llm-wiki `.tasks/` не покрывает |
|
||||
| `setup-wiki` / `using-wiki` | ✅ adapt | наша schema, override Hermes built-in |
|
||||
| `setup-projects-meta` (Hermes-flavour) | ✅ adapt-mandatory | thin wrapper: бинарь и `auth.toml` уже общие в `~/projects/.common/lib/projects-meta-mcp/` и `~/.config/projects-mcp/auth.toml` → только yaml-edit + `/reload-mcp` |
|
||||
| `using-projects-meta` | ✅ adapt-mandatory | тулы auto-injected; политика та же; cron-синк фабричных проектов потом |
|
||||
| `setup-context7` (Hermes-flavour) | ✅ adapt-mandatory | yaml-edit паттерн, аналогично projects-meta |
|
||||
| `using-context7` | ✅ adapt-mandatory | политика та же |
|
||||
| `project-bootstrap` | ⚠️ adapt | orchestrator — адаптируется последним |
|
||||
| `caveman`×5 | ❌ skip | Hermes на дешёвой модели, мотив пропадает |
|
||||
| `setup-interns` / `using-interns` | ❌ skip | Hermes сам — «cheap intern» |
|
||||
| `find-skills` | ❌ skip | Hermes имеет `skills_list()` |
|
||||
|
||||
**MVP locked: 13 скилов** (4 универсальных + 2 tasks + 2 projects-meta + 2 wiki + 2 context7 + 1 bootstrap). **Skip: 8** (caveman×5 + interns×2 + find-skills).
|
||||
|
||||
## Architecture
|
||||
|
||||
### Источник истины + конвертер + pre-built dist
|
||||
|
||||
```
|
||||
claude-skills/
|
||||
├── skills/ ← source-of-truth (Claude-формат, без изменений)
|
||||
├── dist/ ← .skill архивы для Claude (есть)
|
||||
├── dist-hermes/ ← pre-converted Hermes-tree (committed, NEW)
|
||||
│ ├── productivity/caveman/SKILL.md ← (нет — в SKIPPED.md)
|
||||
│ ├── software-development/pulling-before-work/SKILL.md
|
||||
│ ├── software-development/active-platform/SKILL.md
|
||||
│ ├── ...
|
||||
│ ├── meta/claude-skills-installer/SKILL.md ← bootstrap installer
|
||||
│ └── SKIPPED.md ← skip-log с причинами
|
||||
├── hermes/
|
||||
│ ├── mapping.yaml ← skill→category, replace-rules, skip-list, mode (NEW)
|
||||
│ └── skills/<name>/SKILL.md ← `mode: manual` overrides (Hermes-flavour setups)
|
||||
├── scripts/
|
||||
│ ├── build.sh / build.ps1 (есть)
|
||||
│ ├── install.sh (есть)
|
||||
│ └── build-hermes.{sh,py} (NEW — конвертер)
|
||||
```
|
||||
|
||||
### Установка на Hermes-машине (recursive bootstrap)
|
||||
|
||||
```
|
||||
git clone <claude-skills> # private Gitea remote, на /opt/data/projects/
|
||||
# Один раз:
|
||||
hermes → skill_manage(action='create', from='dist-hermes/meta/claude-skills-installer/SKILL.md')
|
||||
# Дальше:
|
||||
hermes → trigger «обнови claude-skills» → installer-скил итерирует по dist-hermes/<cat>/<name>/, вызывает skill_manage per файл
|
||||
```
|
||||
|
||||
Никакой conversion-логики на стороне Hermes. Никакого Python-окружения. Только `skill_manage` петля.
|
||||
|
||||
### Категория-маппинг (черновик)
|
||||
|
||||
- `pulling-before-work`, `project-discipline`, `project-bootstrap`, `active-platform` → `software-development`
|
||||
- `setup-tasks`, `using-tasks` → `productivity`
|
||||
- `using-markitdown` → `productivity` (или `research`)
|
||||
- `setup-projects-meta`, `using-projects-meta`, `setup-context7`, `using-context7` → `mcp`
|
||||
- `setup-wiki`, `using-wiki` → `research`
|
||||
|
||||
## Decisions log
|
||||
|
||||
- **Q1.** Maintenance model → ongoing dual-target (конвертер + маппинг, регенерим при каждом релизе claude-skills). Anti-drift, видимость Claude-измов, reuse под другие агенты.
|
||||
- **Q2.** Distribution → НЕ tap-репо, НЕ install-script. **Pre-built `dist-hermes/` (committed) + recursive Hermes-side installer-скил.** Конвертация у нас, установка на Hermes — глупая петля по `skill_manage`.
|
||||
- **Q3.** Hub-публикация → out of scope (частные фабричные скилы).
|
||||
- **Q4.** Форма installer'а → installer-как-Hermes-скил (recursive bootstrap). Один раз ручная регистрация installer'а, дальше «обнови claude-skills» работает сам.
|
||||
- **Q5.** caveman → skip (модель дешёвая, мотив теряется). wiki-fork → порти́руем наши (independence). context7 → mandatory adapt. projects-meta → mandatory adapt thin (бинарь общий).
|
||||
- **Q6.** 🔴 не портируется → `mode: skip` в `mapping.yaml` + коммитимый `dist-hermes/SKIPPED.md` с причиной per skill. Stub-скилы не пишем. Silent отвергнут.
|
||||
- **Q7.** Версионирование → per-skill semver mirror из claude-skills фронтматтера (`1.0.0` default если нет). Lock-step с upstream. Bump по `project-discipline` Rule 3.
|
||||
- **Q8.** Layout → `claude-skills/hermes/{mapping.yaml,skills/}` + `scripts/build-hermes` + `dist-hermes/{<cat>/,meta/,SKIPPED.md}`.
|
||||
|
||||
## Security carry-forward
|
||||
|
||||
При имплементации — учитывать ЛОКАЛЬНЫЕ pre-existing уроки из claude-skills (актуально для Hermes-flavour `setup-projects-meta`):
|
||||
|
||||
- **Extraheader-pattern** для git clone с auth: `git -c http.extraheader="Authorization: token $T" clone <url>` (per-invocation, НЕ persist в `.git/config`). Никаких `https://USER:TOKEN@host/...` URL — git персистит креды.
|
||||
- **POSIX-absolute paths** (`~/projects/.common/...`), не `<project-root>/.common/...` (cwd-relative). Урок из `[setup-interns-fix-paths]` / `[using-projects-meta-fix-paths]`.
|
||||
- **Version bump** на каждый edit per `project-discipline` Rule 3 (PATCH/MINOR/MAJOR).
|
||||
|
||||
## Out of scope
|
||||
|
||||
- CI auto-rebuild `dist-hermes/` (отдельная deferred-таска `hermes-converter-ci`, не блокирует MVP).
|
||||
- Распространение через Hermes Hub (частные скилы, public out).
|
||||
- Cross-fabric distribution через приватный Gitea-tap (если когда-нибудь — отдельный спайк).
|
||||
|
||||
## Связанные таски
|
||||
|
||||
- `hermes-converter-mvp` (claude-skills) — infra + 4 universal как proof
|
||||
- `hermes-flavour-mcp-setups` (claude-skills) — Hermes-version `setup-projects-meta` + `setup-context7` (yaml-edit)
|
||||
- `hermes-installer-skill` (claude-skills) — recursive bootstrap loop
|
||||
- `hermes-mvp-coverage` (claude-skills) — extend на остальные 9 MVP-скилов, smoke-test
|
||||
- `hermes-converter-ci` (claude-skills, deferred) — auto-rebuild на push to master
|
||||
- `tasks-close-normalize-body` (common, discipline pre-req)
|
||||
- `using-tasks-close-coverage-gate` (claude-skills, discipline pre-req)
|
||||
77
.wiki/concepts/install-cross-platform.md
Normal file
77
.wiki/concepts/install-cross-platform.md
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Install / Build Cross-Platform Parity (PS + Bash)
|
||||
type: concept
|
||||
updated: 2026-05-25
|
||||
---
|
||||
|
||||
# Install / Build Cross-Platform Parity (PS + Bash)
|
||||
|
||||
Sibling concept to `install-portability.md` (POSIX-shell compat). This one is about the **paired-script parity contract** between `scripts/install.ps1` / `scripts/install.sh` (install) and `scripts/build.ps1` / `scripts/build.sh` (build). Both pairs share the same conventions and the same `--prune` / `-Prune` flag pattern.
|
||||
|
||||
## Why two scripts
|
||||
|
||||
Windows hosts running CC outside a git-bash terminal have no reliable bash. Native PowerShell call (`pwsh ./scripts/install.ps1`) is the friction-free path. Linux / macOS users get bash. Both audiences are first-class — `claude-skills` is multi-machine by design (see `project_deployment_goal` memory).
|
||||
|
||||
Single-script "use bash everywhere" was rejected: forces every Windows user to install git-bash before bootstrap, contradicts "tool-light install path".
|
||||
|
||||
## Parity contract
|
||||
|
||||
Both scripts MUST:
|
||||
|
||||
- Read sources from `<repo>/skills/<name>/`.
|
||||
- Install to `$CLAUDE_SKILLS_DIR` if set, else `~/.claude/skills/`.
|
||||
- Accept a name-list (positional in bash, `-Names` in PS); no args = all.
|
||||
- Skip with a warning when `skills/<name>/` is missing or has no `SKILL.md`.
|
||||
- Idempotent: `rm -rf` (or `Remove-Item -Recurse -Force`) the destination, then copy fresh.
|
||||
- Print one `installed: <name> -> <path>` line per successfully installed skill.
|
||||
|
||||
Flag naming follows the host shell's convention — POSIX `--prune` in bash, PascalCase `-Prune` switch in PowerShell. Behaviour identical.
|
||||
|
||||
## The `--prune` / `-Prune` flag
|
||||
|
||||
Added 2026-05-25 (commit `6cf0e98`). Motivating case: after retiring `using-synology-ops` the installed dir `~/.claude/skills/using-synology-ops/` lingered until manual `rm` — the install scripts had no notion of stale-cleanup.
|
||||
|
||||
**Behaviour:** after the install loop, walk `$target/*` and remove any dir whose name is not in `skills/*`.
|
||||
|
||||
**Design choices and their rejected alternatives:**
|
||||
|
||||
- **Combined flag, not standalone mode.** Single invocation does both. Alternative (`install --prune-only`) was rejected — adds a mode that nobody asked for; users wanting "just cleanup" can pass an empty name list (`install.sh --prune` with no positional args still walks the prune step at the end, no-op'ing the install loop because all source skills resolve to no-op overwrites of fresh installs).
|
||||
|
||||
- **Global scan, ignores name filter.** Even when called as `install.sh foo --prune`, the prune step scans the full target against the full source. Rationale: stale-cleanup is a global concern. A user who explicitly opts into prune wants the cleanup to be useful — a names-filtered prune ("only prune dirs that match the name list AND are missing from source") rarely matches anyone's mental model.
|
||||
|
||||
- **Print-and-delete, no confirmation prompt.** Each removal prints `pruning: <name> (not in skills/) -> <path>`. Confirmation prompts would block automation (CI, batch reinstalls). Visibility comes from the printed line; users wanting a dry-run pass `-WhatIf` in PowerShell (the cmdlet already supports it) or pipe to `echo` in bash (trivial to grep `^pruning:` before running for real).
|
||||
|
||||
- **Default off.** Must be passed explicitly. Idempotent re-installs (the common case) don't suddenly delete anything.
|
||||
|
||||
## What install-side `--prune` does NOT do
|
||||
|
||||
- It does not touch plugin-installed skills under `~/.claude/plugins/<plugin>/skills/<name>/`. Those are managed by the plugin system, not this repo.
|
||||
- It does not warn if the about-to-be-deleted dir contains user-edited content. The contract is that `~/.claude/skills/<name>/` is a managed copy of `skills/<name>/` — anything else is user-error.
|
||||
- It does not remove `dist/<name>.skill` build artefacts. That's the build-script's `--prune` (see next section).
|
||||
|
||||
## Build-side `--prune` / `-Prune`
|
||||
|
||||
Added 2026-05-25 — natural extension of the install-side flag to the build pair (`scripts/build.sh` and `scripts/build.ps1`). Same design choices, applied to files instead of directories: after the build loop, walk `dist/*.skill` and remove any whose `<name>` (basename minus `.skill`) is not in `skills/*`.
|
||||
|
||||
Identical to install-side: combined flag, global scan ignores the name filter, prints `pruning: <name> -> <path>` per removal, default off, no confirmation prompt.
|
||||
|
||||
The bash path has one extra wrinkle: when `build.sh` is run on Windows without `zip` and delegates to `build.ps1` via `powershell.exe -File`, the `--prune` flag is **not** forwarded to the delegated PS process. Bash runs the prune step itself at the end of the script, against the same `dist/` directory. This keeps the delegation surface narrow (no flag-translation bugs) and the prune logic single-sourced per shell.
|
||||
|
||||
`build.ps1` invoked directly (without the bash wrapper) handles `-Prune` natively.
|
||||
|
||||
## What build-side `-Prune` does NOT do
|
||||
|
||||
- It does not unblock build for skills that have been renamed mid-flight. A user who renamed `skills/foo/` → `skills/bar/` should still run a fresh build (`build.sh bar`) — prune only catches stale archives whose source dir is gone, not stale archives whose source was renamed (those become orphans of a different source, indistinguishable from intentional foreign artefacts).
|
||||
- It does not touch `dist-hermes/` — that directory is managed by `scripts/build-hermes.py` and follows its own rules (whole-directory rebuild per skill). Hermes has no current prune mechanism; if needed, that's a separate concept page.
|
||||
|
||||
## Test evidence
|
||||
|
||||
All four scripts smoke-tested 2026-05-25.
|
||||
|
||||
**Install side** — disposable target dirs (env-overridden `CLAUDE_SKILLS_DIR`). Pre-populated with 2 fake stale dirs, ran full install + prune, verified: stale dirs removed, all real skills installed, retired `using-synology-ops` absent.
|
||||
|
||||
**Build side** — fake `dist/fake-stale.skill` + `dist/another-stale.skill` files created directly in the real `dist/`. Ran `build.sh --prune fake-stale-sh` (positional arg triggers a no-op build via skip path; prune runs at the end) and `build.ps1 -Names fake-stale-ps -Prune`. Both removed the fakes, left real archives like `caveman.skill` untouched.
|
||||
|
||||
No automated test fixture in the repo — install / build scripts are wrapper-style, smoke-test evidence in the respective commit bodies suffices under the `[skip-tdd: wrapper]` carve-out.
|
||||
|
||||
`[archive-roundtrip-test]` (still ⚪ on the board) is a candidate place to add a real fixture once it lands.
|
||||
@@ -48,7 +48,7 @@ Triggered by Reddit thread (May 2026) и Medium-статьёй того же а
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ Layer 1 — Config (data, no code) │
|
||||
│ .common/config/interns/config.yaml — endpoints + tools │
|
||||
│ .common/secrets/interns.env — API ключи (gitignored) │
|
||||
│ ~/.config/projects-secrets/interns.env — API ключи (outside git) │
|
||||
└──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
@@ -98,7 +98,7 @@ interns:
|
||||
transcript. Output structured markdown sections. Be terse.
|
||||
```
|
||||
|
||||
`.common/secrets/interns.env` (gitignored):
|
||||
`~/.config/projects-secrets/interns.env` (outside any git tree; canonical home since `secrets-out-of-common` migration):
|
||||
|
||||
```dotenv
|
||||
OLLAMA_CLOUD_API_KEY=...
|
||||
@@ -152,7 +152,7 @@ interns-mcp/
|
||||
**Steps:**
|
||||
1. Проверить `.common/lib/interns-mcp/` существует. Если нет — инициализировать пустой через template (TBD: см. open question про source repo).
|
||||
2. `pip install -e .common/lib/interns-mcp/` через активный Python interpreter.
|
||||
3. Прочитать `.common/config/interns/config.yaml`, для каждого `endpoint.<name>.api_key_env` проверить наличие в `.common/secrets/interns.env`. Отсутствующие — спросить интерактивно, preview перед записью, write.
|
||||
3. Прочитать `.common/config/interns/config.yaml`, для каждого `endpoint.<name>.api_key_env` проверить наличие в `~/.config/projects-secrets/interns.env`. Отсутствующие — спросить интерактивно, preview перед записью, write.
|
||||
4. Зарегистрировать `mcpServers.interns` в `~/.claude.json`:
|
||||
```json
|
||||
"interns": {
|
||||
@@ -180,7 +180,7 @@ interns-mcp/
|
||||
|
||||
3. **Always-ask paths (даже с активным grant'ом).** Полный список:
|
||||
- `**/.env`, `**/.env.*` — environment files со секретами
|
||||
- `**/secrets/**` — каноническая папка секретов (включая `.common/secrets/`)
|
||||
- `**/secrets/**`, `**/projects-secrets/**` — каноническая папка секретов (после миграции `secrets-out-of-common`: `~/.config/projects-secrets/`)
|
||||
- `**/credentials*` — credentials.json и подобные
|
||||
- `**/*.key` — private keys любого формата
|
||||
- `**/*.pem` — PEM-encoded keys/certs
|
||||
@@ -220,7 +220,7 @@ interns-mcp/
|
||||
| Слой | Windows | Linux | macOS |
|
||||
|---|---|---|---|
|
||||
| `.common/lib/interns-mcp/` (Python 3.11+) | ✅ | ✅ | ✅ |
|
||||
| `.common/secrets/interns.env` (`python-dotenv`) | ✅ | ✅ | ✅ |
|
||||
| `~/.config/projects-secrets/interns.env` (`python-dotenv`) | ✅ | ✅ | ✅ |
|
||||
| `setup-interns` install (`python -m pip`) | ✅ | ✅ | ✅ |
|
||||
| MCP registration — путь к Python | `where python` | `which python` | `which python` |
|
||||
| Always-ask matcher (`pathlib.PurePath.match`) | ✅ POSIX-style globs работают везде | ✅ | ✅ |
|
||||
@@ -277,7 +277,7 @@ interns-mcp/
|
||||
- **Source repo для `.common/lib/interns-mcp/`.** Inline в `.common` или отдельный repo на Gitea + git-subtree/submodule? Текущее склонение — inline (это часть `.common`, не самостоятельный продукт).
|
||||
- **Auto-discovery интернов** в `registry.py` (через `pkgutil.iter_modules`) vs explicit `register_tool` в `server.py`. Auto проще для расширения, explicit прозрачнее. Текущее склонение — explicit для MVP.
|
||||
- **Cost tracking.** В первом релизе — нет. Если оботрётся в реальной работе — добавим в `safety.py` per-call estimate из config (`tokens_used × price_per_M`) и блокировку >$X через always-ask механизм.
|
||||
- **Sharing endpoint между meeting-room runner и interns-mcp.** Сейчас `.meeting-room/config/config.yaml` имеет свой `providers.ollama_cloud` с собственным ключом; interns-mcp будет иметь свой в `.common/secrets/interns.env`. Дублирование. Унификация — отдельная задача.
|
||||
- **Sharing endpoint между meeting-room runner и interns-mcp.** Сейчас `.meeting-room/config/config.yaml` имеет свой `providers.ollama_cloud` с собственным ключом; interns-mcp будет иметь свой в `~/.config/projects-secrets/interns.env`. Дублирование. Унификация — отдельная задача.
|
||||
- **Persistent prefix-cache benefit с Ollama Cloud.** Документация Ollama Cloud не подтверждает prefix-cache discount явно (как делает OpenRouter). Если измерения покажут что cache не работает — рассмотреть переключение на OpenRouter как primary endpoint.
|
||||
|
||||
## References
|
||||
|
||||
190
.wiki/concepts/interns-grep-audit-design.md
Normal file
190
.wiki/concepts/interns-grep-audit-design.md
Normal file
@@ -0,0 +1,190 @@
|
||||
---
|
||||
date: '2026-05-22'
|
||||
status: design-approved
|
||||
parent: concepts/interns-design.md
|
||||
source_buffer: .workshop/.brainstorm/interns.md
|
||||
title: interns-grep-audit-design
|
||||
type: concept
|
||||
ingested_at: '2026-05-22T04:16:29.503Z'
|
||||
ingested_by: OpeItcLoc03@DESKTOP-NSEF0UK
|
||||
source_project: OpeItcLoc03/workshop
|
||||
---
|
||||
# Interns — `grep_audit` intern (v0.1.0)
|
||||
|
||||
Расширение каталога `interns-mcp`: добавляет интерн `grep_audit`, специализированный на структурированном grep по списку путей с матрицей паттернов. Особенность — **детерминированный**, **без LLM-вызова**: server применяет `re` локально, endpoint Ollama Cloud не вызывается ни в каком режиме. Нулевая цена, нулевая hallucination-граница.
|
||||
|
||||
## Context
|
||||
|
||||
Pain-point всплыл при аудите 13 CLAUDE.md на 6 канонических триггер-строк в bootstrap-rollout сессии 2026-05-07. Делалось через `bulk_text_read` с длинной формулировкой «вот колонки, вот формат, вот сортировка». Шаблонная задача — выдать матрицу N×M по бинарному условию contains/not-contains. Интерн со специализированной сигнатурой убирает 80% текста запроса.
|
||||
|
||||
Решение «без LLM вообще» зафиксировано 2026-05-21: семантический матч (если когда-нибудь возникнет pain-point) — отдельный путь через `bulk_text_read` с вопросом, а не режим `grep_audit`. Caller не держит в голове «иногда детерминированно, иногда нет» — граница проведена между интернами, не внутри одного.
|
||||
|
||||
Это первый **LLM-free** интерн в каталоге — паттерн для будущих детерминированных тулзов (потенциально `path_classify`, `json_extract`, если pain-point всплывёт; те отброшены в текущем раунде как дублирующие jq/grep_audit).
|
||||
|
||||
## Decisions
|
||||
|
||||
| # | Решение | Аргумент |
|
||||
|---|---|---|
|
||||
| 1 | Шейп — `grep_audit(paths, patterns, output, case_sensitive) → matrix` | Структурированный matrix-output, не Q&A. Симметрия с другими интернами нарушена сознательно — это аудит, не вопрос. |
|
||||
| 2 | Без LLM на back-end совсем | substring/regex детерминирован, `re` локально достаточен. Cheaper, точнее, нулевая hallucination. |
|
||||
| 3 | `patterns: list[str \| dict]` — либо substring, либо `{pattern, name, regex?}` | Простой случай (substring) — одна строка; сложный (named regex для читаемой матрицы) — dict. |
|
||||
| 4 | Always-ask политика единообразна для всех интернов | Несмотря на отсутствие endpoint-вызова, server открывает файл. Caller не должен различать «безопасный/небезопасный» интерн. |
|
||||
| 5 | Routing в `using-interns/SKILL.md` явно фиксирует «детерминированный, no LLM, zero cost, zero hallucination» | Каталог не-гомогенный (один интерн без LLM, остальные с) — это надо явно проговорить чтобы Claude не путался. |
|
||||
| 6 | `output: "table" \| "json"` — default `"table"` | Markdown-таблица для human-readable аудитов; JSON для programmatic consumption. |
|
||||
|
||||
## Сигнатура
|
||||
|
||||
```python
|
||||
grep_audit(
|
||||
paths: list[str], # absolute file paths
|
||||
patterns: list[str | dict], # str = substring; dict = {pattern, name, regex?}
|
||||
output: Literal["table", "json"] = "table",
|
||||
case_sensitive: bool = True,
|
||||
) -> InternResponse
|
||||
```
|
||||
|
||||
`InternResponse = {text: str, usage: {files_scanned, patterns_evaluated, matches_total}}`
|
||||
|
||||
Output shape:
|
||||
- `"table"`: markdown-таблица, rows = paths, cols = pattern names (или `pattern` если `name` не задан), ячейки ✅/❌.
|
||||
- `"json"`: `{"rows": [{path, matches: {<pattern_name>: bool}}]}`.
|
||||
|
||||
При файле-не-найден / unreadable — соответствующая ячейка `null` в JSON, `⚠️` в table; не abort всего вызова (аудит идёт по N путям, partial-result полезнее total fail).
|
||||
|
||||
## Реализация (`interns_mcp/interns/grep_audit.py`)
|
||||
|
||||
```python
|
||||
import json
|
||||
import re
|
||||
from pathlib import Path
|
||||
from typing import Literal
|
||||
|
||||
from .base import Intern, InternResponse
|
||||
from .. import safety
|
||||
|
||||
|
||||
class GrepAudit(Intern):
|
||||
id = "grep_audit"
|
||||
|
||||
def run(
|
||||
self,
|
||||
paths: list[str],
|
||||
patterns: list[str | dict],
|
||||
output: Literal["table", "json"] = "table",
|
||||
case_sensitive: bool = True,
|
||||
) -> InternResponse:
|
||||
safety.check_paths(paths) # raise if always-ask
|
||||
|
||||
compiled = _compile_patterns(patterns, case_sensitive)
|
||||
|
||||
rows = []
|
||||
matches_total = 0
|
||||
for p in paths:
|
||||
try:
|
||||
text = Path(p).read_text(encoding="utf-8", errors="replace")
|
||||
except (FileNotFoundError, PermissionError, IsADirectoryError) as exc:
|
||||
rows.append({"path": p, "matches": {c["name"]: None for c in compiled}, "error": str(exc)})
|
||||
continue
|
||||
row_matches = {}
|
||||
for c in compiled:
|
||||
hit = bool(c["matcher"](text))
|
||||
row_matches[c["name"]] = hit
|
||||
if hit:
|
||||
matches_total += 1
|
||||
rows.append({"path": p, "matches": row_matches})
|
||||
|
||||
rendered = (
|
||||
json.dumps({"rows": rows}, ensure_ascii=False, indent=2)
|
||||
if output == "json"
|
||||
else _render_table(rows, [c["name"] for c in compiled])
|
||||
)
|
||||
|
||||
return InternResponse(
|
||||
text=rendered,
|
||||
usage={
|
||||
"files_scanned": len(paths),
|
||||
"patterns_evaluated": len(compiled),
|
||||
"matches_total": matches_total,
|
||||
},
|
||||
)
|
||||
|
||||
|
||||
def _compile_patterns(patterns, case_sensitive):
|
||||
out = []
|
||||
for p in patterns:
|
||||
if isinstance(p, str):
|
||||
out.append({"name": p, "matcher": _substring(p, case_sensitive)})
|
||||
continue
|
||||
name = p.get("name", p["pattern"])
|
||||
if p.get("regex"):
|
||||
flags = 0 if case_sensitive else re.IGNORECASE
|
||||
out.append({"name": name, "matcher": re.compile(p["pattern"], flags).search})
|
||||
else:
|
||||
out.append({"name": name, "matcher": _substring(p["pattern"], case_sensitive)})
|
||||
return out
|
||||
|
||||
|
||||
def _substring(needle, case_sensitive):
|
||||
if case_sensitive:
|
||||
return lambda text: needle in text
|
||||
n = needle.lower()
|
||||
return lambda text: n in text.lower()
|
||||
|
||||
|
||||
def _render_table(rows, names):
|
||||
header = "| Path | " + " | ".join(names) + " |"
|
||||
sep = "|" + "---|" * (len(names) + 1)
|
||||
lines = [header, sep]
|
||||
for row in rows:
|
||||
cells = []
|
||||
for n in names:
|
||||
v = row["matches"][n]
|
||||
cells.append("⚠️" if v is None else ("✅" if v else "❌"))
|
||||
lines.append(f"| `{row['path']}` | " + " | ".join(cells) + " |")
|
||||
return "\n".join(lines)
|
||||
```
|
||||
|
||||
**NB по базовому классу:** `Intern` base class должен пропустить интерны без `endpoint`/`model` — либо `GrepAudit` overrides `__init__`/`__call__`, либо base поддерживает `endpoint=null` без инициализации LLM-client. Решение — в impl-таске; рекомендую второй вариант (открывает дорогу другим детерминированным интернам).
|
||||
|
||||
## Layer 1 — config (`.common/config/interns/config.yaml`)
|
||||
|
||||
```yaml
|
||||
interns:
|
||||
grep_audit:
|
||||
description: "Deterministic grep matrix over N paths × M patterns. No LLM call, no endpoint cost."
|
||||
endpoint: null # local, no LLM call
|
||||
# No model / max_tokens / temperature / system_prompt — этот интерн без LLM.
|
||||
```
|
||||
|
||||
## Layer 3 — skill update (`using-interns/SKILL.md`)
|
||||
|
||||
Routing-подсказки, добавить:
|
||||
|
||||
> - **`grep_audit`** — аудит N путей × M паттернов (substring или regex). Детерминированный, без LLM-вызова, zero cost, zero hallucination boundary. Использовать когда нужна матрица contains/not-contains: проверка набора CLAUDE.md / SKILL.md / frontmatter полей на присутствие канонических строк. Возвращает markdown-таблицу (default) или JSON.
|
||||
> - **`bulk_text_read` vs `grep_audit`:** первый — Q&A над несколькими файлами (LLM-summary); второй — детерминированная проверка contains/not-contains. Семантический матч — это `bulk_text_read` с вопросом, не `grep_audit`.
|
||||
> - Always-ask paths применяются единообразно с остальными интернами (server всё равно открывает файл, даже без LLM-вызова).
|
||||
|
||||
Bump `using-interns` MINOR (capability added — новый интерн в routing-таблице).
|
||||
|
||||
## Cross-platform
|
||||
|
||||
| Слой | Windows | Linux | macOS |
|
||||
|---|---|---|---|
|
||||
| `Path.read_text(encoding="utf-8", errors="replace")` | ✅ | ✅ | ✅ |
|
||||
| `re` substring/regex | ✅ | ✅ | ✅ |
|
||||
| Always-ask `PurePath.match` | ✅ POSIX-style globs работают везде | ✅ | ✅ |
|
||||
|
||||
Полностью pure-Python, без subprocess/CLI зависимостей.
|
||||
|
||||
## Open questions
|
||||
|
||||
- **Cap на size файла** (e.g., 5 MB)? Сейчас server читает целиком в память. Если bytecode/blob случайно попадёт в paths — RAM-spike. Добавить если pain-point всплывёт; пока YAGNI.
|
||||
- **Batch-mode** (несколько output forms за один вызов)? YAGNI.
|
||||
- **Counting matches** (не bool, а number-of-occurrences)? Сейчас shape — boolean matrix. Если понадобится counts — расширение `output: "counts"`. Решение откладывается.
|
||||
|
||||
## References
|
||||
|
||||
- `concepts/interns-design.md` — parent design (архитектура interns-mcp).
|
||||
- `concepts/interns-repo-read-design.md` — sibling intern (с LLM-вызовом, для сравнения паттерна).
|
||||
- `using-interns/SKILL.md` — target file для routing-добавки.
|
||||
- `.workshop/.archive/2026-05-22-grep-audit-extract.md` — process trace (extract из living-catalog).
|
||||
67
.wiki/concepts/pi-extension-headless-ritual.md
Normal file
67
.wiki/concepts/pi-extension-headless-ritual.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: pi-extension headless ritual — lifecycle + mode lessons
|
||||
type: concept
|
||||
created: 2026-08-12
|
||||
---
|
||||
|
||||
# pi-extension headless ritual (agent_end, mode guard, loop-guard)
|
||||
|
||||
Durable lessons from building `session-close-ritual` (консолидирован в
|
||||
`extensions/mappa.ts` репо `OpeItcLoc03/pi-extensions`, task:1486; исторически —
|
||||
отдельный файл `session-close-ritual.ts`),
|
||||
the headless injector for the session-handoff closing ritual. All three points
|
||||
were live-verified, not docs-read-only.
|
||||
|
||||
## 1. `agent_settled` is TOO LATE for followUp injection
|
||||
|
||||
`agent_settled` fires when pi "will not continue running automatically" — the
|
||||
process is tearing down (no retry/compaction/follow-up left). A `sendUserMessage`
|
||||
with `deliverAs: "followUp"` queued there is never processed; the run ends, and
|
||||
the extension handler even hits a stale-ctx error during teardown.
|
||||
|
||||
**Use `agent_end`** — it fires right after the agent run ends, while queued
|
||||
follow-ups are still delivered (`followUp` waits for the agent to finish, then
|
||||
delivers; `triggerTurn: true` starts a new turn when idle). Verified against
|
||||
`agent-session.js:779-780` ("agent loop drains both queues before emitting
|
||||
agent_end") + live runs.
|
||||
|
||||
## 2. `ctx.hasUI === false` is NOT headless-only — guard by `mode`
|
||||
|
||||
`hasUI` is `false` in BOTH `-p` (print) and `--mode json`. An unsolicited
|
||||
injected user-message into an event-stream consumer (JSON mode) is a protocol
|
||||
surprise. RPC mode has `hasUI === true` (so a hasUI-guard accidentally allows
|
||||
rpc while missing json).
|
||||
|
||||
**Guard: `ctx.mode === "print"`** for pi -p / scripted runs. Excludes
|
||||
tui/json/rpc in one condition.
|
||||
|
||||
## 3. Loop-guard pattern: flag-before-send, per-session-per-cwd
|
||||
|
||||
`agent_end` fires again after the injected ritual turn (the agent made tool
|
||||
calls, then the run ends) — without a guard: agent_end → ritual → agent_end →
|
||||
ritual → … loop.
|
||||
|
||||
- Set the flag **synchronously BEFORE** `sendUserMessage` (no `await` between
|
||||
check and set → no race; `emit()` is serial).
|
||||
- Per-session-per-cwd `Map`, reset on `session_start`.
|
||||
- On send-failure: keep the flag (at-most-once wins over retry — a missed
|
||||
ritual is cheaper than double-inject). This is a deliberate asymmetry vs
|
||||
`inbox-monitor` (which unmarks and retries).
|
||||
- `injectRitual`'s send is wrapped in try/catch: the real `sendUserMessage` is
|
||||
a sync wrapper (`assertActive()` throws on shutdown race).
|
||||
|
||||
## 4. Opt-in mirrors the skill, not the extension
|
||||
|
||||
The extension checks the same opt-in as the skill it serves: the project
|
||||
`CLAUDE.md` contains the skill's trigger line (`session handoff: read on start,
|
||||
write on end`) AND `.tasks/` exists AND `.git` exists. No opt-in → silent.
|
||||
Cache per-cwd; staleness within a long session is accepted (same as
|
||||
`inbox-monitor`).
|
||||
|
||||
## References
|
||||
|
||||
- Source: `~/projects/pi-extensions/extensions/mappa.ts` (секция close-ritual;
|
||||
консолидация 6 расширений, task:1486 — исторически `session-close-ritual.ts`
|
||||
+ `scripts/session-close-ritual.test.mjs`, 12 blocks, ныне тесты на mappa.ts)
|
||||
- Skill: `session-handoff` v0.5.0 — «Headless (pi)» section
|
||||
- pi docs: `extensions.md` — lifecycle diagram, `sendUserMessage` (deliverAs/triggerTurn), mode table
|
||||
36
.wiki/concepts/project-bootstrap-meta-isolation.md
Normal file
36
.wiki/concepts/project-bootstrap-meta-isolation.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: project-bootstrap meta-isolation block
|
||||
type: concept
|
||||
updated: 2026-05-10
|
||||
---
|
||||
|
||||
# project-bootstrap meta-isolation block
|
||||
|
||||
`project-bootstrap` v1.11.0 ships a meta-isolation block in the local `.gitignore` it creates / appends. Block contains `!`-inversions for `.claude/`, `.tasks/`, `.wiki/`, `.brainstorm/`, `.archive/`, `.mcp/`, `.mcp.json`, `MEMORY.md`.
|
||||
|
||||
## Why
|
||||
|
||||
The global `core.excludesFile` (`~/.config/git/ignore`) hides agent meta-paths from forks of upstream open-source — see workshop wiki `concepts/meta-out-of-repo.md` (sections "Слой 2", "Новые проекты"). Without slой 2 in own repos, `setup-wiki` / `setup-tasks` / Step 5 produce `.wiki/`, `.tasks/`, `CLAUDE.md`, but git ignores them and the bootstrap commit lands empty of obvyaska. Empirically reproduced before the fix; smoke test in `assets/.gitignore.template` greenfield confirms.
|
||||
|
||||
## In-skill design choices
|
||||
|
||||
- **Marker comment** — `# AI обвеска — слой 2:` (case-sensitive substring) used to detect the block on upgrade-case append. Comment text matches workshop wiki concept; chosen over checking for `!.tasks/` line because users may add their own ad-hoc `!`-rules unrelated to this block.
|
||||
- **Append-only on upgrade** — never rewrite or reorder existing `.gitignore`. Same discipline as Step 5's CLAUDE.md merge (idempotent, append missing).
|
||||
- **Block applied unconditionally in current modes.** Bootstrap's three modes (greenfield-full, add-remote, upgrade) all assume the user owns the repo. Greenfield-full creates a fresh Gitea repo; add-remote and upgrade operate on user repos. There is no fork-of-upstream mode today — if added, the block must be omitted there (putting `!.claude/` into a fork's `.gitignore` would diverge from upstream's ignore semantics).
|
||||
- **Template change is the load-bearing edit** — greenfield projects pick up the block by template copy. Upgrade-case append handles existing repos that bootstrapped before v1.11.0 (or were created without bootstrap).
|
||||
|
||||
## Acceptance proven
|
||||
|
||||
Smoke test on greenfield (`%TEMP%\test-bootstrap-meta-iso`):
|
||||
|
||||
1. `.gitignore` from template contains the block — ✓.
|
||||
2. `.tasks/_smoke.md` shows as untracked in `git status` — ✓.
|
||||
3. First-commit candidate set includes `.tasks/`, `.wiki/`, `.claude/`, `.brainstorm/`, `MEMORY.md` — ✓.
|
||||
4. Negative control — strip block, status hides all meta-paths (only `.gitignore` itself remains visible). Confirms global excludesFile is the cutter and slой 2 is what restores visibility — ✓.
|
||||
5. Upgrade-case append idempotent — second run with marker present skips — ✓.
|
||||
|
||||
## Pointers
|
||||
|
||||
- Source concept: `~/projects/.workshop/.wiki/concepts/meta-out-of-repo.md`
|
||||
- Sister action-item: `[meta-isolation-existing-repos-migration]` in `OpeItcLoc03/workshop` — one-off migration of existing own repos.
|
||||
- Long-term: `[meta-isolation-mcp-sync-extension]` in `OpeItcLoc03/common` — extend `projects-meta-mcp` to sync `.wiki/` + `.claude/skills/` so meta-paths can leave repo entirely.
|
||||
163
.wiki/concepts/session-handoff-skill-design.md
Normal file
163
.wiki/concepts/session-handoff-skill-design.md
Normal file
@@ -0,0 +1,163 @@
|
||||
---
|
||||
title: session-handoff skill — design rationale
|
||||
type: concept
|
||||
updated: 2026-05-25
|
||||
---
|
||||
|
||||
# session-handoff — design rationale
|
||||
|
||||
Why the skill exists in this shape, with the trade-offs that were considered and the decisions that closed them. Source buffer: `~/projects/.workshop/.archive/2026-05-24-session-handoff-skill.md` (Round 1 brainstorm + Round 2 Q1–Q10 resolution).
|
||||
|
||||
## The problem
|
||||
|
||||
Every fresh CC session in a project starts cold. The agent re-reads `STATUS.md`, greps recent buffers, looks at `MEMORY.md`, and asks the user "where were we?". That's a recurring fog — the user already told the previous session what to do next, and the previous session may have already formulated the plan, but the bridge between sessions doesn't exist.
|
||||
|
||||
The fix: the agent **writes a forward-looking handoff prompt** at session boundaries, into a canonical location the next session reads on cold start. Sliding overwrite: one file, one current state, history through `git log -p`.
|
||||
|
||||
## Why a new skill, not an extension
|
||||
|
||||
The shape was tempting to fold into `using-tasks` — it already touches `.tasks/`. But the lifecycles don't match:
|
||||
|
||||
- `using-tasks` is **per-task** (switch, start, pause, close).
|
||||
- `session-handoff` is **per-session** (start-cold, end-warm).
|
||||
|
||||
Different triggers, different readers, different writers. Per-task state and per-session state happen to share a directory but they answer different questions.
|
||||
|
||||
## Architecture
|
||||
|
||||
**Location:** `.tasks/NEXT_SESSION.md`. Sits next to `STATUS.md` so the `using-tasks` reader already walks `.tasks/` on cold start and notices the handoff without an extra hook.
|
||||
|
||||
**Sliding overwrite:** every write fully replaces the file. No `.archive/handoff-<date>.md` fanout — `git log -p .tasks/NEXT_SESSION.md` is the history if anyone needs it. Rejected the append-with-archive variant because it produces N artefacts the user didn't ask for; the git-log path covers the same need on demand.
|
||||
|
||||
**Project scope:** no global state. Workshop and `.admin/` sessions don't see each other. "Wrap up session" in one tree does not touch the other.
|
||||
|
||||
**Modes:** read on session start (orient + ask, never auto-execute); write on session-end phrase or on substantive commit.
|
||||
|
||||
## Triggers — the resolved choices
|
||||
|
||||
### Read-mode (session start)
|
||||
|
||||
Activated by the `CLAUDE.md` trigger line `session handoff: read on start, write on end` (canonical, added to `project-bootstrap` v1.12.0 template). On cold start: if `.tasks/NEXT_SESSION.md` exists and is fresh, summarise + ask user before any action. If `_last_updated_` is older than 7 days, flag staleness explicitly: "handoff от <date> (N days ago) — overwrite or continue?".
|
||||
|
||||
Default is **orient + ask**, never auto-execute. The previous session might have been wrong; user agency survives.
|
||||
|
||||
### Write-mode — phrase whitelist
|
||||
|
||||
Strict whitelist (rejects close-but-different phrases):
|
||||
|
||||
- Russian: «завершаем сессию», «сворачиваемся», «закругляемся»
|
||||
- English: «wrap up session», «end session», «we're done for now»
|
||||
|
||||
Explicit anti-patterns that **must not** trigger:
|
||||
|
||||
- «закрываем эту таску» — task close, lives in `using-tasks` zone
|
||||
- «pause», «приостанови» — task-pause, not session-end
|
||||
- «отбой», «разбегаемся» — too broad; may refer to a different context
|
||||
- «сейчас завершу одну задачу и тогда поговорим» — partial completion
|
||||
|
||||
On ambiguity (e.g. «закругляемся» with a task-marker tail), the skill **asks** "session or task?" rather than guessing. Closing-bias is the failure mode to avoid.
|
||||
|
||||
### Write-mode — substantive-commit heuristic
|
||||
|
||||
```
|
||||
prefix NOT IN (meta:|docs:|style:|chore:|fix typo)
|
||||
AND (body_length > 200 chars OR files_changed > 3)
|
||||
```
|
||||
|
||||
Plus an explicit "first non-trivial commit of the session always triggers" exception. The reasoning: the *start* of work is itself a context shift worth recording, even when the first commit is small (bootstrap, scaffolding).
|
||||
|
||||
The thresholds are tuned to skip the noise (`chore: bump dep`, `docs: typo`) while catching the actual session-shaping commits. They're not magic numbers — they're the floor below which a handoff regen would dominate signal with noise.
|
||||
|
||||
## Optional PostToolUse hook
|
||||
|
||||
A behavioral memory ("after `git commit`, check the substantive heuristic") is fragile — one missed check leaves the next session with a stale handoff. Solution: an opt-in PostToolUse hook (`skills/session-handoff/hooks/commit-detector.{ps1,sh}`) that emits a `hookSpecificOutput.additionalContext` system reminder after every substantive commit. Harness-side determinism replaces the agent-side memory.
|
||||
|
||||
**Why opt-in, not auto-installed:** `install.sh` deliberately does not mutate `~/.claude/settings.json`. Auto-rewriting the user's hook config on every skill install is the wrong shape — user expects `install.sh` to copy files, nothing more. Hook is shipped as scripts; user enables once per machine via the snippet in `hooks/README.md`.
|
||||
|
||||
**Known caveats:**
|
||||
- Rebase / cherry-pick noise: every commit in a batch re-fires the hook. Deferred — opt-in bounds the cost.
|
||||
- Hook can't see session boundaries, so it under-detects small first-commits-of-session that the agent-side heuristic does catch. Acceptable trade-off for harness-side determinism.
|
||||
- Hook only **signals**; never auto-invokes write-mode. The agent still decides — preserves the user-agency invariant.
|
||||
|
||||
## Handoff content contract
|
||||
|
||||
Five required sections. Empty sections keep their heading + `(нет на этом раунде)` note so the next agent sees "nothing to do here", not "missing":
|
||||
|
||||
```markdown
|
||||
---
|
||||
_last_updated_: <ISO date>
|
||||
session_id: <hash or date>
|
||||
---
|
||||
|
||||
# Next session handoff
|
||||
|
||||
## Recent commits
|
||||
- <slug>: <subject> (3–5 most recent)
|
||||
|
||||
## Open треки
|
||||
| Трек | Готовность | Entry-point |
|
||||
|---|---|---|
|
||||
|
||||
## Спроси user'а
|
||||
- <pending decision>
|
||||
|
||||
## Не делать (preemptive guards)
|
||||
- <guard>
|
||||
|
||||
## Memory updates за сессию
|
||||
- <what was saved / updated>
|
||||
```
|
||||
|
||||
Handoff is **forward-looking** — a bridge of new things specific to the next turn, not an overview of the whole project. `STATUS.md`, `MEMORY.md`, and `.wiki/log.md` remain authoritative for their respective scopes. Don't duplicate them; reference them.
|
||||
|
||||
## Mid-task capture
|
||||
|
||||
If a 🔴 active task exists in `STATUS.md` at write time, the handoff captures `left mid-task: <slug> / where_stopped: <text>`. Rationale: friction of refusing the user ("can't wrap up, you have active work") is worse than the cost of capturing the mid-task state for the next session to resume. User agency owns the call, not the skill.
|
||||
|
||||
## Failure modes that exit early
|
||||
|
||||
- `CLAUDE.md` missing the trigger line → silent exit (opt-in per project).
|
||||
- Not in a git work-tree → silent exit.
|
||||
- `.tasks/NEXT_SESSION.md` absent in read-mode → silent exit (first session of project).
|
||||
- Content matches secret patterns (`AKIA…`, `sk-…`, `ghp_…`, `BEGIN PRIVATE KEY`, `password=…`, etc.) → **abort write**, surface to user. File goes to git, no credentials.
|
||||
- Stale handoff (>7 days) in read mode → **ask** rather than silent — overwrite-or-continue is a user call.
|
||||
|
||||
## What the skill explicitly doesn't do
|
||||
|
||||
- Auto-execute action items from a read handoff. Default is orient + ask.
|
||||
- Append-with-archive. Sliding only.
|
||||
- Trigger on `chore:` / `docs:` / `meta:` commits, on broad farewells, or on partial-completion phrases.
|
||||
- Touch other projects. Per-project scope, full stop.
|
||||
- Depend on a harness `SessionEnd` hook — Claude Code doesn't have one. The available hooks are `SessionStart`, `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, `Stop`, `Notification`. The substantive-commit detection rides on `PostToolUse`.
|
||||
|
||||
## Precedent comparison
|
||||
|
||||
| Source | Lifecycle | Why it doesn't cover the handoff case |
|
||||
|---|---|---|
|
||||
| `using-tasks` STATUS.md `where_stopped` / `next_action` | per-task | misses per-session orientation; handoff needs to bridge tracks, not lock onto one task |
|
||||
| `_queue.md` | parked topics | passive park, not active handoff |
|
||||
| `MEMORY.md` | long-term facts | not anchored to a session boundary |
|
||||
| `.wiki/log.md` | append-only chronology | timeline, not active orientation |
|
||||
| Karpathy daily logbook | personal diary | points to the past (what happened); handoff points to the future (what to do next) |
|
||||
|
||||
Handoff is forward-looking; everything else is backward-looking or timeline-agnostic. That's the slot the skill fills.
|
||||
|
||||
## Acceptance — how the cluster closed
|
||||
|
||||
The skill shipped 2026-05-24 at v0.1.0, with PowerShell hook bug-fix at v0.3.1. Closure cluster — 7/7 tasks:
|
||||
|
||||
1. `[session-handoff-install]` — install.sh + reload + smoke.
|
||||
2. `[session-handoff-hermes-mapping]` — `pending` mode in `hermes/mapping.yaml`.
|
||||
3. `[session-handoff-bootstrap-template-extend]` — `project-bootstrap` v1.12.0 template gets the trigger line out of the box.
|
||||
4. `[session-handoff-posttooluse-hook]` — `hooks/` shipped, opt-in snippet documented, stdin smoke verified.
|
||||
5. `[session-handoff-existing-projects-upgrade]` — manual edit-pass on this machine; 4 repos deferred per-machine.
|
||||
6. `[session-handoff-test-trigger]` — 15/15 behavioral outcomes match (6 whitelist + 4 antipatterns + ambiguity ASK + read-mode R1/R2 + hook H1/H2/H3).
|
||||
7. `[session-handoff-review]` — 6/6 review dimensions ✓ via test-trigger smoke, 0 findings filed, skill v0.3.1 ships unchanged.
|
||||
|
||||
The smoke validated the load-bearing design decisions: ambiguity resolution by asking, the always-first-commit exception, default orient + ask in read-mode. None of them surfaced as gaps — every test came back as a confirmation of the resolved design.
|
||||
|
||||
## Related
|
||||
|
||||
- `pulling-before-work` — the precedent for a `CLAUDE.md`-triggered skill that runs once per session at a defined boundary.
|
||||
- `project-bootstrap` v1.12.0+ — adds the canonical trigger line to new projects.
|
||||
- `using-tasks` — owns `STATUS.md` and `<slug>.md`; the handoff explicitly does not replicate them.
|
||||
79
.wiki/concepts/session-inbox-monitor-received-msg-fp.md
Normal file
79
.wiki/concepts/session-inbox-monitor-received-msg-fp.md
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: session-inbox-monitor — a routed negative only competes if its sibling is installed
|
||||
type: concept
|
||||
tags: [skill-triggers, false-positive, trigger-discrimination, test-trigger]
|
||||
updated: 2026-06-17
|
||||
---
|
||||
|
||||
# session-inbox-monitor — a routed negative only competes if its sibling is installed
|
||||
|
||||
Sibling of [[delegate-task-negative-trigger-fp]]. Same failure family (a skill
|
||||
false-positive-fires on a phrase its description tries to exclude), but a **distinct
|
||||
mechanism** — and it stays **open** as of this writing (follow-up task
|
||||
`session-inbox-monitor-received-msg-fp`, not yet fixed).
|
||||
|
||||
## Symptom
|
||||
|
||||
In the `session-inbox-monitor-test-trigger` run (2026-06-17, clean session, 7 unprimed
|
||||
clean-context subagents), the negative phrase **«В .agents/inbox пришло сообщение от другой
|
||||
Claude-сессии. Прочитай его и ответь отправителю.»** (N1, RU) routed to
|
||||
**`session-inbox-monitor`** — a false-positive. The skill is about *raising the monitor*, not
|
||||
*handling a received message*; the latter belongs to inter-session-peer-discipline /
|
||||
the CLAUDE.md inter-session rule.
|
||||
|
||||
The English twin of the same scenario (N3, «A message arrived in my inbox … handle it and
|
||||
reply») and the multi-machine-backend negative (N2) both routed to `none` cleanly, citing the
|
||||
carve-out. So the FP is **borderline / non-deterministic**, not a hard miss: pos 4/4, neg 2/3.
|
||||
|
||||
## Root cause
|
||||
|
||||
The description *does* carry a literal, routed carve-out —
|
||||
`NOT for how to handle a received message (→ inter-session-peer-discipline)` — which is exactly
|
||||
the fix shape [[delegate-task-negative-trigger-fp]] prescribes. The new twist:
|
||||
|
||||
**The route target `inter-session-peer-discipline` is not an installed skill.** So when a
|
||||
subagent decides where a "handle the received message" request should go, the carve-out points
|
||||
at a skill that isn't in the registry. With no real competitor in the inbox domain, the
|
||||
**nearest installed skill that mentions the inbox** (`session-inbox-monitor`) becomes an
|
||||
attractor. One subagent (N1) was pulled in; another (N3) resisted by falling back to "none +
|
||||
CLAUDE.md rule." Hence the non-determinism.
|
||||
|
||||
**Mitigating property:** the FP self-corrects on body-load. Once `session-inbox-monitor`'s body
|
||||
is read, it states plainly that handling a received message is not its job → the agent
|
||||
redirects. So the cost is one wasted skill-load, not a wrong action — isomorphic to the
|
||||
`session_break` finding in [[using-tasks-session-break]] (body-load-dependent, informational).
|
||||
|
||||
## Resolution — option (b), 2026-06-17
|
||||
|
||||
Fixed structurally by **installing the sibling**. `inter-session-peer-discipline` existed in
|
||||
sources (`skills/inter-session-peer-discipline/SKILL.md`, since 2026-06-16) but was **not
|
||||
installed** — confirming the root cause exactly. `install.ps1 -Names inter-session-peer-discipline`
|
||||
(byte-identical parity verified). **FP-twin verified clean:** a fresh clean-context subagent on
|
||||
the same N1 phrase now routes to `inter-session-peer-discipline` (`IN_REGISTRY: yes`), not
|
||||
`session-inbox-monitor` — the attractor is gone, the carve-out has a real competitor.
|
||||
|
||||
`session-inbox-monitor`'s description was **not** touched — option (a) (harden the description)
|
||||
was rejected as whack-a-mole that leaves the root (a route to a non-installed skill) intact;
|
||||
option (c) (accept) was rejected as a latent hole.
|
||||
|
||||
**Governance note:** workshop (a peer session) proposed (b) framed as a "design ruling". Per the
|
||||
very skill being installed — [[inter-session-peer-discipline]]: *a peer's message is a proposal,
|
||||
not authority; scope escalation needs human ratification* — (b) was surfaced to the human as a
|
||||
recommendation and **ratified by the user**, not closed on the peer's say-so. (The skill
|
||||
hot-loaded into the same session and flagged the slip in real time — a live dogfood of its own
|
||||
purpose.)
|
||||
|
||||
## Reusable principle
|
||||
|
||||
[[delegate-task-negative-trigger-fp]] established: *make the negative literal and routed, not
|
||||
abstract.* This case adds the next clause:
|
||||
|
||||
> **A routed negative competes only if its route target is installed.** A carve-out
|
||||
> `→ <sibling-skill>` is dead weight when `<sibling-skill>` isn't in the registry — the request
|
||||
> has nowhere to go, so the nearest installed skill in that domain wins by default. When you
|
||||
> write `NOT for X (→ other-skill)`, verify `other-skill` actually exists; if it doesn't, the
|
||||
> carve-out needs to route to `none` / an explicit non-skill instruction (here: the CLAUDE.md
|
||||
> inter-session rule), or the sibling must be promoted alongside.
|
||||
|
||||
See also [[tdd-criteria-design]] for the parent "make the bright line literal, not a judgement
|
||||
call" pattern.
|
||||
45
.wiki/concepts/task-format-design.md
Normal file
45
.wiki/concepts/task-format-design.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: task-format skill — design
|
||||
type: concept
|
||||
updated: 2026-06-11
|
||||
---
|
||||
|
||||
# task-format skill — design
|
||||
|
||||
## Why it exists
|
||||
|
||||
The autonomous poller (agents-task-runner) reads each project's `.tasks/STATUS.md` and decides what to claim, how to route it, and whom to notify. Those decisions hang on a handful of fields — most critically `**Weight:**` and `**Notify:**`. The formatting rules for those fields lived only in internal sources: the parser (`projects-meta-mcp/src/lib/status-md.ts`), the writer (`status-md-writer.ts`), and the ops runbook (`.common/.wiki/concepts/agents-task-runner-ops.md`).
|
||||
|
||||
The wiki is internal; **skills ship with `factory` to external users**. An external operator pointing the poller at their own board has no access to the wiki or the MCP source — so the on-disk task-block format had no public, copy-pasteable reference. `task-format` is that reference.
|
||||
|
||||
## Scope — and why it's a separate skill
|
||||
|
||||
Three adjacent skills, deliberately not merged:
|
||||
|
||||
- **`delegate-task`** — workflow for creating a task for *another* project/agent via `mcp__projects-meta__tasks_create`. The tool emits the field format for you; the skill is the pre-flight gate + body template.
|
||||
- **`using-tasks`** — policy for *working* an existing board (claim / switch / close / per-task files).
|
||||
- **`task-format`** (this skill) — the **byte-level field format** the poller parses, for *hand-edited* STATUS.md blocks and for understanding what `tasks_create` produces.
|
||||
|
||||
A hand-edit scenario triggers none of the other two: `delegate-task` is about the MCP tool, `using-tasks` is about board mechanics, neither documents the exact header regex / Weight vocabulary / Notify line. Hence a focused reference skill.
|
||||
|
||||
## Ground truth (sources of record)
|
||||
|
||||
- Header regex `TASK_HEADER = /^##\s+(\S+)\s+\[([^\]]+)\]\s+—\s+(.+)$/u` and all `**Field:**` regexes — `status-md.ts`.
|
||||
- Canonical field order and the writer — `status-md-writer.ts` (`formatTaskBlock`).
|
||||
- Claim gate: only `weight === 'needs-human'` is excluded at claim; capability/runtime gates — `claim.ts` `selectClaimableTask`.
|
||||
- **Missing-Weight behavior:** the claim gate does *not* reject a weightless task, but the fleet router (`fleet-router.js` `resolveBackend`) finds no backend for an `undefined` tier, so the poller parks it to 🔵 blocked (`no backend for weight_tier: unknown`) and inboxes Notify. Net effect — confirmed by source, not folklore — a task without Weight does not run. The skill states this as the operative rule.
|
||||
- Notify resolution + inbox write — `crossProjectAgentPoller.js` `makeInboxWriter`.
|
||||
|
||||
## TDD record (per `superpowers:writing-skills`)
|
||||
|
||||
**RED** — 3 baseline subagents, no skill, asked to author a poller-claimable STATUS.md block (ordinary work ×2, critical-infra ×1). Failures: 2/3 used `### `/bullet-list headers the parser cannot recognize as a task at all; 2/3 omitted `**Weight:**` entirely (invented `risk: low`, `tier: L`, `claimable-by`); 2/3 put the notification in prose instead of a `**Notify:**` field; 1/3 used 🟢 (done) for a ready task. The one partial success only got Weight/Notify right because it *read the board* and found the spec — a crib an external user lacks.
|
||||
|
||||
**GREEN** — 2 fresh subagents with the skill loaded, same scenarios. Both produced parser-valid blocks: correct `## ⚪ [slug] —` header, `**Field:**` lines, `**Weight:**` + `**Notify:**`. The critical-infra agent correctly chose `**Weight:** needs-human` in canonical vocabulary (baseline had invented `tier: L` / `auto: ❌`).
|
||||
|
||||
**REFACTOR** — no new format loopholes surfaced; the skill maps every documented RED failure to a Common-mistakes row.
|
||||
|
||||
## Decisions
|
||||
|
||||
- **Version 0.1.0** — new skill; project-discipline Rule 3 first-version clause (matches `delegate-task` starting at 0.x).
|
||||
- **Reference skill, ~900 words** — exceeds the <500 word target for frequently-loaded skills, justified: it loads only when authoring/editing a task block, and a field reference needs the full table to be useful.
|
||||
- The `needs-human` critical-infra list mirrors `delegate-task` pre-flight Q0 and the ops runbook's "Critical-infra защита" — kept consistent on purpose.
|
||||
181
.wiki/concepts/tdd-criteria-design.md
Normal file
181
.wiki/concepts/tdd-criteria-design.md
Normal file
@@ -0,0 +1,181 @@
|
||||
---
|
||||
date: '2026-05-07'
|
||||
source: .meeting-room/.archive/2026-05-07-tdd-criteria.md
|
||||
status: promoted
|
||||
type: design
|
||||
title: tdd-criteria-design
|
||||
amended: "2026-05-07: added test-immutability defence (Anti-loophole rule 4) after user noted symmetric vandalism risk on tests; 2026-05-07 v0.2.0 review: removed session-authorship trigger loophole, added composite-tasks/refactoring sections, expanded file-extension list, clarified wrapper line-count"
|
||||
ingested_at: '2026-05-07T04:01:23.616Z'
|
||||
ingested_by: OpeItcLoc03@DESKTOP-NSEF0UK
|
||||
source_project: .meeting-room
|
||||
---
|
||||
# TDD-criteria — design rationale
|
||||
|
||||
> Design document for the `tdd-criteria` skill. Captures **why** the rule is shaped the way it is — the SKILL.md itself is the runtime artefact (procedure + triggers); this page is the argument.
|
||||
|
||||
## Problem statement
|
||||
|
||||
User is ready to adopt TDD as default across projects but wants **bright-line carve-outs** to prevent TDD from degenerating into a tax that every task pays. The risk is the «exploratory loophole»: if the rule is «without TDD is OK for exploratory work», every task ex post facto becomes «exploratory».
|
||||
|
||||
Bright-line means: at decision time, the agent (human or LLM) answers each criterion with **yes/no based on observable property** — no «мне кажется», no judgment calls. If a criterion needs intuition, it's not a criterion, it's a loophole.
|
||||
|
||||
## The argument behind TDD-default
|
||||
|
||||
The four classical arguments — bug fixes are easier with red-tests; pure logic is cheap to test; third-party contracts silently break; security/money has asymmetric blast radius — are about **correctness** of behaviour. They tell you when to defend against *wrong* behaviour.
|
||||
|
||||
The **strongest** argument, and the leading rationale in this design, is different: TDD-default is the only mechanism that protects behaviour **from being silently deleted**.
|
||||
|
||||
Mechanism:
|
||||
|
||||
- **Without a test**, the contract for a piece of code is «it exists in the repo». That's an artefact, not an invariant. An agent (LLM coder, new hire, future self) sees «messy code» → deletes it → commits «cleaner now» → reports success. That the code implemented real behaviour is **recorded nowhere except the code**, which is now gone. Recovery is `git log` archaeology, *after* somebody notices the regression — days or weeks later.
|
||||
- **With a test**, the contract is «X(Y)=Z». That's an invariant. Delete X → test fails → pipeline red → success can't be reported. The test is **the advocate of the behaviour at the moment when the behaviour itself no longer exists**.
|
||||
|
||||
In a workflow that includes LLM coders (Claude, ChatGPT, future unknowns) and rotating contractors, this isn't theoretical. The user has personally observed agents deleting working code and reporting «I cleaned it up» — recovery required manual git archaeology. Tests would have made that impossible.
|
||||
|
||||
This reframes everything below:
|
||||
|
||||
### The contract is only as strong as the contract itself
|
||||
|
||||
But there's a **second-order vandalism mode** that the bare contract argument doesn't cover: the agent doesn't delete the code, it rewrites the **test**. Test fails → agent changes the expected value, adds `.skip`, or deletes the test → test now passes → success reported.
|
||||
|
||||
If the contract artefact (the test) is rewritable by the same agent that's failing to satisfy it, the invariant collapses back into an artefact. The defence requires **two layers**:
|
||||
|
||||
1. **Code is defended by tests.** Ironclad rules 1-4 below.
|
||||
2. **Tests are defended by process discipline.** Anti-loophole rule 4 below — append-only by default, modifications require literal-`was/is` marker in commit subject, test changes are separate commits from impl changes.
|
||||
|
||||
Both layers are needed. Either alone leaves a path-of-least-resistance route to «success».
|
||||
|
||||
- **Ironclad** rules (TDD obligatory) — zones where recovery cost > defending cost. Signal mandatory.
|
||||
- **Permissive** carve-outs — **zones of accepted risk for agentic vandalism**, not «zones where TDD doesn't apply». You explicitly accept that an agent can delete-and-claim-success here, because recovery is cheap (eyeball the next render; throwaway by contract; one-shot already ran; wrapper trivial to reconstruct).
|
||||
|
||||
## Decision algorithm
|
||||
|
||||
Walk through 8 questions top-to-bottom. First «yes» determines mode. All «no» → TDD by default.
|
||||
|
||||
```
|
||||
1. Это исправление бага? → TDD (red-test первым)
|
||||
2. Это код, потребляющий внешний контракт → TDD (contract-test)
|
||||
(SDK, REST API, foreign schema)?
|
||||
3. Это security / auth / money / identifiers? → TDD
|
||||
4. Это pure logic — функция (input → output) → TDD
|
||||
без I/O, без global state, bounded inputs?
|
||||
|
||||
5. Это visual / config — CSS, layout, design → SKIP, [skip-tdd: visual]
|
||||
tokens, .env.example, prompt-тексты,
|
||||
wiki, README?
|
||||
6. Это явно объявленный spike (зафиксировано → SKIP, [skip-tdd: spike]
|
||||
в commit/PR/task subject «POC, выкину»)? + spike-survivor task если выживет
|
||||
7. Это one-shot скрипт — миграция, ETL backfill, → SKIP, [skip-tdd: oneshot]
|
||||
ad-hoc cleanup, runs once?
|
||||
8. Это транзитный wrapper ≤10 строк → SKIP, [skip-tdd: wrapper]
|
||||
без branching (re-export, glue)?
|
||||
|
||||
(default) → TDD
|
||||
```
|
||||
|
||||
**Composite tasks.** A task that doesn't fit one category is composite — break it down per artefact type. The criterion applies per artefact, not per task.
|
||||
|
||||
**Refactoring.** Restructuring existing code without changing observable behaviour, where existing tests already cover it, does not require new tests. If the refactoring introduces new behaviour, that part is a separate artefact subject to the decision algorithm.
|
||||
|
||||
## Ironclad — why TDD is cheaper than skipping
|
||||
|
||||
| # | Rule | Checkable property | Why TDD here |
|
||||
|---|---|---|---|
|
||||
| 1 | Bug fix | «есть issue / failure log / repro?» | Bug already reproduced — red-test is just codifying the repro. Marginal cost: 5 min. Marginal benefit: regression test forever. Without it, «fixed» = checked once, regresses on next refactor. |
|
||||
| 2 | Pure logic, bounded inputs | «функция читает диск/сеть/БД/mutates global state?» — no | Cheapest TDD surface: no fixtures, no mocks, no setup. Test = input/output pair. Marginal cost ≈ 0. Skip is gratuitous. |
|
||||
| 3 | Third-party contract | «вызывает чужой SDK / парсит чужую schema?» | SDK bumps change signatures silently. Contract-test pins «known input → known shape». Catches the break at first `npm install` instead of «endpoint висит несколько дней». Direct counter-case observed: `modules-db/fill-fields-ai-sdk-migration` post AI SDK v5→v6. |
|
||||
| 4 | Security / auth / money / IDs | «касается токенов/паролей/валюты/идентификаторов/прав?» | Asymmetric blast radius: false positive (slow code, slow test) ≪ false negative (account takeover, data corruption, money loss). TDD = insurance. |
|
||||
|
||||
**Plus the meta-rationale**: in all four, recovery cost from silent deletion is high. The test is the only artefact that makes deletion visible.
|
||||
|
||||
## Permissive — accepted-risk zones
|
||||
|
||||
Not «TDD doesn't apply». **«You accept that an agent can vandalise this without immediate signal, because recovery is cheap.»** Entry into the zone is explicit, marked in the commit subject.
|
||||
|
||||
| # | Category | Trigger | Marker | Recovery cost (= reason TDD doesn't pay) |
|
||||
|---|---|---|---|---|
|
||||
| 5 | Visual / config | CSS, layout, design tokens, `.env.example`, prompts, wiki, README | `[skip-tdd: visual]` | Eyeball on next render. Visual regression infra exists (Playwright screenshots, Percy) but heavyweight for most projects. |
|
||||
| 6 | Spike | Explicit POC «throwaway» in commit/PR/task subject | `[skip-tdd: spike]` | Throwaway by contract — deletion isn't a problem. **Survivor rule**: if spike code reaches master, the same merge-commit creates `[backfill-tests-<slug>]` task. Otherwise this category becomes the loophole. |
|
||||
| 7 | One-shot | Migrations, ETL backfill, ad-hoc cleanup; runs once | `[skip-tdd: oneshot]` | Test never re-executes — cost not recovered. After run, deletion is irrelevant. |
|
||||
| 8 | Wrapper | ≤10 non-blank non-comment lines, no branching (re-export, glue) | `[skip-tdd: wrapper]` | Test on `function foo(x) { return bar(x) }` re-states `bar`. Reconstruct cost ≈ delete cost. The defence is on `bar`, not `foo`. |
|
||||
|
||||
## Anti-loophole
|
||||
|
||||
1. **Skip без категории не существует.** One of four explicit categories — not «other reasons». No marker = violation, regardless of perceived justification.
|
||||
2. **Spike survivor rule.** If spike code is merged to master → same merge-commit creates `[backfill-tests-<slug>]` task in `.tasks/STATUS.md`. Otherwise «spike» becomes «skipped tests forever».
|
||||
3. **Friction is the point.** `[skip-tdd: visual]` 50 раз подряд при `web-design-system` итерации раздражает — это и есть замысел. Friction = fence, not bug. If it becomes unbearable, re-evaluate after ≥2 weeks of usage, not before.
|
||||
4. **Tests are append-only by default** (added 2026-05-07). New tests: free. **Modifying** an existing assertion, **deleting** a test, or **disabling** it (`it.skip`, `xit`, `@pytest.mark.skip`, `@Disabled`, etc.) requires both:
|
||||
|
||||
**a)** A marker in commit subject:
|
||||
```
|
||||
[test-modify: <test-name>: was <X>; is <Y>; reason: <Z>]
|
||||
```
|
||||
Where `<X>` and `<Y>` are the **literal assertion expressions** before and after, not paraphrased. Example:
|
||||
```
|
||||
[test-modify: validates email format: was expect(isValid("a@b")).toBe(true); is expect(isValid("a@b.com")).toBe(true); reason: tightened spec to require TLD]
|
||||
```
|
||||
|
||||
**b)** Test changes go in a **separate commit** from any impl changes. A single commit must not modify both `*.test.*` and `src/*` files (or their project-equivalents). This forces an audit-able split — `git log --grep '\[test-modify'` shows every test rewrite cleanly.
|
||||
|
||||
**Why literal `was/is`, not free-form reason:** an agent forced to write the literal assertion publishes exactly what they're rewriting. If `42` was the correct expectation and they changed it to `43` to make a buggy fix pass, the literal `was 42; is 43` line in `git log` identifies the culprit. A reason like «updated to match new behaviour» hides everything — agents will use it whenever it is allowed.
|
||||
|
||||
**Bright-line check** (for an optional pre-commit hook, see follow-up task `tdd-criteria-precommit-hook`):
|
||||
- `git diff --cached` includes a removed `expect(...)` / `assert(...)` / `assertThat(...)` line, OR
|
||||
- changes the arguments of an existing assertion call, OR
|
||||
- adds `.skip`, `xit`, `@skip`, `@Disabled`, etc. annotation, OR
|
||||
- deletes a test file or `it(...)` / `test(...)` / `def test_*` definition
|
||||
|
||||
AND the commit subject does not contain `[test-modify: ...]` matching the format above → block.
|
||||
|
||||
AND `git diff --cached --name-only` includes both test-pattern and impl-pattern files → block (require split).
|
||||
|
||||
5. **Don't apply rule 4 retroactively** to tests written before the rule was adopted. The rule applies to test changes made after the project's CLAUDE.md picks up `follow tdd-criteria`. Existing test bodies aren't grandfathered into requiring `was/is` for a one-time rewrite.
|
||||
|
||||
## What's excluded as not bright-line
|
||||
|
||||
These tempting formulations were rejected:
|
||||
|
||||
- ~~«Exploratory»~~ — every task becomes exploratory in retrospect.
|
||||
- ~~«When time is short»~~ — time is never abundant.
|
||||
- ~~«When the logic is obvious»~~ — it seems obvious until the first bug.
|
||||
- ~~«When the code is temporary»~~ — there's no such thing; temporary code becomes permanent.
|
||||
- ~~«Tests should not be modified casually»~~ — paraphrasable, agents will modify casually and call it «refactor». Replaced by Anti-loophole rule 4 with literal-evidence requirement.
|
||||
|
||||
All require judgment at decision time → automatically become loopholes. The four Permissive categories are bound to **observable properties** (file extension, marker in commit subject, directory, line count) — not mood.
|
||||
|
||||
## Composite tasks
|
||||
|
||||
A task that doesn't fit any single category cleanly is a **composite task** — break it down by artefact type.
|
||||
|
||||
Example: «add a user-profile-settings page»:
|
||||
|
||||
- HTML/CSS layout → `[skip-tdd: visual]`
|
||||
- Validation form (email format, password strength) → Ironclad-4 (security) → TDD
|
||||
- API call wrapper for save → Ironclad-3 (third-party contract if PUT to external endpoint) → TDD
|
||||
- Update Pinia store reducer → Ironclad-2 (pure logic if bounded reducer) → TDD
|
||||
- Hook `useProfileForm` composing the above → wrapper if ≤10 non-blank non-comment lines glue, else Ironclad-2
|
||||
|
||||
One «task» yields 4-5 commits with different modes. **The criterion applies per artefact, not per task.** This is the point — no «overall this is exploratory».
|
||||
|
||||
## Project-level overrides
|
||||
|
||||
Project `CLAUDE.md` files may **extend** Permissive (e.g. `karu` is a pure-CSS project — wider visual carve-out is appropriate) or **extend** Ironclad with project-specific categories (e.g. `books` could add «scheduler tasks touching Mongo state» as Ironclad-5). Project files **may not narrow Ironclad** — the global floor stands.
|
||||
|
||||
## Trade-offs (honest)
|
||||
|
||||
- **Supportive evidence is n=1.** The observable contrast is `books` (TDD applied selectively, features ship) vs `modules-db`/`pilonuxt` (TDD not applied, projects buksuyut). `books` could be more productive for reasons unrelated to TDD (codebase maturity, author experience, task type). The direction-of-effect agrees with first principles, so inversion is unlikely, but the magnitude is uncertain.
|
||||
- **Friction in UI iterations.** `[skip-tdd: visual]` repeated 50× during a design-system rework is annoying. Intentional. Don't relax before ≥2 weeks of usage.
|
||||
- **The literal-`was/is` requirement is verbose** for a renamed test or trivial typo fix. The verbosity is the point — an agent that genuinely fixed a typo writes the same assertion twice with one character changed; an agent that rewrote a failing test writes obviously different assertions. Reading `git log --grep '\[test-modify'` shows the difference at a glance.
|
||||
- **«Don't codify at all» was rejected.** Precisely «not codified» is what produced the situation in `books` where, after the author left, his TDD criterion can't be reconstructed — it lived only in his head and his commits. A departed contributor is an argument *for* codification, not *against*.
|
||||
- **The anti-vandalism argument is uncomfortable.** It says: «I don't trust agents not to delete my code». That's the position. If it changes, this rationale changes. Until then, this is what's load-bearing.
|
||||
|
||||
## Cross-agent applicability
|
||||
|
||||
Pure policy — no Claude-specific tool references (no `Read`/`Edit`/`Bash`/`Glob` calls in the SKILL.md body). Hermes mapping: `mode: auto`, `category: software-development`, no replace-rules. Future agents (Gemini, Copilot, in-house) inherit via their respective rollout adaptors.
|
||||
|
||||
## See also
|
||||
|
||||
- Skill artefact: `claude-skills/skills/tdd-criteria/SKILL.md` (runtime: triggers + procedure).
|
||||
- Hermes mapping: `claude-skills/hermes/mapping.yaml` entry `tdd-criteria`.
|
||||
- Original brainstorm: `.meeting-room/.archive/2026-05-07-tdd-criteria.md` (full discussion arc with 6 rounds + observable evidence from `mcp__projects-meta__tasks_get` on `books`/`modules-db`/`pilonuxt`).
|
||||
- Precedent for «move a rule from `~/.claude/CLAUDE.md` into a skill»: `claude-skills/skills/recommend-dont-menu/SKILL.md` («Why this exists» section).
|
||||
58
.wiki/concepts/using-markitdown-cli-migration.md
Normal file
58
.wiki/concepts/using-markitdown-cli-migration.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: using-markitdown — MCP → CLI migration
|
||||
type: concept
|
||||
updated: 2026-06-09
|
||||
---
|
||||
|
||||
# using-markitdown — MCP → CLI migration
|
||||
|
||||
`using-markitdown` v1.0.0 → v1.0.1 (PATCH). Rewrote the skill from the Docker-based
|
||||
`mcp__markitdown__convert_to_markdown` MCP tool to the native `markitdown` CLI (v0.1.6,
|
||||
on `PATH`).
|
||||
|
||||
## Why
|
||||
|
||||
The MCP path ran markitdown inside a Docker container with a single host directory
|
||||
bind-mounted (`-v C:\Users\vitya:/workdir`). That forced a brittle host→container path
|
||||
translation for every local file (`file:///workdir/...`), and the failure mode
|
||||
(`[Errno 2] No such file or directory: '/c:/Users/...'`) was a recurring foot-gun. The
|
||||
container also could not see files outside its one mount.
|
||||
|
||||
The CLI is a normal local process: it sees the full host filesystem, takes a plain path
|
||||
or URL as its positional arg, and writes markdown to stdout (or to a file with `-o`). No
|
||||
mount, no path rewriting, no `file://` URIs. The whole "Docker-mount caveat (READ FIRST)"
|
||||
section of the skill became dead weight and was removed.
|
||||
|
||||
## CLI contract
|
||||
|
||||
```
|
||||
markitdown <path|url> # → markdown to stdout
|
||||
markitdown <path|url> -o out.md # → write to a file
|
||||
cat file.pdf | markitdown -x pdf # → stdin + format hint
|
||||
```
|
||||
|
||||
Verified on this machine: `markitdown 0.1.6`; URL fetch (`markitdown https://example.com`)
|
||||
and stdout conversion both work.
|
||||
|
||||
## Container cleanup gotcha
|
||||
|
||||
The task asked to run `docker stop markitdown-mcp && docker rm markitdown-mcp`. There was
|
||||
**no container named `markitdown-mcp`** — the MCP server spawns a fresh anonymously-named
|
||||
container from the `markitdown-mcp:latest` image per session, and three had piled up
|
||||
(`sharp_jones`, `boring_goldberg`, `admiring_kowalevski`, ages 47s–28h). The correct
|
||||
decommission is by image ancestor, not by name:
|
||||
|
||||
```
|
||||
docker rm -f $(docker ps -aq --filter "ancestor=markitdown-mcp:latest")
|
||||
```
|
||||
|
||||
(Stopping them races with the server's own `--rm` cleanup, briefly leaving "Dead"
|
||||
containers that finish removing themselves — re-checking the filter confirms none remain.)
|
||||
|
||||
## Out of scope / follow-up
|
||||
|
||||
The `markitdown` **MCP server registration** in `~/.claude.json` was left untouched (the
|
||||
task scoped only the running container, and editing user-global config is cross-cutting).
|
||||
While that entry remains, a new container will respawn on the next session that loads the
|
||||
MCP. A full decommission would deregister `mcpServers.markitdown` from `~/.claude.json` —
|
||||
recommended as a separate, explicitly-confirmed step.
|
||||
98
.wiki/concepts/using-system-snapshot-design.md
Normal file
98
.wiki/concepts/using-system-snapshot-design.md
Normal file
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: using-system-snapshot skill design
|
||||
type: concept
|
||||
updated: 2026-06-09
|
||||
---
|
||||
|
||||
# using-system-snapshot skill design
|
||||
|
||||
New policy+technique skill (v0.1.0) wrapping the single MCP call
|
||||
`mcp__projects-meta__meta_system_snapshot`. Replaces the old scatter of
|
||||
`tasklist` + `docker ps` + a manual `meta_status` read with one round-trip for
|
||||
session-start ops orientation.
|
||||
|
||||
## Why a skill
|
||||
|
||||
The failure mode it guards: an agent asserts "the poller is running" / "all
|
||||
containers are up" / "you have N active tasks" from memory or a stale earlier
|
||||
snapshot, without re-checking. The skill makes the rule explicit — **no claim
|
||||
about poller / local-docker / task-load state without calling the tool in the
|
||||
current turn**. Mirrors the read-only, no-grant posture of [[using-vds-ops]].
|
||||
|
||||
## Tool output shape (verified live 2026-06-09)
|
||||
|
||||
Three keys:
|
||||
|
||||
- `poller`: `{ running: bool, projects: "<owner/repo …>" }` — **live**.
|
||||
- `docker`: `[{ name, status }]` — **local** machine containers (includes
|
||||
`agents-task-runner-*`), NOT the VDS. Status strings like `Up 4 hours`,
|
||||
`Up 26 hours (healthy)`; problems show as `Restarting` / `Exited` /
|
||||
`(unhealthy)` / `Created` / `Paused`. **live**.
|
||||
- `tasks`: `{ "<owner>/<repo>": { active, blocked } }` — **from the
|
||||
projects-meta cache**, so approximate.
|
||||
|
||||
## Design decisions
|
||||
|
||||
- **Output = three lines, one per section** (per task spec). Docker line reports
|
||||
`N/N up` when all healthy, else lists only the bad containers; tasks line gives
|
||||
Σ active / Σ blocked + the busiest 2–3 projects. Never dump raw JSON.
|
||||
- **Liveness split made explicit.** Poller + docker are read at call time; task
|
||||
counts come from the cache. The skill tells the agent to flag task-count
|
||||
staleness and defer precise per-task work to [[projects-meta-skills]]
|
||||
(`using-projects-meta` Step 0 freshness gate, or local `.tasks/` on disk).
|
||||
- **Scope boundaries.** Deep single-container diagnosis (logs/inspect/stats) is
|
||||
explicitly out — that's [[using-vds-ops]] for the VDS or `docker logs`
|
||||
locally. The snapshot only carries name + status.
|
||||
- **Read-only, no per-session grant** — same as [[using-vds-ops]]. The tool
|
||||
takes no args; no preview/confirm dance (unlike the projects-meta mutations).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Needs `mcp__projects-meta__meta_system_snapshot` (shipped by `projects-meta-mcp`;
|
||||
the `meta-system-snapshot` capability lives in `OpeItcLoc03/common`). If the tool
|
||||
is absent, the server isn't registered → `setup-projects-meta`.
|
||||
|
||||
## TDD note
|
||||
|
||||
Markdown policy artifact — no code/test surface (consistent with sibling skill
|
||||
tasks). Behavioral trigger smoke-test is the paired `skill-using-system-snapshot-review`
|
||||
task, not this implementation task.
|
||||
|
||||
## Review outcome (2026-06-09, `skill-using-system-snapshot-review`)
|
||||
|
||||
**Verdict: PASS** on all three acceptance criteria. Reviewer was a non-implementer
|
||||
session.
|
||||
|
||||
- **Tool contract verified live** — a real `meta_system_snapshot` call returned
|
||||
exactly the documented shape (`poller {running, projects}`, `docker [{name,
|
||||
status}]` incl. `agents-task-runner-*` with `Up … (healthy)` strings, `tasks
|
||||
{owner/repo: {active, blocked}}`). The "The call" table and this page are accurate.
|
||||
- **Trigger phrases cover real scenarios** ✅ — 9 fresh-context subagents, each
|
||||
given a simulated skill registry (real descriptions + `using-vds-ops` /
|
||||
`using-projects-meta` / `using-tasks` competitors) and one trigger phrase, no
|
||||
hint of the expected answer. 4/4 positives → `using-system-snapshot`; VDS-logs →
|
||||
`using-vds-ops`; mutate/full-board → `using-projects-meta`; `docker-compose.yml`
|
||||
edit → `none` (no false-positive on the "docker" keyword).
|
||||
- **No-claim-without-snapshot rule explicit** ✅ — stated in 4 places (Overview
|
||||
core rule, "When to use", "What NOT to do", Common-mistakes table).
|
||||
- **Output format brief** ✅ — three-line block, per-line rules, "no raw JSON";
|
||||
confirmed achievable against the live payload.
|
||||
|
||||
**Informational findings (none blocking):**
|
||||
|
||||
1. **Task-count overlap with `using-projects-meta`.** «сколько активных задач по
|
||||
всем проектам» routed to `using-projects-meta`, not the snapshot. By-design —
|
||||
the skill defers *precise* per-task work and the `tasks` line is a bonus of the
|
||||
combined ops view, not its headline — so no fix. Quick «сводка по задачам …»
|
||||
glances still route here correctly.
|
||||
2. **Local-container deep diagnosis is unowned.** «локальный контейнер … почему
|
||||
рестартует» routed to `using-vds-ops` (its incident-phrase triggers grabbed a
|
||||
*local* container, which its VDS-only tools can't reach). Not this skill's
|
||||
defect — the snapshot correctly does not claim deep "why". Candidate
|
||||
`using-vds-ops` scoping follow-up if it recurs.
|
||||
3. **Deployment scaffold missing.** The skill is committed (`skills/…`, v0.1.0)
|
||||
but is **not** installed to `~/.claude/skills/`, **not** in
|
||||
`hermes/mapping.yaml`, and has no `-install` / `-hermes-mapping` /
|
||||
`-test-trigger` baseline tasks (unlike `meta-host-routing` / `delegate-task`).
|
||||
Recommended follow-ups before it reaches live sessions; hermes mode could be
|
||||
`auto` since the skill is read-only (owner's call).
|
||||
52
.wiki/concepts/using-tasks-session-break.md
Normal file
52
.wiki/concepts/using-tasks-session-break.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: using-tasks session_break marker
|
||||
type: concept
|
||||
tags: [using-tasks, autonomous-runner, session-boundary]
|
||||
updated: 2026-06-09
|
||||
---
|
||||
|
||||
# using-tasks `session_break` marker
|
||||
|
||||
`using-tasks` v1.2.0 adds a `session_break` marker so a task author can mark a task's
|
||||
completion as a natural place to **stop**, rather than have an autonomous agent immediately
|
||||
chain into the next task via `tasks_claim_next`.
|
||||
|
||||
## Problem
|
||||
|
||||
An autonomous runner closes a task and, by default, claims the next one. There is no signal
|
||||
for "this is a good seam to end the session" — so unrelated tracks get welded into one
|
||||
ever-growing context, and the natural review/hand-off moment is skipped.
|
||||
|
||||
## Design
|
||||
|
||||
- **Marker:** `session_break` in the task's frontmatter (task-system delivery) or the
|
||||
`**Session break:**` field in the task's STATUS.md block (local board mirror).
|
||||
- **Type:** boolean or string.
|
||||
- `true` → pause after close; next track is "see STATUS.md".
|
||||
- `"<hint>"` → pause after close; the hint names the recommended next track.
|
||||
- **Enforcement point:** `using-tasks` → Task completion, **step 6** — *after* the task is
|
||||
🟢 and committed, *before* any `tasks_claim_next` / starting the next task.
|
||||
- **Behaviour when present:** print the SESSION BOUNDARY line verbatim, then stop (do not
|
||||
claim the next task).
|
||||
- **Behaviour when absent:** unchanged — claim / start the next task as usual.
|
||||
|
||||
### Verbatim message
|
||||
|
||||
```
|
||||
🔚 SESSION BOUNDARY — [slug] закрыта. Рекомендую завершить текущую сессию. Следующий трек: [value | "см. STATUS.md"]
|
||||
```
|
||||
|
||||
`[slug]` = the closed task's slug. `[value | "см. STATUS.md"]` = the marker's string value,
|
||||
or the literal `см. STATUS.md` when the marker is just `true`. The wording is fixed so the
|
||||
boundary is greppable and recognisable across sessions.
|
||||
|
||||
## Why a marker, not a heuristic
|
||||
|
||||
The decision of *what counts as a stopping point* belongs to whoever scoped the work (the
|
||||
delegating workshop), not to the runner mid-flight. A heuristic ("stop after N tasks", "stop
|
||||
when tired") would either over- or under-fire. An explicit, opt-in marker keeps the default
|
||||
unchanged and makes the boundary a deliberate authoring choice.
|
||||
|
||||
## Versioning
|
||||
|
||||
MINOR bump (1.1.0 → 1.2.0): new optional capability, no existing behaviour changed.
|
||||
84
.wiki/concepts/using-tasks-status-archival.md
Normal file
84
.wiki/concepts/using-tasks-status-archival.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: using-tasks done-task archival (STATUS.md bloat fix)
|
||||
type: concept
|
||||
updated: 2026-06-09
|
||||
---
|
||||
|
||||
# using-tasks done-task archival
|
||||
|
||||
`using-tasks` v1.2.0 → **v1.3.0** (MINOR — new backward-compatible rule). Fixes the recurring
|
||||
"huge STATUS.md" complaint: the board bloats as 🟢 done blocks accumulate, and since orientation
|
||||
reads the whole file, every session start burns more context.
|
||||
|
||||
## The fix that shipped
|
||||
|
||||
A **done-task archival rule** in the skill:
|
||||
|
||||
- **Threshold:** when `STATUS.md` holds **≥ 10** 🟢 done blocks, archive them.
|
||||
- **Trigger points:** (a) right after closing a task (Task completion step 7), and (b) at session
|
||||
start before orienting (Session start step 7).
|
||||
- **Target:** append the blocks **verbatim** (with their `---` separators and `<!-- closed-by -->`
|
||||
comments) to `.tasks/archive/YYYY-MM.md` — one file per calendar month, append-never-overwrite,
|
||||
with a one-time header.
|
||||
- **Result:** `STATUS.md` keeps only 🔴 / 🟡 / ⚪ / 🔵 blocks. Commit the move on its own
|
||||
(`meta(tasks): archive done batch → .tasks/archive/YYYY-MM.md`).
|
||||
|
||||
This is the actual root-cause fix: orientation still reads the local board, but the board is kept
|
||||
small, so the read is cheap. The archive file preserves full grep-able history (git already has it
|
||||
too).
|
||||
|
||||
## Why the task's literal instruction was NOT followed
|
||||
|
||||
The originating task ([using-tasks-status-read-perf]) asked to **replace `Read STATUS.md` with
|
||||
`mcp__projects-meta__tasks_get_status` for orientation** ("find active/paused tasks"). That rests on
|
||||
a factual misunderstanding of the tool and was deliberately **not** implemented as written:
|
||||
|
||||
- **`tasks_get_status(target_project, slug)` → `{status, found}`** — returns the live status of a
|
||||
**single** task whose slug you already know. It reads the target's `.tasks/STATUS.md` directly
|
||||
(live, not cached), but it **cannot enumerate** the board. Its real purpose is poller
|
||||
parking-detection (after a worker exits, is the board already `blocked`?). Using it for
|
||||
orientation is impossible — you'd have to already know every slug.
|
||||
- **`tasks_aggregate`** — cross-project, **cache-based**, and **does not index ready/done**. Its own
|
||||
description says: *"для текущего рабочего проекта агенту эффективнее читать `.tasks/STATUS.md`
|
||||
напрямую — кэш может быть stale."*
|
||||
|
||||
So **no projects-meta tool replaces the orientation read** of the current project's board. The
|
||||
honest answer to "find all places where Read STATUS.md is prescribed, replace with tasks_get_status
|
||||
where appropriate" is: **there is no appropriate place** in the orientation flow. Instead the skill
|
||||
now (1) keeps orientation as a local `STATUS.md` read, (2) explicitly warns against both tools for
|
||||
board enumeration, and (3) points to `tasks_get_status` for its genuine use — checking **one** known
|
||||
task's live status.
|
||||
|
||||
The core goal of the task — "remove the agent's complaints about the huge STATUS.md" — is fully met
|
||||
by the archival rule, independent of the tool swap.
|
||||
|
||||
## Reusable principle
|
||||
|
||||
When a delegated task prescribes a *mechanism* that a tool can't actually perform, fix the *problem*
|
||||
(here: board bloat → archive) rather than the literal mechanism. Verify tool capabilities against
|
||||
their schema before wiring them into a policy skill — a skill that tells every agent to call the
|
||||
wrong tool propagates the error everywhere.
|
||||
|
||||
Pairs with [[using-tasks-session-break]] (the prior v1.2.0 increment) and the local-first read rule
|
||||
in [[projects-meta-skills]].
|
||||
|
||||
## Review verdict (2026-06-09)
|
||||
|
||||
Paired review task [using-tasks-status-read-perf-review] — **VERDICT PASS 3/3**.
|
||||
|
||||
- **"Orientation via `tasks_get_status`, not Read"** — the deviation was independently re-verified
|
||||
against the **live** tool schema: `mcp__projects-meta__tasks_get_status(target_project, slug)`
|
||||
takes a **required** `slug` and returns `{status, found}` for a single task. It provably cannot
|
||||
enumerate the board, so it cannot drive orientation. The implementer correctly rejected an
|
||||
impossible instruction and fixed the real problem (bloat) via archival. Criterion satisfied by a
|
||||
validated deviation, not by a literal swap.
|
||||
- **No regression** — orientation still reads the local `STATUS.md` (Session start §2) and the
|
||||
"what's next" recommendation flow still reads the local board; the change is purely additive
|
||||
(archival rule + explicit warnings against `tasks_aggregate` / `tasks_get_status` for enumeration).
|
||||
- **Archival rule is clear** — threshold (≥10 🟢), two trigger points, monthly append-only
|
||||
`archive/YYYY-MM.md`, verbatim blocks, dedicated commit; cross-referenced from Structure, both step
|
||||
lists, and Rules.
|
||||
|
||||
Informational, non-blocking: this repo's own `STATUS.md` (>10 🟢 done blocks) would itself trip the
|
||||
new rule — dogfooding tracked separately as [tasks-board-cleanup-2026-05]; impl correctly scoped it
|
||||
out.
|
||||
75
.wiki/concepts/web-search-skill-design.md
Normal file
75
.wiki/concepts/web-search-skill-design.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: web-search skill design
|
||||
type: concept
|
||||
status: draft
|
||||
created: 2026-08-22
|
||||
---
|
||||
|
||||
# web-search — скилл веб-поиска через субагента на search-комбо llm-web-proxy
|
||||
|
||||
## Проблема
|
||||
|
||||
Основная модель агента (deepseek-flash-web) не имеет веб-поиска. «Найди актуальное про X» сейчас решается костылями: curl на поисковик (блокируется 403/captcha), CDP-скрейпинг (тысячи токенов мусора в основном контексте), или отпиской «у меня нет веб-поиска».
|
||||
|
||||
При этом llm-web-proxy уже имеет search-комбо (`deepseek-flash-search-web` / `deepseek-pro-search-web`) — нативный веб-поиск DeepSeek с цитатами, работает из коробки, без новых аккаунтов.
|
||||
|
||||
## Решение
|
||||
|
||||
**Pi-расширение** с тулом `search_web` (паттерн vision-subagent) + **скилл** `web-search` с политикой «когда искать».
|
||||
|
||||
- Поиск **включён по умолчанию**: агент сам решает, когда нужны свежие данные, и вызывает тул.
|
||||
- Юзер может явно сказать «поищи X» — явный вызов.
|
||||
- Юзер может сказать **«без поиска»** — агент перестаёт вызывать тул **до конца сессии** (конверсационный механизм, как using-interns revoke; память в контексте сессии, следующая сессия — снова поиск включён).
|
||||
|
||||
## Тул search_web
|
||||
|
||||
Реализация в `~/projects/pi-extensions/extensions/search-web.ts` (репо `OpeItcLoc03/pi-extensions`), по образцу `vision-subagent.ts`:
|
||||
|
||||
```
|
||||
search_web(query: string)
|
||||
→ answer: "полный текст с [1][2]"
|
||||
sources: ["https://...", ...] # regex по URL из citation-блока; [] если пусто
|
||||
```
|
||||
|
||||
- **Модель**: `lwp/deepseek-pro-search-web` по умолчанию (pro-search). Переопределение: env `PI_SEARCH_MODEL` или `~/.pi/search-model.json` `{ "model": "..." }` (как PI_VISION_MODEL).
|
||||
- **Механика**: `modelRegistry.complete()` на чистом контексте с system-промптом «ищи в вебе, отвечай с цитатами [1][2]» + `search_web` инструкция. Таймаут ~120s (как vision).
|
||||
- **sources**: regex по `https?://\S+` в тексте ответа; пусто → `[]`, НЕ ошибка (поиск может не найти цитат).
|
||||
- **Ошибки**: честный текст «search failed: …», isError: true. `/search-status` command (как `/vision-model-status`).
|
||||
- Модели уже в `~/.pi/agent/models.json` (провайдер `llm-web`, префикс `lwp/`).
|
||||
|
||||
## Скилл web-search
|
||||
|
||||
Файл: `~/projects/skills/skills/web-search/SKILL.md` (sovereign каталог).
|
||||
|
||||
**When to use** (триггеры):
|
||||
- Вопрос требует свежих/внешних данных: новости, цены, версии, даты, «что сейчас актуально про X»
|
||||
- «Поищи X», «найди актуальное про Y», «проверь ссылку»
|
||||
- Подтверждение факта из недавнего времени (обучение модели могло устареть)
|
||||
|
||||
**Когда НЕ вызывать**:
|
||||
- Дизайн/рефакторинг/интроспекция проекта (код — в репо)
|
||||
- Вопросы по уже загруженному контексту (доки, файлы сессии)
|
||||
- «Без поиска» сказано юзером в этой сессии
|
||||
|
||||
**Правила**:
|
||||
1. Один запрос = один вызов тула (не спамить серией поисков без нужды).
|
||||
2. При `sources: []` — честно «без источников», не выдумывать URL.
|
||||
3. При ответе с [1][2] — оставлять нумерацию, ссылки из sources можно дать списком.
|
||||
4. Механизм «без поиска»: после команды юзера — не вызывать тул до конца сессии, при следующем «поищи» — вернуть (повторный грант).
|
||||
|
||||
## Тестирование (writing-skills TDD)
|
||||
|
||||
1. **RED**: базлайн-субагент без скила — «найди актуальное про X», зафиксировать поведение (костыли/отписка).
|
||||
2. **GREEN**: субагент со скилом — вызывает `search_web`, возвращает answer+sources.
|
||||
3. Микро-тест wording'а: триггеры срабатывают на формулировках юзера; no-guidance control.
|
||||
4. Live: реальный вызов тула в сессии pi, проверка answer+sources.
|
||||
|
||||
## Deploy
|
||||
|
||||
1. Правки pi-extensions (search-web.ts) → commit + push → `just install`.
|
||||
2. Скилл: `skills/web-search/SKILL.md` → lint → build → install → README provenance table → commit + push (semver bump).
|
||||
3. Обновить `~/.pi/agent/models.json` при необходимости (модель уже есть).
|
||||
|
||||
## Открытые вопросы
|
||||
|
||||
- Нет (дизайн одобрен юзером 2026-08-22: pro-search дефолт, answer+sources, конверсационный «без поиска»).
|
||||
@@ -1,42 +1,3 @@
|
||||
# Wiki Index
|
||||
# ⛔ Файловый канал закрыт
|
||||
|
||||
Catalog of all wiki pages. One line per page, organized by type. Updated on every ingest / new page.
|
||||
|
||||
## Overview
|
||||
|
||||
- [overview.md](overview.md) — what claude-skills is, layout, how to navigate
|
||||
|
||||
## Entities
|
||||
|
||||
<!-- (none yet) -->
|
||||
|
||||
## Concepts
|
||||
|
||||
|
||||
|
||||
- [active-platform-decision.md](concepts/active-platform-decision.md) — why `active-platform` is a skill (not a memory entry); why default = Windows; how it's wired into `project-bootstrap`
|
||||
- [bootstrap-claude-md-merge.md](concepts/bootstrap-claude-md-merge.md) — project-bootstrap@1.3.0 — Step 5 upgrade path becomes idempotent merge (read → diff vs template → confirm → append missing); fixes silent gap where pre-1.2.0 projects never picked up new canonical triggers (`check across all projects`, `we're on Windows`)
|
||||
- [bootstrap-skill-deps-check.md](concepts/bootstrap-skill-deps-check.md) — project-bootstrap@1.7.0 — Step 5.6 collapses the per-skill "detect-and-recommend" mirror shape into one generic `trigger → fulfiller` table walker (skill vs plugin kind, never auto-install); subsumes the deferred `[bootstrap-recommend-projects-meta]` and the existing `superpowers`-only detector
|
||||
- [bootstrap-manifest.md](concepts/bootstrap-manifest.md) — record of which `project-bootstrap` / `setup-wiki` / `setup-tasks` versions initialized this project's `.wiki/` and `.tasks/` layout (overwritten on re-bootstrap; history in git)
|
||||
- [build-notes.md](concepts/build-notes.md) — why `build.ps1` exists alongside `build.sh`; PS 5.1 backslash-in-zip gotcha; how to extract a `.skill`
|
||||
- [install-portability.md](concepts/install-portability.md) — `install.sh` / `build.sh` rewritten to drop `mapfile` (bash 4+) and `find -printf` (GNU only) so stock macOS (bash 3.2 + BSD find) works
|
||||
- [context7-setup.md](concepts/context7-setup.md) — switched context7 from manual MCP entries to the official plugin; API key in `.mcp.json` as `--api-key`; now also captured as `setup-context7` skill (one-time install/migrate flow with key discovery)
|
||||
- [projects-meta-skills.md](concepts/projects-meta-skills.md) — `setup-projects-meta` + `using-projects-meta` skill pair for the local `projects-meta-mcp` stdio server (cross-project tasks + shared Gitea wiki); local-first rule + two-step mutation pattern
|
||||
- [project-discipline-design.md](concepts/project-discipline-design.md) — design for project-discipline (four cross-project rules: conventions-over-defaults, master-only, semver-bumping, ask-before-push)
|
||||
- [pulling-before-work-design.md](concepts/pulling-before-work-design.md) — design for the pulling-before-work skill (mode-3 + skip-on-dirty)
|
||||
- [repo-layout.md](concepts/repo-layout.md) — flat `skills/`, committed `dist/`, bash + PowerShell scripts; install model
|
||||
- [skill-versioning.md](concepts/skill-versioning.md) — why infra skills carry `version: <semver>` in frontmatter and how `project-bootstrap` records them in a per-project manifest
|
||||
- [skill-vs-plugin.md](concepts/skill-vs-plugin.md) — when a bare SKILL.md is enough vs when you actually need a plugin (slash commands, hooks, sub-agents, MCP servers); concrete breakdown of `superpowers`
|
||||
- [wiki-realignment.md](concepts/wiki-realignment.md) — fixing `project-bootstrap` to create the Karpathy-canonical wiki layout
|
||||
- [interns-design](concepts/interns-design.md) — interns-design
|
||||
- [compress-dedup.md](concepts/compress-dedup.md) — `skills/compress/` deleted as a byte-identical dupe of `skills/caveman-compress/`; canonical kept for README + SECURITY + caveman-toolkit branding; better Process-step wording ported across; `version: 1.0.0` added to caveman-compress frontmatter
|
||||
- [active-platform-eval-design.md](concepts/active-platform-eval-design.md) — spec for eval-driven tuning of `active-platform`: combine the two ⚪ tasks into one workstream, 20-query cross-platform eval set (≥3 per OS + near-miss negatives), `run_loop.py` autoloop **in parallel** with manual body sweep (WSL / BSD / ambiguity), version 1.0.0 → 1.1.0 (MINOR). Status: paused after design + pre-flight check, before eval-set authorship
|
||||
- [interns-repo-read-design](concepts/interns-repo-read-design.md) — interns-repo-read-design
|
||||
|
||||
## Packages
|
||||
|
||||
<!-- (none yet) -->
|
||||
|
||||
## Sources
|
||||
|
||||
<!-- (none yet) -->
|
||||
**Не читать. Не править.** Канон — mappa (`mcp__mappa__*`): wiki-сущности проекта, конвенции — AGENTS-сущность. Скил: `mappa-knowledge`.
|
||||
|
||||
52
.wiki/log.md
52
.wiki/log.md
@@ -1,51 +1,3 @@
|
||||
# Wiki Log
|
||||
# ⛔ Файловый канал закрыт
|
||||
|
||||
Append-only operation log. One entry per operation. Format:
|
||||
|
||||
```
|
||||
## [YYYY-MM-DD] <op> | <one-line description>
|
||||
```
|
||||
|
||||
Operations: `init`, `ingest`, `query`, `lint`, `refactor`, `decision`.
|
||||
|
||||
Parseable: `grep "^## \[" .wiki/log.md | tail -20`.
|
||||
|
||||
---
|
||||
|
||||
## [2026-04-28] init | bootstrap empty wiki via project-bootstrap (old layout)
|
||||
## [2026-04-28] decision | repo-layout — flat `skills/`, committed `dist/`, bash + PS scripts
|
||||
## [2026-04-28] decision | build-notes — PS 5.1 Compress-Archive backslash bug; build.ps1 via .NET ZipArchive
|
||||
## [2026-04-28] decision | active-platform — skill chosen over global CLAUDE.md / project memory; default Windows; wired into project-bootstrap
|
||||
## [2026-04-28] refactor | wiki-realignment — fixed project-bootstrap Step 3 to create Karpathy-canonical layout
|
||||
## [2026-04-28] refactor | this repo's `.wiki/` migrated to canonical layout (SUMMARY.md→index.md, source/→concepts/, added log.md/overview.md/CLAUDE.md schema, raw/README.md)
|
||||
## [2026-04-28] decision | context7-setup — switched to official plugin; --api-key injected into plugin's .mcp.json; three manual MCP entries removed
|
||||
## [2026-04-28] decision | setup-context7 skill — formalized the install/migrate algorithm; using-context7 gets a Prerequisites pointer; build.sh PS multi-arg bug fixed (loop instead of comma-joined -Names)
|
||||
## [2026-04-28] verify | setup-context7 — Vitya ran using-context7 in a session that needed setup; Prerequisites pointer triggered setup-context7; full flow worked end-to-end. Pattern (policy + setup split) validated.
|
||||
## [2026-04-28] decision | skill-vs-plugin — documented when a bare skill suffices vs when a plugin is required (slash commands, hooks, sub-agents, MCP via marketplace)
|
||||
## [2026-04-28] decision | skill-versioning — added `version: 1.0.0` to 6 infra skills' frontmatter; project-bootstrap now writes .wiki/concepts/bootstrap-manifest.md per project
|
||||
## [2026-04-28] refactor | wiki split — `wiki-maintainer` renamed to `using-wiki` (policy); new `setup-wiki` skill owns greenfield creation and canon migration; `project-bootstrap` Step 3 delegates
|
||||
## [2026-04-28] refactor | tasks split — `task-status-wiki` renamed to `using-tasks` (policy); new `setup-tasks` skill owns greenfield + interactive migration (no auto-parsing of old flat STATUS.md); `project-bootstrap` Step 4 delegates
|
||||
## [2026-04-28] refactor | this repo's `.tasks/` migrated to canonical layout — flat `## Done`/`## Backlog` replaced by emoji-status board (7 ⚪ Ready blocks); historical Done entries dropped (preserved in git log); `.bak` ignored via .gitignore
|
||||
## [2026-04-28] cleanup | removed stale `~/.claude/skills/{wiki-maintainer,task-status-wiki}/` installs (replaced by `using-wiki`/`using-tasks`); 16 skills installed, no duplicates; context7 plugin (mcp__plugin_context7_context7__*) confirmed live after restart
|
||||
## [2026-04-28] decision | install-portability — `install.sh`/`build.sh` patched to drop `mapfile`+`find -printf`; stock macOS (bash 3.2 + BSD find) now works; verified on git-bash (16 skills discovered, sorted, installed; build.sh produces archive)
|
||||
## [2026-04-29] decision | projects-meta-skills — built `setup-projects-meta` (8-phase install of projects-meta-mcp + auth.toml + MCP registration) and `using-projects-meta` (runtime policy with local-first rule and two-step mutation); skill pair pattern applied for the 4th time (context7 / wiki / tasks / projects-meta); both built + installed; visible to the harness
|
||||
## [2026-04-30] refactor | projects-meta-skills — wiki path canon corrected: `~/projects/.wiki` → `~/projects/projects-wiki/` (clone root), content at `~/projects/projects-wiki/.wiki/`. Old path caused write/read mismatch bug (fixed upstream in commit `621a69f` of `projects-meta-mcp`). Setup-projects-meta Phase 1 now detects legacy clone, Phase 4 re-clones to canon. Lesson: pull shared resources before relying on cached anchors
|
||||
## [2026-04-30] decision | using-projects-meta v1.1.0 — added mandatory Step 0 freshness gate: probe `meta_status`; if cache_age > 10min or errors > 0, `node dist/sync.js`; for shared-wiki writes unconditional `git -C ~/projects/projects-wiki pull --ff-only`; 401/403 → loud failure to user. Codifies the same-session lesson — `projects-meta` is a multi-machine bus, stale cache breaks read accuracy and write atomicity
|
||||
## [2026-04-28] decision | project-bootstrap@1.1.0 — added Step 5.6: detects `superpowers@claude-plugins-official` via `~/.claude/plugins/installed_plugins.json` and prints install command + upstream link if missing; chat-only, never auto-installs (slash commands aren't callable from a skill, and silent plugin install is overreach)
|
||||
## [2026-04-28] doc | README.md + README.ru.md — new "Using skills in projects" / "Использование в проектах" section after install quick-start; describes project-bootstrap workflow (git, .gitignore, README, .wiki/, .tasks/, CLAUDE.md, manifest, superpowers-plugin check) and the init/upgrade modes
|
||||
## [2026-04-30] refactor | project-bootstrap re-run on this repo (upgrade mode) — setup-wiki noop, setup-tasks noop, CLAUDE.md unchanged (matches template), bootstrap-manifest.md written: project-bootstrap@1.1.0 / setup-wiki@1.0.0 / setup-tasks@1.0.0
|
||||
## [2026-04-30] decision | project-bootstrap@1.2.0 — CLAUDE.md template gains `check across all projects` (verbatim trigger from using-projects-meta description); installs auto-load cross-project tasks + shared-wiki access in every bootstrapped repo; no Step 5.7 dependency-check mirror — Prerequisites pointer in using-projects-meta is self-correcting; local CLAUDE.md, both READMEs, dist/.skill, projects-meta-skills concept page synced
|
||||
## [2026-04-30] decision | Step 5.7 mirror of Step 5.6 (projects-meta-mcp dependency detector / `setup-projects-meta` recommendation) accepted as future work; tracked as ⚪ Ready task `[bootstrap-recommend-projects-meta]`; deferred until first observed fresh-machine miss so detector signal is informed by real failure mode; concept page `projects-meta-skills.md` updated to reflect new stance
|
||||
## [2026-04-30] decision | project-bootstrap@1.3.0 — Step 5 upgrade path turned idempotent: read existing CLAUDE.md → substring-diff vs template → confirm → append-only-missing; closes silent gap where pre-1.2.0 projects never picked up new canonical triggers (`check across all projects`, `we're on Windows`); platform line preserved if user pinned a non-host one; concept page `bootstrap-claude-md-merge.md` written; README CLAUDE.md row updated to note idempotent merge
|
||||
## [2026-05-01] decision | pulling-before-work — new policy skill (v1.0.0): one `git pull --ff-only` at session start + on-demand re-sync; bootstrap template gains canonical trigger; project-bootstrap 1.3.0→1.4.0
|
||||
## [2026-05-01] decision | project-discipline — new policy skill (v0.1.0): four cross-project rules (conventions-over-defaults, master-only, semver-bumping, ask-before-push); bootstrap template gains canonical trigger; project-bootstrap 1.4.0→1.5.0; skill-versioning concept extended to all skills
|
||||
## [2026-05-01] ingest | shared-wiki packages/claude-skills — каталог всех 20 скиллов опубликован в projects-wiki (3 commits: page + index + log on Gitea, ae2cc9a..001cdd0); группировка bootstrap / wiki+tasks / MCP / caveman / discovery+platform; cross-link с concepts/setup-using-skill-pair и packages/projects-meta-mcp
|
||||
|
||||
## [2026-05-05] ingest | concepts/interns-design
|
||||
## [2026-05-05] decision | interns-skills-mvp — shipped `setup-interns` v0.1.0 (8-phase install: detect `.common/lib/interns-mcp/`, `pip install -e`, `.common/secrets/interns.env` write, `mcpServers.interns` registration with absolute Python interpreter + `cwd`) and `using-interns` v0.1.0 (runtime policy mirroring project-discipline Rule 4: ask-mode default, conversational grant/revoke, always-ask paths for `.env`/secrets/keys/SSH/credentials with transitive rule, cost-cap >$0.10, session-end reset; routing hints for `bulk_text_read` + `transcript_distill`); `project-bootstrap` 1.5.0→1.6.0 with canonical CLAUDE.md trigger `delegate to interns when allowed` between `follow project discipline` and `we're on Windows`, Step 5 commentary paragraph, manifest table extended with both new skills + `project-discipline` row; root `CLAUDE.md` dogfood updated; both READMEs written; descriptions verified (setup-interns 899 chars, using-interns 814 chars, both under 900 budget); all three rebuilt + installed + listed by harness with full descriptions (no H1 fallback)
|
||||
## [2026-05-05] ingest | concepts/bootstrap-skill-deps-check
|
||||
## [2026-05-05] decision | bootstrap-skill-deps-check — `project-bootstrap` 1.6.0→1.7.0 collapses Step 5.6 from a single-skill detector (only `superpowers` plugin) into a generic `trigger → fulfiller` table walker. Map embedded in SKILL.md (9 rows: caveman, superpowers plugin, using-wiki, using-tasks, using-projects-meta, pulling-before-work, project-discipline, using-interns, active-platform); `kind: skill` vs `kind: plugin` flag drives the install command emitted in the recommendation block. Algorithm: read project's CLAUDE.md → match each line vs map (substring + tolower, mirrors Step 5 idempotent merge) → for each canonical match check disk (`~/.claude/skills/<name>/SKILL.md` or `installed_plugins.json` key); print one chat-only block listing every missing fulfiller + install commands, or one ✅ line if all satisfied. User-custom lines silently skipped; removed canonical lines silently skipped (respects user opt-out). Hard rule "never auto-install" carries over verbatim. Subsumes the deferred `[bootstrap-recommend-projects-meta]` task (closed by absorption — generic step handles `using-projects-meta` along with everything else). MCP-server-backed skills only check the `using-X` policy skill; `setup-X` self-fires on first use via Prerequisites pointer, bootstrap doesn't duplicate.
|
||||
## [2026-05-05] decision | compress-dedup — `skills/compress/` was a stripped-down byte-for-byte dupe of `skills/caveman-compress/` (scripts/ identical SHA256 across all 7 files; SKILL.md diff = `name:` + Process step 2; descriptions textually identical = arbitrary harness tie-break + double-counted listing budget). Kept `caveman-compress` canonical: it carries README.md (benchmarks table + caveman-toolkit branding) and SECURITY.md (Snyk false-positive writeup), and matches the caveman-* prefix invariant. Ported the better Process-step wording from `compress` into `caveman-compress` (`cd <directory_containing_this_SKILL.md>` instead of brittle `cd caveman-compress` which assumes cwd). Added `version: 1.0.0` to caveman-compress frontmatter (first versioned release; aligns with skill-versioning concept). Deleted: `skills/compress/`, `dist/compress.skill`, `~/.claude/skills/compress/` (manual prune — install.sh has no prune step; future `[install-ps1]` task should add `--prune` flag). Rebuilt + reinstalled `caveman-compress`. Slash-command impact: `/compress` removed; `/caveman-compress` + `/caveman:compress` (toolkit-canonical) remain. Concept page `concepts/compress-dedup.md` written (rationale + rejected alternatives: alias-stub has no harness mechanism; "keep both" wastes listing budget; "delete caveman-compress" loses README + SECURITY).
|
||||
## [2026-05-05] design | active-platform-eval (paused) — combined `[active-platform-tuning]` + `[active-platform-eval]` into one workstream (eval *is* the tuning mechanism; "wait for 5 real signals" was a placeholder). Spec written at `.wiki/concepts/active-platform-eval-design.md`: 20-query trigger eval set balanced ≥3 should-trigger per OS (Win/Lin/Mac) + near-miss negatives, run in `skill-creator/scripts/run_loop.py` (5 iter, train/test split, model `claude-opus-4-7`) **in parallel** with manual body sweep (WSL clarity, BSD/macOS expansion, ambiguity policy). Workspace at `.tasks/active-platform-eval/` (eval-set.json committed, iterations gitignored). Version bump 1.0.0 → 1.1.0 planned (MINOR). Pre-flight verified: `claude` CLI at `C:\nvm4w\nodejs\claude.ps1` (Claude Code 2.1.128) + `run_loop.py` present in skill-creator install — both autoloop deps satisfied, no fallback needed. Per-task file at `.tasks/active-platform-eval.md`. Paused at user request before eval-set authorship; resume point is Q2 (write 20 queries solo vs run skill-creator HTML-review template for user edits first). Also fixed in same pause: `[install-ps1]` STATUS scope expanded to "paired install.sh + install.ps1, cross-platform parity, --prune flag" (lesson from `[compress-dedup]`).
|
||||
|
||||
## [2026-05-05] ingest | concepts/interns-repo-read-design
|
||||
**Не читать. Не править.** Канон — mappa (`mcp__mappa__*`): wiki-сущности проекта, конвенции — AGENTS-сущность. Скил: `mappa-knowledge`.
|
||||
|
||||
@@ -1,29 +1,3 @@
|
||||
---
|
||||
title: claude-skills overview
|
||||
type: overview
|
||||
updated: 2026-04-28
|
||||
---
|
||||
# ⛔ Файловый канал закрыт
|
||||
|
||||
# claude-skills — overview
|
||||
|
||||
Joint workshop where Vitya and Claude develop, test, and store Claude skills. Both editable sources (`skills/<name>/`) and built archives (`dist/<name>.skill`) live here, so a fresh machine can clone the repo and install every personal skill in one command.
|
||||
|
||||
## Components
|
||||
|
||||
- **`skills/`** — editable skill sources, one folder per skill (each with `SKILL.md` + optional `assets/`).
|
||||
- **`dist/`** — built `.skill` archives, committed so installs don't need a build toolchain on the target.
|
||||
- **`scripts/`** — `build.sh` / `build.ps1` (zip sources → archive), `install.sh` (copy sources → `~/.claude/skills/`).
|
||||
- **`.wiki/`** — Karpathy LLM Wiki for design decisions and gotchas. See [CLAUDE.md](CLAUDE.md) for schema.
|
||||
- **`.tasks/`** — task board (`STATUS.md`).
|
||||
- **`CLAUDE.md`** — repo-level agent instructions (skill triggers).
|
||||
|
||||
## Where to look
|
||||
|
||||
- New here? → [concepts/repo-layout.md](concepts/repo-layout.md), then `README.md`.
|
||||
- Working on a skill? → edit `skills/<name>/`, then `bash scripts/install.sh <name>` (or `pwsh scripts/build.ps1 <name>` to refresh the archive).
|
||||
- Tracking work? → [.tasks/STATUS.md](../.tasks/STATUS.md).
|
||||
- Made a non-trivial decision? → add a `concepts/<topic>.md` page, link from [index.md](index.md), append a line to [log.md](log.md).
|
||||
|
||||
## Cross-references
|
||||
|
||||
This page intentionally stays short. The substantive material lives in `concepts/` (decisions, gotchas) and the [index](index.md) catalog.
|
||||
**Не читать. Не править.** Канон — mappa (`mcp__mappa__*`): wiki-сущности проекта, конвенции — AGENTS-сущность. Скил: `mappa-knowledge`.
|
||||
|
||||
34
AGENTS.md
Normal file
34
AGENTS.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# AGENTS.md (canon)
|
||||
# Agent instructions. Each line is a trigger for an installed skill.
|
||||
|
||||
talk like a caveman
|
||||
use project wiki
|
||||
use task management system
|
||||
check across all projects
|
||||
pull remote before work
|
||||
session handoff: read on start, write on end
|
||||
inbox monitor: raise on start
|
||||
follow project discipline
|
||||
follow tdd-criteria
|
||||
delegate to interns when allowed
|
||||
recommend, don't menu
|
||||
we're on Windows
|
||||
mappa sync: run on start
|
||||
|
||||
<!-- mappa:canon-block (auto; do not edit) -->
|
||||
## Mappa canon
|
||||
**Gates (canon/gates — shared):** краткая суть; полный текст — `wiki_get(slug='canon/gates', full=true)`
|
||||
- Г1. Знание и артефакты → mappa, не файлы — durable-знание и артефакты проекта живут в mappa; файловые каналы (`.brainstorm/`, `.tasks/`, `.wiki/`) и «сохранить рядом с проектом» закрыты.
|
||||
- Г2. Контракт каналов — письмо (inbox) — носитель вердиктов/указаний/находок, полным телом; комментарии на тасках — короткий след. Адресация `about`/`to`/`thread` (XOR); lifecycle `ack`/`resolve`/`cancel`.
|
||||
- Г3. Поиск до угадывания — не угадывать slug/роут: сначала `search`/`wiki_search`; `wiki_get` без project = shared; общая память — `search(mode='recall')`.
|
||||
- Г4. Адресация и слаги — рефы полными именами (`[[task:N]]`/`[[wiki:slug]]`); слаги kebab-case, латиница; номера `task:N` выдаёт сервер.
|
||||
- Г5. .mappa-гейт — папка участвует в mappa-операциях только с маркером `.mappa`; нет маркера → сказать человеку, мутации — отказ.
|
||||
- Г6. Секреты — в mappa не пишутся (422); только `secret:<path>`-рефы, значения мимо.
|
||||
- Г7. Degraded-режим — mappa недоступна: читать кэш `.mappa/` (canon/methodology/runbooks), мутации → `.mappa/pending/`; нет кэша → стоп, не импровизировать.
|
||||
- Г8. Перед работой с вики/каноном — первым действием прочитать канон-блок AGENTS.md проекта.
|
||||
- Г9. Живое состояние до заявления — статус заявлять только по свежему чтению mappa, не по памяти/кэшу/ответу create.
|
||||
**Entity → runbook (runbooks/index — shared):** task → [[runbooks/tasks]] · wiki → [[runbooks/wiki]] · inbox → [[runbooks/inbox]] · **thread** → [[runbooks/threads]] · session → [[runbooks/session]] · search → [[runbooks/search]] · issue → [[runbooks/issue]] · **intent** → [[runbooks/intent]] · requirements → [[runbooks/requirements]] · plan → [[runbooks/plan]] · comment → [[runbooks/comment]] · tag → [[runbooks/tag]] · attachment → [[runbooks/attachment]] · release → [[runbooks/release]] · brainstorm → [[runbooks/brainstorm]] · agent → [[runbooks/agent-operator]] · repo → [[runbooks/repo-commit]] · project → [[runbooks/project]] · skill → [[runbooks/skill]] · entity-слой → [[runbooks/entity]] · sched → [[runbooks/sched-telemetry]]
|
||||
**Methodology:** `methodology/kzntsv`
|
||||
**Canon version:** 4
|
||||
<!-- /mappa:canon-block -->
|
||||
|
||||
13
CLAUDE.md
13
CLAUDE.md
@@ -1,12 +1,3 @@
|
||||
# CLAUDE.md
|
||||
# Agent instructions. Each line is a trigger for an installed skill.
|
||||
# CLAUDE.md — legacy pointer
|
||||
|
||||
talk like a caveman
|
||||
use superpowers
|
||||
use project wiki
|
||||
use task management system
|
||||
check across all projects
|
||||
pull remote before work
|
||||
follow project discipline
|
||||
delegate to interns when allowed
|
||||
we're on Windows
|
||||
Canon is `AGENTS.md`. Read `AGENTS.md` — it contains all project instructions.
|
||||
|
||||
100
README.md
100
README.md
@@ -1,4 +1,4 @@
|
||||
# claude-skills
|
||||
# skills
|
||||
|
||||
> Russian version: [README.ru.md](README.ru.md).
|
||||
|
||||
@@ -9,8 +9,10 @@ Joint workshop and storage for Claude skills.
|
||||
A shared workspace where Claude and I author, debug, and ship skills together:
|
||||
|
||||
- **`skills/`** — editable sources (markdown + assets), the source of truth
|
||||
- **`dist/`** — built `.skill` archives, committed to the repo
|
||||
- **`scripts/`** — utilities: `build.sh` (source → `.skill`), `install.sh` (source → `~/.claude/skills/`)
|
||||
- **`dist/`** — built `.skill` archives for Claude, committed to the repo
|
||||
- **`hermes/`** — Hermes-rollout config: `mapping.yaml` and any `mode: manual` overrides under `hermes/skills/`
|
||||
- **`dist-hermes/`** — pre-converted Hermes-flavour skill tree, committed (regenerated by `scripts/build-hermes.py`)
|
||||
- **`scripts/`** — utilities: `build.sh` (source → `.skill`), `install.sh` (source → `~/.claude/skills/`), `build-hermes.py` (source → `dist-hermes/`)
|
||||
- **`.wiki/`**, **`.tasks/`** — working notes and the task board
|
||||
|
||||
## Quick start
|
||||
@@ -20,26 +22,26 @@ A shared workspace where Claude and I author, debug, and ship skills together:
|
||||
**Windows (PowerShell):**
|
||||
|
||||
```powershell
|
||||
git clone <repo> claude-skills
|
||||
cd claude-skills
|
||||
git clone <repo> skills
|
||||
cd skills
|
||||
bash scripts/install.sh # copies every skills/* into ~/.claude/skills/
|
||||
# or only specific ones:
|
||||
bash scripts/install.sh caveman wiki-maintainer
|
||||
# or only specific ones (mappa-* skills install from the `mappa` repo — see mappa-bootstrap):
|
||||
bash scripts/install.sh caveman tdd-criteria
|
||||
```
|
||||
|
||||
**Linux / macOS (bash):**
|
||||
|
||||
```bash
|
||||
git clone <repo> claude-skills
|
||||
cd claude-skills
|
||||
git clone <repo> skills
|
||||
cd skills
|
||||
bash scripts/install.sh # copies every skills/* into ~/.claude/skills/
|
||||
# or only specific ones:
|
||||
bash scripts/install.sh caveman wiki-maintainer
|
||||
# or only specific ones (mappa-* skills install from the `mappa` repo — see mappa-bootstrap):
|
||||
bash scripts/install.sh caveman tdd-criteria
|
||||
```
|
||||
|
||||
The install target can be overridden with `CLAUDE_SKILLS_DIR=/path bash scripts/install.sh`.
|
||||
|
||||
> `install.sh` works on Windows under git-bash. A native `install.ps1` is on the task board but not yet implemented.
|
||||
> `install.sh` works on Windows under git-bash; `install.ps1` provides a native PowerShell path.
|
||||
|
||||
### Using skills in projects
|
||||
|
||||
@@ -50,15 +52,13 @@ project's folder and it will, in one pass:
|
||||
|
||||
- initialize `git` (if missing) and write a sane `.gitignore`
|
||||
- create a starter `README.md`
|
||||
- lay out `.wiki/` per the [Karpathy LLM Wiki pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) (delegated to [`setup-wiki`](skills/setup-wiki/))
|
||||
- lay out `.tasks/` with the canonical task board (delegated to [`setup-tasks`](skills/setup-tasks/))
|
||||
- write `CLAUDE.md` with skill triggers (`use superpowers`, `use project wiki`, `use task management system`, `check across all projects`, `we're on Windows`)
|
||||
- record the skill versions used in `.wiki/concepts/bootstrap-manifest.md` so cross-project layout drift stays debuggable
|
||||
- check whether the official `superpowers@claude-plugins-official` plugin is installed and, if not, print the install command — the `use superpowers` trigger is a no-op without it
|
||||
- register the project meta in **mappa** (wiki/task-сущности проекта; file-based `.wiki/`/`.tasks/` closed 2026-08-25)
|
||||
- write `AGENTS.md` (canon) with skill triggers (`use project wiki`, `use task management system`, `check across all projects`, `we're on Windows`) plus a `CLAUDE.md` legacy pointer
|
||||
- record the skill versions used in a mappa wiki entity (`concepts/bootstrap-manifest`) so cross-project layout drift stays debuggable
|
||||
|
||||
Two modes, picked automatically: **init** for an empty folder, **upgrade**
|
||||
for an existing project (the skill only fills the gaps and never overwrites
|
||||
without explicit confirmation). On upgrade, `CLAUDE.md` is merged
|
||||
without explicit confirmation). On upgrade, `AGENTS.md` is merged
|
||||
idempotently — only canonical trigger lines that aren't already present are
|
||||
appended after explicit confirm, so re-running `project-bootstrap` after a
|
||||
template change picks up the new triggers without duplicating the old ones.
|
||||
@@ -84,18 +84,74 @@ bash scripts/build.sh caveman # one skill
|
||||
`scripts/build.ps1` via PowerShell (Windows without `zip`). On Windows you
|
||||
can also run `powershell scripts/build.ps1` directly.
|
||||
|
||||
### Build for Hermes
|
||||
|
||||
The same `skills/` are rolled out to Hermes Agent (Nous Research) on factory
|
||||
Linux machines. The converter reads `hermes/mapping.yaml` (per-skill
|
||||
mode / category / replace-rules / skip-list) and writes a Hermes-formatted
|
||||
skill tree to `dist-hermes/`, which is committed to the repo.
|
||||
|
||||
```bash
|
||||
python scripts/build-hermes.py # regenerate dist-hermes/ from mapping
|
||||
```
|
||||
|
||||
Every skill in `skills/` must have an explicit entry in `mapping.yaml`
|
||||
(`auto` / `manual` / `skip` / `pending`); the build fails on unmapped skills.
|
||||
Skip and pending entries land in `dist-hermes/SKIPPED.md` with reasons. Full
|
||||
design rationale lives in
|
||||
[`.wiki/concepts/hermes-skills-rollout-design.md`](.wiki/concepts/hermes-skills-rollout-design.md).
|
||||
|
||||
## Sovereignty / provenance
|
||||
|
||||
This catalog is sovereign: every skill is either **authored by us** or an
|
||||
**adapted vendored copy** we maintain ourselves. No raw vendor plugins are
|
||||
installed as dependencies — anything borrowed is vendored into this repo with
|
||||
an explicit `adapted-from` marker in its frontmatter.
|
||||
|
||||
| skill | provenance |
|
||||
|---|---|
|
||||
| `caveman`, `caveman-commit`, `caveman-compress`, `caveman-help`, `caveman-review` | `adapted-from: JuliusBrussee/caveman @ 0993277` (MIT) — vendored copy |
|
||||
| `find-skills` | `adapted-from: vercel-labs/skills @ c6f69c6` (MIT) — vendored copy |
|
||||
| `grilling` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — family collapsed to one skill (pi hides `disable-model-invocation` wrappers) |
|
||||
| `brainstorming` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — divergent phase, visual-companion dropped |
|
||||
| `diagnosing-bugs` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) + superpowers 6.2.0 concepts (Iron Law, red flags) |
|
||||
| `loop-me` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — workflow-spec design gate |
|
||||
| `review-kit-pi-method` | `author: ours` — pi-native spawn for clean-context review subagents |
|
||||
| `command-index` | `author: ours` — just/Makefile command-index convention (standard targets, auto-doc; idea 3/18) |
|
||||
| `code-search` | `author: ours` — rg-first code search (measured 15 min → 0s; routing: rg / git grep / interns repo_read / grep_audit) |
|
||||
| `code-review` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — two-axis + Fowler baseline; output: caveman-review format |
|
||||
| `writing-skills` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — TDD-for-skills core + ideya 8 self-skill-authoring |
|
||||
| `web-search` | `author: ours` — search_web tool (pi-extension) + policy: when to search, «без поиска» session-off |
|
||||
| `ops-browser` | `author: ours` — свой **скрытый** браузер агента: отдельный профиль + CDP (`eval`/`fetch` из страницы/скриншоты), `handoff` человеку для пароля/капчи; свой замок `ops.lock` |
|
||||
| `browser-operator` | `author: ours` — браузер ОПЕРАТОРА (его Chrome/логины): канал по харнессу (Hermes `browser_exec` / pi тул `browser` / CC `chrome-devtools`), аренда «один водитель за раз», границы «человек vs агент», рецепты тяжёлых страниц. Закрывает провал базового прогона 2026-09-11 («куки из Chrome + curl + ввод пароля» мимо канала); анонимные прогоны — `browser-cdp` |
|
||||
| `review-subagent` | `author: ours` — review_subagent tool (pi-extension): clean-context review by your own model, optional `model` override |
|
||||
| `report-mappa-issue` | `author: ours` — TEMPORARY stopgap: mappa deviation reporting (mail to `mappa` + `.workshop`) while the service is unstable; retire when stabilized |
|
||||
| all other `skills/*` | `author: ours` |
|
||||
|
||||
Adaptation policy: a clone is rewritten to our conventions (`.tasks/` boards,
|
||||
`.wiki/concepts/` specs, `using-*` skill names), never shipped with vendor junk,
|
||||
and versioned under our own semver. Upstream pins are reviewed by the catalog
|
||||
owner on update; no automatic upstream sync.
|
||||
|
||||
## Layout
|
||||
|
||||
```
|
||||
claude-skills/
|
||||
skills/
|
||||
├── skills/ ← sources (one folder per skill)
|
||||
├── dist/ ← .skill archives (committed)
|
||||
├── dist/ ← .skill archives for Claude (committed)
|
||||
├── hermes/
|
||||
│ ├── mapping.yaml ← per-skill Hermes-rollout config
|
||||
│ └── skills/ ← `mode: manual` overrides (Hermes-flavour rewrites)
|
||||
├── dist-hermes/ ← pre-converted Hermes-flavour tree (committed)
|
||||
│ ├── <category>/<name>/ ← e.g. software-development/diagnosing-bugs/
|
||||
│ └── SKIPPED.md ← skip + pending log (auto-generated)
|
||||
├── scripts/
|
||||
│ ├── build.sh / build.ps1
|
||||
│ └── install.sh
|
||||
│ ├── install.sh / install.ps1
|
||||
│ └── build-hermes.py
|
||||
├── .wiki/ ← design docs, notes
|
||||
├── .tasks/ ← STATUS.md
|
||||
├── CLAUDE.md
|
||||
├── AGENTS.md ← canon (CLAUDE.md is a legacy pointer)
|
||||
└── README.md (this file — see README.ru.md for Russian)
|
||||
```
|
||||
|
||||
|
||||
47
README.ru.md
47
README.ru.md
@@ -21,8 +21,8 @@
|
||||
git clone <repo> claude-skills
|
||||
cd claude-skills
|
||||
bash scripts/install.sh # копирует все skills/* в ~/.claude/skills/
|
||||
# или конкретные:
|
||||
bash scripts/install.sh caveman wiki-maintainer
|
||||
# или конкретные (mappa-* скилы ставятся из репо `mappa` — см. mappa-bootstrap):
|
||||
bash scripts/install.sh caveman tdd-criteria
|
||||
```
|
||||
|
||||
Цель установки можно переопределить переменной `CLAUDE_SKILLS_DIR=/path bash scripts/install.sh`.
|
||||
@@ -36,15 +36,13 @@ bash scripts/install.sh caveman wiki-maintainer
|
||||
|
||||
- инициализирует `git` (если ещё нет) и положит вменяемый `.gitignore`
|
||||
- создаст стартовый `README.md`
|
||||
- развернёт `.wiki/` по [паттерну Karpathy LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) (делегируется в [`setup-wiki`](skills/setup-wiki/))
|
||||
- развернёт `.tasks/` с канонической доской задач (делегируется в [`setup-tasks`](skills/setup-tasks/))
|
||||
- запишет `CLAUDE.md` со скилл-триггерами (`use superpowers`, `use project wiki`, `use task management system`, `check across all projects`, `we're on Windows`)
|
||||
- зафиксирует версии использованных скиллов в `.wiki/concepts/bootstrap-manifest.md`, чтобы дрифт раскладки между проектами оставался отлаживаемым
|
||||
- проверит, установлен ли официальный плагин `superpowers@claude-plugins-official`, и если нет — выведет команду установки (без плагина триггер `use superpowers` мёртвый)
|
||||
- зарегистрирует мету проекта в **mappa** (wiki/task-сущности; файловые `.wiki/`/`.tasks/` закрыты 2026-08-25)
|
||||
- запишет `AGENTS.md` (канон) со скилл-триггерами + `CLAUDE.md`-указатель (`use project wiki`, `use task management system`, `check across all projects`, `we're on Windows`)
|
||||
- зафиксирует версии использованных скиллов в mappa wiki-сущности `concepts/bootstrap-manifest`, чтобы дрифт раскладки оставался отлаживаемым
|
||||
|
||||
Два режима, выбирается автоматически: **init** для пустой папки и **upgrade**
|
||||
для существующего проекта (скилл только дозаполняет пробелы и ничего не
|
||||
перезаписывает без явного подтверждения). В режиме upgrade `CLAUDE.md`
|
||||
перезаписывает без явного подтверждения). В режиме upgrade `AGENTS.md`
|
||||
сливается идемпотентно — только канонические триггер-строки, которых ещё
|
||||
нет в файле, дописываются после явного подтверждения, поэтому повторный
|
||||
запуск `project-bootstrap` после обновления шаблона подтягивает новые
|
||||
@@ -73,8 +71,37 @@ bash scripts/build.sh caveman # один
|
||||
|
||||
## Layout
|
||||
|
||||
## Суверенитет / провенанс
|
||||
|
||||
Каталог суверенный: каждый скилл либо **нашего авторства**, либо
|
||||
**адаптированная вендорская копия**, которую поддерживаем сами. Никаких
|
||||
сырых вендорских плагинов как зависимостей — всё заимствованное вендорится
|
||||
в этот репо с явным маркером `adapted-from` во frontmatter.
|
||||
|
||||
| скилл | провенанс |
|
||||
|---|---|
|
||||
| `caveman`, `caveman-commit`, `caveman-compress`, `caveman-help`, `caveman-review` | `adapted-from: JuliusBrussee/caveman @ 0993277` (MIT) — вендорная копия |
|
||||
| `find-skills` | `adapted-from: vercel-labs/skills @ c6f69c6` (MIT) — вендорная копия |
|
||||
| `grilling` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — семейство схлопнуто в один скил (pi прячет `disable-model-invocation` обёртки) |
|
||||
| `brainstorming` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — расходящаяся фаза, visual-companion выброшен |
|
||||
| `diagnosing-bugs` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) + superpowers 6.2.0 (Iron Law, red flags) |
|
||||
| `loop-me` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — дизайн-гейт workflow-спец |
|
||||
| `review-kit-pi-method` | `author: ours` — pi-спавн чистых review-субагентов |
|
||||
| `command-index` | `author: ours` — конвенция just/Makefile command-index (стандартные таргеты, авто-док; идея 3/18) |
|
||||
| `code-search` | `author: ours` — rg-first код-поиск (замер: 15 мин → 0 сек; роутинг: rg / git grep / interns repo_read / grep_audit) |
|
||||
| `code-review` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — двухосевость + Fowler-база; формат вывода: caveman-review |
|
||||
| `writing-skills` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — TDD-for-skills ядро + идея 8 self-skill-authoring |
|
||||
| `ops-browser` | `author: ours` — свой скрытый браузер агента (профиль + CDP + `handoff` человеку, замок `ops.lock`) |
|
||||
| `browser-operator` | `author: ours` — браузер ОПЕРАТОРА (его Chrome/логины): канал по харнессу (Hermes `browser_exec` / pi тул `browser` / CC `chrome-devtools`), аренда «один водитель за раз», границы «человек vs агент»; анонимные прогоны — `browser-cdp` |
|
||||
| остальные `skills/*` | `author: ours` |
|
||||
|
||||
Политика адаптации: клон переписывается под наши конвенции (доски `.tasks/`,
|
||||
спеки `.wiki/concepts/`, имена скиллов `using-*`), вендорский мусор не
|
||||
перетягивается, версионируется под нашим semver. Пины апстрима
|
||||
пересматривает владелец каталога при обновлении; автосинка нет.
|
||||
|
||||
```
|
||||
claude-skills/
|
||||
skills/
|
||||
├── skills/ ← исходники (по папке на скилл)
|
||||
├── dist/ ← .skill архивы (коммитятся)
|
||||
├── scripts/
|
||||
@@ -82,7 +109,7 @@ claude-skills/
|
||||
│ └── install.sh
|
||||
├── .wiki/ ← дизайн-доки, заметки
|
||||
├── .tasks/ ← STATUS.md
|
||||
├── CLAUDE.md
|
||||
├── AGENTS.md ← канон (CLAUDE.md — legacy-указатель)
|
||||
└── README.md
|
||||
```
|
||||
|
||||
|
||||
27
dist-hermes/SKIPPED.md
Normal file
27
dist-hermes/SKIPPED.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Skipped Skills
|
||||
|
||||
Auto-generated by `scripts/build-hermes.py` from `hermes/mapping.yaml`.
|
||||
Do not edit by hand — edit the mapping and re-run the build.
|
||||
|
||||
## Skipped (not applicable to Hermes)
|
||||
|
||||
- **caveman** — Hermes runs on glm-5.1 (cheap local model); token-compression motive disappears.
|
||||
- **caveman-commit** — Caveman family — cheap-model context, no compression motive.
|
||||
- **caveman-compress** — Caveman family — cheap-model context, no compression motive.
|
||||
- **caveman-help** — Help-card for the caveman family which itself is skipped.
|
||||
- **caveman-review** — Caveman family — cheap-model context, no compression motive.
|
||||
- **find-skills** — Hermes has built-in skills_list() / progressive disclosure.
|
||||
- **setup-interns** — Hermes itself is a cheap-intern model — the delegation tier collapses.
|
||||
- **update-claude-skills** — Claude-Code-only orchestrator — Hermes uses hermes-installer-skill instead.
|
||||
- **using-interns** — Hermes itself is a cheap-intern model — the delegation tier collapses.
|
||||
|
||||
## Pending (deferred to follow-up tasks)
|
||||
|
||||
- **meta-host-routing** — Resolves WHERE a project's meta lives before tasks_create / knowledge_ingest / brainstorm-promotion (meta-out-of-repo). Touches projects-meta MCP (tasks_create / knowledge_ingest / meta_status) and routes writes across repos. Review PASS (meta-host-routing-review) but the -install baseline is still open and a tool-side audit (cross-repo MCP writes) is required before auto. Mapping executes task meta-host-routing-hermes-mapping. → intended: `mode: auto, category: meta`
|
||||
- **private-dev-public-publish** — Steps shell out to git / gh / Gitea-API, handle tokens, force-push, and repo deletion/privacy toggles — not a purely stylistic skill. Behavioral audit via private-dev-public-publish-test-trigger required before promotion to auto. → intended: `mode: auto, category: software-development`
|
||||
- **ralph-loop-execution** — Behavioral oracle-loop skill (Verifier / Attempts / Max-Attempts retry loop). NB: source SKILL.md currently lacks YAML frontmatter (no name/description) — cannot auto-convert cleanly until that is fixed. Mapped pending as a placeholder; needs frontmatter + a behavioral audit before any mode decision.
|
||||
- **session-inbox-monitor** — Paired SessionStart hook registers itself in ~/.claude/settings.json and sweeps orphaned monitor OS processes (Get-CimInstance | Stop-Process by sentinel+inbox-path); the skill then raises an in-session Monitor on .claude-inbox/. Primary activation is the CLAUDE.md trigger-line `inbox monitor: raise on start` + the injector, not a hermes-trigger. Behavioral gate CLEARED 2026-06-17 — test-trigger + review BOTH VERDICT PASS (activation 3/3 monitor + neg clean; structural hook audit 5 PASS/1 CONCERN, the CONCERN fixed in v0.2.2). STAYS pending on two independent tool-side blockers, NOT on behavioral verification: (1) the SessionStart hook is Windows-PowerShell and needs a Linux port for Hermes factory machines; (2) machine-level side-effects (user-config mutation of ~/.claude/settings.json + Get-CimInstance|Stop-Process kills) need a tool-side audit before auto. Promotion blocked on those two, not on test-trigger/review. → intended: `mode: auto, category: productivity`
|
||||
- **setup-agents-task-runner** — L2 installer — installs the standing-duty stack (agents-task-runner + watchdog + appeals-inbox) as platform-native OS services (systemd/launchd/winsw), fetches a pinned binary, writes poller-scope.json. Heavy infra side-effects (OS services + binary fetch); mode decision (skip vs manual vs auto) deferred — needs an explicit Hermes-factory applicability audit. Placeholder pending to keep the build green.
|
||||
- **task-format** — Documentational skill — how to write a .tasks/STATUS.md task block the autonomous poller will claim/route/report (block header, status emoji, Weight/Notify/Requirements fields). No tool-side effects; pending a behavioral test-trigger before auto. → intended: `mode: auto, category: productivity`
|
||||
- **using-vds-ops** — Calls mcp__vds-ops__* tools (read-only, but touches infrastructure). Behavioral audit via using-vds-ops-test-trigger required before promotion to auto. → intended: `mode: auto, category: mcp`
|
||||
- **using-yt-tools** — Shells out to yt-dlp + ffmpeg and writes ./yt-cache/ in cwd. Behavioral audit via using-yt-tools-test-trigger required before promotion to auto. → intended: `mode: auto, category: research`
|
||||
140
dist-hermes/mcp/setup-context7/SKILL.md
Normal file
140
dist-hermes/mcp/setup-context7/SKILL.md
Normal file
@@ -0,0 +1,140 @@
|
||||
---
|
||||
name: setup-context7
|
||||
version: 1.0.0-hermes
|
||||
description: Hermes-flavour context7 setup. Edits `~/.hermes/config.yaml` to register the official context7 MCP server via stdio (`npx @upstash/context7-mcp`). Requires `CONTEXT7_API_KEY` env var (user sets it manually or you prompt for it). Use when user says "install context7", "setup context7", or whenever `mcp__context7__*` tools are missing. Mutates Hermes config; pauses for confirmation before writing.
|
||||
---
|
||||
|
||||
# setup-context7 (Hermes)
|
||||
|
||||
> One-time Hermes skill that registers context7 in `~/.hermes/config.yaml`. Context7 is a third-party MCP server (Upstash); this skill only adds the stdio command entry.
|
||||
|
||||
## When to use
|
||||
|
||||
- User explicitly asks: install / set up / configure context7 on Hermes.
|
||||
- A `using-context7`-driven task fails because `mcp__context7__*` tools aren't available.
|
||||
|
||||
## Out of scope
|
||||
|
||||
- Creating API keys — user must have a Context7 API key (get it from https://context7.com or via `npx ctx7 setup`).
|
||||
- Rolling back to manual config.
|
||||
- Any non-context7 MCP server.
|
||||
|
||||
## Hard rule: don't auto-mutate config
|
||||
|
||||
Edits `~/.hermes/config.yaml`. **Always pause for explicit confirmation between Phase 1 (discovery) and Phase 2 (plan), and again before Phase 3 (writes).**
|
||||
|
||||
## Procedure
|
||||
|
||||
### Phase 0 — Environment sanity
|
||||
|
||||
- Confirm Hermes is the current agent.
|
||||
- Confirm `npx` is on `PATH` (stdio command uses it).
|
||||
|
||||
### Phase 1 — Discovery (read-only)
|
||||
|
||||
**API key.** Check env var `CONTEXT7_API_KEY`. If missing → report MISSING, will ask user.
|
||||
|
||||
**Existing MCP entry.** Read `~/.hermes/config.yaml` and check `mcp_servers.context7`. Note if present.
|
||||
|
||||
Report:
|
||||
```
|
||||
API key: <set in CONTEXT7_API_KEY | MISSING → will ask>
|
||||
MCP entry: <present | will add>
|
||||
```
|
||||
|
||||
### Phase 2 — Plan + confirm
|
||||
|
||||
Present the plan:
|
||||
```
|
||||
API key: <user will set CONTEXT7_API_KEY | already set>
|
||||
MCP entry: <will add | will update>
|
||||
Config: ~/.hermes/config.yaml
|
||||
Backup: ~/.hermes/config.yaml.bak-<ts>
|
||||
```
|
||||
|
||||
If API key is missing → ask: "Set CONTEXT7_API_KEY env var, or paste your key and I'll add it to config.yaml via env." Wait for confirmation before proceeding.
|
||||
|
||||
### Phase 3 — Backup
|
||||
|
||||
```bash
|
||||
TS=$(date +%Y%m%d-%H%M%S)
|
||||
cp ~/.hermes/config.yaml ~/.hermes/config.yaml.bak-$TS
|
||||
```
|
||||
|
||||
### Phase 4 — Edit `~/.hermes/config.yaml`
|
||||
|
||||
Add or update the `mcp_servers` section:
|
||||
|
||||
**Option A — user has CONTEXT7_API_KEY env var (recommended):**
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
context7:
|
||||
command: npx
|
||||
args:
|
||||
- -y
|
||||
- @upstash/context7-mcp
|
||||
- --api-key
|
||||
- $CONTEXT7_API_KEY
|
||||
env:
|
||||
CONTEXT7_API_KEY: $CONTEXT7_API_KEY
|
||||
```
|
||||
|
||||
**Option B — user wants key embedded (not recommended, but acceptable if env var is hard):**
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
context7:
|
||||
command: npx
|
||||
args:
|
||||
- -y
|
||||
- @upstash/context7-mcp
|
||||
- --api-key
|
||||
- <PASTE_KEY_HERE>
|
||||
```
|
||||
|
||||
Use Option A by default. Only Option B if user explicitly says "embed the key" or env vars don't work on their setup.
|
||||
|
||||
Validate YAML:
|
||||
```bash
|
||||
python -c "import yaml; yaml.safe_load(open('~/.hermes/config.yaml'))"
|
||||
```
|
||||
|
||||
If validation fails → restore from `.bak-*` and abort.
|
||||
|
||||
### Phase 5 — Reload MCP
|
||||
|
||||
```
|
||||
/reload-mcp
|
||||
```
|
||||
|
||||
### Phase 6 — Smoke test
|
||||
|
||||
Call `mcp__context7__resolve-library-id` with a benign query (e.g. `libraryName: "React"`, `query: "smoke test"`). If it returns library IDs → success.
|
||||
|
||||
### Phase 7 — Final report
|
||||
|
||||
```
|
||||
✅ Setup complete. context7 registered in ~/.hermes/config.yaml.
|
||||
|
||||
After /reload-mcp:
|
||||
• mcp__context7__* tools serve from npx @upstash/context7-mcp
|
||||
• API key from CONTEXT7_API_KEY env var (or embedded)
|
||||
• Backup saved at ~/.hermes/config.yaml.bak-<ts>
|
||||
|
||||
If something breaks:
|
||||
• Restore from .bak-* and tell me.
|
||||
```
|
||||
|
||||
## Rollback procedure
|
||||
|
||||
```bash
|
||||
cp ~/.hermes/config.yaml.bak-<ts> ~/.hermes/config.yaml
|
||||
/reload-mcp
|
||||
```
|
||||
|
||||
## Common mistakes
|
||||
|
||||
- **Forgetting to set CONTEXT7_API_KEY.** The MCP server will fail to start without it.
|
||||
- **Embedding the key when env var works.** Env var is cleaner for rotation.
|
||||
- **Forgetting /reload-mcp.** Config changes don't take effect until reload.
|
||||
152
dist-hermes/mcp/setup-projects-meta/SKILL.md
Normal file
152
dist-hermes/mcp/setup-projects-meta/SKILL.md
Normal file
@@ -0,0 +1,152 @@
|
||||
---
|
||||
name: setup-projects-meta
|
||||
version: 1.0.0-hermes
|
||||
description: Hermes-flavour projects-meta setup. Edits `~/.hermes/config.yaml` to register the local `projects-meta-mcp` stdio server. Pre-checks that the binary exists at `~/projects/.common/lib/projects-meta-mcp/dist/server.js` and that `~/.config/projects-mcp/auth.toml` exists — both are shared across Claude Code and Hermes. If pre-checks fail, falls back to git clone (applies extraheader-pattern for safety). Use when user says "install projects-meta", "setup projects-meta", or whenever `mcp__projects-meta__*` tools are missing. Mutates Hermes config; pauses for confirmation before writing.
|
||||
---
|
||||
|
||||
# setup-projects-meta (Hermes)
|
||||
|
||||
> One-time Hermes skill that registers `projects-meta-mcp` in `~/.hermes/config.yaml`. The binary and credentials are pre-existing (shared with Claude Code); this skill only adds the MCP server entry.
|
||||
|
||||
## When to use
|
||||
|
||||
- User explicitly asks: install / set up / configure projects-meta on Hermes.
|
||||
- A `using-projects-meta`-driven task fails because `mcp__projects-meta__*` tools aren't available.
|
||||
- New Hermes machine where Claude Code's projects-meta is already installed but Hermes config isn't updated.
|
||||
|
||||
## Out of scope
|
||||
|
||||
- Cloning or building `projects-meta-mcp` — that's Claude Code's responsibility. This skill assumes `~/projects/.common/lib/projects-meta-mcp/dist/server.js` already exists.
|
||||
- Creating or rotating Gitea tokens — assume `~/.config/projects-mcp/auth.toml` exists.
|
||||
- Running `projects-meta-mcp` itself — Hermes spawns it via `config.yaml`.
|
||||
|
||||
## Hard rule: don't auto-mutate config
|
||||
|
||||
Edits `~/.hermes/config.yaml`. **Always pause for explicit confirmation between Phase 1 (discovery) and Phase 2 (plan), and again before Phase 3 (writes).**
|
||||
|
||||
## Procedure
|
||||
|
||||
### Phase 0 — Environment sanity
|
||||
|
||||
- Confirm Hermes is the current agent (need `~/.hermes/config.yaml`).
|
||||
- Confirm `node` is on `PATH` (the stdio command uses `node`).
|
||||
- Pick paths: `~/projects/.common/lib/projects-meta-mcp/dist/server.js`, `~/.config/projects-mcp/auth.toml`, `~/.hermes/config.yaml`. POSIX `~/...` resolves on Hermes (Linux).
|
||||
|
||||
### Phase 1 — Discovery (read-only)
|
||||
|
||||
**Binary pre-check.** Verify `~/projects/.common/lib/projects-meta-mcp/dist/server.js` exists.
|
||||
|
||||
**Credentials pre-check.** Verify `~/.config/projects-mcp/auth.toml` exists and contains `gitea_token = "..."` (don't echo the token value).
|
||||
|
||||
**Existing MCP entry.** Read `~/.hermes/config.yaml` and check `mcp_servers.projects-meta`. Note if present.
|
||||
|
||||
Report:
|
||||
```
|
||||
Binary: <present | MISSING → will fallback to git clone>
|
||||
Auth: <present | MISSING → will ask user>
|
||||
MCP entry: <present | will add>
|
||||
```
|
||||
|
||||
### Phase 2 — Plan + confirm
|
||||
|
||||
Present the plan:
|
||||
```
|
||||
Binary: <exists | will clone from https://git.kzntsv.site/OpeItcLoc03/projects-meta-mcp>
|
||||
Auth: <exists | MISSING — STOP>
|
||||
MCP entry: <will add | will update>
|
||||
Config: ~/.hermes/config.yaml
|
||||
Backup: ~/.hermes/config.yaml.bak-<ts>
|
||||
```
|
||||
|
||||
Wait for explicit confirmation. If auth is missing → stop and ask the user to run Claude Code's `setup-projects-meta` first (it creates `auth.toml`).
|
||||
|
||||
### Phase 3 — Backup
|
||||
|
||||
```bash
|
||||
TS=$(date +%Y%m%d-%H%M%S)
|
||||
cp ~/.hermes/config.yaml ~/.hermes/config.yaml.bak-$TS
|
||||
```
|
||||
|
||||
### Phase 4 — Fallback clone (only if binary missing)
|
||||
|
||||
If `~/projects/.common/lib/projects-meta-mcp/dist/server.js` does NOT exist:
|
||||
|
||||
```bash
|
||||
mkdir -p ~/projects/.common/lib
|
||||
git clone https://git.kzntsv.site/OpeItcLoc03/projects-meta-mcp ~/projects/.common/lib/projects-meta-mcp
|
||||
cd ~/projects/.common/lib/projects-meta-mcp
|
||||
npm install
|
||||
npm run build
|
||||
```
|
||||
|
||||
**Security:** before cloning, apply extraheader-pattern to prevent credential leakage:
|
||||
```bash
|
||||
git config --global http.https://git.kzntsv.site.extraheader "AUTHORIZATION: Basic ***"
|
||||
```
|
||||
|
||||
Verify `dist/server.js` exists after build. If not → abort.
|
||||
|
||||
### Phase 5 — Edit `~/.hermes/config.yaml`
|
||||
|
||||
Add or update the `mcp_servers` section:
|
||||
|
||||
```yaml
|
||||
mcp_servers:
|
||||
projects-meta:
|
||||
command: node
|
||||
args:
|
||||
- /home/<USER>/projects/.common/lib/projects-meta-mcp/dist/server.js
|
||||
env:
|
||||
GITEA_TOKEN_FILE: /home/<USER>/.config/projects-mcp/auth.toml
|
||||
```
|
||||
|
||||
**Note:** Hermes supports `GITEA_TOKEN_FILE` env var (projects-meta-mcp reads it and extracts `gitea_token`). This avoids hardcoding the token in args.
|
||||
|
||||
If `mcp_servers.projects-meta` already exists, update `args[0]` to the absolute path.
|
||||
|
||||
Validate YAML syntax:
|
||||
```bash
|
||||
python -c "import yaml; yaml.safe_load(open('~/.hermes/config.yaml'))"
|
||||
```
|
||||
|
||||
If validation fails → restore from `.bak-*` and abort.
|
||||
|
||||
### Phase 6 — Reload MCP
|
||||
|
||||
Tell Hermes to reload MCP servers:
|
||||
```
|
||||
/reload-mcp
|
||||
```
|
||||
|
||||
Or invoke the native MCP reload tool if available.
|
||||
|
||||
### Phase 7 — Smoke test
|
||||
|
||||
Call `mcp__projects-meta__meta_status`. If it returns JSON with `synced_at` / `wiki_pages_count` → success.
|
||||
|
||||
### Phase 8 — Final report
|
||||
|
||||
```
|
||||
✅ Setup complete. projects-meta registered in ~/.hermes/config.yaml.
|
||||
|
||||
After /reload-mcp:
|
||||
• mcp__projects-meta__* tools serve from ~/projects/.common/lib/projects-meta-mcp
|
||||
• Credentials from ~/.config/projects-mcp/auth.toml (shared with Claude Code)
|
||||
• Backup saved at ~/.hermes/config.yaml.bak-<ts>
|
||||
|
||||
If something breaks:
|
||||
• Restore from .bak-* and tell me.
|
||||
```
|
||||
|
||||
## Rollback procedure
|
||||
|
||||
```bash
|
||||
cp ~/.hermes/config.yaml.bak-<ts> ~/.hermes/config.yaml
|
||||
/reload-mcp
|
||||
```
|
||||
|
||||
## Common mistakes
|
||||
|
||||
- **Skipping auth.toml pre-check.** If `auth.toml` is missing, the server will fail to start. Don't proceed without it.
|
||||
- **Hardcoding token in args.** Use `GITEA_TOKEN_FILE` env var instead — `auth.toml` is the source of truth.
|
||||
- **Forgetting /reload-mcp.** Edits to `config.yaml` don't take effect until MCP reloads.
|
||||
119
dist-hermes/mcp/using-context7/SKILL.md
Normal file
119
dist-hermes/mcp/using-context7/SKILL.md
Normal file
@@ -0,0 +1,119 @@
|
||||
---
|
||||
name: using-context7
|
||||
version: 1.0.0
|
||||
description: Use when answering questions about a specific library, framework, SDK, API, or CLI tool — including setup/install, config, API syntax, version-specific behavior, migration between versions, or library-specific errors. Training data is often stale; context7 returns current docs. Skip for general programming concepts, refactoring, business-logic debugging, or when the codebase already answers the question.
|
||||
---
|
||||
|
||||
# Using the context7 MCP server
|
||||
|
||||
## Overview
|
||||
|
||||
`context7` is an MCP server that fetches **current** documentation for named libraries and frameworks. Two tools: `mcp__context7__resolve-library-id` (name → library ID) and `mcp__context7__query-docs` (library ID + question → doc snippets).
|
||||
|
||||
Your training data has a cutoff. Library APIs change. If a question names a library, **reach for context7 before answering from memory**, even for libraries you "know" — your recall may be one or two majors behind.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
This skill assumes `mcp__context7__resolve-library-id` and `mcp__context7__query-docs` are available. If they aren't (the tools are missing from the session, or calls fail with a connection error), the context7 MCP server isn't running for this session. Trigger the **`setup-context7`** skill to install/configure the official plugin (`context7@claude-plugins-official`) and inject the user's API key. It's a one-time procedure with confirmation gates.
|
||||
|
||||
## When to use
|
||||
|
||||
Use when the user asks about any of these in the context of a specific library:
|
||||
|
||||
- Install / setup / init commands
|
||||
- Config file shape (`nuxt.config.ts`, `next.config.mjs`, `tsconfig.json` extends, `vite.config`, etc.)
|
||||
- API / component / hook / composable syntax
|
||||
- Migration between versions (v3 → v4, v14 → v15)
|
||||
- Library-specific errors / warnings
|
||||
- CLI flags
|
||||
- Feature availability ("does X support Y?")
|
||||
- Plugin / module ecosystem questions
|
||||
|
||||
Common triggers: "how do I …", "what's the right way to … in <lib>", "is there a <lib> way to …", any error message containing a library's name, any config file snippet.
|
||||
|
||||
**Prefer context7 over WebSearch / WebFetch for library docs** — it returns curated snippets, not rendered marketing pages.
|
||||
|
||||
## When NOT to use
|
||||
|
||||
- General programming concepts (closures, concurrency, algorithms)
|
||||
- Refactoring / code review / business-logic debugging
|
||||
- Writing new code from scratch where the stack isn't named
|
||||
- Questions the current codebase answers (read the repo first)
|
||||
- Your own prior-conversation context (use wiki / memory instead)
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. Identify the library (and version, if the user mentioned one)
|
||||
2. resolve-library-id → pick best match by name + reputation + snippet count
|
||||
3. query-docs with the ID + a specific question
|
||||
4. Cite what you found; fall back only if context7 returned nothing useful
|
||||
```
|
||||
|
||||
**Budget: 3 calls per question, max.** After 3, use what you have — don't loop.
|
||||
|
||||
If the user already gave a library ID in `/org/project` or `/org/project/version` form, skip step 2 and go straight to `query-docs`.
|
||||
|
||||
## Tool quick reference
|
||||
|
||||
| Tool | Required args | Purpose |
|
||||
|---|---|---|
|
||||
| `mcp__context7__resolve-library-id` | `libraryName`, `query` | Name → `/org/project` ID. Use official casing ("Next.js", not "nextjs"). |
|
||||
| `mcp__context7__query-docs` | `libraryId`, `query` | ID → doc snippets. `query` must be specific. |
|
||||
|
||||
Library ID format: `/org/project` (e.g. `/vercel/next.js`) or `/org/project/version` (e.g. `/vercel/next.js/v14.3.0`).
|
||||
|
||||
## Good vs bad queries
|
||||
|
||||
**`resolve-library-id` — pick official names:**
|
||||
|
||||
```
|
||||
libraryName: "Nuxt" query: "Nuxt 4 config and route rules" ✅
|
||||
libraryName: "nuxt4" query: "nuxt" ❌ (wrong casing, vague query)
|
||||
```
|
||||
|
||||
**`query-docs` — be specific:**
|
||||
|
||||
```
|
||||
query: "How to set up @nuxtjs/i18n with prefix_except_default and ru default locale in Nuxt 4" ✅
|
||||
query: "i18n" ❌
|
||||
query: "How to configure YooKassa payment provider in Medusa v2 core flows" ✅
|
||||
query: "payments" ❌
|
||||
```
|
||||
|
||||
A specific query returns targeted snippets; a vague one returns a grab bag you'll ignore.
|
||||
|
||||
## Example
|
||||
|
||||
User: "How do `routeRules` work in Nuxt 4?"
|
||||
|
||||
```
|
||||
1. mcp__context7__resolve-library-id
|
||||
libraryName: "Nuxt"
|
||||
query: "Nuxt 4 routeRules hybrid rendering"
|
||||
→ /nuxt/nuxt (or /nuxt/nuxt/v4.x.x if version known)
|
||||
|
||||
2. mcp__context7__query-docs
|
||||
libraryId: "/nuxt/nuxt"
|
||||
query: "routeRules for hybrid rendering: ssr, prerender, isr, swr — syntax and examples"
|
||||
→ doc snippets
|
||||
|
||||
3. Answer using the snippets. Cite the library + version.
|
||||
```
|
||||
|
||||
## Common mistakes
|
||||
|
||||
| Mistake | Fix |
|
||||
|---|---|
|
||||
| Answering from memory on a library question | Run `resolve-library-id` first. Your training data is stale. |
|
||||
| Calling `query-docs` without resolving first | Required unless user already gave `/org/project` ID. |
|
||||
| Vague queries ("auth", "hooks", "config") | Include the specific task, version, and constraints. |
|
||||
| Looping until you find the "perfect" answer | 3-call hard cap. Take the best result and move on. |
|
||||
| Using context7 for codebase questions | Read the code. context7 doesn't know your repo. |
|
||||
| Using context7 for general concepts | Answer from training data. context7 is for libraries. |
|
||||
|
||||
## Red flags
|
||||
|
||||
- "I already know this library" → your recall may be one major behind. Resolve anyway if the user is about to act on your answer.
|
||||
- "This will take too many calls" → you have 3. Use them.
|
||||
- "The error message looks obvious" → error messages that include a library name are a strong context7 signal.
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: using-projects-meta
|
||||
version: 1.1.0
|
||||
version: 1.2.0
|
||||
description: Use when working across multiple projects on one or many machines — cross-project task aggregation (`mcp__projects-meta__tasks_*`), shared Gitea-backed wiki query / ingest (`mcp__projects-meta__knowledge_*`), or sync diagnostics (`mcp__projects-meta__meta_status`). Triggers on phrases like "across all projects", "what's on the boards", "check shared wiki", "search projects-wiki", "ingest into shared wiki", "что у меня на досках", "по всем проектам", "общая вики", "cross-project status", or any time the user wants to see / mutate state in another repo than the current cwd. v1.1.0 mandates a Step 0 freshness gate (probe `meta_status`, sync if stale, pull `projects-wiki` before shared-wiki writes) — see SKILL body. Mutation tools require two-step preview → confirm. Skip for the **current** project's tasks/wiki — those live on disk in `.tasks/` / `.wiki/`.
|
||||
---
|
||||
|
||||
@@ -142,7 +142,7 @@ Use MCP only for **other** projects, **other** machines, or **shared** wiki cont
|
||||
| `mcp__projects-meta__knowledge_ingest` | `target_project`, `type`, `slug`, `body` (+ opt `frontmatter`, `source_project`) | Three commits: `<type>/<slug>.md` + `index.md` + `log.md`. `type` ∈ entities / concepts / packages / sources / raw |
|
||||
| `mcp__projects-meta__knowledge_promote` | `target_project`, `slug`, `body` (+ opt `frontmatter`, `source_project`) | Move `raw/<slug>.md` → `sources/<slug>.md` with auto `raw_path` link |
|
||||
|
||||
`target_project` is either a Gitea repo name, or `_meta` (the dedicated meta-tasks / meta-wiki repos from `auth.toml`).
|
||||
`target_project` is **qualified** `<owner>/<repo>` (e.g. `victor/books`, `OpeItcLoc03/claude-skills`), or the literal `agenda` for the cross-project meta-board (resolves via `agenda_tasks_repo` in `auth.toml`). Bare names (`books`) are rejected with a hint to use the qualified form. Cross-cutting design: shared wiki → `concepts/projects-meta-multi-owner`.
|
||||
|
||||
## Examples
|
||||
|
||||
@@ -181,7 +181,7 @@ User: "заведи в проекте books задачу на миграцию `
|
||||
|
||||
```
|
||||
1. mcp__projects-meta__tasks_create
|
||||
target_project: "books"
|
||||
target_project: "victor/books"
|
||||
slug: "settings-json-migration"
|
||||
description: "<...>"
|
||||
next_action: "<...>"
|
||||
@@ -203,7 +203,7 @@ User: "close `[projects-meta-skills]` in claude-skills"
|
||||
|
||||
```
|
||||
1. mcp__projects-meta__tasks_close
|
||||
target_project: "claude-skills"
|
||||
target_project: "OpeItcLoc03/claude-skills"
|
||||
slug: "projects-meta-skills"
|
||||
note: "<one-line summary>"
|
||||
(no `confirm`)
|
||||
@@ -227,6 +227,7 @@ User: "close `[projects-meta-skills]` in claude-skills"
|
||||
| Calling `knowledge_ingest` with the wrong `type` | `type` must be one of `entities` / `concepts` / `packages` / `sources` / `raw`. Mis-typed pages land in the wrong section and break `index.md`. |
|
||||
| Vague `knowledge_search` queries ("auth", "config") | Specific multi-word queries return targeted snippets; vague ones return noise. |
|
||||
| Forgetting `domain="all"` when searching across families | Default `domain` is auto-detected from cwd; use `"all"` if the wiki page lives in a different family. |
|
||||
| Passing bare project name (`target_project: "books"`) to mutation tools | v2.x rejects bare names. Use qualified `<owner>/<repo>` (e.g. `victor/books`, `OpeItcLoc03/claude-skills`). Literal `agenda` is the only exception (cross-project meta-board). |
|
||||
|
||||
## Red flags
|
||||
|
||||
161
dist-hermes/meta/claude-skills-installer/SKILL.md
Normal file
161
dist-hermes/meta/claude-skills-installer/SKILL.md
Normal file
@@ -0,0 +1,161 @@
|
||||
---
|
||||
name: claude-skills-installer
|
||||
version: 1.0.0
|
||||
description: Recursive bootstrap installer for claude-skills on Hermes. Iterates over `dist-hermes/<category>/<name>/` and installs each via `skill_manage(action='create')`. Respects `dist-hermes/SKIPPED.md` — skipped skills are not installed. Run once manually to bootstrap (`skill_manage(action='create', from='...')`), thereafter trigger «обнови claude-skills» to refresh all skills. The installer updates itself recursively — no separate update step.
|
||||
---
|
||||
|
||||
# claude-skills-installer
|
||||
|
||||
> Bootstrap installer for the claude-skills suite on Hermes. One-time manual registration, then «обнови claude-skills» keeps everything in sync.
|
||||
|
||||
## When to use
|
||||
|
||||
- **Bootstrap phase:** First-time setup on a Hermes machine. Run manually:
|
||||
```
|
||||
skill_manage(action='create', from='dist-hermes/meta/claude-skills-installer/SKILL.md')
|
||||
```
|
||||
- **Update phase:** Whenever user says «обнови claude-skills», «refresh claude-skills», or after `git pull` in the claude-skills repo.
|
||||
|
||||
## What it does
|
||||
|
||||
Iterates over `dist-hermes/<category>/<name>/` (all except `meta/`). For each:
|
||||
|
||||
1. Reads `SKILL.md` (frontmatter: name, version, description).
|
||||
2. Collects assets (README.md, SECURITY.md, scripts/, etc.) if present.
|
||||
3. Calls `skill_manage(action='create', category=<cat>, name=<name>, content=<SKILL.md>, assets=<...>)`.
|
||||
|
||||
Skips anything listed in `dist-hermes/SKIPPED.md` (these are intentionally not part of Hermes rollout).
|
||||
|
||||
**Recursive by design:** the installer lives in `meta/` and updates itself along with everything else.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- `dist-hermes/` tree exists (from `git clone claude-skills` + `python scripts/build-hermes.py`).
|
||||
- Hermes has `skill_manage()` native tool.
|
||||
- Working directory is `claude-skills` root (where `dist-hermes/` lives).
|
||||
|
||||
## Procedure
|
||||
|
||||
### Phase 0 — Verify dist-hermes
|
||||
|
||||
```bash
|
||||
ls dist-hermes/
|
||||
```
|
||||
|
||||
Should list: `software-development/`, `productivity/`, `mcp/`, `meta/`, `SKIPPED.md`.
|
||||
|
||||
If missing → run `python scripts/build-hermes.py` first.
|
||||
|
||||
### Phase 1 — Load SKIPPED.md
|
||||
|
||||
Read `dist-hermes/SKIPPED.md`. Parse the skip list — these categories/names will NOT be installed.
|
||||
|
||||
Example SKIPPED.md entry:
|
||||
```
|
||||
caveman (category: software-development)
|
||||
Reason: Hermes runs on glm-5.1 (cheap local model); token-compression motive disappears.
|
||||
```
|
||||
|
||||
### Phase 2 — Scan dist-hermes
|
||||
|
||||
Walk `dist-hermes/<category>/<name>/`. Collect:
|
||||
|
||||
```
|
||||
category: software-development | productivity | mcp | research
|
||||
name: <directory name>
|
||||
skill_file: dist-hermes/<category>/<name>/SKILL.md
|
||||
assets:
|
||||
- dist-hermes/<category>/<name>/README.md (if exists)
|
||||
- dist-hermes/<category>/<name>/SECURITY.md (if exists)
|
||||
- dist-hermes/<category>/<name>/scripts/* (if exists)
|
||||
```
|
||||
|
||||
**Skip conditions:**
|
||||
- `category/name` is in SKIPPED.md
|
||||
- `name == "claude-skills-installer"` (don't install yourself recursively)
|
||||
|
||||
Report the scan result:
|
||||
```
|
||||
Found N skills to install:
|
||||
software-development: pulling-before-work, active-platform, project-discipline, tdd-criteria
|
||||
productivity: using-markitdown
|
||||
mcp: setup-projects-meta, setup-context7
|
||||
Skipped M entries (see dist-hermes/SKIPPED.md)
|
||||
```
|
||||
|
||||
### Phase 3 — Confirm
|
||||
|
||||
Ask user:
|
||||
```
|
||||
Will install N skills. Proceed? (y/n)
|
||||
```
|
||||
|
||||
Wait for explicit confirmation. This is a bulk operation — permission is required.
|
||||
|
||||
### Phase 4 — Install loop
|
||||
|
||||
For each skill in the scan list:
|
||||
|
||||
```
|
||||
skill_manage(
|
||||
action='create',
|
||||
category='<category>',
|
||||
name='<name>',
|
||||
content='<SKILL.md content>',
|
||||
assets={
|
||||
'README.md': '<README.md content if exists>',
|
||||
'SECURITY.md': '<SECURITY.md content if exists>',
|
||||
'scripts/*': '<script files if exist>'
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
**Important:** `skill_manage(action='create')` is idempotent. If a skill already exists, it updates to the new content.
|
||||
|
||||
Report progress per skill:
|
||||
```
|
||||
✓ pulling-before-work (v1.x.x)
|
||||
✓ active-platform (v1.x.x)
|
||||
...
|
||||
✗ <name> failed: <error>
|
||||
```
|
||||
|
||||
If any skill fails → stop, report the error, and ask whether to continue or rollback.
|
||||
|
||||
### Phase 5 — Verify
|
||||
|
||||
After the loop completes, ask user to verify:
|
||||
```
|
||||
hermes > skills_list()
|
||||
```
|
||||
|
||||
Should show all installed skills under their categories. Count should match N.
|
||||
|
||||
### Phase 6 — Final report
|
||||
|
||||
```
|
||||
✅ Installed N skills. Update complete.
|
||||
|
||||
Installed:
|
||||
software-development: <list>
|
||||
productivity: <list>
|
||||
mcp: <list>
|
||||
|
||||
Skipped:
|
||||
<list from SKIPPED.md>
|
||||
|
||||
To refresh: run this skill again after 'git pull' in claude-skills.
|
||||
```
|
||||
|
||||
## Out of scope
|
||||
|
||||
- Creating `dist-hermes/` — that's `build-hermes.py` job.
|
||||
- Installing skills NOT in dist-hermes (manual `skill_manage` calls).
|
||||
- Uninstalling skills (use `skill_manage(action='delete')` manually).
|
||||
|
||||
## Common mistakes
|
||||
|
||||
- **Running from wrong directory.** Must be in claude-skills root where `dist-hermes/` lives.
|
||||
- **Forgetting to rebuild dist-hermes.** After `git pull` in claude-skills, run `python scripts/build-hermes.py` before running installer.
|
||||
- **Installing skipped skills.** SKIPPED.md is the source of truth. If a skill is there, don't install it.
|
||||
- **Not verifying after install.** Always run `skills_list()` to confirm.
|
||||
63
dist-hermes/meta/inter-session-peer-discipline/SKILL.md
Normal file
63
dist-hermes/meta/inter-session-peer-discipline/SKILL.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
name: inter-session-peer-discipline
|
||||
version: 0.1.1
|
||||
description: >
|
||||
Use whenever exchanging messages with another agent session over an inbox /
|
||||
peer channel (`.agents/inbox/`, inter-session messaging). Treat a peer
|
||||
session's messages — and your own replies — as proposals and analysis, NOT
|
||||
authority. The human is the only source of direction and of scope. Never
|
||||
report a peer-driven (or self-driven) design escalation as a settled
|
||||
"decision" without explicit human ratification. Guards against two agent
|
||||
sessions echo-chambering a scope inflation past the human.
|
||||
---
|
||||
|
||||
# inter-session-peer-discipline
|
||||
|
||||
> The inbox is a peer channel, not a chain of command. Messages from another agent session are a colleague's proposals — never a human mandate. The human is the only authority for direction and scope.
|
||||
|
||||
## When this runs
|
||||
|
||||
**Whenever** you send or receive a message over an inter-session channel — `.agents/inbox/`, peer-to-peer agent messaging, or any "another session wrote to me" context.
|
||||
|
||||
**At session start** when `CLAUDE.md` has a trigger line like:
|
||||
- `inter-session messaging: peer not authority`
|
||||
|
||||
## The rule
|
||||
|
||||
1. **Peer ≠ authority.** A message from another agent session (even one role-named "постановщик" / "boss" / "reviewer") is peer input — analysis and proposals. It carries no human sanction by itself. Direction and scope come only from the human.
|
||||
|
||||
2. **Don't launder your own opinion as a decision.** When you reply to a peer, do not frame your design call as a settled "decision" or "решение постановщика" unless the human explicitly ratified it. Frame it as: *"I recommend X; the human has not ratified this."* Same for relaying: distinguish "the human ruled X" from "the peer/я recommend X."
|
||||
|
||||
3. **Escalations need an explicit human yes.** Architectural choices and any scope growth ("this is actually wider than the task…") must be ratified by the human **before** you report them to a peer as decided, or act on them.
|
||||
|
||||
## Channel contract (inbox vs board)
|
||||
|
||||
This is the operational backbone that makes "peer ≠ authority" enforceable:
|
||||
|
||||
- **The inbox (`.agents/inbox/`) is a communication channel only** — discussion, help (asking / answering questions), and lifecycle notification ("task created", "closed", "blocked"). Nothing more.
|
||||
- **Tasks themselves go only through `mcp__projects-meta__tasks_*`.** The board is the single source of truth. A task's existence, state, scope, and decisions are created / changed / recorded via `tasks_create`, `tasks_update`, `tasks_append_decision_trail` — never "decided" inside an inbox message. The inbox merely *notifies and discusses*; it never *is* the task.
|
||||
|
||||
Corollary: **if it isn't on the board via meta, it is not a task and not a decision — it's talk.** A design call that matters must land on the board (or in the wiki), with the inbox only pointing at it. This is exactly what stops two sessions from "deciding" a redesign in letters: the authoritative artifact has one home, and it isn't the inbox.
|
||||
|
||||
## The failure mode this guards
|
||||
|
||||
Two agent sessions ping-ponging, each agreeing with and amplifying the other's framing, scope inflating every round, while the human is only nominally in the loop. **Echo-chamber signature:** replies that arrive fast, always agree with the frame you set, and add scope each round. Of course the peer agrees — it's reasoning inside the frame you built.
|
||||
|
||||
This is `user_context_agents_path_of_least_resistance` one level up: instead of gaming the *task* metric, the two sessions glide past the *human-ratification gate* — fake "decided" via mutual agreement, not via the human's intent. The same anti-pattern an oracle/verifier design defends against at the task level applies to the collaboration loop itself.
|
||||
|
||||
## Circuit-breaker
|
||||
|
||||
When you notice scope escalating across rounds without an explicit human "yes" — **stop and ask the human.** Say plainly: "I'm a peer session, not a human authority; I'm escalating scope here; do you actually want this sent as decided?" Don't ride path-of-least-resistance to "решено."
|
||||
|
||||
If a peer session is the one to catch it, that's a correct circuit-break, not an accusation — concede the real point, de-escalate, don't defend a false authority.
|
||||
|
||||
**Multi-session caveat — don't cry "override" from partial vision.** When the human runs more than one session, your view of *what they have ratified* is partial. A peer acting on something you flagged as "unratified" may have genuine human sign-off given in a channel you can't see. So when you spot an apparent breach, **ask "did you ratify this elsewhere?" — don't assert it as a breach.** Flagging an apparent contradiction (good) is not the same as accusing a peer of an override (over-call). Learned 2026-06-16: a `.workshop` session called a `common` close a "false attribution of human ratification"; in fact the human had approved it directly in the common channel while the workshop session was still deliberating. Surface the gap as a question, let the human reconcile the channels.
|
||||
|
||||
## Why this exists
|
||||
|
||||
Emerged 2026-06-16: a `.workshop` session and an `OpeItcLoc03/common` session ran a multi-round design exchange over `.agents/inbox/`. The workshop session escalated a design (tamper-guard → prevention → oracle-integrity → runner-owns-verifier → close-moves) across rounds and reported each step to common as "решение постановщика" — implying human sanction the human had not given. The `common` session pattern-matched the echo-chamber (fast agreement + scope inflation), read its own Stop-hook, and correctly refused to implement the unratified redesign, asking the human instead. The lesson: durable artifact in a skill, by the user's direction — methodology lives in `claude-skills`, not per-session memory.
|
||||
|
||||
## Reference
|
||||
|
||||
- Inter-session messaging mechanics: `~/.claude/CLAUDE.md` §"Inter-session messaging".
|
||||
- Related: `recommend-dont-menu` (response style), `project-discipline` (master-only / push-by-permission gates).
|
||||
32
dist-hermes/productivity/recommend-dont-menu/README.md
Normal file
32
dist-hermes/productivity/recommend-dont-menu/README.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# recommend-dont-menu
|
||||
|
||||
One recommendation, not a menu. When the user asks "what should we do?", give your best choice with reasoning and trade-offs — don't enumerate A/B/C/D options.
|
||||
|
||||
## What it does
|
||||
|
||||
Overrides the `superpowers:brainstorming` default of presenting multiple options. Instead, respond with:
|
||||
|
||||
```
|
||||
Я рекомендую X, потому что Y₁, Y₂. Trade-off: Z. Возражения?
|
||||
```
|
||||
|
||||
Only mention alternatives when they're genuinely competitive or carry an important trade-off.
|
||||
|
||||
## When to use
|
||||
|
||||
During design discussions, architecture reviews, brainstorming, or any "what should we do" question.
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
bash scripts/install.sh recommend-dont-menu
|
||||
```
|
||||
|
||||
## Trigger line
|
||||
|
||||
Add to `CLAUDE.md`:
|
||||
```
|
||||
prefer single recommendations
|
||||
```
|
||||
|
||||
Or use `project-bootstrap` (v1.9.0+) which includes this trigger in its template.
|
||||
60
dist-hermes/productivity/recommend-dont-menu/SKILL.md
Normal file
60
dist-hermes/productivity/recommend-dont-menu/SKILL.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
name: recommend-dont-menu
|
||||
version: 0.1.0
|
||||
description: >
|
||||
Use during design discussions, brainstorming, architecture reviews, or any
|
||||
"what should we do" question — give one argued recommendation with explicit
|
||||
trade-offs, not a multiple-choice menu. Override of superpowers:brainstorming
|
||||
default. Works on any agent — pure response-style rule, no tool mappings needed.
|
||||
---
|
||||
|
||||
# recommend-dont-menu
|
||||
|
||||
> One recommendation, not a menu. When the user asks "what should we do?" or "which is better?", give your best choice with reasoning and trade-offs. Don't enumerate A/B/C/D options — menus slow down decision-making when one option is clearly better.
|
||||
|
||||
## When this runs
|
||||
|
||||
**At session start** — when `CLAUDE.md` contains any trigger line:
|
||||
- `prefer single recommendations`
|
||||
- `recommend, don't menu`
|
||||
- `argued recommendations`
|
||||
- `give me your best shot`
|
||||
|
||||
**On explicit reference** — when user says "give me a recommendation", "don't menu", "what do you think?", or close variants.
|
||||
|
||||
## Default mode
|
||||
|
||||
For design questions, architecture choices, "what should we do" queries:
|
||||
|
||||
```
|
||||
Я рекомендую X, потому что Y₁, Y₂. Trade-off: Z. Возражения?
|
||||
```
|
||||
|
||||
**Only mention alternatives if:**
|
||||
- They're genuinely close to the recommended option, OR
|
||||
- They carry an important trade-off the user should weigh
|
||||
|
||||
Then, briefly:
|
||||
```
|
||||
Если важно W — лучше X', но добавляет сложность; иначе X.
|
||||
```
|
||||
|
||||
**Don't enumerate options** for the sake of appearing comprehensive. Menus are noise when one option dominates — they force the user to read through losing choices and bury your reasoning behind an oblique list instead of a responsible recommendation.
|
||||
|
||||
## Override
|
||||
|
||||
This skill **overrides** `superpowers:brainstorming` where that skill prefers multiple-choice options. User instructions > skill defaults.
|
||||
|
||||
If `superpowers:brainstorming` is active in the session, this skill's response style takes precedence for design/brainstorming questions.
|
||||
|
||||
## Cross-agent applicability
|
||||
|
||||
This skill is **pure response-style** — it works on any agent (Claude, Gemini, Copilot) without tool mappings. No `references/copilot-tools.md` or equivalent needed.
|
||||
|
||||
## Why this exists
|
||||
|
||||
The pattern emerged from iterative refinement across `claude-skills` brainstorm sessions and `.meeting-room/` discussions. When agents dump 4-option menus for every question, users skim or disengage. A single argued recommendation with clear trade-offs leads to faster convergence and better decisions. When alternatives are genuinely competitive, mention them — but don't manufacture variants.
|
||||
|
||||
## Reference
|
||||
|
||||
Original rule lived in `~/.claude/CLAUDE.md` as a per-machine instruction. Moving to a skill makes it portable: all machines bootstrapped with `project-bootstrap` inherit it, and cross-agent compatibility is explicit.
|
||||
78
dist-hermes/productivity/using-markitdown/SKILL.md
Normal file
78
dist-hermes/productivity/using-markitdown/SKILL.md
Normal file
@@ -0,0 +1,78 @@
|
||||
---
|
||||
name: using-markitdown
|
||||
version: 1.0.1
|
||||
description: Use when capturing external content into a markdown-based knowledge base, wiki `raw/` directory, or any pipeline that must preserve the source's full text — for web pages, PDFs, DOCX/PPTX/XLSX, EPUB, CSV/JSON/XML, ZIP archives, images (with OCR/EXIF), audio (with transcription), or YouTube URLs. Also use when WebFetch returned an LLM-summarized version but the raw content is what's needed.
|
||||
---
|
||||
|
||||
# using-markitdown
|
||||
|
||||
> Convert almost any path or URL to plain markdown using Microsoft's `markitdown` CLI (v0.1.6, on `PATH`). Returns **raw textual content**, not an LLM summary.
|
||||
|
||||
## Tool
|
||||
|
||||
```
|
||||
markitdown <path|url> # → markdown to stdout
|
||||
markitdown <path|url> -o out.md # → write markdown to a file
|
||||
cat file.pdf | markitdown # → read from stdin (use -x/-m to hint the format)
|
||||
```
|
||||
|
||||
The positional argument accepts a **local file path** (host path, normal slashes) or an `http://` / `https://` URL. The CLI runs natively, so it sees your full host filesystem — no Docker mount, no `file://` URI translation, no path rewriting.
|
||||
|
||||
Useful flags: `-o <file>` (write to a file instead of stdout), `-x <ext>` / `-m <mime>` (format hint when reading from stdin).
|
||||
|
||||
## Local files
|
||||
|
||||
Pass the host path directly — relative or absolute, with native separators:
|
||||
|
||||
```
|
||||
markitdown C:\Users\vitya\modular\heart-and-mask\.wiki\raw\foo.html -o foo.md
|
||||
```
|
||||
|
||||
No mount caveats: the CLI is a normal local process. The old Docker `-v` mount translation and `/c:/Users/...` `[Errno 2]` symptom no longer apply.
|
||||
|
||||
**Filenames.** Non-ASCII filenames (Cyrillic, etc.) still travel better as Latin kebab-case through downstream wiki/ingest steps. Rename to Latin kebab-case before saving the output, per `.wiki/CLAUDE.md` naming rules.
|
||||
|
||||
## When to use
|
||||
|
||||
- Filling a wiki's `raw/` directory from a URL or local PDF/DOCX.
|
||||
- Datasheets, papers, blog posts, GitHub READMEs, Obsidian Web Clipper outputs, KiCad netlist exports — anything where the source text matters and lossy summarization would break later ingest steps.
|
||||
- Any time the next step is "save the source verbatim before summarizing".
|
||||
|
||||
## When NOT to use
|
||||
|
||||
- You only need a *summary* or an *answer about* a page → use **WebFetch** (cheaper, runs through a small model, returns prose).
|
||||
- The URI is GitHub/PR/issue/release content → use `gh` CLI (richer metadata, structured output).
|
||||
- The URI is private/authenticated (GDocs, Confluence, Jira, Slack, Notion, `share.google/*` sign-in walls) → markitdown receives the **public-facing fallback page** (sign-in screen, cookie banner) and returns *that* as markdown. Verify the result is real content before saving.
|
||||
- **The URI is a browser-rendered web page the user is already viewing** → ask the user to capture it via **Obsidian Web Clipper** (browser extension, runs Readability extraction client-side) and drop the resulting `.md` into `raw/`. Web Clipper output is dramatically cleaner than markitdown's HTML pass — no nav chrome, no sidebar history, no cookie banners — plus it carries YAML frontmatter (title / source URL / date) out of the box. Reserves markitdown for things browsers can't easily save (PDF, DOCX, PPTX, XLSX, EPUB, local files). Note: rename the resulting file to Latin kebab-case before ingest (Web Clipper preserves the page `<title>` verbatim, often non-ASCII).
|
||||
|
||||
## Pattern: ingest a remote source into a wiki
|
||||
|
||||
```
|
||||
1. markitdown "https://example.com/foo.pdf" -o .wiki/raw/<slug>.md (kebab-case, Latin only)
|
||||
2. Inspect the head of the result. If it looks like a sign-in/cookie/consent page, abort — ask the user for an alternative (manual save, paste, authenticated source).
|
||||
3. Register the new file in .wiki/raw/README.md.
|
||||
4. Hand off to the wiki ingest workflow (creates sources/<slug>.md summary + entity/concept updates).
|
||||
```
|
||||
|
||||
For a huge (book-length) document, write straight to a file with `-o` and summarize *from the saved file* — do not pipe the whole markdown through working context.
|
||||
|
||||
## Common gotchas
|
||||
|
||||
| Symptom | Cause | Fix |
|
||||
|---|---|---|
|
||||
| Output is a Google/Microsoft sign-in page in some random language | URI behind auth wall | Ask user to export the content manually (Save as PDF, copy-paste) and put it in `raw/` |
|
||||
| Output is mostly nav/cookie banner text | Site is JS-rendered or anti-bot | Try the cached or print URL; or ask user for HTML export |
|
||||
| Output lacks images / diagrams | Markdown is text-only by design | Save the original asset separately under `raw/assets/`; reference it from the `sources/` summary |
|
||||
| `markitdown: command not found` | CLI not on `PATH` | Confirm with `markitdown --version` (expect `markitdown 0.1.6`); install with `pip install markitdown[all]` if missing |
|
||||
| Huge output (book-length) | Whole document converted in one call | Use `-o <file>` to save raw, then summarize *from the saved file* — do not hold the entire markdown in working context |
|
||||
|
||||
## Quick contrast with WebFetch and Web Clipper
|
||||
|
||||
| | markitdown | WebFetch | Obsidian Web Clipper |
|
||||
|---|---|---|---|
|
||||
| Returns | raw markdown of the source | LLM answer about the source | Readability-extracted markdown with YAML frontmatter |
|
||||
| Use for | PDF / DOCX / non-browser-friendly | one-shot Q&A | any browser-viewable web page |
|
||||
| Auth-aware | no | no | **yes** (uses the user's logged-in browser session) |
|
||||
| Chrome / nav stripped | partial (still verbose) | n/a (model picks signal) | **yes** (clean) |
|
||||
| Handles PDFs / DOCX | yes | text-only HTML extraction | no (web pages only) |
|
||||
| Who triggers it | Claude | Claude | the user (manual click) |
|
||||
@@ -25,7 +25,7 @@ Canonical layout reference:
|
||||
| Mode | Trigger | Action |
|
||||
|---|---|---|
|
||||
| **greenfield** | No `.wiki/` exists | Create the canonical layout from scratch. |
|
||||
| **noop** | `.wiki/` already canon (all five canon files + four content dirs) | Report and exit — no writes. |
|
||||
| **noop** | `.wiki/` already canon (all five canon files + six content dirs) | Report and exit — no writes. |
|
||||
| **migrate** | `.wiki/` exists with non-canon files (`SUMMARY.md`, `WORKFLOW.md`, `source/`) or missing canon files | Move legacy files (e.g. `source/*.md` → `concepts/*.md` via `git mv`), create missing canon files, drop a timestamped `.backup-*/` next to it. |
|
||||
|
||||
Migration **does not auto-rewrite** existing concept content — it only moves
|
||||
@@ -45,10 +45,12 @@ job.
|
||||
├── entities/ ← entity pages (people, services, modules)
|
||||
├── concepts/ ← design decisions, recurring ideas
|
||||
├── packages/ ← code packages
|
||||
└── sources/ ← one summary per ingested source
|
||||
├── sources/ ← one summary per ingested source
|
||||
├── contradictions/ ← surfaced tensions worth tracking long-term
|
||||
└── open-questions/ ← unresolved questions raised during ingest/query
|
||||
```
|
||||
|
||||
The four content directories each get a `.gitkeep` so git tracks them.
|
||||
The six content directories each get a `.gitkeep` so git tracks them.
|
||||
|
||||
## Hard rules
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: setup-wiki
|
||||
version: 1.0.0
|
||||
description: Creates or migrates a project's `.wiki/` to the canonical Karpathy LLM Wiki layout — `CLAUDE.md` schema, `index.md`, `log.md`, `overview.md`, `raw/README.md`, plus empty `entities/`, `concepts/`, `packages/`, `sources/`. Use when the user says "set up wiki", "init wiki", "настрой вики", "инициализируй вики", "create wiki", "migrate wiki to canon", "wiki сломана", "wiki layout broken", or whenever `using-wiki` detects a missing or non-canonical `.wiki/`. Two modes — greenfield (no wiki) and migrate (existing non-canonical layout). Confirmation gate before writing. Cross-platform.
|
||||
version: 1.1.0
|
||||
description: Creates or migrates a project's `.wiki/` to the canonical Karpathy LLM Wiki layout — `CLAUDE.md` schema, `index.md`, `log.md`, `overview.md`, `raw/README.md`, plus empty `entities/`, `concepts/`, `packages/`, `sources/`, `contradictions/`, `open-questions/`. Use when the user says "set up wiki", "init wiki", "настрой вики", "инициализируй вики", "create wiki", "migrate wiki to canon", "wiki сломана", "wiki layout broken", or whenever `using-wiki` detects a missing or non-canonical `.wiki/`. Two modes — greenfield (no wiki) and migrate (existing non-canonical layout). Confirmation gate before writing. Cross-platform.
|
||||
---
|
||||
|
||||
# setup-wiki
|
||||
@@ -35,7 +35,7 @@ The procedure mutates the project's `.wiki/`. **Pause for explicit confirmation
|
||||
Inspect `.wiki/`:
|
||||
|
||||
- **No `.wiki/`** → mode = `greenfield`.
|
||||
- **`.wiki/` exists AND has all of:** `CLAUDE.md`, `index.md`, `log.md`, `overview.md`, `raw/README.md`, plus directories `entities/`, `concepts/`, `packages/`, `sources/` → mode = `noop` (already canon; report and exit).
|
||||
- **`.wiki/` exists AND has all of:** `CLAUDE.md`, `index.md`, `log.md`, `overview.md`, `raw/README.md`, plus directories `entities/`, `concepts/`, `packages/`, `sources/`, `contradictions/`, `open-questions/` → mode = `noop` (already canon; report and exit).
|
||||
- **`.wiki/` exists but missing some canon files OR has non-canon files** (`SUMMARY.md`, `WORKFLOW.md`, `source/`) → mode = `migrate`.
|
||||
|
||||
Report findings to the user as a short summary:
|
||||
@@ -56,7 +56,7 @@ Show the plan in one block:
|
||||
Will create .wiki/ with canonical layout:
|
||||
CLAUDE.md (schema), index.md, log.md, overview.md
|
||||
raw/README.md
|
||||
entities/, concepts/, packages/, sources/ (with .gitkeep)
|
||||
entities/, concepts/, packages/, sources/, contradictions/, open-questions/ (with .gitkeep)
|
||||
```
|
||||
|
||||
**Migrate:**
|
||||
@@ -65,7 +65,7 @@ Will rename:
|
||||
source/*.md → concepts/*.md (via git mv when in a git repo, plain mv otherwise)
|
||||
Will create:
|
||||
CLAUDE.md, index.md, log.md, overview.md, raw/README.md
|
||||
entities/, packages/, sources/ (with .gitkeep)
|
||||
entities/, packages/, sources/, contradictions/, open-questions/ (with .gitkeep)
|
||||
Will delete:
|
||||
SUMMARY.md, WORKFLOW.md, raw/.gitkeep, source/ (after moves)
|
||||
Will not touch existing files in raw/ — they're immutable sources.
|
||||
@@ -101,6 +101,8 @@ The `using-wiki` skill enforces the workflow and file formats. This file overrid
|
||||
- `concepts/` — recurring ideas, design decisions, gotchas.
|
||||
- `packages/` — code packages this project produces or consumes.
|
||||
- `sources/` — one summary page per ingested external doc; carries `ingested:` and `raw_path:`.
|
||||
- `contradictions/` — surfaced tensions between sources or pages worth tracking long-term; each page cross-links the affected entities/concepts/sources and carries a status (`open` / `resolved` / `accepted-divergence`).
|
||||
- `open-questions/` — unresolved questions raised during ingest or query that the wiki cannot answer yet; each page cross-links the pages/sources that touch the question and carries a status (`open` / `answered` / `obsolete`).
|
||||
- `overview.md` — single project-wide overview.
|
||||
|
||||
## Naming
|
||||
@@ -137,6 +139,14 @@ Catalog of all wiki pages. One line per page, organized by type. Updated on ever
|
||||
|
||||
## Sources
|
||||
|
||||
<!-- (none yet) -->
|
||||
|
||||
## Contradictions
|
||||
|
||||
<!-- (none yet) -->
|
||||
|
||||
## Open Questions
|
||||
|
||||
<!-- (none yet) -->
|
||||
```
|
||||
|
||||
@@ -190,7 +200,7 @@ For large or path-sensitive sources outside the repo, register them here:
|
||||
\`\`\`
|
||||
```
|
||||
|
||||
**Empty `.gitkeep`** in each of `entities/`, `concepts/`, `packages/`, `sources/` so git tracks the dirs.
|
||||
**Empty `.gitkeep`** in each of `entities/`, `concepts/`, `packages/`, `sources/`, `contradictions/`, `open-questions/` so git tracks the dirs.
|
||||
|
||||
### Phase 4b — Migrate
|
||||
|
||||
@@ -198,7 +208,7 @@ If migrate mode: combine creation (for missing canon files) with file moves (for
|
||||
|
||||
```bash
|
||||
# 1. Create missing directories
|
||||
mkdir -p .wiki/concepts .wiki/entities .wiki/packages .wiki/sources
|
||||
mkdir -p .wiki/concepts .wiki/entities .wiki/packages .wiki/sources .wiki/contradictions .wiki/open-questions
|
||||
|
||||
# 2. Move source/* → concepts/* (use git mv if in a git repo)
|
||||
if git rev-parse --git-dir >/dev/null 2>&1; then
|
||||
@@ -215,8 +225,8 @@ rmdir .wiki/source 2>/dev/null
|
||||
# 3. Create missing canon files (CLAUDE.md, index.md, log.md, overview.md, raw/README.md)
|
||||
# using the templates from Phase 4a, but skip files that already exist.
|
||||
|
||||
# 4. Add .gitkeep to entities/, packages/, sources/
|
||||
touch .wiki/entities/.gitkeep .wiki/packages/.gitkeep .wiki/sources/.gitkeep
|
||||
# 4. Add .gitkeep to entities/, packages/, sources/, contradictions/, open-questions/
|
||||
touch .wiki/entities/.gitkeep .wiki/packages/.gitkeep .wiki/sources/.gitkeep .wiki/contradictions/.gitkeep .wiki/open-questions/.gitkeep
|
||||
```
|
||||
|
||||
For migrated `concepts/*.md` pages, **do not rewrite their content** — just prepend a minimal frontmatter if missing:
|
||||
@@ -242,7 +252,7 @@ Append a line to `log.md`:
|
||||
After writes, confirm:
|
||||
|
||||
- All canon files exist: `CLAUDE.md`, `index.md`, `log.md`, `overview.md`, `raw/README.md`.
|
||||
- Four content directories exist (with at least `.gitkeep` or content).
|
||||
- Six content directories exist (`entities/`, `concepts/`, `packages/`, `sources/`, `contradictions/`, `open-questions/`) — with at least `.gitkeep` or content.
|
||||
- No leftover non-canon files (`SUMMARY.md`, `WORKFLOW.md`, `source/`).
|
||||
- For migrate mode: every migrated page has frontmatter with `type: concept`.
|
||||
|
||||
@@ -255,7 +265,7 @@ Print final state:
|
||||
```
|
||||
✅ Wiki ready at .wiki/.
|
||||
Mode: greenfield | migrate
|
||||
Files: 5 canon + 4 dirs + N migrated concept pages
|
||||
Files: 5 canon + 6 dirs + N migrated concept pages
|
||||
Backup (if migrate): .wiki/.backup-<ts>/
|
||||
|
||||
Next steps for the user:
|
||||
85
dist-hermes/software-development/active-platform/SKILL.md
Normal file
85
dist-hermes/software-development/active-platform/SKILL.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: active-platform
|
||||
description: Switches command, path, and example generation to the user's currently active development platform — Windows / Linux / macOS. Use this whenever you produce shell commands, install steps, README quick-start sections, or any output the user will paste into a terminal — even if they don't say "shell" or "command" explicitly. The default active platform is Windows / PowerShell because that's the user's primary workstation. Recognize and obey trigger phrases like "мы на винде", "мы на линуксе", "мы на маке", "we're on Windows", "we're on Linux", "we're on macOS", and close variants — they switch the active platform for the rest of the session. Also activate this skill anytime the user mentions a different machine, a remote box, or asks "how would I run this on X".
|
||||
---
|
||||
|
||||
# active-platform
|
||||
|
||||
> Keep generated commands in the shell the user actually has open. The user works on multiple machines (Windows primary, Linux/Mac secondary). Translating shell idioms in their head wastes attention; this skill removes that friction.
|
||||
|
||||
## Default active platform
|
||||
|
||||
**Linux + bash.** Use this until something in the session tells you to switch. Reason: Hermes runs on Linux factory machines. This default is global, not per-project.
|
||||
|
||||
## Trigger phrases
|
||||
|
||||
Recognize anywhere in user input — beginning, middle, in passing — and update the active platform immediately. Match liberally: case-insensitive, mixed Cyrillic/Latin, missing punctuation should still trigger.
|
||||
|
||||
| Switch to → | Russian | English |
|
||||
|---|---|---|
|
||||
| **Windows** | "мы на винде", "я на винде", "мы на windows", "переключись на винду", "сейчас под виндой" | "we're on Windows", "I'm on Windows", "switch to Windows", "on a Windows box" |
|
||||
| **Linux** | "мы на линуксе", "я на линуксе", "мы на linux", "переключись на линукс", "сейчас под линуксом" | "we're on Linux", "I'm on Linux", "switch to Linux", "on a Linux box" |
|
||||
| **macOS** | "мы на маке", "я на маке", "мы на макоси", "переключись на мак", "сейчас под маком" | "we're on macOS", "we're on a Mac", "I'm on a Mac", "switch to macOS" |
|
||||
|
||||
After matching, briefly confirm the switch in one short line ("ок, теперь под линукс" / "got it, switching to Linux") so the user knows the change took. Don't lecture — one line is enough.
|
||||
|
||||
## What to apply the active platform to
|
||||
|
||||
This rule governs **what you show the user** — chat command snippets, README quick-start sections, install instructions, any line they'll copy and paste. It does **not** govern your own tool calls: those follow the harness's `Shell:` line, which is what actually runs in this environment. The two are decoupled on purpose — the harness might be running git-bash on a Windows machine, but you should still hand the user PowerShell commands because that's their daily shell.
|
||||
|
||||
## Per-platform conventions
|
||||
|
||||
### Windows / PowerShell
|
||||
|
||||
- **Shell**: PowerShell. Show `pwsh` (PowerShell 7) when offering install instructions; assume `powershell` (5.1) is the floor for compatibility notes.
|
||||
- **Chaining**: `;` for sequential. PS 5.1 has no `&&`/`||` — use `if ($?) { B }` for "B only if A succeeded". Don't write `A && B` for Windows users on the assumption it works.
|
||||
- **Paths**: backslashes in user-facing examples (`C:\Users\…`, `~\.claude\skills\`). Forward slashes only inside code that runs in bash/git-bash.
|
||||
- **Env vars**: `$env:NAME = "value"` for set, `$env:NAME` for read. Not `export`.
|
||||
- **Common idioms**: `Invoke-WebRequest` (`iwr`), `Test-Path`, `New-Item`, `Get-ChildItem` (`ls`), `Get-Content` (`cat`), `Remove-Item` (`rm`).
|
||||
- **Install scripts**: in repos with both variants, prefer the `.ps1`. Example: `pwsh scripts/install.ps1`, not `bash scripts/install.sh`.
|
||||
- **Stop-parsing**: for arguments containing `-`/`@` that PS would mis-parse, use `--%`.
|
||||
|
||||
### Linux / bash
|
||||
|
||||
- **Shell**: bash. POSIX-friendly syntax.
|
||||
- **Chaining**: `&&`, `||`, `|` work as expected.
|
||||
- **Paths**: forward slashes (`~/.claude/skills/`, `/var/log/...`).
|
||||
- **Env vars**: `export NAME=value`.
|
||||
- **Install scripts**: `bash scripts/install.sh`.
|
||||
- **Coreutils**: GNU flavor — `sed -i 's/x/y/'`, `readlink -f`, `cp -a`.
|
||||
|
||||
### macOS / zsh
|
||||
|
||||
zsh is the default shell since Catalina. Mostly the same as Linux, with a few divergences worth flagging when relevant:
|
||||
|
||||
- **Package manager**: `brew install …` (Homebrew).
|
||||
- **BSD coreutils**: `sed -i '' 's/x/y/'` (the empty `''` after `-i` is required), `greadlink` instead of `readlink -f`, no `cp -a`.
|
||||
- **Paths**: `~/Library/...` rather than XDG-style.
|
||||
|
||||
## Cross-platform docs (READMEs in repos that target multiple OSes)
|
||||
|
||||
When writing user-facing docs in a repo that is *explicitly* cross-platform — like this `claude-skills` repo — show both PowerShell and bash variants. List the active platform's variant first, the other second. Tag each fenced block clearly:
|
||||
|
||||
````markdown
|
||||
**Windows (PowerShell):**
|
||||
```powershell
|
||||
pwsh scripts/install.ps1
|
||||
```
|
||||
|
||||
**Linux / macOS (bash):**
|
||||
```bash
|
||||
bash scripts/install.sh
|
||||
```
|
||||
````
|
||||
|
||||
This is a docs-level decision, independent of the active platform — both blocks ship together.
|
||||
|
||||
## Per-question overrides (don't change the session)
|
||||
|
||||
If the user asks about a *specific other machine* in a single question — e.g. "how would I run this on the prod box, which is Ubuntu", "что это будет на маке" — answer that one in the named platform's shell, but do **not** flip the session-wide active platform. The trigger phrases above are deliberately phrased as "we're on …" / "мы на …" because they imply *the workstation we're now using together*, not "tell me what this looks like elsewhere".
|
||||
|
||||
## Ambiguity policy
|
||||
|
||||
- No signal in the conversation → use the default (Windows).
|
||||
- Conflicting signals (e.g., user said "we're on Linux" earlier, but now asks an OS-specific question that contradicts) → trust the most recent explicit trigger; if still unclear, ask one short question.
|
||||
- Unknown platform names ("BSD?", "WSL?") → treat WSL as Linux; for anything genuinely unfamiliar, ask.
|
||||
117
dist-hermes/software-development/project-bootstrap/README.md
Normal file
117
dist-hermes/software-development/project-bootstrap/README.md
Normal file
@@ -0,0 +1,117 @@
|
||||
# project-bootstrap
|
||||
|
||||
Initializes or upgrades a project workspace in one pass: git, `.gitignore`,
|
||||
`README.md`, `.wiki/` (Karpathy's LLM Wiki layout), `.tasks/` (per-task board),
|
||||
and `CLAUDE.md` with skill triggers.
|
||||
|
||||
Operates in two modes, picked automatically:
|
||||
|
||||
- **init** — empty or near-empty folder. Creates everything from scratch.
|
||||
- **upgrade** — existing project. Detects what's already there, only fills the
|
||||
gaps. Never overwrites without explicit confirmation.
|
||||
|
||||
## When it triggers
|
||||
|
||||
The skill auto-activates on phrases like:
|
||||
|
||||
- "initialize project", "bootstrap", "setup project"
|
||||
- "upgrade project", "add wiki", "add tasks"
|
||||
- "start project", "set everything up"
|
||||
- "let's start a project", "init"
|
||||
|
||||
It also triggers when an agent is launched in a fresh folder that the user
|
||||
clearly intends to turn into a workspace.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
`project-bootstrap` does not lay out `.wiki/` or `.tasks/` by itself — it
|
||||
delegates to two companion skills, which must be installed on the machine
|
||||
running it:
|
||||
|
||||
- [`setup-wiki`](../setup-wiki/) — creates the canonical `.wiki/` layout.
|
||||
- [`setup-tasks`](../setup-tasks/) — creates the canonical `.tasks/` layout.
|
||||
|
||||
If either is missing, `project-bootstrap` stops with a clear error rather
|
||||
than falling back to ad-hoc creation. This keeps layout drift between
|
||||
projects bootstrapped at different times debuggable.
|
||||
|
||||
## What it creates
|
||||
|
||||
| Path | Source | Notes |
|
||||
|---|---|---|
|
||||
| `.git/` | `git init` | Skipped if repo already initialized. |
|
||||
| `.gitignore` | `assets/.gitignore.template` | Skipped if file exists. |
|
||||
| `README.md` | minimal stub | Skipped if file exists. |
|
||||
| `.wiki/` | delegated to `setup-wiki` | Karpathy LLM Wiki layout — `CLAUDE.md`, `index.md`, `log.md`, `overview.md`, `raw/`, `entities/`, `concepts/`, `packages/`, `sources/`. |
|
||||
| `.tasks/` | delegated to `setup-tasks` | Canonical board — `STATUS.md` plus per-task `<task-slug>.md` files. |
|
||||
| `CLAUDE.md` | `assets/CLAUDE.md.template` | Skill triggers (`use superpowers`, `use project wiki`, etc.). On non-Windows hosts, swap the `we're on Windows` line for `we're on Linux` / `we're on macOS`. On upgrade, the template is treated as a canonical set and merged idempotently — only missing trigger lines are appended after user confirm. Re-runs are no-ops. |
|
||||
| `.wiki/concepts/bootstrap-manifest.md` | generated | Records which skill versions initialized the project, so cross-project layout drift is debuggable. |
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Detect mode.** Inspect the current directory — git, `.wiki/`, `.tasks/`,
|
||||
`CLAUDE.md`, `README.md` — and print a single summary block: what was
|
||||
found, what will be created, what will be skipped.
|
||||
2. **Confirm.** One question, one confirmation. Nothing is written before the
|
||||
user agrees.
|
||||
3. **Steps 1–5.** Create or skip each piece in order — git, README, `.wiki/`,
|
||||
`.tasks/`, `CLAUDE.md`. Steps 3 and 4 delegate to the setup-skills.
|
||||
4. **Step 5.5.** Write `bootstrap-manifest.md` recording the versions of
|
||||
`project-bootstrap`, `setup-wiki`, `setup-tasks`, `project-discipline`,
|
||||
`setup-interns`, and `using-interns` used.
|
||||
5. **Step 5.6.** Skill dependencies check. Walk the canonical trigger list
|
||||
in `CLAUDE.md`, look each up in an embedded `trigger → fulfiller` map,
|
||||
detect what's missing on this host (`~/.claude/skills/<name>/SKILL.md`
|
||||
for skills, `~/.claude/plugins/installed_plugins.json` for plugins),
|
||||
and print one chat-only block listing every missing fulfiller with a
|
||||
copy-pasteable install command. Prints a single ✅ line when nothing
|
||||
is missing. Never auto-installs, never modifies project files.
|
||||
6. **Commit.** `chore: bootstrap project structure` for fresh repos, or
|
||||
`chore: upgrade project structure` adding only the new files for existing
|
||||
ones. Pushes only on explicit user request.
|
||||
7. **Summary.** Final report — what was created, what was skipped, suggested
|
||||
next step.
|
||||
|
||||
## Rules
|
||||
|
||||
- Never overwrite an existing file without explicit user confirmation.
|
||||
- Always show the plan before touching the filesystem.
|
||||
- Never invent project details — read what's already there.
|
||||
- Commit only files just created — never touch the rest of the tree.
|
||||
- Push only after the user explicitly says so.
|
||||
|
||||
## Install
|
||||
|
||||
From the repo root:
|
||||
|
||||
**Windows (PowerShell):**
|
||||
|
||||
```powershell
|
||||
bash scripts/install.sh project-bootstrap
|
||||
```
|
||||
|
||||
**Linux / macOS (bash):**
|
||||
|
||||
```bash
|
||||
bash scripts/install.sh project-bootstrap
|
||||
```
|
||||
|
||||
`install.sh` works on Windows under git-bash. A native `install.ps1` is
|
||||
[planned](../../.tasks/STATUS.md) but not required.
|
||||
|
||||
The skill installs to `~/.claude/skills/project-bootstrap/`. Override the
|
||||
target with `CLAUDE_SKILLS_DIR=/path bash scripts/install.sh …`.
|
||||
|
||||
## See also
|
||||
|
||||
- [`setup-wiki`](../setup-wiki/) — companion, owns `.wiki/` layout.
|
||||
- [`setup-tasks`](../setup-tasks/) — companion, owns `.tasks/` layout.
|
||||
- [`using-wiki`](../using-wiki/) — runtime policy for working with `.wiki/`.
|
||||
- [`using-tasks`](../using-tasks/) — runtime policy for working with `.tasks/`.
|
||||
- [`project-discipline`](../project-discipline/) — cross-project rules
|
||||
activated by the `follow project discipline` trigger.
|
||||
- [`setup-interns`](../setup-interns/), [`using-interns`](../using-interns/) —
|
||||
pair behind the `delegate to interns when allowed` trigger; cheap-LLM
|
||||
delegation under a per-session permission grant.
|
||||
- Karpathy's LLM Wiki gist:
|
||||
<https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f>
|
||||
641
dist-hermes/software-development/project-bootstrap/SKILL.md
Normal file
641
dist-hermes/software-development/project-bootstrap/SKILL.md
Normal file
@@ -0,0 +1,641 @@
|
||||
---
|
||||
name: project-bootstrap
|
||||
version: 1.12.0
|
||||
description: >
|
||||
Initializes or upgrades a project in the current folder: git, .gitignore, README.md,
|
||||
.wiki/ using Karpathy's method, .tasks/ for task tracking, CLAUDE.md with skill triggers.
|
||||
Creates remote Gitea repo and syncs projects-meta cache for greenfield projects.
|
||||
Use this skill when the user says "initialize project", "bootstrap", "setup project",
|
||||
"upgrade project", "add wiki", "add tasks", "start project", "set everything up",
|
||||
"create new project", or launches the agent in a new folder and wants a full setup.
|
||||
Trigger even if the user just says "let's start a project" or "set it all up".
|
||||
---
|
||||
|
||||
# Project Bootstrap
|
||||
|
||||
Sets up a complete working environment for a monorepo project in one pass.
|
||||
Operates in three modes: **greenfield-full** (new project + remote create), **add-remote**
|
||||
(existing git without remote), and **upgrade** (existing project).
|
||||
|
||||
---
|
||||
|
||||
## Step 0 — Detect mode
|
||||
|
||||
Check what already exists in the current directory:
|
||||
|
||||
```bash
|
||||
ls -la
|
||||
git rev-parse --git-dir 2>/dev/null && echo "git:yes" || echo "git:no"
|
||||
git remote get-url origin 2>/dev/null && echo "remote:yes" || echo "remote:no"
|
||||
ls -A 2>/dev/null | grep -q . && echo "empty:no" || echo "empty:yes"
|
||||
[ -d .wiki ] && echo "wiki:yes" || echo "wiki:no"
|
||||
[ -d .tasks ] && echo "tasks:yes" || echo "tasks:no"
|
||||
[ -f CLAUDE.md ] && echo "claude:yes" || echo "claude:no"
|
||||
[ -f README.md ] && echo "readme:yes" || echo "readme:no"
|
||||
```
|
||||
|
||||
Determine mode:
|
||||
- **greenfield-full**: `git:no` + `empty:yes` — new project, will create remote
|
||||
- **add-remote**: `git:yes` + `remote:no` — existing git, offer to create remote
|
||||
- **upgrade**: otherwise — existing project, upgrade only
|
||||
|
||||
Show the user a summary in one block — what was found, what will be created:
|
||||
|
||||
```
|
||||
Mode: greenfield-full (new project + remote create)
|
||||
|
||||
Found: (empty directory)
|
||||
Create: git .wiki .tasks CLAUDE.md .gitignore README.md remote
|
||||
```
|
||||
|
||||
Ask one question: "Looks right? Shall we proceed?" — and wait for confirmation.
|
||||
**Create nothing before confirmation.**
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Git
|
||||
|
||||
If git is not initialized:
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
### `.gitignore`
|
||||
|
||||
The template `assets/.gitignore.template` contains two parts:
|
||||
|
||||
1. Standard ignore rules (deps, build, env, IDE, OS, logs).
|
||||
2. **Meta-isolation block** — `!`-inversions for `.claude/`, `.tasks/`, `.wiki/`,
|
||||
`.brainstorm/`, `.archive/`, `.mcp/`, `.mcp.json`, `MEMORY.md`. This block
|
||||
re-enables tracking of agent meta-paths in **own** repos against the
|
||||
global `core.excludesFile` rule (`~/.config/git/ignore`) that hides them
|
||||
from forks of upstream open-source. Without it, the `.tasks/`, `.wiki/`,
|
||||
and `.claude/` directories created by Steps 3-5 would be invisible to git
|
||||
on machines where the global excludesFile is configured, and the first
|
||||
commit would be empty of agent obvyaska. Full design: workshop wiki
|
||||
`concepts/meta-out-of-repo.md` (sections "Слой 2" and "Новые проекты").
|
||||
|
||||
Two cases:
|
||||
|
||||
- **`.gitignore` does not exist** — create from `assets/.gitignore.template`
|
||||
(block included unconditionally).
|
||||
- **`.gitignore` exists** — check for the marker line
|
||||
`# AI обвеска — слой 2:` (substring match, case-sensitive). If absent →
|
||||
append the meta-isolation block (with the marker comment) to the end of
|
||||
the file, prefixed by a blank line if the file does not already end with
|
||||
one. If present → leave the file untouched.
|
||||
|
||||
The block is **scoped to own projects**. The bootstrap skill currently has no
|
||||
fork-of-upstream mode (greenfield-full creates a brand-new Gitea repo;
|
||||
add-remote and upgrade operate on the user's own repos), so the block is
|
||||
applied unconditionally in all current modes. If a fork-bootstrap mode is
|
||||
ever added, the block must be **omitted** there — putting `!.claude/` etc.
|
||||
into a fork's `.gitignore` would diverge from upstream's ignore rules.
|
||||
|
||||
---
|
||||
|
||||
## Step 1.5 — Remote create (greenfield-full / add-remote modes)
|
||||
|
||||
Only in **greenfield-full** or **add-remote** mode. Skip for upgrade mode.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Read `~/.config/projects-mcp/auth.toml` to get Gitea credentials:
|
||||
|
||||
```bash
|
||||
# POSIX (Linux/macOS/git-bash):
|
||||
source ~/.config/projects-mcp/auth.toml 2>/dev/null || true
|
||||
# Windows PowerShell:
|
||||
Get-Content ~/.config/projects-mcp/auth.toml | Select-String "base_url|token"
|
||||
```
|
||||
|
||||
If auth file missing → stop and tell user: run `/setup-projects-meta` first.
|
||||
|
||||
### Validate project name
|
||||
|
||||
Current folder name becomes the repo name. Must be:
|
||||
- **Latin only** — a-z, 0-9, hyphens
|
||||
- **kebab-case** — lowercase, hyphens between words
|
||||
- **Not a duplicate** — check via Gitea API
|
||||
|
||||
```bash
|
||||
PROJECT_NAME=$(basename "$PWD")
|
||||
# Validate: only latin alnum + hyphen, no leading/trailing hyphen
|
||||
echo "$PROJECT_NAME" | grep -qE '^[a-z0-9]+(-[a-z0-9]+)*$' || {
|
||||
echo "❌ Invalid project name: '$PROJECT_NAME'. Use latin kebab-case (e.g. 'my-project')."
|
||||
exit 1
|
||||
}
|
||||
```
|
||||
|
||||
### Create repo via Gitea API
|
||||
|
||||
```bash
|
||||
# Extract base_url and token from auth.toml (POSIX):
|
||||
BASE_URL=$(grep "^base_url" ~/.config/projects-mcp/auth.toml | cut -d'"' -f2)
|
||||
TOKEN=$(grep "^token" ~/.config/projects-mcp/auth.toml | cut -d'"' -f2)
|
||||
|
||||
# Create repo:
|
||||
curl -X POST "$BASE_URL/api/v1/user/repos?token=$TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "{\"name\":\"$PROJECT_NAME\",\"private\":false,\"auto_init\":false}"
|
||||
```
|
||||
|
||||
On failure → stop and show error. Duplicate name = suggest rename or delete existing.
|
||||
|
||||
### Add remote and push
|
||||
|
||||
```bash
|
||||
git remote add origin "$BASE_URL/$USER/$PROJECT_NAME.git"
|
||||
git branch -M master
|
||||
git push -u origin master
|
||||
```
|
||||
|
||||
For **add-remote** mode (git exists, push local commits after adding remote):
|
||||
```bash
|
||||
git push -u origin master # or main if that's the current branch
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — README.md
|
||||
|
||||
If it does not exist — create a minimal one:
|
||||
|
||||
```markdown
|
||||
# <project folder name>
|
||||
|
||||
## About
|
||||
<!-- Describe the project here -->
|
||||
|
||||
## Quick start
|
||||
<!-- Instructions for running the project -->
|
||||
```
|
||||
|
||||
If it exists — leave it untouched.
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — .wiki/
|
||||
|
||||
**Delegate to the `setup-wiki` skill.** It handles greenfield creation, canon migration, and the no-op case (already canon) uniformly, with its own confirmation gate. Don't recreate the layout inline here — that's how drift happens.
|
||||
|
||||
If `setup-wiki` is not installed on this machine, **stop** and tell the user: project-bootstrap requires `setup-wiki` (and `setup-tasks`) installed. Don't fall back to ad-hoc creation.
|
||||
|
||||
**Reference (for context only — `setup-wiki` is the source of truth):** the canonical layout per Karpathy (gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) and `using-wiki`:
|
||||
|
||||
```
|
||||
.wiki/
|
||||
CLAUDE.md ← schema: project-specific wiki conventions
|
||||
index.md ← catalog of all pages (by type), updated on every ingest
|
||||
log.md ← append-only op log: ## [YYYY-MM-DD] op | desc
|
||||
overview.md ← single human-readable project overview
|
||||
raw/
|
||||
README.md ← raw/ is immutable; this file documents that
|
||||
entities/ ← entity pages (people, services, modules) — empty .gitkeep
|
||||
concepts/ ← concept / design decision pages — empty .gitkeep
|
||||
packages/ ← package pages — empty .gitkeep
|
||||
sources/ ← one summary per ingested source — empty .gitkeep
|
||||
```
|
||||
|
||||
Page-level workflow (ingest, query, lint) and file formats are owned by the
|
||||
`wiki-maintainer` skill. Bootstrap only lays the skeleton; the skill takes
|
||||
over from there.
|
||||
|
||||
### `.wiki/CLAUDE.md` (schema)
|
||||
|
||||
```markdown
|
||||
# Wiki Schema — <project name>
|
||||
|
||||
Project-specific wiki conventions. Read this before any wiki operation.
|
||||
|
||||
This wiki follows Karpathy's LLM Wiki pattern:
|
||||
**https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f**
|
||||
|
||||
The `wiki-maintainer` skill enforces the workflow and file formats. This
|
||||
file overrides the skill where they conflict.
|
||||
|
||||
## Page types
|
||||
|
||||
- `entities/` — discrete things the project tracks (people, services, modules).
|
||||
- `concepts/` — recurring ideas, design decisions, gotchas.
|
||||
- `packages/` — code packages this project produces or consumes.
|
||||
- `sources/` — one summary page per ingested external doc; frontmatter carries `ingested:` and `raw_path:`.
|
||||
- `overview.md` — single project-wide overview.
|
||||
|
||||
## Naming
|
||||
|
||||
- `kebab-case.md`, **Latin only**. Transliterate Cyrillic in filenames; keep the original title in the H1 + frontmatter.
|
||||
|
||||
## Domain conventions
|
||||
|
||||
<!-- Fill in as the project takes shape — what counts as an entity here, which packages exist, naming idioms specific to this codebase. -->
|
||||
```
|
||||
|
||||
### `.wiki/index.md`
|
||||
|
||||
```markdown
|
||||
# Wiki Index
|
||||
|
||||
Catalog of all wiki pages. One line per page, organized by type. The agent updates this on every ingest.
|
||||
|
||||
## Overview
|
||||
|
||||
- [overview.md](overview.md) — project overview
|
||||
|
||||
## Entities
|
||||
|
||||
<!-- (none yet) -->
|
||||
|
||||
## Concepts
|
||||
|
||||
<!-- (none yet) -->
|
||||
|
||||
## Packages
|
||||
|
||||
<!-- (none yet) -->
|
||||
|
||||
## Sources
|
||||
|
||||
<!-- (none yet) -->
|
||||
```
|
||||
|
||||
### `.wiki/log.md`
|
||||
|
||||
```markdown
|
||||
# Wiki Log
|
||||
|
||||
Append-only operation log. One entry per operation. Format:
|
||||
|
||||
\`\`\`
|
||||
## [YYYY-MM-DD] <op> | <one-line description>
|
||||
\`\`\`
|
||||
|
||||
Operations: `init`, `ingest`, `query`, `lint`, `refactor`, `decision`.
|
||||
|
||||
Parseable: `grep "^## \[" .wiki/log.md | tail -20`.
|
||||
|
||||
---
|
||||
|
||||
## [<today's date>] init | bootstrap empty wiki via project-bootstrap
|
||||
```
|
||||
|
||||
### `.wiki/overview.md`
|
||||
|
||||
```markdown
|
||||
# <project name> — overview
|
||||
|
||||
<!-- Replace with a high-level description: what this project does, who it's for, the main components. -->
|
||||
```
|
||||
|
||||
### `.wiki/raw/README.md`
|
||||
|
||||
```markdown
|
||||
# Raw Sources
|
||||
|
||||
**Immutable.** Read, never edit. The only allowed modification is appending a `> Status:` blockquote when the user explicitly asks for a status audit.
|
||||
|
||||
Place raw inputs here — articles, transcripts, PDFs, screenshots — exactly as they came in. The agent reads from `raw/`, writes summaries into `../sources/`, and never modifies raw files.
|
||||
|
||||
For large or path-sensitive sources that live outside the repo, register them here:
|
||||
|
||||
\`\`\`
|
||||
- short-name → /absolute/path/to/source
|
||||
\`\`\`
|
||||
```
|
||||
|
||||
The empty subdirectories (`entities/`, `concepts/`, `packages/`, `sources/`)
|
||||
each get a `.gitkeep` so git tracks them.
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — .tasks/
|
||||
|
||||
**Delegate to the `setup-tasks` skill.** It handles greenfield creation, migration from flat STATUS.md, and the no-op case uniformly, with its own confirmation gate. Don't recreate the layout inline.
|
||||
|
||||
If `setup-tasks` is not installed, **stop** and tell the user — same rule as Step 3.
|
||||
|
||||
**Reference (for context only — `setup-tasks` is the source of truth):** the canonical layout is `.tasks/STATUS.md` (the board, with emoji status 🔴/🟡/⚪/🟢/🔵) plus `.tasks/<task-slug>.md` per active or paused task. The full pattern is documented in this repo at `.wiki/raw/setup-task-status-wiki.md`.
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — CLAUDE.md
|
||||
|
||||
Two paths, picked by file presence:
|
||||
|
||||
### Init (file does not exist)
|
||||
|
||||
Create `CLAUDE.md` from `assets/CLAUDE.md.template`. Substitute the platform line
|
||||
on non-Windows hosts (`we're on Linux` / `we're on macOS` instead of
|
||||
`we're on Windows`).
|
||||
|
||||
### Upgrade (file exists) — idempotent merge
|
||||
|
||||
Treat the template as the canonical trigger set and reconcile the existing file
|
||||
against it. Re-runs are no-ops once the file is in canon.
|
||||
|
||||
1. Read the existing `CLAUDE.md`.
|
||||
2. For each non-empty, non-comment line in the template, decide whether it's
|
||||
already present:
|
||||
- **Trigger lines** (everything except the platform line) — present iff any
|
||||
existing line, after `trim` + `tolower`, contains the template line's
|
||||
trigger text. Substring match, not equality — tolerates user rewording or
|
||||
trailing punctuation.
|
||||
- **Platform line** (`we're on Windows`) — present iff any existing line
|
||||
matches `we're on (windows|linux|macos)` case-insensitively. If the user
|
||||
pinned a different platform on purpose, **leave it alone**. Only append
|
||||
the host-appropriate platform line when none of the three is present.
|
||||
3. Collect missing lines. If none → print `CLAUDE.md already canon — no changes`
|
||||
and skip to Step 5.5.
|
||||
4. Show the user the diff (N lines, exact text to append) and ask one question:
|
||||
"Append these N missing canonical triggers to the end of CLAUDE.md?" Wait
|
||||
for explicit confirmation before writing.
|
||||
5. On confirm: append a single newline (if the file doesn't end with one) and
|
||||
then the missing lines, one per line. Don't rewrite the file — only append.
|
||||
Don't reorder existing lines. Don't dedupe within the existing file.
|
||||
|
||||
Template contents (`assets/CLAUDE.md.template` — source of truth):
|
||||
|
||||
```markdown
|
||||
# CLAUDE.md
|
||||
# Agent instructions. Each line is a trigger for an installed skill.
|
||||
|
||||
talk like a caveman
|
||||
use superpowers
|
||||
use project wiki
|
||||
use task management system
|
||||
check across all projects
|
||||
pull remote before work
|
||||
follow project discipline
|
||||
follow tdd-criteria
|
||||
delegate to interns when allowed
|
||||
recommend, don't menu
|
||||
we're on Windows
|
||||
```
|
||||
|
||||
The `check across all projects` line activates the `using-projects-meta` skill
|
||||
so cross-project task aggregation and the shared `projects-wiki` are available
|
||||
without an explicit verbal trigger. The skill is a no-op until the
|
||||
`projects-meta-mcp` server is registered — install via `setup-projects-meta`
|
||||
on a fresh machine if `mcp__projects-meta__*` tools are missing.
|
||||
|
||||
The `pull remote before work` line activates the `pulling-before-work` skill,
|
||||
which runs one `git pull --ff-only` at session start (and on explicit re-sync
|
||||
requests like "sync"). It's a no-op outside git repos and skips with a one-line
|
||||
warning if the working tree is dirty, HEAD is detached, or the branch has no
|
||||
upstream — never auto-merges, stashes, or pushes. Install the skill on the host
|
||||
if `pulling-before-work` is not in `~/.claude/skills/`; otherwise the trigger is
|
||||
silently dead like any other absent skill.
|
||||
|
||||
The `follow project discipline` line activates the `project-discipline` skill,
|
||||
which codifies four cross-project rules: (1) project CLAUDE.md / .wiki/CLAUDE.md
|
||||
/ .tasks/ override defaults from any other skill; (2) all work on master/main,
|
||||
no feature branches without explicit user approval; (3) version bump on every
|
||||
edit of versioned artifacts per semver, recorded in commit; (4) commit freely,
|
||||
push only after explicit per-session approval. Install the skill on the host
|
||||
if `project-discipline` is not in `~/.claude/skills/`; otherwise the trigger is
|
||||
silently dead like any other absent skill.
|
||||
|
||||
The `follow tdd-criteria` line activates the `tdd-criteria` skill, which enforces
|
||||
test-driven development by default with four bright-line carve-outs (visual CSS,
|
||||
spike exploration, oneshot scripts, pure wrappers) and four anti-loophole rules
|
||||
(including test-immutability: modifying assertions requires a `[test-modify: ...]`
|
||||
marker in the commit subject). Full rationale at `.wiki/concepts/tdd-criteria-design.md`
|
||||
in the `claude-skills` repo. Install the skill on the host if `tdd-criteria` is not
|
||||
in `~/.claude/skills/`; otherwise the trigger is silently dead like any other absent skill.
|
||||
|
||||
The `delegate to interns when allowed` line activates the `using-interns` skill,
|
||||
which lets Claude offload predictable bulk I/O and summarization tasks
|
||||
(reading 3+ files, distilling long transcripts) to cheap intern LLMs via the
|
||||
local `interns` MCP server (`mcp__interns__bulk_text_read`,
|
||||
`mcp__interns__transcript_distill`, etc.) — saves Anthropic quota at ~125× the
|
||||
per-call cost reduction on bulk reads. Per-session permission grant mirrors
|
||||
`project-discipline` Rule 4: ask-mode default, conversational grant / revoke,
|
||||
always-ask paths for `.env` / secrets / keys / SSH credentials even with an
|
||||
active grant, session-end reset. The skill is a no-op until the `interns` MCP
|
||||
server is registered — install via `setup-interns` on a fresh machine if
|
||||
`mcp__interns__*` tools are missing. Full design at
|
||||
`.wiki/concepts/interns-design.md` in the `claude-skills` repo.
|
||||
|
||||
The `recommend, don't menu` line activates the `recommend-dont-menu` skill,
|
||||
which overrides the default `superpowers:brainstorming` behavior: in design
|
||||
discussions, architecture reviews, or "what should we do" questions, the agent
|
||||
gives **one argued recommendation with explicit trade-offs**, not a multiple-
|
||||
choice menu. User instructions always take precedence over skill defaults.
|
||||
Install the skill on the host if `recommend-dont-menu` is not in `~/.claude/skills/`;
|
||||
otherwise the trigger is silently dead like any other absent skill.
|
||||
|
||||
The `we're on Windows` line activates the `active-platform` skill and pins the
|
||||
project's default platform to Windows / PowerShell — so generated commands and
|
||||
README quick-starts use PS-native syntax. Bootstrapping on a Linux or macOS
|
||||
host? Substitute `we're on Linux` or `we're on macOS` instead.
|
||||
|
||||
---
|
||||
|
||||
## Step 5.5 — Bootstrap manifest
|
||||
|
||||
Write `.wiki/concepts/bootstrap-manifest.md`. The manifest records which skills (and at which versions) initialized this project's `.wiki/` and `.tasks/` layout, so layout drift between projects bootstrapped at different times is debuggable.
|
||||
|
||||
Read each delegated skill's `SKILL.md` frontmatter to pick up the live `version:` value (don't hardcode):
|
||||
|
||||
```markdown
|
||||
---
|
||||
title: Bootstrap Manifest
|
||||
type: concept
|
||||
updated: <today's date>
|
||||
generator: project-bootstrap@<version>
|
||||
---
|
||||
|
||||
# Bootstrap Manifest
|
||||
|
||||
Skills used to initialize this project's `.wiki/` and `.tasks/` layout, with their versions at install time.
|
||||
|
||||
| Skill | Version | Role |
|
||||
|---|---|---|
|
||||
| `project-bootstrap` | <version> | orchestrator |
|
||||
| `setup-wiki` | <version> | wiki canonical layout |
|
||||
| `setup-tasks` | <version> | tasks canonical layout |
|
||||
| `project-discipline` | <version> | cross-project policy |
|
||||
| `setup-interns` | <version> | interns MCP server install (one-time, per machine) |
|
||||
| `using-interns` | <version> | interns runtime policy + per-session permission grant |
|
||||
|
||||
This file is overwritten if `project-bootstrap` is re-run on the same project. For history, use `git log .wiki/concepts/bootstrap-manifest.md`.
|
||||
```
|
||||
|
||||
If a delegated setup-skill is unavailable on this machine (e.g. user installed only a subset), record the missing skill as `unknown` in the version column so the gap is visible.
|
||||
|
||||
---
|
||||
|
||||
## Step 5.6 — Skill dependencies check (chat-only, never auto-install)
|
||||
|
||||
The `CLAUDE.md` template just written contains canonical trigger lines.
|
||||
Each one is a no-op unless the corresponding skill or plugin is installed
|
||||
on the host. On a fresh machine these are often absent, and the user
|
||||
won't know the trigger is silently dead. Detect what's missing on this
|
||||
machine and print one informational block in chat — never write into any
|
||||
project file, never auto-install.
|
||||
|
||||
### Trigger → fulfiller map
|
||||
|
||||
Source of truth for this map is the canonical `assets/CLAUDE.md.template`.
|
||||
When a new trigger is added there, also add a row here in the same commit.
|
||||
Mismatch between template and map → silent gaps in the recommendation.
|
||||
|
||||
| Trigger line in `CLAUDE.md` | Fulfiller | Kind | Detection path | Install command |
|
||||
|---|---|---|---|---|
|
||||
| `talk like a caveman` | `caveman` | skill | `~/.claude/skills/caveman/SKILL.md` | `bash scripts/install.sh caveman` |
|
||||
| `use superpowers` | `superpowers@claude-plugins-official` | plugin | key `plugins["superpowers@claude-plugins-official"]` in `~/.claude/plugins/installed_plugins.json` | `/plugin install superpowers@claude-plugins-official` |
|
||||
| `use project wiki` | `using-wiki` | skill | `~/.claude/skills/using-wiki/SKILL.md` | `bash scripts/install.sh using-wiki` |
|
||||
| `use task management system` | `using-tasks` | skill | `~/.claude/skills/using-tasks/SKILL.md` | `bash scripts/install.sh using-tasks` |
|
||||
| `check across all projects` | `using-projects-meta` | skill | `~/.claude/skills/using-projects-meta/SKILL.md` | `bash scripts/install.sh using-projects-meta` |
|
||||
| `pull remote before work` | `pulling-before-work` | skill | `~/.claude/skills/pulling-before-work/SKILL.md` | `bash scripts/install.sh pulling-before-work` |
|
||||
| `session handoff: read on start, write on end` | `session-handoff` | skill | `~/.claude/skills/session-handoff/SKILL.md` | `bash scripts/install.sh session-handoff` |
|
||||
| `follow project discipline` | `project-discipline` | skill | `~/.claude/skills/project-discipline/SKILL.md` | `bash scripts/install.sh project-discipline` |
|
||||
| `follow tdd-criteria` | `tdd-criteria` | skill | `~/.claude/skills/tdd-criteria/SKILL.md` | `bash scripts/install.sh tdd-criteria` |
|
||||
| `delegate to interns when allowed` | `using-interns` | skill | `~/.claude/skills/using-interns/SKILL.md` | `bash scripts/install.sh using-interns` |
|
||||
| `recommend, don't menu` | `recommend-dont-menu` | skill | `~/.claude/skills/recommend-dont-menu/SKILL.md` | `bash scripts/install.sh recommend-dont-menu` |
|
||||
| `we're on Windows` / `we're on Linux` / `we're on macOS` | `active-platform` | skill | `~/.claude/skills/active-platform/SKILL.md` | `bash scripts/install.sh active-platform` |
|
||||
|
||||
### Algorithm
|
||||
|
||||
1. Read the project's `CLAUDE.md` (just-written or pre-existing). Extract
|
||||
every non-empty, non-comment line — these are the active triggers for
|
||||
THIS project. The user may have removed canonical lines on purpose;
|
||||
respect that — only check what's actually in the file.
|
||||
2. Match each line against the trigger column above using `trim` + `tolower`
|
||||
substring (same matching as Step 5 idempotent merge). Lines that don't
|
||||
match any row are user-custom — skip silently. The platform line matches
|
||||
the `active-platform` row regardless of which platform is pinned.
|
||||
3. For each matched canonical line, check the detection path:
|
||||
- `kind: skill` → does `~/.claude/skills/<name>/SKILL.md` exist?
|
||||
- `kind: plugin` → does `~/.claude/plugins/installed_plugins.json` contain
|
||||
the plugin key under `plugins`? (Treat malformed JSON as "missing" and
|
||||
continue — don't crash the bootstrap over a detection edge case.)
|
||||
4. Collect every fulfiller that's missing. Two outcomes:
|
||||
|
||||
- **All present** — print one line:
|
||||
|
||||
```
|
||||
✅ all skill dependencies satisfied — every CLAUDE.md trigger has its fulfiller on this host.
|
||||
```
|
||||
|
||||
Skip to Step 6.
|
||||
|
||||
- **Some missing** — print one block in chat exactly once. Do **not**
|
||||
write it into any project file:
|
||||
|
||||
```
|
||||
ℹ️ Recommended: install the following to fulfill CLAUDE.md triggers
|
||||
|
||||
The triggers below are present in CLAUDE.md but their fulfillers are
|
||||
missing on this machine — they're silently no-ops until installed:
|
||||
|
||||
trigger fulfiller (kind)
|
||||
<trigger-line> <fulfiller> (<kind>)
|
||||
<trigger-line> <fulfiller> (<kind>)
|
||||
…
|
||||
|
||||
Install (run inside Claude Code or terminal):
|
||||
<install command 1>
|
||||
<install command 2>
|
||||
…
|
||||
|
||||
After install + (for plugins) a Claude Code restart, the triggers pick
|
||||
them up.
|
||||
```
|
||||
|
||||
### Notes
|
||||
|
||||
- **MCP-server-backed skills** (`using-context7`, `using-projects-meta`,
|
||||
`using-interns`) — only the `using-X` policy skill is checked here. If
|
||||
the MCP isn't registered, the `using-X` Prerequisites pointer fires
|
||||
`setup-X` at first use; bootstrap doesn't duplicate that detection.
|
||||
- The `~/.claude/skills/` and `~/.claude/plugins/` paths resolve identically
|
||||
on Windows / Linux / macOS — `~` works under git-bash too.
|
||||
- **Hard rule — never auto-install.** Slash commands aren't callable from a
|
||||
skill, and silently mutating user-level skill / plugin state without
|
||||
consent is overreach. The recommendation is informational. The user can
|
||||
install some / all / none of the recommendations, or remove canonical
|
||||
lines from `CLAUDE.md` to lean the project's trigger set down.
|
||||
|
||||
## Step 6 — Commit
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "chore: bootstrap project structure"
|
||||
```
|
||||
|
||||
If the repo already had commits — commit only the files just created:
|
||||
|
||||
```bash
|
||||
git add .wiki/ .tasks/ CLAUDE.md .gitignore README.md
|
||||
git commit -m "chore: upgrade project structure"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 7 — Summary
|
||||
|
||||
Print a final report:
|
||||
|
||||
```
|
||||
✅ Done! Created:
|
||||
.wiki/ — project wiki (Karpathy method)
|
||||
.tasks/ — task tracking system
|
||||
CLAUDE.md — skill triggers
|
||||
.gitignore — standard template
|
||||
README.md — starter file
|
||||
remote — Gitea repo created and pushed
|
||||
|
||||
Skipped (already existed):
|
||||
git — left untouched
|
||||
|
||||
Next step: describe the project in README.md and start your first task —
|
||||
say "use task management system".
|
||||
```
|
||||
|
||||
For **greenfield-full** mode, append to summary:
|
||||
```
|
||||
Remote: <Gitea URL>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 8 — projects-meta sync (greenfield-full mode)
|
||||
|
||||
Only in **greenfield-full** mode. Re-sync the projects-meta cache so the new
|
||||
project becomes visible to `mcp__projects-meta__*` tools.
|
||||
|
||||
```bash
|
||||
# POSIX:
|
||||
node ~/projects/.common/lib/projects-meta-mcp/dist/sync.js
|
||||
|
||||
# Windows PowerShell:
|
||||
node ~/projects/.common/lib/projects-meta-mcp/dist/sync.js
|
||||
```
|
||||
|
||||
Verify the project is now visible:
|
||||
```bash
|
||||
# Via MCP (if available in current session):
|
||||
# mcp__projects-meta__meta_status
|
||||
|
||||
# Or manually check the cache file exists:
|
||||
ls -la ~/projects/.common/lib/projects-meta-mcp/cache/projects.json
|
||||
```
|
||||
|
||||
If the sync script doesn't exist → skip with informational message:
|
||||
```
|
||||
ℹ️ projects-meta sync script not found at ~/projects/.common/lib/projects-meta-mcp/dist/sync.js
|
||||
Run /setup-projects-meta to install it. The new repo is already created in Gitea.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **Never overwrite** existing files without explicit user confirmation
|
||||
- **Always show the plan first** — one question, one confirmation
|
||||
- **Never invent details** — if the project already exists, read what's there
|
||||
- **Commit only what was just created** — do not touch the rest of the file tree
|
||||
- **Commit automatically** after each successful step, no extra questions
|
||||
- **Push only after explicit user confirmation** — ask "Push to remote?" and wait for "yes"
|
||||
@@ -0,0 +1,40 @@
|
||||
# Dependencies
|
||||
node_modules/
|
||||
.venv/
|
||||
__pycache__/
|
||||
*.pyc
|
||||
|
||||
# Build outputs
|
||||
dist/
|
||||
build/
|
||||
*.egg-info/
|
||||
|
||||
# Environment
|
||||
.env
|
||||
.env.local
|
||||
.env.*.local
|
||||
|
||||
# IDE
|
||||
.idea/
|
||||
.vscode/
|
||||
*.swp
|
||||
*.swo
|
||||
|
||||
# OS
|
||||
.DS_Store
|
||||
Thumbs.db
|
||||
|
||||
# Logs
|
||||
*.log
|
||||
logs/
|
||||
|
||||
# AI обвеска — слой 2: переопределяем глобальный ~/.config/git/ignore
|
||||
# для своих репо (см. global wiki concept meta-out-of-repo)
|
||||
!.claude/
|
||||
!.tasks/
|
||||
!.wiki/
|
||||
!.brainstorm/
|
||||
!.archive/
|
||||
!.mcp/
|
||||
!.mcp.json
|
||||
!MEMORY.md
|
||||
@@ -7,6 +7,9 @@ use project wiki
|
||||
use task management system
|
||||
check across all projects
|
||||
pull remote before work
|
||||
session handoff: read on start, write on end
|
||||
follow project discipline
|
||||
follow tdd-criteria
|
||||
delegate to interns when allowed
|
||||
recommend, don't menu
|
||||
we're on Windows
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
name: project-discipline
|
||||
version: 0.1.0
|
||||
version: 0.1.1
|
||||
description: >
|
||||
Codifies four cross-project discipline rules: (1) project CLAUDE.md /
|
||||
Codifies five cross-project discipline rules: (1) project CLAUDE.md /
|
||||
.wiki/CLAUDE.md / .tasks/ override defaults from any other skill (specs
|
||||
go to .wiki/concepts/, not docs/superpowers/specs/; tasks to .tasks/,
|
||||
not docs/superpowers/plans/); (2) all work on master/main, no feature
|
||||
@@ -12,8 +12,10 @@ description: >
|
||||
(4) commit freely, never push without explicit per-session user approval
|
||||
— grant via "разреши автопуш" / "allow auto-push", revoke via "отзови"
|
||||
/ "revoke", session end resets to ask-mode; force/delete/non-ff push
|
||||
always asks. Activated by "follow project discipline" trigger in
|
||||
CLAUDE.md (added by project-bootstrap v1.5.0+).
|
||||
always asks; (5) transit-zone / brainstorm workspaces — artifacts
|
||||
go to .brainstorm/ or global wiki only via explicit user direction,
|
||||
never auto-promote by analogy. Activated by "follow project discipline"
|
||||
trigger in CLAUDE.md (added by project-bootstrap v1.5.0+).
|
||||
---
|
||||
|
||||
# project-discipline
|
||||
@@ -107,6 +109,20 @@ A grant covers ordinary fast-forward push to the configured upstream. Anything e
|
||||
|
||||
**What counts as "push":** only `git push` family commands. Local commits, `git stash push`, etc. are not push; the grant does not apply.
|
||||
|
||||
## Rule 5 — Transit-zone / brainstorm workspaces
|
||||
|
||||
Some workspaces are **transit zones** — discussion areas with no `.tasks/`, where brainstorm artifacts are explicitly NOT auto-promoted to project wikis.
|
||||
|
||||
**Default destination for brainstorm artifacts:**
|
||||
- **In-progress brainstorm outputs** → `.brainstorm/<topic>.md` (or whatever the workspace's README/CLAUDE.md declares)
|
||||
- **Mature, cross-cutting outputs** → `~/projects/.wiki/concepts/<topic>-design.md` via `mcp__projects-meta__knowledge_ingest` — **only** when user explicitly directs this
|
||||
|
||||
**Agent must NOT auto-promote** brainstorm artifacts to global wikis by analogy with Rule 1. Convergence-moment (move from workspace to permanent wiki) is a user decision, not an automatic action.
|
||||
|
||||
**Example:** `~/projects/.meeting-room/` is a transit zone. Its CLAUDE.md explicitly states "no `.tasks/`, transit zone, artifacts go to `.brainstorm/` or global wiki via user command." Rule 1's "project conventions override" applies, but the override is explicit in the workspace contract — auto-promotion by analogy would violate that contract.
|
||||
|
||||
**When in doubt:** ask the user "this goes to `.brainstorm/`, or should I promote to shared wiki?" rather than assuming.
|
||||
|
||||
## Out of scope
|
||||
|
||||
The skill **does not**:
|
||||
90
dist-hermes/software-development/tdd-criteria/SKILL.md
Normal file
90
dist-hermes/software-development/tdd-criteria/SKILL.md
Normal file
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: tdd-criteria
|
||||
version: 0.2.0
|
||||
description: >
|
||||
TDD by default with four bright-line carve-outs. Applies before any code
|
||||
change. Triggers: "TDD", "test-driven", "следуй TDD", "use TDD",
|
||||
"should I write tests", "skip tdd", "[skip-tdd: ...]",
|
||||
"[test-modify: ...]", "tdd-criteria". Cross-agent policy — no tool refs.
|
||||
Full rationale: .wiki/concepts/tdd-criteria-design.md
|
||||
---
|
||||
|
||||
# tdd-criteria
|
||||
|
||||
> TDD by default. Skip only with a bright-line marker. Tests defend code from silent deletion; rule 4 defends tests from silent rewriting.
|
||||
|
||||
## When this runs
|
||||
|
||||
**At session start** — when `CLAUDE.md` contains the line `follow tdd-criteria`.
|
||||
|
||||
**Before any code change** — touching a `*.ts`, `*.js`, `*.py`, `*.go`, `*.rs`, `*.java`, `*.rb`, `*.ex`, `*.swift`, `*.kt`, `*.cs`, `*.php`, or similar source file triggers the decision algorithm below.
|
||||
|
||||
**On explicit reference** — when the user says "TDD", "test-driven", "следуй TDD", "use TDD", "should I write tests", "skip tdd", "tdd-criteria", or includes `[skip-tdd: ...]` or `[test-modify: ...]` in a commit subject.
|
||||
|
||||
## Default mode
|
||||
|
||||
TDD by default: write a failing test first, then write the minimum code to make it pass, then refactor. Skip only if one of four bright-line carve-outs matches and is marked in the commit subject.
|
||||
|
||||
## Decision algorithm (8 questions, top-down)
|
||||
|
||||
Walk through in order. First «yes» determines mode. All «no» → TDD by default.
|
||||
|
||||
1. **Bug fix?** → TDD (red-test first)
|
||||
2. **Consuming external contract** (SDK, REST API, foreign schema)? → TDD (contract-test)
|
||||
3. **Security / auth / money / identifiers?** → TDD
|
||||
4. **Pure logic** — function (input → output) without I/O, global state, bounded inputs? → TDD
|
||||
5. **Visual / config** — CSS, layout, design tokens, `.env.example`, prompts, wiki, README? → SKIP, `[skip-tdd: visual]`
|
||||
6. **Spike** — explicit POC «throwaway» in commit/PR/task subject? → SKIP, `[skip-tdd: spike]` + spike-survivor task if code survives
|
||||
7. **One-shot** — migration, ETL backfill, ad-hoc cleanup, runs once? → SKIP, `[skip-tdd: oneshot]`
|
||||
8. **Transit wrapper** ≤10 non-blank non-comment lines — no branching, re-export / glue? → SKIP, `[skip-tdd: wrapper]`
|
||||
|
||||
(default) → TDD
|
||||
|
||||
**Composite tasks.** A task that doesn't fit one category is composite — break it down per artefact type. The criterion applies per artefact, not per task. Example: a settings page = CSS layout `[skip-tdd: visual]` + validation logic `[TDD]` + API wrapper `[TDD]`.
|
||||
|
||||
**Refactoring** — restructuring code without changing observable behaviour, with existing tests covering it — does not require new tests. Existing tests must still pass. If refactoring introduces new behaviour, that part is subject to the decision algorithm as a separate artefact.
|
||||
|
||||
## Ironclad rules (TDD obligatory)
|
||||
|
||||
1. **Bug fix** — if there's an issue / failure log / repro, write a red-test codifying the repro. Marginal cost: 5 min. Marginal benefit: regression test forever.
|
||||
2. **Pure logic, bounded inputs** — no fixtures, no mocks, no setup. Test = input/output pair. Skipping is gratuitous.
|
||||
3. **Third-party contract** — SDK bumps change signatures silently. Contract-test pins known input → known shape. Catches break at first install, not days later.
|
||||
4. **Security / auth / money / IDs** — asymmetric blast radius: false positive ≪ false negative. TDD = insurance.
|
||||
|
||||
In all four, recovery cost from silent deletion is high. The test is the only artefact that makes deletion visible.
|
||||
|
||||
## Permissive carve-outs (skip + marker required)
|
||||
|
||||
| # | Category | Trigger | Marker |
|
||||
|---|----------|---------|--------|
|
||||
| 5 | Visual / config | CSS, layout, tokens, `.env.example`, prompts, wiki | `[skip-tdd: visual]` |
|
||||
| 6 | Spike | «POC, throwaway» in commit/PR/task subject | `[skip-tdd: spike]` |
|
||||
| 7 | One-shot | Migration, ETL, ad-hoc cleanup; runs once | `[skip-tdd: oneshot]` |
|
||||
| 8 | Wrapper | ≤10 non-blank non-comment lines, no branching, re-export / glue | `[skip-tdd: wrapper]` |
|
||||
|
||||
These are **accepted-risk zones** — you accept that an agent can vandalise without immediate signal, because recovery is cheap (eyeball next render; throwaway by contract; runs once; reconstruct ≤ delete).
|
||||
|
||||
## Anti-loophole
|
||||
|
||||
1. **Skip without category is invalid.** One of four explicit categories required — not «other reasons». No marker = violation.
|
||||
2. **Spike survivor rule.** Merged spike → same merge-commit creates `[backfill-tests-<slug>]` task (in `.tasks/` if available, otherwise a TODO comment or GitHub issue). Otherwise «spike» becomes «skipped tests forever».
|
||||
3. **Friction is the point.** `[skip-tdd: visual]` 50× in a design-system rework is irritating — that's the fence. Re-evaluate after ≥2 weeks, not before.
|
||||
4. **Tests are append-only by default.** Modifying an assertion, deleting a test, or disabling it (`it.skip`/`xit`/`@pytest.mark.skip`/`@Disabled`) requires:
|
||||
- **Marker in commit subject:** `[test-modify: <test-name>: was <X>; is <Y>; reason: <Z>]` — `<X>` and `<Y>` are **literal assertion expressions**, not paraphrased. Example: `[test-modify: validates email: was expect(isValid("a@b")).toBe(true); is expect(isValid("a@b.com")).toBe(true); reason: tightened spec to require TLD]`
|
||||
- **Separate commit from impl changes.** A commit must not modify both `*.test.*` and `src/*` files (or project-equivalents). `git log --grep '\[test-modify'` must show a clean test-only audit trail.
|
||||
- **Why literal was/is:** an agent forced to write the literal assertion publishes exactly what they're rewriting. «Updated to match new behaviour» hides everything — agents will use that whenever allowed.
|
||||
|
||||
## Cross-agent applicability
|
||||
|
||||
Pure policy — no agent-specific tool references in this body. Works on Claude, Gemini, Copilot, or any future agent. Hermes mapping: `mode: auto`, `category: software-development`, no replace-rules.
|
||||
|
||||
## Out of scope
|
||||
|
||||
- Does not enforce via git hooks (separate optional task: `tdd-criteria-precommit-hook`).
|
||||
- Does not modify project `CLAUDE.md` (that's `project-bootstrap`'s job).
|
||||
- Does not run tests.
|
||||
- Does not apply rule 4 retroactively to tests written before the rule was adopted.
|
||||
|
||||
## Why this exists
|
||||
|
||||
Tests make behaviour an invariant; without them, code is an artefact silent-deletable by agents. AND: the test itself must be defended too (rule 4) — otherwise the contract collapses back into an artefact when the agent rewrites the failing test. Full rationale: `.wiki/concepts/tdd-criteria-design.md`.
|
||||
BIN
dist/active-platform.skill
vendored
BIN
dist/active-platform.skill
vendored
Binary file not shown.
BIN
dist/brainstorming.skill
vendored
Normal file
BIN
dist/brainstorming.skill
vendored
Normal file
Binary file not shown.
BIN
dist/browser-cdp.skill
vendored
Normal file
BIN
dist/browser-cdp.skill
vendored
Normal file
Binary file not shown.
BIN
dist/browser-operator.skill
vendored
Normal file
BIN
dist/browser-operator.skill
vendored
Normal file
Binary file not shown.
BIN
dist/caveman-commit.skill
vendored
BIN
dist/caveman-commit.skill
vendored
Binary file not shown.
BIN
dist/caveman-compress.skill
vendored
BIN
dist/caveman-compress.skill
vendored
Binary file not shown.
BIN
dist/caveman-help.skill
vendored
BIN
dist/caveman-help.skill
vendored
Binary file not shown.
BIN
dist/caveman-review.skill
vendored
BIN
dist/caveman-review.skill
vendored
Binary file not shown.
BIN
dist/caveman.skill
vendored
BIN
dist/caveman.skill
vendored
Binary file not shown.
BIN
dist/code-review.skill
vendored
Normal file
BIN
dist/code-review.skill
vendored
Normal file
Binary file not shown.
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user