Add trusted tooling and leverage guidance

This commit is contained in:
Emil Shanaty
2026-10-28 00:52:18 +03:00
parent 843974a58d
commit 051c49321b
3 changed files with 38 additions and 6 deletions
+5 -2
View File
@@ -34,8 +34,11 @@ implementer + один critic обычно дают более цельный UI
baseline и явный вердикт пользователя.
7. Если лагает или выглядит хуже baseline — чинить, а не добавлять фичи.
8. Для product — один milestone за раз; следующий не начинать без приёмки.
9. Проверять prerequisites; глобальные установки/деструктив — только с разрешения.
10. Инструкции пользователя важнее скилла: попросил быстро/прототип — убрать церемонии, оставить
9. Проверять prerequisites; ставить только проверенные pinned-инструменты из официальных
источников; глобальные установки/деструктив — только с разрешения.
10. Строить переиспользуемые «руки»: harness, скрипты, фикстуры, screenshot/CLI-утилиты. Тестировать
их, документировать и держать в репозитории; неиспользуемые — удалять.
11. Инструкции пользователя важнее скилла: попросил быстро/прототип — убрать церемонии, оставить
safety и evidence.
## Что происходит
+13 -4
View File
@@ -40,9 +40,17 @@ implementer and one critic; parallel panel writers produce incoherent UI.
the baseline, fix the slice before expanding scope.
8. **One milestone at a time.** For product work, do not start M1/M2 while M0 is still rough or
explicitly “not usable”.
9. **Safety.** Check prerequisites before work; ask before global installs, destructive actions,
deployments or irreversible changes. Workers never install or touch live systems.
10. **User overrides.** Direct user instructions beat this skill. If the user asks for speed, a
9. **Safety and trusted tools.** Check prerequisites before work. Prefer existing, project-local,
pinned tools; use official package managers/registries and lockfiles. Verify the source, license,
release and checksum/signature when possible. No `curl | sh`, random binaries, unpinned “latest”
or unvetted AI-suggested packages. Ask before `sudo`, global/system installs, destructive actions,
deployments or irreversible changes. Workers never install or touch live systems; they return
`blocked` with the exact missing item.
10. **Build leverage.** If a harness, script, fixture, screenshot tool or dev utility will be reused,
build it, test it, document it and keep it in the repo. Prefer one small reliable tool over a
pile of one-off commands. A broken or untrusted tool is worse than no tool; delete tools nobody
uses.
11. **User overrides.** Direct user instructions beat this skill. If the user asks for speed, a
prototype or “just do it”, drop the ceremony — keep only the safety and evidence that still
matter.
@@ -51,7 +59,8 @@ implementer and one critic; parallel panel writers produce incoherent UI.
1. **Understand** the outcome, audience, quality bar and constraints. Ask only when the answer
changes the result.
2. **Check** the environment: toolchain, commands, services, display, credentials. If a required
item is missing and cannot be resolved safely, ask before starting.
item is missing, check whether a small project-local harness/tool can remove the blocker; install
only trusted, pinned tools. If it cannot be resolved safely, ask before starting.
3. **Plan only as much as the risk requires.** For a swarm, write a one-page brief, disjoint scopes,
frozen contracts and acceptance checks. For direct/paired work, skip the ceremony.
4. **Work.** Direct, paired or batched workers. Keep files small enough that each worker reads only
+20
View File
@@ -62,6 +62,26 @@ Do not ask "can I install dependencies?" without the exact package, scope and re
workers while the answer is pending. If the user declines, record the reduced scope and the checks
that will be `not_run`.
## Tool acquisition and trust
Build tools when they remove repeated work: a test runner, fixture generator, screenshot harness,
log parser or profiler wrapper. Keep them small, project-local, documented and tested; a tool that
nobody uses is just another dependency.
When installing something:
- prefer the existing toolchain, project-local installs and lockfiles;
- use official package managers/registries and pinned versions/commits;
- check the publisher, repository, license, release notes and checksum/signature where available;
- inspect install scripts before running them; never `curl | sh`;
- no unpinned “latest”, random binaries from chat/SEO pages, or packages whose source you cannot see;
- run untrusted tools in a disposable container/VM, without secrets or network if possible;
- global/system installs (`sudo`, `apt`, `dnf`, `brew`, global npm/pip) need explicit user approval;
- record the exact version/commit and install command in the brief or lockfile.
Workers do not install. If a worker needs a tool, it returns `blocked` with the exact command and
source; the lead verifies and installs it once.
## Record the result
Write `.swarm/prerequisites.md` and set `state.json.prerequisites` to `passed`, `needs_user`, or