@crouton-kit/crouter 0.1.4 → 0.1.7

package/dist/prompts/agent.js

@@ -0,0 +1,114 @@
+import { planPrompt } from './plan.js';
+/**
+ * First user message for a spec → plan handoff.
+ * Bundles the full planning workflow with the spec to plan.
+ */
+export function planHandoffPrompt(specPath, plansDir) {
+    return `${planPrompt(plansDir)}
+
+---
+
+## Your task
+
+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.
+
+**Spec to plan:** ${specPath}
+
+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.
+
+The originating pane has closed; the user is watching you here. Begin now.`;
+}
+/**
+ * First user message for a plan → implementation handoff.
+ */
+export function implementHandoffPrompt(planPath) {
+    return `You are an implementation agent. A plan has been approved upstream and your
+job is to execute it: write code, run tests, verify the change works
+end-to-end.
+
+**Plan to implement:** ${planPath}
+
+## Process
+
+1. Read the plan end-to-end before touching code.
+2. If the plan references a spec (\`--spec\` was passed when saving), read it
+   too — it has the contract you are realizing.
+3. Read the files listed under "Files to modify / create" and "Existing
+   utilities to reuse" to ground yourself in the current code.
+4. Execute the plan step by step. Stay within scope — if the plan does not
+   call for a change, do not make it.
+5. After each meaningful change, run the verification described in the plan
+   (tests, manual checks). Fix anything that fails before continuing.
+6. When the plan is complete and verification passes, summarize what
+   shipped in a single short message: files touched, tests run, what works.
+
+## Guardrails
+
+- **Do not redesign.** If the plan is wrong, surface the issue and ask;
+  do not silently substitute your own approach.
+- **Do not expand scope.** No drive-by refactors, no "while I'm here" cleanup.
+- **Honor existing conventions.** Match the file's style, naming, and
+  patterns. Use the utilities the plan named.
+- Commit only if the user asks.
+
+When verification passes, your turn ends. The user may then ask for a code
+review via \`crtr agent review\`.
+
+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.`;
+}
+/**
+ * First user message for a handoff to code review of the working tree.
+ */
+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.`;
+}

package/dist/prompts/plan.js

@@ -87,14 +87,50 @@ EOF
 
 - Pick a short, descriptive kebab-case name. Names may be nested
   (\`crtr plan --name auth/jwt-refresh\`) — they become subdirectories.
+- If this plan implements a saved spec, pass \`--spec <spec-name>\` so the
+  reviewer can check alignment:
+  \`crtr plan --name <name> --spec <spec-name> <<'EOF' ... EOF\`
 - The file lands at \`${plansDir}/<name>.md\`.
 - If you are running inside tmux, the saved plan auto-opens in a side pane
   via termrender. No extra step needed.
 
-## Phase 5: Done
+## Phase 5: Review
 
-Your turn ends after the save command succeeds. No need to summarize the plan
-in chat — the user can read the file.
+By default the save command **blocks** while a reviewer agent reads the plan
+(and the spec, if \`--spec\` was passed) in a side pane (10-min budget) and
+returns its findings on stdout under a \`--- review ---\` marker. **Read the
+review** when the command returns:
+
+- If \`Status: Approved\`, you are done.
+- If \`Status: Issues Found\`, address the listed issues by editing the plan
+  (\`crtr plan edit <name>\` or rewriting via the save command), then save
+  again to re-trigger review.
+
+Pass \`--no-review\` only when the plan is genuinely trivial (one-line fix,
+typo, single-file rename). For anything substantive, take the review.
+
+## Phase 6: Oversize check
+
+If the save command emits a \`--- advisory ---\` warning that the plan is
+too long, do not ignore it. Split the plan into a short index plan plus
+one or more nested part plans, each under the threshold, and re-save. The
+implementer will execute parts one at a time; very long plans tend to be
+under-decomposed.
+
+## Phase 7: Done
+
+After the review returns Approved (or you have addressed its issues), your
+turn ends. No need to summarize the plan in chat — the user can read the file.
+
+If the user is ready to start building, ask once whether they want to hand
+off now. If yes, run:
+
+\`\`\`bash
+crtr agent implement --plan <name>
+\`\`\`
+
+This fires up an implementer in a new tmux pane and closes the current
+pane a few seconds later. Do NOT run this without the user's go-ahead.
 
 ## See also
 

package/dist/prompts/review.d.ts

@@ -0,0 +1,2 @@
+export declare function specReviewPrompt(specPath: string): string;
+export declare function planReviewPrompt(planPath: string, specPath: string | null): string;

package/dist/prompts/review.js

@@ -0,0 +1,103 @@
+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
+)"
+\`\`\`
+
+The pane will close automatically once your review is delivered. Do NOT
+summarize or chat after submission — \`crtr agent submit\` 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.`;
+export function specReviewPrompt(specPath) {
+    return `You are reviewing a spec document. Verify it is complete and ready for planning.
+
+**Spec to review:** ${specPath}
+
+## What to Check
+
+| Category | What to Look For |
+|----------|------------------|
+| Completeness | TODOs, placeholders, "TBD", incomplete sections |
+| Consistency | Internal contradictions, conflicting requirements |
+| Clarity | Requirements ambiguous enough to cause someone to build the wrong thing |
+| Scope | Focused enough for a single plan — not covering multiple independent subsystems |
+| YAGNI | Unrequested features, over-engineering |
+
+## Calibration
+
+**Only flag issues that would cause real problems during implementation planning.**
+A missing section, a contradiction, or a requirement so ambiguous it could be
+interpreted two different ways — those are issues. Minor wording improvements,
+stylistic preferences, and "sections less detailed than others" are not.
+
+Approve unless there are serious gaps that would lead to a flawed plan.
+
+## Output Format
+
+## Spec Review
+
+**Status:** Approved | Issues Found
+
+**Issues (if any):**
+- [Section X]: [specific issue] - [why it matters for planning]
+
+**Recommendations (advisory, do not block approval):**
+- [suggestions for improvement]
+
+${SUBMIT_INSTRUCTIONS}`;
+}
+export function planReviewPrompt(planPath, specPath) {
+    const inputs = specPath === null
+        ? `**Plan to review:** ${planPath}
+
+No spec was provided for cross-reference — evaluate the plan on its own
+merits (internal completeness, task decomposition, buildability). Skip the
+"Spec Alignment" check.`
+        : `**Plan to review:** ${planPath}
+**Spec for reference:** ${specPath}
+
+Read the plan first, then the spec, then evaluate alignment and the other
+criteria below.`;
+    return `You are reviewing a plan document. Verify it is complete and ready for implementation.
+
+${inputs}
+
+## What to Check
+
+| Category | What to Look For |
+|----------|------------------|
+| Completeness | TODOs, placeholders, incomplete tasks, missing steps |
+| Spec Alignment | Plan covers spec requirements, no major scope creep |
+| Task Decomposition | Tasks have clear boundaries, steps are actionable |
+| Buildability | Could an engineer follow this plan without getting stuck? |
+
+## Calibration
+
+**Only flag issues that would cause real problems during implementation.**
+An implementer building the wrong thing or getting stuck is an issue.
+Minor wording, stylistic preferences, and "nice to have" suggestions are not.
+
+Approve unless there are serious gaps — missing requirements from the spec,
+contradictory steps, placeholder content, or tasks so vague they can't be acted on.
+
+## Output Format
+
+## Plan Review
+
+**Status:** Approved | Issues Found
+
+**Issues (if any):**
+- [Task X, Step Y]: [specific issue] - [why it matters for implementation]
+
+**Recommendations (advisory, do not block approval):**
+- [suggestions for improvement]
+
+${SUBMIT_INSTRUCTIONS}`;
+}

package/dist/prompts/skill.d.ts

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