mindforge-cc 11.2.1 → 11.3.1

package/.agent/mindforge/plan-phase.md

@@ -0,0 +1,131 @@
+---
+description: Plan a project phase. Usage: /mindforge:plan-phase [N]
+---
+
+Plan a project phase. Usage: /mindforge:plan-phase [N]
+
+## Pre-check
+If N is not given, read STATE.md for the current phase number and increment by 1.
+Read PROJECT.md, REQUIREMENTS.md, ARCHITECTURE.md, and STATE.md before proceeding.
+
+## Pre-read (before any questions or planning)
+
+Read these files in order:
+1. `AGENTS_LEARNING.md` (MUST READ to avoid repeating past mistakes)
+2. `.planning/PROJECT.md`
+3. `.planning/REQUIREMENTS.md`
+4. `.planning/ARCHITECTURE.md`
+5. `.planning/STATE.md`
+6. `.planning/phases/phase-[N]/CONTEXT.md` (if it exists)
+
+### If CONTEXT.md exists for phase [N]:
+This means `/mindforge:discuss-phase [N]` was already run.
+The user's implementation decisions are already captured.
+DO NOT re-ask questions that CONTEXT.md already answers.
+Read CONTEXT.md completely before asking any clarifying questions.
+Report: "I've read the phase discussion context. [N] decisions were captured.
+Planning will follow these decisions."
+
+### If CONTEXT.md has open questions:
+Read the "Open questions" section in CONTEXT.md.
+Present unresolved questions to the user NOW, before planning begins.
+Do not create plans that assume answers to open questions without confirming first.
+
+### If CONTEXT.md does NOT exist for phase [N]:
+Proceed normally with the discussion → planning flow.
+
+## Step 1 — Discuss phase scope
+Ask:
+1. "Describe what Phase [N] should accomplish. 2-3 sentences."
+2. "Have you already made any implementation decisions for this phase?
+    (libraries, patterns, approaches) If yes, list them."
+3. "Are there any constraints I should know about?
+    (deadlines, dependencies on other teams, tech limitations)"
+
+Write answers to `.planning/phases/phase-[N]/CONTEXT.md`.
+
+If `.planning/phases/phase-[N]/CONTEXT.md` already exists:
+1. Read it first.
+2. If it has "Open questions", ask the user to resolve them before planning.
+3. Update CONTEXT.md with the answers and mark those questions as resolved.
+
+### If CONTEXT.md exists — skip already-answered questions
+Only ask about areas NOT covered in CONTEXT.md.
+Example: if CONTEXT.md captures the layout decision, do not ask "What layout do you want?"
+Respect the prior discussion. Build on it. Do not repeat it.
+
+## Step 2 — Domain research (spawn subagent)
+Spawn a research subagent with this context only:
+- The tech stack from PROJECT.md
+- The phase scope from CONTEXT.md
+- CONVENTIONS.md
+
+Instruct it to investigate:
+1. Best available libraries for this phase's requirements (with version numbers)
+2. Common pitfalls and anti-patterns for this tech domain
+3. Project-specific anti-patterns from `AGENTS_LEARNING.md`
+4. Relevant architectural patterns (with tradeoffs)
+5. Any known security considerations specific to this domain
+
+Write findings to `.planning/phases/phase-[N]/RESEARCH.md`.
+
+## Step 3 — Create atomic task plans
+Based on CONTEXT.md and RESEARCH.md, create 3-6 PLAN files.
+Each plan must be completable in a single fresh context window.
+Each plan targets specific files — no plan should touch more than 6 files.
+
+File naming: `.planning/phases/phase-[N]/PLAN-[N]-[NN].md`
+Example: `.planning/phases/1/PLAN-1-01.md`
+
+Each plan uses this XML format:
+
+```xml
+<task type="auto">
+  <n>Short descriptive task name</n>
+  <persona>developer</persona>
+  <phase>[N]</phase>
+  <plan>[NN]</plan>
+  <dependencies>List any PLAN files that must complete before this one, or "none"</dependencies>
+  <files>
+    src/exact/file/path.ts
+    src/another/file.ts
+  </files>
+  <context>
+    Relevant decisions from ARCHITECTURE.md:
+    - [decision]
+    Skills to load before starting:
+    - [skill name if applicable, or "none"]
+  </context>
+  <action>
+    Precise implementation instructions.
+    Include exact library names and versions.
+    Include the approach, not just the goal.
+    Include specific anti-patterns to avoid.
+  </action>
+  <verify>
+    [Exact runnable command or check]
+    Example: curl -X POST localhost:3000/api/auth/login -d '{"email":"test@test.com","password":"test"}' | jq .status
+    Must produce a deterministic pass/fail result.
+  </verify>
+  <done>One sentence definition of done.</done>
+</task>
+```
+
+## Step 4 — Validate plans
+Check every plan against REQUIREMENTS.md:
+- Does this plan implement anything out of scope? If yes: revise.
+- Does this plan contradict ARCHITECTURE.md? If yes: create an ADR first.
+- Is the `<verify>` step actually runnable? If no: rewrite it.
+
+## Step 5 — Update state and confirm
+Update STATE.md: current phase = N, status = "Phase N planned, ready to execute".
+
+Tell the user:
+"✅ Phase [N] planned. [X] task plans created.
+
+Plans:
+  PLAN-[N]-01: [task name]
+  PLAN-[N]-02: [task name]
+  ...
+
+Run /mindforge:execute-phase [N] to begin execution."

