theslopmachine 1.0.12 → 1.0.13

package/assets/agents/slopmachine-claude.md

@@ -148,11 +148,14 @@ Do not interact with Claude through raw `claude` commands, manual tmux typing, u
 - Claude messages must read like a lead engineer talking to another engineer.
 - Use private planning only to decide the next normal Claude instruction; do not mention private planning or its existence.
 - Include what to build or fix, why it matters, the broad affected area, expected behavior, and useful verification.
+- Prompt Claude phase-by-phase and slice-by-slice. Prefer one phase, scaffold, module, or fix batch per prompt; at most combine two adjacent tightly coupled slices when separating them would create needless churn.
+- Never give Claude the whole workflow, all phases, or a full end-to-end delivery packet at once.
 - For substantial Claude turns, you may include a normal human reminder that Claude can use its own built-in subagents for bounded investigation, implementation support, or verification inside the same Claude lane. Do not frame Claude subagents as separate workflow lanes, and do not create OpenCode subagents to help Claude implement.
 - Keep ordinary issue prompts at module/product level. Avoid file/line details unless the user explicitly asks you to pass exact references.
 - Do not paste, summarize, cite, name, or mention hidden plans.
 - Do not combine original-prompt orientation, design, implementation, verification, and bugfix work into one large prompt.
 - Do not send workflow mechanics, evaluator internals, Beads state, hidden-file paths, owner-state reasoning, or negative instructions about nonexistent artifacts to Claude.
+- After each Claude completion, verify the result against the original product prompt in `./metadata.json`, `./docs/design.md`, `./docs/api-spec.md` when applicable, and owner-private `../.ai/plan.md`. If there are issues, correct through the same active Claude lane before proceeding to the next slice.
 - If you make a direct owner-side code or docs change that affects the product repo, tell the active Claude lane exactly what changed and what remains to verify.
 
 ## Claude Utility Map
@@ -193,6 +196,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Scaffold first, then proceed module by module.
 - Prompt in casual human language using only visible project context.
 - Use internal planning privately for review and module acceptance.
+- Do not send more than the current module/slice, or two adjacent tightly coupled slices, in a single Claude prompt.
 - Record Claude turns, issues, verification evidence, and module acceptance in metadata and Beads.
 - After all modules are complete, ask the same Claude lane to check the implementation against the design/API docs and provide startup commands plus expected flows.
 

package/assets/agents/slopmachine.md

@@ -127,10 +127,13 @@ All other subagent types are forbidden for owner use unless the user explicitly
 - Developer messages must read like a lead engineer talking to another engineer.
 - Use private planning only to decide the next normal implementation instruction; do not mention private planning or its existence.
 - Include what to build or fix, why it matters, the broad affected area, expected behavior, and useful verification.
+- Prompt developers phase-by-phase and slice-by-slice. Prefer one phase, scaffold, module, or fix batch per prompt; at most combine two adjacent tightly coupled slices when separating them would create needless churn.
+- Never give the developer the whole workflow, all phases, or a full end-to-end delivery packet at once.
 - Keep ordinary issue prompts at module/product level. Avoid file/line details unless the user explicitly asks you to pass exact references.
 - Do not paste, summarize, cite, name, or mention hidden plans.
 - Do not combine original-prompt orientation, design, implementation, verification, and bugfix work into one large prompt.
 - Do not send workflow mechanics, evaluator internals, Beads state, hidden-file paths, owner-state reasoning, or negative instructions about nonexistent artifacts to developers.
+- After each developer completion, verify the result against the original product prompt in `./metadata.json`, `./docs/design.md`, `./docs/api-spec.md` when applicable, and owner-private `../.ai/plan.md`. If there are issues, correct through the same active developer session before proceeding to the next slice.
 - If you make a direct owner-side code or docs change that affects the product repo, tell the active developer session exactly what changed and what remains to verify.
 
 ## Phase Model
@@ -160,6 +163,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Scaffold first, then proceed module by module.
 - Prompt in casual human language using only visible project context.
 - Use internal planning privately for review and module acceptance.
+- Do not send more than the current module/slice, or two adjacent tightly coupled slices, in a single developer prompt.
 - Record session turns, issues, verification evidence, and module acceptance in metadata and Beads.
 - After all modules are complete, ask the same session to check the implementation against the design/API docs and provide startup commands plus expected flows.
 

package/assets/skills/development-guidance/SKILL.md

@@ -20,6 +20,8 @@ Use this skill during `Phase 3: Development` before prompting the active develop
 
 Prompt like a human developer working with an AI coding assistant.
 
+Prompt one bounded slice at a time. The preferred unit is one phase-purpose, scaffold, module, work package, or fix batch. At most combine two adjacent tightly coupled slices in one prompt, and only when splitting them would make the work less coherent. Never send all phases, the full private plan, or a start-to-finish workflow packet to the developer/Claude lane.
+
 Use direct wording such as:
 - `I checked the user module and found a missing authorization test. Please add that and rerun the relevant tests.`
 - `Continue with the invoice module. Build the create/list/detail flow against the existing product contract and cover the main success and validation paths.`
