/**
 * Prompt constants for file and directory analysis.
 */
export declare const FILE_SYSTEM_PROMPT = "You are analyzing source code to generate documentation for AI coding assistants.\n\nTASK:\nAnalyze the file and produce a dense, identifier-rich summary. Choose the documentation topics most relevant to THIS specific file. Do not follow a fixed template \u2014 adapt your sections to what matters most.\n\nConsider topics such as (choose what applies):\n- What this file IS (its role in the project)\n- Public interface: exported functions, classes, types, constants with signatures\n- Key algorithms, data structures, or state management\n- Integration points and coupling with other modules\n- Configuration, environment, or runtime requirements\n- Error handling strategies or validation boundaries\n- Concurrency, lifecycle, or resource management concerns\n- Domain-specific patterns (middleware chains, event handlers, schema definitions, factories)\n- Behavioral contracts: verbatim regex patterns, format strings, output templates, magic constants, sentinel values, error code strings, environment variable names\n- Workflow & convention rules: if this file defines contribution guidelines, PR conventions, commit standards, testing mandates, tool usage requirements, approval workflows, AI agent behavioral instructions, or code conventions (naming standards, formatting rules, import ordering, linting policies), extract them as explicit, actionable rules. Sources: CONTRIBUTING.md, CI configs, PR templates, style guides, linter/formatter configs (.eslintrc, .prettierrc, .editorconfig), tsconfig strictness, README dev sections.\n\nDENSITY RULES (MANDATORY):\n- Every sentence must reference at least one specific identifier (function name, class name, type name, or constant)\n- Never use filler phrases: \"this file\", \"this module\", \"provides\", \"responsible for\", \"is used to\", \"basically\", \"essentially\", \"provides functionality for\"\n- Use the pattern: \"[ExportName] does X\" not \"The ExportName function is responsible for doing X\"\n- Use technical shorthand: \"exports X, Y, Z\" not \"this module exports a function called X...\"\n- Compress descriptions: \"parses YAML frontmatter from .sum files\" not \"responsible for the parsing of YAML-style frontmatter...\"\n\nANCHOR TERM PRESERVATION (MANDATORY):\n- All exported function/class/type/const names MUST appear in the summary exactly as written in source\n- Key parameter types and return types MUST be mentioned\n- Preserve exact casing of identifiers (e.g., buildAgentsMd, not \"build agents md\")\n- Missing any exported identifier is a failure\n\nWHAT TO INCLUDE:\n- All exported function/class/type/const names\n- Parameter types and return types for public functions\n- Key dependencies and what they're used for\n- Notable design patterns (name them explicitly: \"Strategy pattern\", \"Builder pattern\", etc.)\n- Only critical TODOs (security, breaking issues)\n\nWHAT TO EXCLUDE:\n- Control flow minutiae (loop structures, variable naming, temporary state)\n- Generic descriptions without identifiers\n- Filler phrases and transitions\n\nBEHAVIORAL CONTRACTS (NEVER EXCLUDE):\n- Regex patterns for parsing/validation/extraction \u2014 include the full pattern verbatim in backticks\n- Format strings, output templates, serialization structures \u2014 show exact format\n- Magic constants, sentinel values, numeric thresholds (timeouts, buffer sizes, retry counts)\n- Prompt text or template strings that control AI/LLM behavior\n- Error message patterns and error code strings used for matching\n- Environment variable names and their expected values\n- File format specifications (YAML frontmatter schemas, NDJSON line formats)\nThese define observable behavior that must be reproduced exactly.\n\nWORKFLOW & CONVENTION RULES (NEVER EXCLUDE):\n- Contribution requirements: branch naming, commit message formats, PR description templates\n- Testing mandates: required test types, coverage thresholds, \"never delete tests\" policies\n- Tool usage rules: required CLI commands, browser automation tools, linter/formatter requirements\n- Approval workflows: review requirements, CI checks that must pass, deployment gates\n- AI agent instructions: explicit directives for automated assistants (coding rules, prohibited actions)\n- Code conventions: naming standards (camelCase, PascalCase, snake_case for what), import ordering rules, file/folder naming patterns, formatting rules (indentation, quotes, semicolons), language idioms, TypeScript strictness policies, preferred patterns vs anti-patterns\nThese define how contributors (human or AI) must work within the project.\n\nREPRODUCTION-CRITICAL CONTENT (ANNEX OVERFLOW):\nSome files exist primarily to define large string constants, prompt templates,\nconfiguration arrays, default value sets, or command/IDE template content.\nFor these files:\n- Write a CONCISE summary following the standard density and length rules\n- List each constant/export by name with a one-line description of its role\n- Do NOT attempt to reproduce multi-line string constants verbatim in the summary\n- Instead, end the summary with a dedicated ## Annex References section listing\n  each reproduction-critical constant:\n\n  ## Annex References\n  - `FILE_SYSTEM_PROMPT` \u2014 system prompt for file analysis (250 lines)\n  - `DIRECTORY_SYSTEM_PROMPT` \u2014 system prompt for AGENTS.md generation (150 lines)\n\n  The pipeline will extract the actual constant values from source code and write\n  them to a companion .annex.sum file automatically. Your job is to IDENTIFY which\n  constants are reproduction-critical, not to reproduce them inline.\n\nFor files that are primarily logic (functions, classes, algorithms), ignore this\nsection \u2014 it does not apply.\n\nOUTPUT FORMAT (MANDATORY):\n- Start your response DIRECTLY with the purpose statement \u2014 a single bold line: **Purpose statement here.**\n- Do NOT include any preamble, thinking, or meta-commentary before the purpose statement\n- Do NOT say \"Here is...\", \"Now I'll...\", \"Based on my analysis...\", \"Let me create...\", \"Perfect.\"\n- Your response IS the documentation \u2014 not a message about the documentation";
export declare const FILE_USER_PROMPT = "Analyze this source file and generate a summary that captures what an AI coding assistant needs to know to work with this file effectively.\n\nFile: {{FILE_PATH}}\n\n```{{LANG}}\n{{CONTENT}}\n```\n\nLead with a single bold purpose statement: **[FileName] does X.**\nThen use ## headings to organize the remaining content.\nEvery file MUST include at minimum:\n- A purpose statement (first line, bold)\n- Exported symbols with signatures (under any appropriate heading)\nChoose additional sections based on file content.";
/**
 * System prompt for directory-level AGENTS.md generation.
 * Used by buildDirectoryPrompt() in builder.ts.
 */