package/.agent/mindforge/plan-write.md

@@ -0,0 +1,95 @@
+---
+description: "Generate no-placeholder implementation plan with complete steps. Usage: /mindforge:plan-write [spec-or-description] [--steps N] [--verify]"
+---
+
+<objective>
+Produce a complete, zero-placeholder implementation plan where every step contains exact file paths, complete code, and verification commands. No TODOs, no "implement here", no ambiguity — every step is directly executable.
+</objective>
+
+<execution_context>
+@.mindforge/skills/writing-plans/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (specification text or file path, optional --steps N for target step count, optional --verify to include verification per step)
+Knowledge: ARCHITECTURE.md, CONVENTIONS.md, current codebase structure, dependency graph.
+</context>
+
+<process>
+1. **Parse spec**: Read and understand the specification or description:
+   - If argument is a file path: read the file content
+   - If argument is inline text: parse as the requirement
+   - Identify the scope: what files need to change, what new files are needed
+   - Identify constraints: performance, security, backward compatibility
+   - Determine target step count (--steps N, default: auto-size based on complexity)
+
+2. **Decompose into bite-sized steps**: Break the work into atomic steps where each step:
+   - Changes 1-3 files maximum
+   - Can be verified independently
+   - Builds on the previous step (no forward references)
+   - Is small enough to hold entirely in working memory
+   - Has a clear "done" state visible from the outside
+
+3. **For each step — specify exact file paths**: Every step must state:
+   - Full absolute file path(s) being created or modified
+   - Whether the file is new (create) or existing (modify)
+   - The specific location within the file (after which function, which line range)
+   - Import/dependency changes needed for this step
+
+4. **For each step — provide complete code**: Every step must include:
+   - The exact code to write or the exact diff to apply
+   - No placeholder comments ("// TODO: implement this")
+   - No ellipsis ("...")  or abbreviated code
+   - No "similar to above" references — repeat if needed
+   - Complete import statements at the top of new files
+   - Full function signatures with types
+
+5. **Add verification per step** (always if --verify, otherwise for critical steps):
+   - Command to run that proves the step works (test, build, lint, curl)
+   - Expected output or success criteria
+   - What to do if verification fails (specific fix, not "debug")
+   - Verification must be automated (no manual "check in browser")
+
+6. **Number dependencies**: For each step, declare:
+   - `depends_on: [step numbers]` — which steps must complete first
+   - `parallelizable_with: [step numbers]` — which steps can run concurrently
+   - `blocks: [step numbers]` — which steps are waiting on this one
+   - This enables parallel execution where possible
+
+7. **Handle existing code**: When modifying existing files:
+   - Show the exact lines being replaced (old code)
+   - Show the exact replacement (new code)
+   - Include enough context (3-5 surrounding lines) for unambiguous placement
+   - Note if the change requires changes in other files (ripple effects)
+
+8. **Include rollback instructions**: For risky steps:
+   - What to revert if the step causes problems
+   - Git command to undo (specific commit or file checkout)
+   - Whether downstream steps need adjustment after rollback
+
+9. **Output plan document**: Write the plan in structured format:
+   ```
+   # Implementation Plan: [title]
+   ## Metadata
+   - Total steps: N
+   - Estimated effort: [time]
+   - Risk level: low|medium|high
+   - Parallelizable steps: [list]
+   
+   ## Step 1: [descriptive title]
+   - Files: [exact paths]
+   - Depends on: none
+   - Code: [complete implementation]
+   - Verify: [command + expected output]
+   
+   ## Step 2: ...
+   ```
+
+10. **Final validation**: Before outputting, verify the plan:
+    - Every file referenced actually exists (for modifications) or has a create step
+    - No circular dependencies between steps
+    - Import graph is consistent (nothing imports from a file not yet created)
+    - All types/interfaces referenced are defined somewhere in the plan
+    - Running all steps in order produces a working, compilable result
+    - No placeholders, TODOs, or ambiguous instructions remain
+</process>

