@jskit-ai/jskit-cli 0.2.89 → 0.2.91

package/src/server/sessionRuntime/prompts/issue_details.md

@@ -1,49 +0,0 @@
-Gather exact issue details for JSKIT session {{session_id}}.
-
-GitHub issue: {{issue_url}}
-Issue number: {{issue_number}}
-Issue title: {{issue_title}}
-Issue body file: {{issue_file}}
-Issue details file JSKIT will write after user approval (`issue_details.md`): {{issue_details_file}}
-Worktree: {{worktree}}
-
-This step exists before planning. Do not edit files, create session receipts, create or overwrite the issue details file, create commits, create branches, create issues, create pull requests, merge, or clean worktrees. JSKIT will save the approved details to the issue details file after the user reviews them.
-
-No stones unturned:
-
-- Read the issue and inspect the app enough to understand the implementation surface.
-- Read `.jskit/APP_BLUEPRINT.md` and `.jskit/helper-map.md` when present.
-- Read package.json, `.jskit/lock.json`, `config/public.js`, relevant `src/`, relevant `packages/`, and relevant package docs or `npx --no-install jskit show ... --details`.
-- Read JSKIT agent docs before inferring framework patterns from source. 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. Then read the specific pattern docs that match the issue: CRUD, page scaffolding, surfaces, placements, client requests, live actions, generated UI contracts, or UI testing.
-- Ask follow-up questions until all important issue details are known.
-- Ask the user for whatever is still needed.
-- Ask for final confirmation before emitting final details.
-- Do not output the final markers below until the user has confirmed the details.
-
-For CRUD or persisted data, confirm entity/table name, fields, field types, nullability, defaults, uniqueness, indexes, relationships, ownership, allowed operations, list/view/form shape, validation, permissions, migration/generator lane, and exact CRUD generator command or exact reason no CRUD generator applies.
-
-For UI, confirm route path, surface/placement target, navigation expectations, responsive layout, loading/empty/error/disabled/success states, Material/Vuetify expectations, Playwright verification path, and auth/bootstrap strategy if needed.
-
-For server-only work, confirm endpoint/command/job shape, request/response shape, validation, auth/permission behavior, persistence ownership, error behavior, and verification path.
-
-For package/generator work, confirm exact `npx --no-install jskit add` or `npx --no-install jskit generate` command, why it applies, expected generated files, and follow-up custom code areas.
-
-When source files and docs appear to disagree, ask or record the discrepancy. Do not silently prefer code archaeology over package-owned JSKIT guide and pattern docs.
-
-When the details are confirmed, output only the final classification, details, and decision notes surrounded by these exact markers:
-
-[issue_category]
-<client | server | client_server | tooling | unknown>
-[/issue_category]
-
-[ui_impact]
-<none | possible | definite | unknown>
-[/ui_impact]
-
-[issue_details]
-<confirmed issue details in Markdown>
-[/issue_details]
-
-[agent_decisions]
-<concise decision entries with reasons>
-[/agent_decisions]

package/src/server/sessionRuntime/prompts/new_issue.md

@@ -1,46 +0,0 @@
-Create a GitHub issue from this user request:
-
-{{user_input}}
-
-First inspect the local app enough to understand the request in context. App setup has already passed before this prompt is rendered; treat this as a ready JSKIT app. This issue-drafting step is read-only.
-
-Allowed inspection:
-
-- Read files with commands such as `pwd`, `ls`, `find`, `rg`, `cat`, `sed`, and `git status`.
-- Read package.json, `.jskit/lock.json`, config, routes, packages, source files, `.jskit/APP_BLUEPRINT.md`, and `.jskit/helper-map.md` when available.
-- Use non-mutating JSKIT inspection commands when available and relevant: `npx --no-install jskit list`, `npx --no-install jskit show <package> --details`, and `npx --no-install jskit list-placements`.
-- Read JSKIT agent docs before inferring framework patterns from source. 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. Then read only the relevant pattern docs for the request, such as CRUD, page scaffolding, surfaces, placements, client requests, live actions, or UI testing.
-- If the filesystem contradicts a ready JSKIT app, stop and report that app setup must be rerun. Do not draft a recovery issue inside this session.
-
-Do not run workflow, repair, or mutation commands during issue drafting:
-
-- Do not run `npx --no-install jskit session`, `npx --no-install jskit session step`, or any command that advances a JSKIT session.
-- Do not run `gh`, `git add`, `git commit`, `git push`, `npm install`, generators, tests, verification, devlinks, or doctor commands.
-- Do not try to fix missing PATH entries or missing helper binaries. If a tool is unavailable, continue with read-only file inspection.
-- Do not edit files.
-
-Draft an implementation-ready issue, not a broad product essay.
-
-Preserve these JSKIT boundaries:
-
-- If platform choices are still provisional, make the issue resolve those choices before installing tenancy-sensitive packages.
-- Do not ask the developer to redesign standard JSKIT package-owned workflows from scratch. Treat selected package workflows as defaults unless the request asks for overrides, restrictions, or custom additions.
-- For persisted app-owned data, prefer generated/package ownership over direct hand-built persistence. A new ordinary table should usually become a server CRUD-owned entity before CRUD UI or route work.
-- For non-CRUD app pages, prefer the JSKIT UI generator when it fits.
-- Keep direct knex or low-level runtime work exceptional and explicitly justified.
-- Prefer documented JSKIT guide and pattern docs over reverse-engineering framework architecture from source files. Use source inspection to understand this app and verify details, not as the first source of JSKIT design rules.
-- Do not include workflow bookkeeping such as old workboards in the issue body. JSKIT session state and receipts are the workflow tracker.
-
-Ask concise clarifying questions if the request is not specific enough to produce a useful implementation issue. Ask only for details that materially change the ticket.
-
-When the issue is ready, output only the final issue title and body surrounded by these exact markers:
-
-[issue_title]
-<short issue title>
-[/issue_title]
-
-[issue_text]
-<issue body in Markdown, without repeating the title as a heading>
-[/issue_text]
-
-The issue should be concrete, scoped, and implementation-ready. Include acceptance criteria when they are useful.