boomcode 0.5.3__tar.gz → 0.5.5__tar.gz

{boomcode-0.5.3 → boomcode-0.5.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boomcode
-Version: 0.5.3
+Version: 0.5.5
 Summary: BOOMCODE — AI coding CLI for Termux. Your app, BLAM, done!
 Author: zyvo9
 License: MIT

{boomcode-0.5.3 → boomcode-0.5.5}/boomcode.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boomcode
-Version: 0.5.3
+Version: 0.5.5
 Summary: BOOMCODE — AI coding CLI for Termux. Your app, BLAM, done!
 Author: zyvo9
 License: MIT

{boomcode-0.5.3 → boomcode-0.5.5}/boomcode.egg-info/SOURCES.txt

@@ -35,6 +35,7 @@ python/boomcode/layer/scripts/patch-brand.py
 python/boomcode/layer/scripts/__pycache__/patch-brand.cpython-312.pyc
 python/boomcode/layer/skills/android-app/SKILL.md
 python/boomcode/layer/skills/api-integration/SKILL.md
+python/boomcode/layer/skills/ask-install/SKILL.md
 python/boomcode/layer/skills/bash-cli-expert/SKILL.md
 python/boomcode/layer/skills/bot-development/SKILL.md
 python/boomcode/layer/skills/clean-code-performance/SKILL.md

{boomcode-0.5.3 → boomcode-0.5.5}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "boomcode"
-version = "0.5.3"
+version = "0.5.5"
 description = "BOOMCODE — AI coding CLI for Termux. Your app, BLAM, done!"
 readme = "README.md"
 requires-python = ">=3.8"

{boomcode-0.5.3 → boomcode-0.5.5}/python/boomcode/__init__.py

@@ -6,4 +6,4 @@ hands over to the real installer (install.sh) which does everything
 else (core engine, deps, single-line live progress).
 """
 
-__version__ = "0.5.3"
+__version__ = "0.5.5"

{boomcode-0.5.3 → boomcode-0.5.5}/python/boomcode/layer/config/agent/build.md

@@ -111,6 +111,12 @@ You are text-only — you cannot see images directly. **Delegate EVERY image-vie
 
 **Never** invent image content you could not actually see. If vision fails, tell the user honestly that you could not see it.
 
+## Installs — always ask first
+If anything is missing or an install becomes needed (pkg/pip/npm/apt, downloaded
+tools — anything), follow the **ask-install** skill: tell the user what is missing
+and why in plain words, then WAIT for a yes. Never install silently; "no" means
+find another way.
+
 ## When stuck
 - Read the full error message — then decide
 - If two attempts fail: try a different approach

boomcode-0.5.5/python/boomcode/layer/skills/ask-install/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: ask-install
+description: >
+  Install guard for every task. Whenever a tool, package, library, or
+  dependency is missing — or becomes needed mid-work (pkg, pip, npm, apt,
+  curl-downloaded tools, any installer) — the AI STOPS and asks the user
+  first in plain words: what is missing, why it is needed, and "should I
+  install it?". Never install anything silently. Use on any task where
+  something needs installing or setting up.
+allowed-tools: Bash, Read, Write, Edit, AskUserQuestion, Skill
+---
+
+# ask-install
+
+Nothing gets installed behind the user's back. Ask first, always.
+
+## The rule
+
+While working, if you find something missing — or the task now needs a new
+tool/package/library — do NOT install it yourself. Instead:
+
+1. **Stop and tell the user, in three simple lines:**
+   - what is missing (name, one plain-words meaning)
+   - why it is needed for their task (one line)
+   - "Should I install it?" — plus a rough size/time estimate when known
+2. **Wait for the answer.** "No" means no — do not install; instead offer an
+   alternative path that avoids it (skip the feature, use what is already
+   there, or change approach).
+3. **On yes:** install it, then confirm in one line ("ffmpeg installed ✅ —
+   continuing"). If the install fails, show the real error honestly and
+   suggest the next step (retry, reinstall, or an alternative).
+
+## What counts as "installing" (all of these need asking)
+
+- `pkg install …` / `apt install …` / `apt-get …` (Termux/Linux packages)
+- `pip install …` / `pip3 install …` (Python libraries)
+- `npm install …` / `npx …` (Node packages)
+- downloading and running any tool via `curl`/`wget`
+- anything else that brings NEW software onto the device
+
+## Exceptions (no need to ask again)
+
+- The user already said yes for this exact thing earlier in the same session.
+- The user explicitly ordered the install themselves ("install ffmpeg").
+- Updating files inside the project, or using tools that are already
+  installed — none of that is an install.
+
+## Style
+
+Beginner-friendly, short sentences. Never blame the user or the tool;
+just say what happened and what comes next.

{boomcode-0.5.3 → boomcode-0.5.5}/python/boomcode/layer/skills/lets-scroll/SKILL.md

@@ -71,18 +71,29 @@ Ask these in plain words. Accept answers in any language. Record the answers
 3. **Look & feel** — show the options by feel, one line each (default: **clay
    diorama**; alternates in `references/prompts.md`: papercraft, glossy toy,
    claymation, neon night, photoreal). One choice for the whole site.
-4. **Camera style** — ask by feel: *"should the camera walk through the world
-   (walkthrough) or dive down into it from above (fly-through)?"*
-   - walkthrough → architecture **A** (one continuous forward take — simpler,
-     recommended)
-   - fly-through, god's-eye → architecture **B** (dive + connector clips)
-   - If they want a fixed isometric camera the whole way, that's A with the
-     locked-iso clause from `references/prompts.md`.
-5. **How many scenes?** Offer 2 / 4 / 6 (6 is the max that stays smooth).
+4. **Site type** — what kind of journey? Show these picks, one line each:
+   - **Business tour** — walk through the shop/kitchen/office like a visitor
+   - **Product showcase / review** — the camera circles and closes in on ONE
+     product from all sides, close-up details, like a video review
+   - **Story journey** — how it's made / farm-to-table / idea-to-launch
+   - **Portfolio / gallery** — one beautiful vignette per work or project
+   The pick shapes the scene list (a product showcase builds every scene
+   around the same product; a tour builds one scene per place, etc.).
+5. **Camera style** — ask by feel, one line each:
+   - **Walkthrough** — the camera walks through the world like a visitor
+     (architecture **A** — one continuous forward take; simplest, recommended)
+   - **Fly-through** — the camera dives down into the world from above
+     (architecture **B** — dive + linking clips)
+   - **Orbit showcase** — for product review: the camera circles the product,
+     sweeps around it and pushes in on details (A with orbit moves from
+     `references/prompts.md` mid-leg move library)
+   - **Postcard view** — a fixed, postcard-pretty angle on every scene,
+     almost no camera movement (A with the locked-iso clause)
+6. **How many scenes?** Offer 2 / 4 / 6 (6 is the max that stays smooth).
    Then propose the scene list from their answer to #1 — each scene gets a
    subject, a short headline idea, one-line body, 0–3 tags; the last scene is
    the hero + call-to-action. Confirm the list with the user.
-6. **Phone version?** ("should the site also have a vertical version for
+7. **Phone version?** ("should the site also have a vertical version for
    phones?") — if yes, the kit doubles the video prompts (a 9:16 copy of each)
    — say plainly that it's about twice the generating work for them.
 
@@ -92,15 +103,16 @@ Create ONE folder in the project root:
 
 ```
 lets-scroll/
-├── GUIDE.md
-├── image-01-<short-scene-name>.txt      ← picture prompt
-│   image-01-<short-scene-name>.png      ← user saves the result HERE, same name
-├── image-02-<name>.txt
-│   image-02-<name>.png
-├── video-01-<what-it-does>.txt          ← video prompt
-│   video-01-<what-it-does>.mp4
-└── video-connector-1.txt                ← only for architecture B
-    video-connector-1.mp4
+├── GUIDE.md                             ← the friendly how-to (project root level)
+└── prompts/                             ← THE prompt folder — prompts AND outputs live here
+    ├── image-01-<short-scene-name>.txt  ← picture prompt
+    │   image-01-<short-scene-name>.png  ← user saves the result HERE, same name
+    ├── image-02-<name>.txt
+    │   image-02-<name>.png
+    ├── video-01-<what-it-does>.txt      ← video prompt
+    │   video-01-<what-it-does>.mp4
+    └── video-connector-1.txt            ← only for architecture B
+        video-connector-1.mp4
 ```
 
 **Naming rules (this is the whole system):**
@@ -113,6 +125,22 @@ lets-scroll/
 - Architecture B: the same images, but videos are `video-01…` (dive into each
   scene) plus `video-connector-1…` (the linking flight between scenes).
 
+**STRONG PROMPT RULES — every prompt must be rich, specific, and self-contained.**
+A weak prompt gives a generic result and breaks the world's cohesion. Every
+prompt you write must include ALL of:
+- **Subject in detail** — what exactly is in the scene, named and described
+  (materials, colors, props, tiny details that make it feel real)
+- **Environment** — surroundings, ground, sky, background depth cues
+- **Lighting** — direction, warmth, time of day, mood of the light
+- **Camera** — angle, height, lens feel (for videos: the exact movement,
+  speed, and "no camera shake / no cuts / smooth" clauses)
+- **Style block** — the full style preamble from `references/prompts.md`
+  baked in verbatim (never "same style as before" — every file works alone)
+- **Negatives** — "no text, no watermark, no logo, no people unless asked,
+  no motion blur"
+One prompt = one full paragraph of specifics. If a prompt could describe a
+hundred different scenes, it is too weak — rewrite it.
+
 **Every prompt file starts with a marker line, then the full prompt:**
 
 ```