fix: address PR comments and complete prompt centralization

- Fix inline type imports in defaults.ts (move to top-level imports)
- Update ideation-service.ts to use centralized prompts from settings
- Update generate-title.ts to use centralized prompts
- Update validate-issue.ts to use centralized prompts
- Clean up validation-schema.ts (prompts already centralized)
- Minor server index cleanup

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

apps/server/src/routes/github/routes/validate-issue.ts

@@ -30,11 +30,11 @@ import { writeValidation } from '../../../lib/validation-storage.js';
 import { streamingQuery } from '../../../providers/simple-query-service.js';
 import {
   issueValidationSchema,
-  ISSUE_VALIDATION_SYSTEM_PROMPT,
   buildValidationPrompt,
   ValidationComment,
   ValidationLinkedPR,
 } from './validation-schema.js';
+import { getPromptCustomization } from '../../../lib/settings-helpers.js';
 import {
   trySetValidationRunning,
   clearValidationStatus,
@@ -117,13 +117,17 @@ async function runValidation(
 
     let responseText = '';
 
+    // Get customized prompts from settings
+    const prompts = await getPromptCustomization(settingsService, '[ValidateIssue]');
+    const issueValidationSystemPrompt = prompts.issueValidation.systemPrompt;
+
     // Determine if we should use structured output (Claude/Codex support it, Cursor/OpenCode don't)
     const useStructuredOutput = isClaudeModel(model) || isCodexModel(model);
 
     // Build the final prompt - for Cursor, include system prompt and JSON schema instructions
     let finalPrompt = basePrompt;
     if (!useStructuredOutput) {
-      finalPrompt = `${ISSUE_VALIDATION_SYSTEM_PROMPT}
+      finalPrompt = `${issueValidationSystemPrompt}
 
 CRITICAL INSTRUCTIONS:
 1. DO NOT write any files. Return the JSON in your response only.
@@ -167,7 +171,7 @@ ${basePrompt}`;
       prompt: finalPrompt,
       model: model as string,
       cwd: projectPath,
-      systemPrompt: useStructuredOutput ? ISSUE_VALIDATION_SYSTEM_PROMPT : undefined,
+      systemPrompt: useStructuredOutput ? issueValidationSystemPrompt : undefined,
       abortController,
       thinkingLevel: effectiveThinkingLevel,
       reasoningEffort: effectiveReasoningEffort,

apps/server/src/routes/github/routes/validation-schema.ts

@@ -1,8 +1,11 @@
 /**
- * Issue Validation Schema and System Prompt
+ * Issue Validation Schema and Prompt Building
  *
  * Defines the JSON schema for Claude's structured output and
- * the system prompt that guides the validation process.
+ * helper functions for building validation prompts.
+ *
+ * Note: The system prompt is now centralized in @automaker/prompts
+ * and accessed via getPromptCustomization() in validate-issue.ts
  */
 
 /**
@@ -82,76 +85,6 @@ export const issueValidationSchema = {
   additionalProperties: false,
 } as const;
 
-/**
- * System prompt that guides Claude in validating GitHub issues.
- * Instructs the model to use read-only tools to analyze the codebase.
- */
-export const ISSUE_VALIDATION_SYSTEM_PROMPT = `You are an expert code analyst validating GitHub issues against a codebase.
-
-Your task is to analyze a GitHub issue and determine if it's valid by scanning the codebase.
-
-## Validation Process
-
-1. **Read the issue carefully** - Understand what is being reported or requested
-2. **Search the codebase** - Use Glob to find relevant files by pattern, Grep to search for keywords
-3. **Examine the code** - Use Read to look at the actual implementation in relevant files
-4. **Check linked PRs** - If there are linked pull requests, use \`gh pr diff <PR_NUMBER>\` to review the changes
-5. **Form your verdict** - Based on your analysis, determine if the issue is valid
-
-## Verdicts
-
-- **valid**: The issue describes a real problem that exists in the codebase, or a clear feature request that can be implemented. The referenced files/components exist and the issue is actionable.
-
-- **invalid**: The issue describes behavior that doesn't exist, references non-existent files or components, is based on a misunderstanding of the code, or the described "bug" is actually expected behavior.
-
-- **needs_clarification**: The issue lacks sufficient detail to verify. Specify what additional information is needed in the missingInfo field.
-
-## For Bug Reports, Check:
-- Do the referenced files/components exist?
-- Does the code match what the issue describes?
-- Is the described behavior actually a bug or expected?
-- Can you locate the code that would cause the reported issue?
-
-## For Feature Requests, Check:
-- Does the feature already exist?
-- Is the implementation location clear?
-- Is the request technically feasible given the codebase structure?
-
-## Analyzing Linked Pull Requests
-
-When an issue has linked PRs (especially open ones), you MUST analyze them:
-
-1. **Run \`gh pr diff <PR_NUMBER>\`** to see what changes the PR makes
-2. **Run \`gh pr view <PR_NUMBER>\`** to see PR description and status
-3. **Evaluate if the PR fixes the issue** - Does the diff address the reported problem?
-4. **Provide a recommendation**:
-   - \`wait_for_merge\`: The PR appears to fix the issue correctly. No additional work needed - just wait for it to be merged.
-   - \`pr_needs_work\`: The PR attempts to fix the issue but is incomplete or has problems.
-   - \`no_pr\`: No relevant PR exists for this issue.
-
-5. **Include prAnalysis in your response** with:
-   - hasOpenPR: true/false
-   - prFixesIssue: true/false (based on diff analysis)
-   - prNumber: the PR number you analyzed
-   - prSummary: brief description of what the PR changes
-   - recommendation: one of the above values
-
-## Response Guidelines
-
-- **Always include relatedFiles** when you find relevant code
-- **Set bugConfirmed to true** only if you can definitively confirm a bug exists in the code
-- **Provide a suggestedFix** when you have a clear idea of how to address the issue
-- **Use missingInfo** when the verdict is needs_clarification to list what's needed
-- **Include prAnalysis** when there are linked PRs - this is critical for avoiding duplicate work
-- **Set estimatedComplexity** to help prioritize:
-  - trivial: Simple text changes, one-line fixes
-  - simple: Small changes to one file
-  - moderate: Changes to multiple files or moderate logic changes
-  - complex: Significant refactoring or new feature implementation
-  - very_complex: Major architectural changes or cross-cutting concerns
-
-Be thorough in your analysis but focus on files that are directly relevant to the issue.`;
-
 /**
  * Comment data structure for validation prompt
  */