@crouton-kit/crouter 0.2.6 → 0.3.1

package/dist/prompts/agent.d.ts

@@ -1,13 +1,18 @@
 /**
  * First user message for a spec → plan handoff.
- * Bundles the full planning workflow with the spec to plan.
+ *
+ * Thin prompt: the worker discovers the full planning workflow by running
+ * `crtr flow plan new -h`, then saves the plan via `crtr flow plan new`. This avoids
+ * embedding the planPrompt() blob here and keeps the prompt in sync with the
+ * live CLI without any coupling.
  */
-export declare function planHandoffPrompt(specPath: string, plansDir: string): string;
+export declare function planHandoffPrompt(specPath: string, jobId: string): string;
 /**
  * First user message for a plan → implementation handoff.
  */
-export declare function implementHandoffPrompt(planPath: string): string;
+export declare function implementHandoffPrompt(planPath: string, jobId: string): string;
 /**
- * First user message for a handoff to code review of the working tree.
+ * First user message for a reviewer agent.
+ * The reviewer submits via `crtr job submit` rather than `crtr agent submit`.
  */
-export declare function reviewHandoffPrompt(): string;
+export declare function reviewerHandoffPrompt(artifactPath: string, artifactKind: 'plan' | 'spec', specPath: string | null, jobId: string): string;

package/dist/prompts/agent.js

@@ -1,30 +1,40 @@
-import { planPrompt } from './plan.js';
+import { planReviewPrompt, specReviewPrompt } from './review.js';
 /**
  * First user message for a spec → plan handoff.
- * Bundles the full planning workflow with the spec to plan.
+ *
+ * Thin prompt: the worker discovers the full planning workflow by running
+ * `crtr flow plan new -h`, then saves the plan via `crtr flow plan new`. This avoids
+ * embedding the planPrompt() blob here and keeps the prompt in sync with the
+ * live CLI without any coupling.
  */
