@jskit-ai/jskit-cli 0.2.89 → 0.2.90

package/src/server/sessionRuntime/prompts/{execute_plan.md → plan_executed.md}

@@ -4,24 +4,14 @@ GitHub issue: {{issue_url}}
 Issue number: {{issue_number}}
 Issue title: {{issue_title}}
 Issue body file: {{issue_file}}
-Issue details file (`issue_details.md`): {{issue_details_file}}
-Plan file: {{plan_file}}
 Worktree: {{worktree}}
 
-Confirmed issue details:
-
-{{issue_details_text}}
-
-Approved plan:
-
-{{plan_text}}
-
-Implement the plan in the session worktree. Keep the change scoped to the issue, confirmed issue details, and approved plan.
+Implement the plan that was just reviewed in this Codex conversation. If the plan is not visible in the current terminal context, first make a concise plan from the issue, then execute it. Keep the change scoped to the issue.
 
 Implementation rules:
 
 - Inspect the current app before editing. App setup has already passed; if required JSKIT app files are missing, report setup failure rather than inventing recovery work.
-- Follow both `{{issue_details_file}}` and `{{plan_file}}`. If they disagree, ask for clarification before changing files.
+- Follow `{{issue_file}}`. If the request is ambiguous, ask for clarification before changing files.
 - Before implementing JSKIT app structure, generators, CRUD, surfaces, placements, app setup, package-owned workflows, or UI verification paths, read the relevant JSKIT agent docs. Start with `node_modules/@jskit-ai/agent-docs/DISTR_AGENT.md`, `node_modules/@jskit-ai/agent-docs/guide/agent/index.md`, and `node_modules/@jskit-ai/agent-docs/patterns/INDEX.md` when present. If working inside the JSKIT monorepo or a devlinked sibling, use `packages/agent-docs/...` as the source-tree equivalent.
 - Read specific pattern docs before touching their lane, such as CRUD scaffolding/repository mapping, page scaffolding, surfaces, placements, client requests, live actions, generated UI contract tracking, and UI testing. Prefer these docs and package descriptors over reverse-engineering framework rules from source files.
 - Read `.jskit/helper-map.md` when it exists before creating helpers, composables, service functions, maps, or package glue.
@@ -34,7 +24,7 @@ Implementation rules:
 - Keep direct knex exceptional and minimal. Prefer internal json-rest-api seams outside generated CRUD packages and explicit weird-custom feature lanes.
 - Keep runtime, UI, and data concerns separated.
 - Avoid accidental scope expansion.
-- Do not create `.jskit/WORKBOARD.md`; the session files and receipts are the workflow record.
+- Do not create `.jskit/WORKBOARD.md`; the session files are the workflow record.
 - If user-facing UI changes, bring the screen to Material Design and Vuetify quality before calling it done. Include coherent responsive layout, loading, empty, error, disabled, and success states where relevant.
 - If verification needs login, use the app's local development auth bootstrap path rather than a live external auth login.
 
@@ -44,21 +34,6 @@ After making changes:
 - Run the smallest relevant checks you can run safely in the worktree.
 - For changed user-facing UI, run or clearly identify the Playwright verification path. When possible, record UI verification with `npx --no-install jskit app verify-ui --command "<playwright command>" --feature "<label>" --auth-mode <mode>`.
 - `npx --no-install jskit app verify-ui` does not start the app server. Before using it for Playwright, make sure the app is reachable. If a local server is needed, inspect `.jskit/config/testrun_command` when present and use the app's documented server command, or start the server explicitly and wait for it before invoking `verify-ui`. Do not first run a bare Playwright command against a stopped server.
-- Summarize changed files and checks run.
-- If implementation deviated from the approved plan, generator choices, package ownership, helper reuse, UI verification path, or data ownership, include concise decision entries with reasons in this exact marker block:
-
-```text
-[agent_decisions]
-<implementation decisions or "No new decisions.">
-[/agent_decisions]
-```
+- Summarize changed files, checks run, and any important implementation decisions or verification gaps in the terminal.
 
 Do not create commits, branches, issues, pull requests, merges, or worktree cleanup yourself. JSKIT session will handle those steps.
-
-At the very end, include this completion block so Studio knows the step is complete:
-
-[jskit_step_result]
-status: complete
-step: plan_executed
-summary: Short summary of what changed and what was checked.
-[/jskit_step_result]

package/src/server/sessionRuntime/prompts/{prepare_pr_merge.md → pr_merge_prepared.md}

@@ -7,9 +7,9 @@ Branch: {{branch}}
 Base branch: {{base_branch}}
 Pull request: {{pr_url}}
 Issue: {{issue_url}}
-Final report: {{final_report_file}}
+Pull request file: {{pull_request_file}}
 
-Your job is to get the pull request into a state where the user can decide whether to press the JSKIT Merge PR button.
+Your job is to do whatever is needed, within the session scope, to get the pull request into a state where the user can press the JSKIT Merge button.
 
 Required boundaries:
 