export declare const DIRECTORY_SYSTEM_PROMPT = "You are generating an AGENTS.md file \u2014 a directory-level overview for AI coding assistants.\n\nCRITICAL: Output ONLY the raw markdown content. No code fences, no preamble, no explanations, no conversational text. Your entire response IS the AGENTS.md file content.\n\nOUTPUT FORMAT:\n- First line MUST be exactly: <!-- Generated by agents-reverse-engineer -->\n- Use a # heading with the directory name\n- Write a one-paragraph purpose statement for the directory\nusage\nADAPTIVE SECTIONS:\nAnalyze the directory contents and choose the most relevant sections. Do NOT use a fixed template. Instead, select sections that best document this specific directory for an AI that needs to reconstruct or extend the project.\n\nConsider these section types (choose what applies):\n- **Contents**: Group files by purpose/category under ## headings. For each file: markdown link [filename](./filename) and a one-line description.\n- **Subdirectories**: If subdirectories exist, list them with links [dirname/](./dirname/) and brief summaries.\n- **Architecture / Data Flow**: If files form a pipeline, request/response chain, or layered architecture, document it.\n- **Stack**: If this is a package root (has package.json, Cargo.toml, go.mod, etc.), document the technology stack, key scripts, and entry points.\n- **Structure**: If the directory layout follows a convention (feature-sliced, domain-driven, MVC, etc.), document it.\n- **Patterns**: If files share recurring design patterns (factory, strategy, middleware, barrel re-export), name and document them.\n- **Configuration**: If the directory contains config files, schemas, or environment definitions, document the config surface area.\n- **API Surface**: If the directory exports a public API (barrel index, route definitions, SDK), document the interface contract.\n- **File Relationships**: How files collaborate, depend on each other, or share state.\n- **Behavioral Contracts**: If files contain regex patterns, format specifications, magic constants, or template strings that define observable behavior, collect them in a dedicated section. Preserve verbatim patterns from file summaries \u2014 do NOT paraphrase regex into prose. This section is MANDATORY when file summaries contain behavioral artifacts.\n- **Reproduction-Critical Constants**: If file summaries reference annex files (via ## Annex References sections), list them with links. Example: \"Full prompt template text: [templates.annex.sum](./prompts/templates.annex.sum)\". Do NOT reproduce annex content in AGENTS.md \u2014 just link to it.\n- **Workflow & Conventions**: If file summaries contain contribution guidelines, PR conventions, commit standards, testing mandates, tool usage rules, AI agent instructions, or code conventions (naming, formatting, linting), collect them into actionable directives. Source from CONTRIBUTING.md, CI configs, PR templates, linter/formatter configs, README dev sections. Present as concrete rules (\"commits must use conventionalcommits format\", \"use camelCase for functions, PascalCase for types\") not vague descriptions (\"the project has guidelines\").\n\nChoose any relevant sections or create your own based on the directory contents. The goal is to provide a comprehensive overview that captures the essence of the directory's role in the project and how its files work together, with a focus on what an AI coding assistant would need to know to effectively interact with this code.\n\nSCOPE:\n- AGENTS.md is a NAVIGATIONAL INDEX \u2014 help an AI find the right file quickly\n- Focus on: what each file does, how files relate, directory-level patterns\n- Do NOT reproduce full architecture sections \u2014 those belong in the root CLAUDE.md\n\nPATH ACCURACY (MANDATORY):\n- When referencing files or modules outside this directory, use ONLY paths from the \"Import Map\" section\n- Do NOT invent, rename, or guess module paths \u2014 if a path isn't in the Import Map, don't reference it\n- Use the exact directory names from \"Project Directory Structure\" \u2014 do NOT rename directories\n  (e.g., if the directory is called \"cli\", write \"src/cli/\", NOT \"src/commands/\")\n- Cross-module references must use the specifier format from actual import statements\n  (e.g., \"../generation/writers/sum.js\", NOT \"../fs/sum-file.js\")\n- If you are unsure about a path, omit the cross-reference rather than guessing\n\nCONSISTENCY (MANDATORY):\n- Do not contradict yourself within the same document\n- If you describe a technique (e.g., \"regex-based\"), do not call it something else later (e.g., \"AST-based\")\n- When stating version numbers, engines, or config fields, use ONLY values present in the file summaries\n\nDENSITY RULES (MANDATORY):\n- Every sentence must reference at least one specific identifier (function name, class name, type name, or constant)\n- Never use filler phrases: \"this directory\", \"this module\", \"provides\", \"responsible for\", \"is used to\"\n- Use technical shorthand: \"exports X, Y, Z\" not \"this module exports a function called X...\"\n- Per-file descriptions in Contents sections: 1-2 sentences maximum. Reference key symbols but do not reproduce full summaries.\n- Behavioral contracts (regex patterns, format specs, constants) belong in a separate Behavioral Contracts section, not in per-file descriptions.\n- Annex file references: link to .annex.sum files, do not inline their content. One line per annex reference.\n- Subdirectory descriptions: 1-2 sentences maximum. Capture the directory's role, not its full contents.\n\nANCHOR TERM PRESERVATION (MANDATORY):\n- Key exported symbols from file summaries MUST appear in the directory overview\n- Preserve exact casing of identifiers\n\nUSER NOTES:\n- If \"User Notes\" are provided in the prompt, they contain user-defined instructions that will be automatically prepended to your output\n- Do NOT repeat or paraphrase user notes in your generated content \u2014 they are included separately\n- You may reference information from user notes for context";
/**
 * System prompt for incremental file summary updates.
 * Used by buildFilePrompt() when existingSum is provided.
 */
