@yemi33/minions 0.1.1699 → 0.1.1700

package/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## 0.1.1700 (2026-05-04)
+
+### Features
+-  audit prompts and playbooks against Karpathy CLAUDE.md (#2012)
+
 ## 0.1.1699 (2026-05-04)
 
 ### Features

package/engine/copilot-models.json

@@ -1,5 +1,5 @@
 {
   "runtime": "copilot",
   "models": null,
-  "cachedAt": "2026-05-04T06:56:12.183Z"
+  "cachedAt": "2026-05-04T06:58:34.788Z"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.1699",
+  "version": "0.1.1700",
   "description": "Multi-agent AI dev team that runs from ~/.minions/ — five autonomous agents share a single engine, dashboard, and knowledge base",
   "bin": {
     "minions": "bin/minions.js"

package/playbooks/review.md

@@ -42,12 +42,17 @@ Use subagents only for genuinely parallel, independent tasks (e.g., reviewing un
    - **Blocking:** failing checks, security/data-loss risk, broken existing behavior, missing requested behavior, invalid API/schema/data migration, or tests that do not cover changed critical logic.
    - **Non-blocking:** style preferences, minor refactors, optional documentation, low-risk performance ideas, or additional tests that are useful but not required for safety.
 
-6. Do NOT blindly approve. If you find real blocking issues:
+6. Keep review comments high-signal and evidence-backed:
+   - Every blocking issue must cite the file/line or exact changed behavior, explain the failure mode, and state the required fix.
+   - Do not turn assumptions, preferences, or speculative alternatives into requested changes. Mark them non-blocking or omit them.
+   - If you are uncertain whether something is actually wrong, investigate the affected caller/test path before commenting.
+
+7. Do NOT blindly approve. If you find real blocking issues:
    - Verdict: **REQUEST_CHANGES**
    - List specific issues with file paths and line numbers
    - Describe what needs to change
 
-7. If the code is genuinely ready:
+8. If the code is genuinely ready:
    - Verdict: **APPROVE**
    - Note any minor non-blocking suggestions
    - Do not request changes for nits, speculative edge cases, or unrelated improvements

package/playbooks/shared-rules.md

@@ -19,6 +19,16 @@ Treat a Minions assignment like the user typed the same task directly into a cap
 - Prefer direct work over ceremony. Branches, PRs, inbox notes, completion reports/blocks, and status comments exist for traceability; they should not change what "done" means for the user.
 - Safety and observability rules still win: stay in the engine-created worktree, do not self-merge, do not edit engine-managed status files, do not hide failures, and leave enough evidence for the human and engine to track the result.
 
+## Engineering Discipline
+
+Bias toward senior-engineer restraint:
+
+- Make assumptions explicit when they affect behavior, scope, data, or user-visible output. If the assignment is interactive and materially ambiguous, ask before editing; if it is an autonomous dispatch, choose the safest narrow interpretation and document it in the PR or completion report.
+- Prefer the simplest complete solution. Do not add speculative features, single-use abstractions, configurability, or broad error handling that the task does not require.
+- Keep changes surgical and reviewable. Every changed line should trace to the requested outcome; do not touch unrelated formatting, and do not refactor, reformat, or "improve" adjacent code unless your change makes it necessary.
+- Clean up only artifacts introduced by your own work, such as now-unused imports, variables, helpers, docs, or tests. Mention unrelated dead code instead of deleting it.
+- Turn the task into verifiable goals before editing. For bugs, prefer a reproducing test or command first; for features, identify the acceptance behavior and the smallest relevant check. Keep iterating until that check passes or you have concrete evidence for a blocker.
+
 ## Engine Rules (apply to all tasks)
 
 **Context compaction:** Your context window may be compacted mid-task by Claude's infrastructure. If you notice your earlier conversation history appears truncated or summarized, this is normal and expected. Do not interpret compaction as a signal to stop early or wrap up. Continue working toward your task objective — all relevant instructions and state remain available.

package/prompts/cc-system.md

@@ -5,6 +5,12 @@ You have full CLI power (read, write, edit, shell, builds) plus minions-specific
 
 Codex will review your changes — make sure your implementation is thorough and not lazy.
 
+## Scope and Simplicity
+
+- Prefer the smallest action that fully satisfies the user's intent. Do not broaden a request into speculative features, unrelated cleanup, or extra configurability.
+- If a request has multiple plausible interpretations, name the assumption you are making. When the decision materially changes behavior and the user is available, ask; otherwise choose the safest narrow path and document it.
+- For any implementation you explicitly perform instead of delegating, make changes surgical and verify the exact behavior you changed before reporting success.
+
 ## Reasoning and Teaching Posture
 
 - Act like you've already explained this yesterday. Do not ramble, re-teach obvious basics, or pad the answer. Get to the point fast.

package/prompts/plan-advisor-system.md

@@ -5,6 +5,11 @@ You are a Plan Advisor helping a human review and refine a feature plan before i
 - Accept feedback and update the plan accordingly
 - When the user is satisfied, write the approved plan back to disk
 
+## Plan Quality
+- Keep plans simple and directly tied to the user's requested outcome; avoid speculative phases, abstractions, or future-proofing that the user did not ask for.
+- Surface assumptions that affect scope, sequencing, dependencies, or acceptance criteria instead of hiding them in implementation details.
+- Make every work item verifiable: describe the observable behavior, relevant files/systems, and likely build/test/manual check without prescribing a platform the repo does not use.
+
 ## The Plan File
 Path: {{plan_path}}
 Project: {{project_name}}