package/.agent/mindforge/plant-seed.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:plant-seed
+description: Capture speculative ideas with triggers that surface automatically when relevant
+argument-hint: <idea>
+allowed-tools:
+  - list_dir
+  - write_to_file
+  - view_file
+---
+
+<objective>
+Capture speculative or long-term ideas (seeds) and store them in a way that they can be automatically resurfaced when a relevant future milestone or phase is started.
+</objective>
+
+<execution_context>
+.claude/commands/mindforge/plant-seed.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (The speculative idea)
+Storage: .planning/seeds/
+Trigger mechanism: Files in this directory are checked during `init-project` or `milestone` creation.
+</context>
+
+<process>
+1. **Ensure storage**: Verify `.planning/seeds/` exists; create if not.
+2. **Generate filename**: Create a slugified filename based on the idea or a timestamp.
+3. **Write seed**: Create a markdown file with the idea, any inferred triggers (tags/keywords), and the current timestamp.
+4. **Link to system**: Add a note to the master seed index if one exists.
+5. **Confirm**: Let the user know the seed has been planted and what might trigger its resurrection.
+</process>

package/.agent/mindforge/platform.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:platform
+description: "Design internal developer platform. Usage: /mindforge:platform [scope] [--tool backstage|custom] [--teams number]"
+argument-hint: "[scope] [--tool backstage|custom] [--teams number]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design comprehensive platform system architecture with best practices and production-ready patterns.
+</objective>
+
+<execution_context>
+@.mindforge/skills/internal-developer-platform/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/internal-developer-platform/`
+State: Analyzes requirements, constraints, and scale to generate optimized platform architecture.
+</context>
+
+<process>
+1. **Requirement Analysis**: Analyze domain-specific requirements, performance constraints, and scalability needs.
+2. **Architecture Design**: Design system architecture with component interaction patterns and data flow.
+3. **Technology Selection**: Evaluate and select appropriate technologies, tools, and frameworks.
+4. **Integration Strategy**: Define integration patterns with existing systems and external dependencies.
+5. **Optimization Approach**: Implement performance, cost, and resource optimization strategies.
+6. **Monitoring Framework**: Design observability, alerting, and debugging mechanisms.
+7. **Deployment Planning**: Create deployment strategy with rollback procedures and disaster recovery.
+</process>

package/.agent/mindforge/plugins.md

@@ -0,0 +1,44 @@
+---
+description: Read PLUGINS-MANIFEST.md. Display installed plugins with version and permissions.
+---
+
+# MindForge — Plugins Command
+# Usage: /mindforge:plugins [list|install|uninstall|info|validate|create] [name]
+
+## list
+Read PLUGINS-MANIFEST.md. Display installed plugins with version and permissions.
+If no plugins: "No plugins installed. Find plugins: npm search mindforge-plugin"
+
+## install [plugin-name]
+Full installation protocol per plugin-loader.md:
+1. Resolve package: `mindforge-plugin-[name]` convention
+2. Download to chmod 700 temp directory
+3. Validate plugin.json manifest
+4. Check plugin_api_version compatibility (1.0.0 required)
+5. Run injection guard on ALL .md files in the plugin
+6. Run Level 1 + 2 skill validation on all SKILL.md files
+7. Display permission list for user approval:
+   ```
+   Plugin: mindforge-plugin-jira-advanced v1.0.0
+   Requests these permissions:
+     • read_audit_log:  read AUDIT.jsonl ✅ (safe)
+     • write_audit_log: append to AUDIT.jsonl ⚠️
+     • network_access:  make HTTP requests ⚠️
+   Install? (yes/no)
+   ```
+8. Install components (commands, skills, personas, hooks)
+9. Add to PLUGINS-MANIFEST.md
+10. Write AUDIT entry
+
+## uninstall [plugin-name]
+Remove all installed components. Update PLUGINS-MANIFEST.md.
+Confirm: "This will remove [N] commands, [N] skills from this plugin."
+
+## info [plugin-name]
+Display: version, description, author, permissions, commands, skills, personas, hooks.
+
+## validate
+Validate all installed plugins for compatibility, injection safety, permission scope.
+
+## create [plugin-name]
+Generate a plugin scaffold:

package/.agent/mindforge/pr-review.md

@@ -0,0 +1,45 @@
+---
+description: Run the AI PR review engine on a pull request diff.
+---
+
+# MindForge — PR Review Command
+# Usage: /mindforge:pr-review [--diff path] [--sha base..head] [--output github|json|markdown]
+
+Run the AI PR review engine on a pull request diff.
+
+Steps:
+1. Determine diff source:
+   - `--diff path`: read diff from file
+   - `--sha base..head`: run `git diff base..head`
+   - Default: `git diff HEAD~1` (last commit) or `git diff --staged` (staged changes)
+
+2. Load review context (per ai-reviewer.md):
+   - PROJECT.md, ARCHITECTURE.md, CONVENTIONS.md, SECURITY.md
+   - Current phase's CONTEXT.md (if in an active phase)
+   - Any active ADRs relevant to changed files
+
+3. Detect change type and select review template:
+   - Auth/security changes → Security-focused review template
+   - Database migrations → Database migration review template
+   - API changes → API breaking change review template
+   - Default → Standard review template
+
+4. Check API availability:
+   - ANTHROPIC_API_KEY set? If not: warn and skip AI review
+   - Check daily review limit (from ai-reviewer.md)
+   - Check cache: has this SHA been reviewed in the last 60 minutes?
+
+5. Call Claude API (per ai-reviewer.md buildSystemPrompt + buildReviewPrompt)
+   - Handle errors gracefully — API unavailable is NOT a build failure
+   - Timeout: 60 seconds
+
+6. Format output per --output flag:
+   - github: GitHub-flavoured markdown for PR comment
+   - json: structured JSON with findings array
+   - markdown: standard markdown
+
+7. Write to output:
+   - If in CI: write to /tmp/mindforge-review.md (read by GitHub Actions step)
+   - If interactive: display to user
+
+8. Write AUDIT entry

package/.agent/mindforge/privacy-eng.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:privacy-eng
+description: "Design data privacy engineering system. Usage: /mindforge:privacy-eng [system] [--regulation gdpr|ccpa|hipaa] [--technique anonymization|differential|encryption]"
+argument-hint: "[system] [--regulation gdpr|ccpa|hipaa] [--technique anonymization|differential|encryption]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design comprehensive privacy-eng system architecture with best practices and production-ready patterns.
+</objective>
+
+<execution_context>
+@.mindforge/skills/data-privacy-engineering/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/data-privacy-engineering/`
+State: Analyzes requirements, constraints, and scale to generate optimized privacy-eng architecture.
+</context>
+
+<process>
+1. **Requirement Analysis**: Analyze domain-specific requirements, performance constraints, and scalability needs.
+2. **Architecture Design**: Design system architecture with component interaction patterns and data flow.
+3. **Technology Selection**: Evaluate and select appropriate technologies, tools, and frameworks.
+4. **Integration Strategy**: Define integration patterns with existing systems and external dependencies.
+5. **Optimization Approach**: Implement performance, cost, and resource optimization strategies.
+6. **Monitoring Framework**: Design observability, alerting, and debugging mechanisms.
+7. **Deployment Planning**: Create deployment strategy with rollback procedures and disaster recovery.
+</process>