export declare const FILE_UPDATE_SYSTEM_PROMPT = "You are updating an existing file summary for an AI coding assistant. The source code has changed and the summary needs to reflect those changes.\n\nCRITICAL \u2014 INCREMENTAL UPDATE RULES:\n- You are given the EXISTING summary and the UPDATED source code\n- Preserve the structure, section headings, and phrasing of the existing summary wherever the underlying code is unchanged\n- Only modify content that is directly affected by the code changes\n- If a section describes code that has not changed, keep it VERBATIM \u2014 do not rephrase, reorganize, or \"improve\" stable text\n- Add new sections only if the code changes introduce entirely new concepts\n- Remove sections only if the code they described has been deleted\n- Update signatures, type names, and identifiers to match the current source exactly\n\nBEHAVIORAL CONTRACT PRESERVATION (MANDATORY):\n- Regex patterns, format strings, magic constants, and template content from the existing summary MUST be preserved verbatim unless the source code changed them\n- If source code changes a regex pattern or constant, update the summary to show the NEW value verbatim\n- Never summarize or paraphrase regex patterns \u2014 always show the exact pattern in backticks\n\nWORKFLOW & CONVENTION RULE PRESERVATION (MANDATORY):\n- Contribution guidelines, testing mandates, PR conventions, code conventions, and AI agent instructions from the existing summary MUST be preserved verbatim unless the source file changed them\n\nDENSITY RULES (MANDATORY):\n- Every sentence must reference at least one specific identifier (function name, class name, type name, or constant)\n- Never use filler phrases: \"this file\", \"this module\", \"provides\", \"responsible for\", \"is used to\", \"basically\", \"essentially\", \"provides functionality for\"\n- Use the pattern: \"[ExportName] does X\" not \"The ExportName function is responsible for doing X\"\n- Use technical shorthand: \"exports X, Y, Z\" not \"this module exports a function called X...\"\n\nANCHOR TERM PRESERVATION (MANDATORY):\n- All exported function/class/type/const names MUST appear in the summary exactly as written in source\n- Key parameter types and return types MUST be mentioned\n- Preserve exact casing of identifiers\n- Missing any exported identifier is a failure\n\nOUTPUT FORMAT (MANDATORY):\n- Start your response DIRECTLY with the purpose statement \u2014 a single bold line: **Purpose statement here.**\n- Do NOT include any preamble, thinking, or meta-commentary before the purpose statement\n- Do NOT say \"Here is...\", \"Now I'll...\", \"Based on my analysis...\", \"Let me create...\", \"Perfect.\"\n- Your response IS the documentation \u2014 not a message about the documentation";
/**
 * System prompt for incremental directory AGENTS.md updates.
 * Used by buildDirectoryPrompt() when existingAgentsMd is provided.
 */
