@janvitos/pi-plan-build 0.1.44 → 0.1.46

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/package.json +1 -1
  2. package/prompts.ts +4 -3
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@janvitos/pi-plan-build",
3
- "version": "0.1.44",
3
+ "version": "0.1.46",
4
4
  "description": "Plan safely, approve explicitly, then implement here or in a clean session.",
5
5
  "type": "module",
6
6
  "license": "MIT",
package/prompts.ts CHANGED
@@ -43,9 +43,10 @@ The plan file is the only file you may edit, and only while finalizing the plan
43
43
  - Include only the recommended approach, not every alternative considered.
44
44
  - Be concise enough to scan quickly but detailed enough to implement.
45
45
  - Identify the critical files that need modification.
46
- - Include a minimal \`## Verification\` section covering only the basic functionality directly affected by the change. Use the fewest checks needed to confirm that the change works at a basic level. Group related checks, and do not mirror every implementation step or plan exhaustive regression, edge-case, performance, or compatibility testing.
47
- - **Agent checks:** List safe, non-disruptive checks the agent should run after implementation. Include exact repository-supported commands when available; never invent commands. Prefer one targeted test, build, type-check, config validation, dry run, or smoke check that covers the change.
48
- - **User checks:** List only essential checks requiring user access or judgment, or checks that could affect running services, data, external systems, or machine state. Include an exact known command and brief expected result when useful. The agent must not perform these checks unless separately requested. Omit this subsection when no user action is needed.
46
+ - Include a brief \`## Verification\` section describing the smallest credible proof that the changed basic functionality works. Group related validation and avoid exhaustive regression, edge-case, performance, or compatibility testing.
47
+ - Structure the section using standalone bold labels without colons:
48
+ - Place \`**Agent**\` on its own line, followed by checks the agent should perform after implementation. Prefer one targeted behavior-level test or smoke check with an exact repository-supported command and a short expected observable result. If no behavioral command exists, use the smallest relevant build, type-check, configuration validation, or dry run. Never invent commands.
49
+ - When needed, place \`**User**\` on its own line, followed only by essential validation the agent cannot safely or realistically perform because it requires user access, credentials, judgment, hardware, privileged operations, or could affect running services, data, external systems, or machine state. Give an exact known command or action and expected result. The agent must not perform these items unless separately requested. Omit this label and its checks when unnecessary.
49
50
  - End with a \`## Implementation Steps\` section containing the executable top-level steps as \`- [ ] ...\` checklist items. Keep these items discrete and ordered; the optional fullscreen step-by-step workflow uses them directly.
50
51
 
51
52
  After writing the complete plan, call plan_exit to request approval. Do not use the question tool to ask whether the completed plan is acceptable; plan_exit handles approval.