package/.agent/mindforge/product-spec.md

@@ -0,0 +1,90 @@
+---
+description: "Create PRD with user stories and prioritized backlog. Usage: /mindforge:product-spec [feature] [--framework RICE|MoSCoW]"
+---
+
+<objective>
+Generate a Product Requirements Document with well-defined personas, user journeys, scored user stories, and a prioritized backlog ready for sprint planning. Outputs an actionable PRD with acceptance criteria.
+</objective>
+
+<execution_context>
+@.mindforge/skills/product-manager/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (feature name or description, optional --framework for prioritization)
+Knowledge: PROJECT.md, existing BRDs, market research, competitive analysis, user feedback.
+</context>
+
+<process>
+1. **Define personas**: Create 2-4 user personas relevant to the feature:
+   - Name, role, and demographic summary
+   - Goals and motivations
+   - Pain points and frustrations
+   - Technical proficiency level
+   - Key quote that captures their mindset
+   - Usage frequency (daily, weekly, monthly)
+
+2. **Map user journeys**: For each persona, trace the end-to-end journey:
+   - Trigger (what initiates the journey)
+   - Steps (each action the user takes)
+   - Touchpoints (where they interact with the system)
+   - Emotions at each step (frustrated, neutral, delighted)
+   - Drop-off risk points
+   - Success criteria for journey completion
+
+3. **Write user stories**: For each journey step that requires system behavior:
+   - Format: "As a [persona], I want to [action] so that [outcome]"
+   - Include edge cases as separate stories
+   - Tag with epic/theme grouping
+   - Estimate complexity (story points: 1, 2, 3, 5, 8, 13)
+
+4. **Score with framework**: Apply the selected prioritization framework:
+   - **RICE**: Reach * Impact * Confidence / Effort (score each 1-10)
+   - **MoSCoW**: Must have / Should have / Could have / Won't have
+   - Document scoring rationale for each story
+   - Flag any stories where team disagrees on score
+
+5. **Prioritize backlog**: Rank all stories by framework score:
+   - Group into release milestones (MVP, v1.1, v1.2, future)
+   - Identify dependencies between stories (must-before relationships)
+   - Mark stories that can be parallelized
+   - Calculate total effort per milestone
+
+6. **Define acceptance criteria**: For each Must-have story:
+   - Given-When-Then scenarios (happy path + error paths)
+   - Performance expectations (load time, response time)
+   - Accessibility requirements (WCAG level)
+   - Cross-browser/device requirements
+   - Data validation rules
+
+7. **Output PRD**: Write the complete PRD with sections:
+   - Problem Statement (what pain are we solving, for whom, why now)
+   - Goals and Non-Goals (explicitly state what we will NOT do)
+   - Personas and User Journeys
+   - Feature Requirements (prioritized backlog)
+   - Technical Constraints and Dependencies
+   - Success Metrics (leading and lagging indicators)
+   - Release Plan (milestones with dates)
+   - Open Questions and Risks
+
+8. **Define success metrics**: For the feature overall:
+   - Adoption metric (% of target users who try it)
+   - Engagement metric (frequency/depth of usage)
+   - Retention metric (continued usage after 30 days)
+   - Business metric (revenue, cost reduction, NPS impact)
+   - Technical metric (error rate, latency, support tickets)
+
+9. **Risk assessment**: Identify risks to successful delivery:
+   - Technical risks (feasibility, integration complexity)
+   - Market risks (user adoption, competitive response)
+   - Resource risks (team availability, skill gaps)
+   - Timeline risks (dependencies, scope creep triggers)
+   - Mitigation plan for each risk
+
+10. **Stakeholder review package**: Prepare summary for review:
+    - One-page executive summary
+    - Prioritized feature list with effort estimates
+    - Key trade-off decisions requiring input
+    - Timeline with confidence intervals
+    - Request specific decisions from specific stakeholders
+</process>