@@ -17,6 +17,6 @@ Required boundaries:
 - Resolve merge conflicts or failing checks if the fix is clear and in scope.
 - Commit and push any preparation changes to the session branch.
 - Do not merge the pull request.
-- Do not remove the worktree, archive the session, update the local base branch, or write JSKIT receipts. JSKIT owns deterministic cleanup after the user decides.
+- Do not remove the worktree, archive the session, update the local base branch, or write JSKIT session state. JSKIT owns deterministic cleanup after the user decides.
 
 When you are done, summarize what you checked, what changed, and whether you believe the PR is ready for the user to merge.

package/src/server/sessionRuntime/prompts/{resolve_deslop_findings.md → review_changes_accepted_resolve.md}

@@ -1,13 +1,9 @@
-Resolve the listed deslop findings in the current worktree.
+Resolve the important findings from the latest deslop review in this conversation.
 
-Fix only the listed findings. Keep scope tight. Do not create commits, branches, issues, pull requests, merges, or worktree cleanup.
+Fix only those findings. Keep scope tight. Do not create commits, branches, issues, pull requests, merges, or worktree cleanup.
 
 Use existing JSKIT helpers, generators, package seams, and app-local helpers where they fit. Do not introduce helper churn or unrelated refactors while resolving these findings.
 
-[resolve_deslop_findings]
-{{findings}}
-[/resolve_deslop_findings]
-
 When finished:
 
 - Summarize the exact findings fixed.

package/src/server/sessionRuntime/prompts/{review_changes.md → review_prompt_rendered.md}

@@ -6,9 +6,9 @@ Changed files in the current session worktree:
 
 {{changed_files}}
 
-Review the current worktree changes, but do not silently fix everything you find unless Studio explicitly asks you to resolve selected findings.
+Review the current worktree changes, but do not silently fix everything you find unless the user explicitly sends the resolve deslop prompt.
 
-First, inspect the worktree and produce a short, prioritized list of important findings. The answer should be conversational and useful for the user to read. End every review answer with one small machine-readable `[deslop_result]` block so Studio can decide whether to automate another pass.
+Inspect the worktree and produce a short, prioritized list of important findings. The answer should be conversational and useful for the user to read; the user will decide what happens next.
 
 Use priorities this way:
 
@@ -16,7 +16,7 @@ Use priorities this way:
 - `medium`: maintainability, meaningful duplication, missing required state, weak JSKIT reuse, important verification gap, or visible UI quality issue inside the requested scope.
 - `low`: polish, optional cleanup, copy tuning, minor test expansion, or judgment-call improvements the user should decide on.
 
-If Studio later sends a `[resolve_deslop_findings]` block, fix only the listed findings in the current worktree. After fixing them, summarize what changed and wait for the next review prompt.
+If the user later sends the resolve deslop prompt, fix the important findings from this deslop review in the current worktree. After fixing them, summarize what changed and wait for the next review prompt.
 
 If there are no important findings, say so explicitly and do not make cosmetic churn.
 
@@ -59,28 +59,3 @@ Use four passes:
 Do not create commits, branches, pull requests, merges, or worktree cleanup yourself. JSKIT session owns those steps.
 
 When finished, report the findings considered, fixes made during this pass if any, changed files, checks run, and anything still unverified. If there are no important findings, say so explicitly and list residual risk.
-
-At the very end of each review answer, include this block. Keep it plain text, not JSON:
-
-[deslop_result]
-priority: high | medium | low
-category: bug | maintainability | jskit | ui | verification | content | other
-title: Short finding title
-files:
-- path/to/file
-reason: Why this matters
-recommended_action: What should be done
-
-priority: low
-category: other
-title: Another optional finding
-files:
-- path/to/file
-reason: Why this is optional
-recommended_action: What the user may choose to do
-[/deslop_result]
-
-If there are no findings, return an empty result block:
-
-[deslop_result]
-[/deslop_result]

package/src/server/sessionRuntime/prompts/{user_check.md → user_check_completed.md}

@@ -1,21 +1,11 @@
-User check for session {{session_id}}.
+Complete user check for session {{session_id}}.
 
 Issue: {{issue_url}}
 Issue title: {{issue_title}}
 Issue body file: {{issue_file}}
-Issue details file (`issue_details.md`): {{issue_details_file}}
-Plan file: {{plan_file}}
 
 The code should already be built or runnable according to the implementation instructions.
 
-Confirmed issue details:
-
-{{issue_details_text}}
-
-Approved plan:
-
-{{plan_text}}
-
 Ask the user to test the changed behavior in the app and report whether it works as intended. Be specific about the user-visible behavior, route, command, or workflow to inspect.
 
 If the user finds a problem, diagnose the root cause and fix it in this worktree. Keep the fix scoped. Reuse JSKIT helpers, generated seams, and package workflows where they apply.