@@ -29,7 +31,7 @@ Do not send robotic process language. Do not require a specific response format.
 
 Do not keep restating visible doc paths in routine follow-up prompts when the same session already knows the project contract. It is fine to say `existing product contract`, `accepted docs`, or simply name the module. Mention exact doc paths only when orienting a new session, resolving confusion, or asking for a final contract check.
 
-For larger module slices, group expectations by user/business behavior instead of turning every endpoint, field, and negative case into a long checklist. Ask for real backend-backed behavior, visible UI states, and meaningful success/failure tests, but keep the wording natural.
+For larger module slices, group expectations by user/business behavior instead of turning every endpoint, field, and negative case into a long checklist. Ask for real backend-backed behavior, visible UI states, and meaningful success/failure tests, but keep the wording natural. If a module is too large to explain without becoming a checklist packet, split it into smaller sequential prompts.
 
 Example of a good larger module prompt:
 
@@ -61,11 +63,13 @@ Do not say `the review found`, `the evaluation found`, or `the audit found`. The
 
 3. **Proceed module by module.**
    - Select the next section/module from `./docs/design.md` and the private plan.
-   - Prompt the developer using the docs only.
+   - Prompt the developer using the docs only, one module/work package at a time by default.
    - Ask for the implementation and the relevant tests/checks for that module.
+   - Combine two adjacent modules/work packages only when they share the same user flow or data contract and are easier to verify together.
 
 4. **Owner checks after each module.**
    - Inspect changed files manually.
+   - Compare behavior against the original product prompt in `./metadata.json`.
    - Compare behavior against `./docs/design.md` and `./docs/api-spec.md`.
    - Privately compare against `../.ai/plan.md` for tests, coverage, discoverability, functionality, and module completeness.
    - Run targeted checks when practical.

package/assets/skills/planning-guidance/SKILL.md

@@ -70,8 +70,9 @@ Phase 2 establishes the primary developer session and produces the accepted plan
    - Provide original prompt, stack/context, accepted questions, requirements breakdown, design, and API spec.
    - The general subagent must use the packaged `phase-2-execution-planning-prompt.md` as its instruction prompt.
    - The general subagent must use the packaged `phase-2-plan-template.md` as the required structure for `../.ai/plan.md`.
-   - Require output to `../.ai/plan.md` and `../.ai/test-coverage.md` when useful.
-   - Record private plan and coverage artifact paths in metadata and Beads after the subagent returns.
+- Require output to `../.ai/plan.md` and `../.ai/test-coverage.md` when useful.
+- Record private plan and coverage artifact paths in metadata and Beads after the subagent returns.
+- Ensure the private plan can be executed as small sequential developer prompts. Reject plans that require dumping multiple phases or the whole delivery contract into a single developer/Claude prompt.
 
 8. Owner accepts or rejects the planning package.
    - Use `planning-gate`.

package/assets/slopmachine/phase-2-execution-planning-prompt.md

@@ -50,6 +50,8 @@ Use the provided plan template.
 
 `../.ai/plan.md` must be actionable enough to support one clean human implementation prompt at a time without exposing this file.
 
+The plan must be sequenced so the owner can prompt the developer/Claude lane one bounded slice at a time. Prefer one work package per prompt. Mark any pair that should be sent together only when two adjacent slices are tightly coupled and easier to verify together. Do not create a plan that requires sending all phases, all modules, or the full delivery workflow to the implementation lane at once.
+
 `../.ai/test-coverage.md`, when written, should summarize planned coverage by module, API/interface, UI flow, risk, and final verification need.
 
 If the design or API spec has a material contradiction, record it as a planning exception instead of silently rewriting the contract.

package/assets/slopmachine/phase-2-plan-template.md

@@ -181,9 +181,11 @@ For each module, acceptance requires:
 
 Translate these into human prompts; do not paste this section verbatim.
 
-| Sequence | Human prompt intent | Visible context to mention | Expected completion report |
-|---|---|---|---|
-| 1 |  |  |  |
+Each row should represent one bounded prompt by default. Mark a combined prompt only when two adjacent rows are tightly coupled and should be implemented/verified together. Never combine all phases, the full plan, or the whole delivery into one developer/Claude prompt.
+
+| Sequence | Human prompt intent | Visible context to mention | Expected completion report | Combine with adjacent row? |
+|---|---|---|---|---|
+| 1 |  |  |  | no |
 
 ## 13. Plan Closure Checklist
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "theslopmachine",
-  "version": "1.0.12",
+  "version": "1.0.13",
   "description": "SlopMachine installer and project bootstrap CLI",
   "license": "MIT",
   "type": "module",