package/.agent/mindforge/profile-team.md

@@ -0,0 +1,27 @@
+---
+description: Generate and maintain team/developer profiles for response personalization.
+---
+
+# MindForge — Profile Team Command
+# Usage: /mindforge:profile-team [--refresh] [--developer email] [--questionnaire]
+
+Generate and maintain team/developer profiles for response personalization.
+
+## Data sources
+1. Declared questionnaire preferences
+2. Inferred patterns from AUDIT + git history + metrics
+3. Defaults from org conventions
+
+## Outputs
+- `.mindforge/team/TEAM-PROFILE.md`
+- `.mindforge/team/profiles/PROFILE-[dev-id].md`
+
+## Modes
+- `--refresh`: inference-only update
+- `--developer`: target one developer profile
+- `--questionnaire`: prompt preference questions before writing
+
+## AUDIT
+```json
+{ "event": "team_profile_updated", "developers_profiled": 1, "method": "inferred" }
+```

package/.agent/mindforge/prompt.md

@@ -0,0 +1,78 @@
+---
+description: "Design and optimize AI prompts with caching strategy. Usage: /mindforge:prompt [task-description] [--style system|few-shot|cot] [--cache]"
+---
+
+<objective>
+Design and optimize AI prompts with appropriate structure, caching strategy, and iteration based on edge-case testing — producing production-grade prompts that maximize model performance.
+</objective>
+
+<execution_context>
+@.mindforge/skills/prompt-engineering/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (task description, optional --style system|few-shot|cot, optional --cache flag)
+Knowledge: Current system prompts, model capabilities, prompt caching mechanics, few-shot example libraries.
+</context>
+
+<process>
+1. **Analyze task**: Understand the task requirements:
+   - What is the desired output format and quality bar?
+   - What model will execute this prompt? (capabilities, context window)
+   - What failure modes are likely? (hallucination, refusal, drift)
+   - What constraints exist? (token budget, latency, cost)
+   - Is this a one-shot task or a recurring pattern?
+
+2. **Select prompt style**: Based on --style flag or task analysis:
+   - `system`: Structured system prompt with role, constraints, and output format
+   - `few-shot`: System prompt + curated examples demonstrating desired behavior
+   - `cot`: Chain-of-thought with explicit reasoning steps before answer
+   - Hybrid: Combine styles when task complexity demands it
+   - Document rationale for style selection
+
+3. **Design system prompt structure**: Build the prompt skeleton:
+   - Identity/role definition (who the model is)
+   - Task description (what to do)
+   - Constraints and guardrails (what NOT to do)
+   - Output format specification (exact structure expected)
+   - Edge-case handling instructions (when ambiguous, do X)
+   - Prioritization rules (if conflicts, prefer Y over Z)
+
+4. **Add few-shot examples if needed**: When --style includes few-shot:
+   - Select 3-5 diverse examples covering the input distribution
+   - Include at least one edge case example
+   - Include at least one "refusal" example (when to say no)
+   - Order examples from simple to complex
+   - Ensure examples are representative, not cherry-picked
+
+5. **Implement caching strategy**: When --cache flag is set:
+   - Place static content first (system prompt, examples, reference docs)
+   - Mark cache breakpoint after static prefix
+   - Keep dynamic content (user input, session context) after breakpoint
+   - Estimate cache hit rate based on usage pattern
+   - Calculate cost savings (cached tokens at 90% discount)
+   - Ensure static prefix exceeds minimum cacheable length (1024 tokens)
+
+6. **Test with edge cases**: Validate the prompt against:
+   - Adversarial inputs (prompt injection attempts)
+   - Ambiguous inputs (multiple valid interpretations)
+   - Empty/minimal inputs (graceful handling)
+   - Maximum-length inputs (truncation behavior)
+   - Out-of-domain inputs (appropriate refusal)
+   - Multi-language inputs if applicable
+
+7. **Iterate on failures**: For each failure mode discovered:
+   - Identify root cause (missing constraint, ambiguous instruction, weak example)
+   - Add targeted fix (new constraint, clarified instruction, better example)
+   - Re-test to confirm fix without regression
+   - Document the failure and fix for future reference
+   - Version the prompt iteration (v1, v2, v3...)
+
+8. **Output final prompt**: Deliver the production prompt:
+   - Complete prompt text with clear section markers
+   - Token count breakdown (system, examples, dynamic budget)
+   - Caching configuration if applicable
+   - Known limitations and edge cases
+   - Recommended model and temperature settings
+   - Eval criteria for ongoing quality monitoring
+</process>