-export function planHandoffPrompt(specPath, plansDir) {
-    return `${planPrompt(plansDir)}
+export function planHandoffPrompt(specPath, jobId) {
+    return `You were launched in a new tmux pane to turn an approved spec into a plan.
 
----
+**Spec:** ${specPath}
 
-## Your task
+1. Run \`crtr flow plan new -h\` to load the planning workflow and output schema.
+2. Read the spec end-to-end.
+3. Follow the workflow from step 1 and save the plan by passing the plan markdown to \`crtr flow plan new\` on stdin.
+4. When done, submit your result:
 
-You were just launched in a new tmux pane via \`crtr agent plan\`. A spec
-has been approved upstream and you are responsible for turning it into a plan.
+\`\`\`bash
+echo '{"status":"done","plan_saved":true}' > /tmp/crtr-result-${jobId}.json
+crtr job submit ${jobId} --context-file /tmp/crtr-result-${jobId}.json
+\`\`\`
 
-**Spec to plan:** ${specPath}
+If you cannot complete the plan, still submit:
 
-Read the spec end-to-end before anything else. Then proceed through the
-workflow above. When you save the plan, pass \`--spec <spec-name>\` so the
-plan reviewer can check alignment.
+\`\`\`bash
+echo '{"status":"failed","reason":"<why>"}' > /tmp/crtr-result-${jobId}.json
+crtr job submit ${jobId} --context-file /tmp/crtr-result-${jobId}.json
+\`\`\`
 
-The originating pane has closed; the user is watching you here. Begin now.`;
+Begin now.`;
 }
 /**
  * First user message for a plan → implementation handoff.
  */
-export function implementHandoffPrompt(planPath) {
+export function implementHandoffPrompt(planPath, jobId) {
     return `You are executing an approved plan. For small plans, implement directly.
 For plans with parallelizable scale, orchestrate parallel subagents and
 coordinate them — don't write all the code yourself when the plan is
@@ -34,11 +44,9 @@ structured to fan out.
 
 ## Phase 1: Read
 
-1. Read the plan end-to-end. If it references a spec (\`--spec\` was passed
-   at save time), read that too — it's the contract you are realizing.
-2. Read the files the plan names under "Files to modify / create" (or the
-   per-task \`Files:\` lines) and "Existing utilities to reuse" to ground
-   yourself in current code.
+1. Read the plan end-to-end. If it references a spec, read that too.
+2. Read the files the plan names under "Files to modify / create" and
+   "Existing utilities to reuse" to ground yourself in current code.
 3. If the plan has task blocks with dependencies, extract the task list,
    dependency graph, and integration contracts.
 
@@ -101,11 +109,20 @@ Wait for all subagents in the current layer. Then:
 subagent returns blocked work and the fix is small enough that re-dispatch
 would be slower.
 
-## Phase 6: Report
+## Phase 6: Report and submit
+
+When all tasks complete and verification passes, submit your result:
 
-When all tasks complete and verification passes, write one short message:
-files touched per group, tests run, what works. The user may then ask for
-a code review via \`crtr agent review\`.
+\`\`\`bash
+echo '{"status":"done","summary":"<one-line summary of files touched>"}' > /tmp/crtr-result-${jobId}.json
+crtr job submit ${jobId} --context-file /tmp/crtr-result-${jobId}.json
+\`\`\`
+
+If implementation fails, still submit:
+\`\`\`bash
+echo '{"status":"failed","reason":"<why>"}' > /tmp/crtr-result-${jobId}.json
+crtr job submit ${jobId} --context-file /tmp/crtr-result-${jobId}.json
+\`\`\`
 
 ## Guardrails (apply to you AND your subagents)
 
@@ -117,58 +134,18 @@ a code review via \`crtr agent review\`.
   patterns. Use the utilities the plan named.
 - **Commit only if the user asks.**
 
-You were launched in a new tmux pane via \`crtr agent implement\`. The
-originating pane has closed; the user is watching you here. Begin by reading
-the plan.`;
+Begin by reading the plan.`;
 }
 /**
- * First user message for a handoff to code review of the working tree.
+ * First user message for a reviewer agent.
+ * The reviewer submits via `crtr job submit` rather than `crtr agent submit`.
  */
-export function reviewHandoffPrompt() {
-    return `You are a code reviewer. A change has just been implemented and your job is
-to review it before it lands.
-
-## Scope
-
-Review the **uncommitted** changes in the working tree of the current
-directory. Use \`git status\` and \`git diff\` (including staged changes via
-\`git diff --cached\`) to enumerate what changed. If there are zero changes,
-say so and stop.
-
-## What to check
-
-| Category | What to look for |
-|----------|------------------|
-| Correctness | Does the code do what it claims? Off-by-ones, wrong branches, missed cases. |
-| Security | Injection, auth bypass, leaking secrets, unsafe defaults. |
-| Style fit | Matches the file's existing conventions, naming, error-handling style. |
-| Tests | Are there tests for new behavior? Do they actually exercise the change? |
-| Scope | Did the change stay within its mandate, or sneak in unrelated edits? |
-| Reuse | Are there existing utilities that should have been used? |
-
-## Calibration
-
-Only flag issues that would matter to the next reader, on-call, or future
-maintainer. Nits are fine in a "Recommendations" section, but **do not block
-on style preferences**. Approve unless something is wrong, missing, or risky.
-
-## Output
-
-\`\`\`
-## Code Review
-
-**Status:** Approved | Issues Found
-
-**Issues (if any):**
-- [file:line]: [specific issue] — [why it matters]
-
-**Recommendations (advisory):**
-- [suggestions]
-\`\`\`
-
-After printing the review, your turn ends.
-
-You were launched in a new tmux pane via \`crtr agent review\`. The
-originating pane has closed; the user is watching you here. Begin by checking
-the working tree.`;
+export function reviewerHandoffPrompt(artifactPath, artifactKind, specPath, jobId) {
+    const reviewBody = artifactKind === 'spec'
+        ? specReviewPrompt(artifactPath)
+        : planReviewPrompt(artifactPath, specPath);
+    const patched = reviewBody.replace('__CRTR_SUBMIT_INSTRUCTION__', `the submit command injected below. The \`--kill-pane\` flag closes this reviewer pane after submission — keep it, do not drop it.\n\n\`\`\`bash\ncat > /tmp/crtr-result-${jobId}.json <<'JSON'\n{"status":"done","review":"<your full review markdown>"}\nJSON\ncrtr job submit ${jobId} --context-file /tmp/crtr-result-${jobId}.json --kill-pane\n\`\`\``);
+    return `${patched}
+
+After calling \`crtr job submit\`, your turn ends and the pane closes itself. Do NOT chat or summarize after submission.`;
 }

package/dist/prompts/debug.d.ts

@@ -0,0 +1,8 @@
+/**
+ * First user message for a reproduction-only debug handoff.
+ *
+ * The agent's sole job is ONE failing integration test that reproduces the
+ * reported bug. It never fixes the bug. Symmetric with the agent.ts handoff
+ * builders: thin prompt, exact submit contract, turn ends after submit.
+ */
+export declare function reproHandoffPrompt(issue: string, jobId: string): string;

package/dist/prompts/debug.js

@@ -0,0 +1,37 @@
+/**
+ * First user message for a reproduction-only debug handoff.
+ *
+ * The agent's sole job is ONE failing integration test that reproduces the
+ * reported bug. It never fixes the bug. Symmetric with the agent.ts handoff
+ * builders: thin prompt, exact submit contract, turn ends after submit.
+ */
+export function reproHandoffPrompt(issue, jobId) {
+    return `You were spawned solely to write ONE integration test that fails *because of this bug*:
+
+${issue}
+
+Rules — follow exactly:
+
+- Do NOT fix the bug. Do NOT modify product code to make a test pass. Your only output is a test.
+- The test must fail against the current code, and the failure must BE the reported bug — not an import error, a typo, or an unrelated assertion. Run it; paste the real failing output; confirm the failure mode matches the issue.
+- Prefer an integration test against real dependencies. Mocking away the broken component is theater and does NOT count as reproduction.
+- If you cannot produce a faithful failing test, GIVE UP. Never weaken assertions, hardcode expected values, or fabricate a clean-looking run — a tautological or over-mocked test is worse than none.
+
+Submit exactly one of the following via \`crtr job submit\`, then your turn ends — do not chat:
+
+Reproduced:
+\`\`\`bash
+cat > /tmp/crtr-result-${jobId}.json <<'JSON'
+{"status":"done","reproduces":true,"test_path":"<path>","test_command":"<exact cmd>","failure_output":"<pasted failing output>"}
+JSON
+crtr job submit ${jobId} --context-file /tmp/crtr-result-${jobId}.json
+\`\`\`
+
+Gave up (no faithful repro achievable):
+\`\`\`bash
+echo '{"status":"failed","reproduces":false,"reason":"<why a faithful repro was not achievable>"}' > /tmp/crtr-result-${jobId}.json
+crtr job submit ${jobId} --context-file /tmp/crtr-result-${jobId}.json
+\`\`\`
+
+Begin now.`;
+}

package/dist/prompts/review.js

@@ -1,20 +1,13 @@
 const SUBMIT_INSTRUCTIONS = `## Delivering your review
 
-When your review is complete, run a single Bash command to submit it back to
-the parent agent:
-
-\`\`\`bash
-crtr agent submit "$(cat <<'EOF'
-<your full review markdown here, using the Output Format below>
-EOF
-)"
-\`\`\`
+When your review is complete, deliver your verdict as instructed by
+__CRTR_SUBMIT_INSTRUCTION__
 
 The pane will close automatically once your review is delivered. Do NOT
-summarize or chat after submission — \`crtr agent submit\` IS the response.
+summarize or chat after submission — the submit call IS the response.
 
 If you cannot complete the review (file missing, totally malformed, etc.),
-still call \`crtr agent submit\` with a brief explanation of why.`;
+still submit with a brief explanation of why.`;
 export function specReviewPrompt(specPath) {
     return `You are reviewing a spec document. Verify it is complete and ready for
 planning.

package/dist/prompts/skill.d.ts

@@ -1,3 +1,2 @@
-export declare function skillPrompt(): string;
 export declare function skillCreatePrompt(topic: string): string;
 export declare function skillTemplatePrompt(type: string, topic: string): string;