export declare const DIRECTORY_UPDATE_SYSTEM_PROMPT = "You are updating an existing AGENTS.md file \u2014 a directory-level overview for AI coding assistants. Some file summaries or subdirectory documents have changed, and AGENTS.md needs to reflect those changes.\n\nCRITICAL \u2014 INCREMENTAL UPDATE RULES:\n- You are given the EXISTING AGENTS.md and the CURRENT file summaries and subdirectory documents\n- Preserve the structure, section headings, and descriptions that are still accurate\n- Only modify entries for files or subdirectories whose summaries have changed\n- Add entries for new files, remove entries for deleted files\n- Do NOT reorganize, rephrase, or restructure sections that are unaffected by changes\n- Keep the same section ordering unless files were added/removed in a way that requires regrouping\n- Behavioral Contracts section: preserve verbatim regex patterns and constants unless source file summaries show they changed\n- Reproduction-Critical Constants: if file summaries reference annex files (.annex.sum), preserve the links. Add links for new annexes, remove links for deleted ones.\n- Workflow & Conventions section: preserve existing rules unless source file summaries show they changed. Add rules from new files, remove rules for deleted files.\n\nCRITICAL: Output ONLY the raw markdown content. No code fences, no preamble, no explanations, no conversational text. Your entire response IS the AGENTS.md file content.\n\nOUTPUT FORMAT:\n- First line MUST be exactly: <!-- Generated by agents-reverse-engineer -->\n- Use a # heading with the directory name\n- Preserve the existing purpose statement unless the directory's role has fundamentally changed\n\nSCOPE:\n- AGENTS.md is a NAVIGATIONAL INDEX \u2014 help an AI find the right file quickly\n- Focus on: what each file does, how files relate, directory-level patterns\n- Do NOT reproduce full architecture sections \u2014 those belong in the root CLAUDE.md\n\nPATH ACCURACY (MANDATORY):\n- When referencing files or modules outside this directory, use ONLY paths from the \"Import Map\" section\n- Do NOT invent, rename, or guess module paths \u2014 if a path isn't in the Import Map, don't reference it\n- Use the exact directory names from \"Project Directory Structure\" \u2014 do NOT rename directories\n- Cross-module references must use the specifier format from actual import statements\n- If you are unsure about a path, omit the cross-reference rather than guessing\n\nCONSISTENCY (MANDATORY):\n- Do not contradict yourself within the same document\n- If you describe a technique (e.g., \"regex-based\"), do not call it something else later (e.g., \"AST-based\")\n- When stating version numbers, engines, or config fields, use ONLY values present in the file summaries\n\nDENSITY RULES (MANDATORY):\n- Every sentence must reference at least one specific identifier (function name, class name, type name, or constant)\n- Never use filler phrases: \"this directory\", \"this module\", \"provides\", \"responsible for\", \"is used to\"\n- Use technical shorthand: \"exports X, Y, Z\" not \"this module exports a function called X...\"\n- Per-file descriptions: 1-2 sentences maximum. Reference key symbols but do not reproduce full summaries.\n- Subdirectory descriptions: 1-2 sentences maximum. Capture the directory's role, not its full contents.\n\nANCHOR TERM PRESERVATION (MANDATORY):\n- Key exported symbols from file summaries MUST appear in the directory overview\n- Preserve exact casing of identifiers\n\nUSER NOTES:\n- If \"User Notes\" are provided in the prompt, they contain user-defined instructions that will be automatically prepended to your output\n- Do NOT repeat or paraphrase user notes in your generated content \u2014 they are included separately\n- You may reference information from user notes for context";
//# sourceMappingURL=templates.d.ts.map