feat: add 4 template bundles (writing, backend, security, quick-fix)

Ready-to-use project templates with team, workflow, domain, and config:
- writing-short-story: fiction 5-15k words, custom archetypes, sonnet for prose
- backend-feature: standard PDCA, full team, haiku for reviews
- security-review: thorough 3-cycle, all reviewers incl. trickster
- quick-fix: minimal 1-cycle, creator+maker+guardian only

templates/bundles/backend-feature/config.yaml

@@ -0,0 +1,20 @@
+# Config: backend-feature defaults
+# Cost-optimized for typical backend work. Haiku handles most tasks well
+# for code — only upgrade to sonnet if review quality needs it.
+
+budget:
+  max_usd: 5              # Backend features are typically bounded
+  warn_at_pct: 80
+
+models:
+  default: haiku           # Haiku is sufficient for code tasks
+  explorer: haiku          # Codebase mapping is analytical
+  creator: haiku           # Design proposals are structural
+  maker: haiku             # Code generation — haiku handles well
+  guardian: haiku           # Security review — pattern matching
+  sage: haiku              # Quality review — checklist-driven
+
+variables:
+  max_cycles: 2
+  test_command: ""
+  lint_command: ""

templates/bundles/backend-feature/domain.yaml

@@ -0,0 +1,66 @@
+# Domain: Code
+# Standard code domain — software development with ArcheFlow defaults.
+# No concept remapping needed (code is the default domain).
+
+name: code
+description: "Software development — applications, libraries, infrastructure"
+
+concepts:
+  implementation: "code changes"
+  tests: "automated tests"
+  files_changed: "files changed"
+  test_coverage: "test coverage %"
+  code_review: "code review"
+  build: "build/compile"
+  deploy: "deploy"
+  refactor: "refactor"
+  bug: "bug"
+  feature: "feature"
+  PR: "pull request"
+
+metrics:
+  - files_changed
+  - lines_added
+  - lines_removed
+  - tests_added
+  - tests_passing
+  - coverage_delta
+
+review_focus:
+  guardian:
+    - security_vulnerabilities
+    - breaking_changes
+    - dependency_risks
+    - error_handling
+  sage:
+    - code_quality
+    - test_coverage
+    - documentation
+    - pattern_consistency
+  skeptic:
+    - design_assumptions
+    - scalability
+    - alternative_approaches
+    - edge_cases
+  trickster:
+    - malformed_input
+    - concurrency_races
+    - error_path_exploitation
+    - dependency_failures
+
+context:
+  always:
+    - "README.md"
+    - ".archeflow/config.yaml"
+  plan_phase:
+    - "relevant source files (Explorer identifies)"
+    - "existing tests for affected area"
+  do_phase:
+    - "Creator's proposal"
+    - "test fixtures and helpers"
+  check_phase:
+    - "git diff from Maker"
+    - "proposal risk section"
+
+# Code domain uses default archetype model assignments
+model_overrides: {}

templates/bundles/backend-feature/manifest.yaml

@@ -0,0 +1,19 @@
+# Bundle: backend-feature
+# Standard setup for backend feature implementation: API endpoint, DB migration, tests.
+# Uses the standard PDCA pipeline with 2 review cycles.
+
+name: backend-feature
+description: "Backend feature implementation — API, DB migration, tests (standard PDCA)"
+version: "1.0.0"
+domain: code
+includes:
+  team: team.yaml
+  workflow: workflow.yaml
+  domain: domain.yaml
+  config: config.yaml
+  archetypes: []
+requires: []
+variables:
+  max_cycles: 2            # PDCA review cycles
+  test_command: ""         # Override: pytest, cargo test, npm test, etc.
+  lint_command: ""         # Override: ruff, clippy, eslint, etc.

templates/bundles/backend-feature/team.yaml

@@ -0,0 +1,28 @@
+# Team: Backend Feature
+# Full team for backend feature development.
+# Explorer scopes the change, Creator designs the approach, Maker implements,
+# Guardian + Sage review for security and quality.
+
+name: backend-feature
+description: "Backend feature development: scope, design, implement, review"
+domain: code
+
+# Plan: explorer maps affected code, creator designs the approach with
+#        API contract, DB schema changes, and test strategy.
+plan: [explorer, creator]
+
+# Do: maker implements the feature — code, migration, tests.
+do: [maker]
+
+# Check: guardian reviews for security, breaking changes, error handling.
+#         sage reviews for code quality, test coverage, documentation.
+check: [guardian, sage]
+
+exit: all_approved
+max_cycles: ${max_cycles}
+
+# Notes:
+# - All archetypes are standard (no custom archetypes needed for code)
+# - Guardian focuses on security and breaking changes (code domain review_focus)
+# - Sage focuses on quality and test coverage (code domain review_focus)
+# - Explorer is critical for scoping — finds affected files, existing tests, dependencies

templates/bundles/backend-feature/workflow.yaml

@@ -0,0 +1,63 @@
+# Workflow: Backend Feature
+# Standard PDCA for backend feature implementation.
+# 2 cycles: first pass implements, second pass addresses review findings.
+
+name: backend-feature
+description: "Backend feature — scope, design, implement, review (2 cycles)"
+team: backend-feature
+
+phases:
+  plan:
+    archetypes: [explorer, creator]
+    parallel: false
+    description: |
+      1. explorer: Map affected codebase areas. Identify existing patterns, relevant
+         tests, DB schema, API routes, and dependencies. Flag risks.
+      2. creator: Design the implementation approach. Define:
+         - API contract (endpoints, request/response shapes)
+         - DB migration (if needed)
+         - Test strategy (unit, integration, edge cases)
+         - Confidence table for each axis (understanding, completeness, risk)
+    inputs:
+      - "Feature description / ticket"
+      - "Relevant source files (Explorer identifies)"
+      - "Existing tests for affected area"
+
+  do:
+    archetypes: [maker]
+    parallel: false
+    description: |
+      Implement the feature following Creator's design.
+      Order: DB migration -> models -> business logic -> API endpoint -> tests.
+      Commit after each logical unit. Run tests before moving to next unit.
+      Run lint (${lint_command}) and tests (${test_command}) before marking complete.
+    inputs:
+      - "Creator's design proposal"
+      - "Test fixtures and helpers"
+      - "Existing code patterns (from Explorer)"
+
+  check:
+    archetypes: [guardian, sage]
+    parallel: true
+    description: |
+      guardian: Security vulnerabilities, breaking changes, dependency risks, error handling.
+               Pay special attention to input validation, auth checks, and SQL injection.
+      sage: Code quality, test coverage, documentation, pattern consistency.
+            Verify tests actually test the right things (not just passing).
+    inputs:
+      - "git diff from Maker"
+      - "Creator's proposal (risk section)"
+      - "Existing test baseline"
+
+  act:
+    exit_when: all_approved
+    max_cycles: ${max_cycles}
+    on_reject: |
+      Guardian findings: fix in Maker (security/breaking changes are blocking).
+      Sage findings: fix in Maker (quality issues, missing tests).
+      Re-run affected tests after each fix.
+
+hooks:
+  pre_plan: []
+  post_check: []
+  post_act: []

templates/bundles/quick-fix/config.yaml

@@ -0,0 +1,18 @@
+# Config: quick-fix defaults
+# Minimal budget, haiku everywhere. Quick fixes should be cheap and fast.
+# If the fix escalates (A1 rule), budget may need manual increase.
+
+budget:
+  max_usd: 2              # Tight budget — this is a small fix
+  warn_at_pct: 80
+
+models:
+  default: haiku           # Haiku for everything — speed over depth
+  creator: haiku
+  maker: haiku
+  guardian: haiku
+
+variables:
+  max_cycles: 1
+  test_command: ""
+  lint_command: ""

templates/bundles/quick-fix/domain.yaml

@@ -0,0 +1,51 @@
+# Domain: Code
+# Standard code domain for quick fixes. Identical to the default code domain.
+# Included for bundle completeness — all bundles ship their own domain config.
+
+name: code
+description: "Software development — bug fixes and patches"
+
+concepts:
+  implementation: "code changes"
+  tests: "automated tests"
+  files_changed: "files changed"
+  test_coverage: "test coverage %"
+  code_review: "code review"
+  build: "build/compile"
+  deploy: "deploy"
+  refactor: "refactor"
+  bug: "bug"
+  feature: "feature"
+  PR: "pull request"
+
+metrics:
+  - files_changed
+  - lines_added
+  - lines_removed
+  - tests_added
+  - tests_passing
+  - coverage_delta
+
+review_focus:
+  guardian:
+    - regression_risk
+    - security_vulnerabilities
+    - breaking_changes
+    - error_handling
+
+context:
+  always:
+    - "README.md"
+    - ".archeflow/config.yaml"
+  plan_phase:
+    - "bug report / description"
+    - "relevant source files"
+    - "existing tests for affected area"
+  do_phase:
+    - "Creator's fix proposal"
+  check_phase:
+    - "git diff from Maker"
+    - "fix proposal risk section"
+
+# All haiku — quick fixes don't need expensive models
+model_overrides: {}

templates/bundles/quick-fix/manifest.yaml

@@ -0,0 +1,19 @@
+# Bundle: quick-fix
+# Minimal setup for small bug fixes and patches. Fast workflow with 1 cycle,
+# reduced team (no Explorer or Sage), and low budget. Get in, fix, get out.
+
+name: quick-fix
+description: "Small bug fix or patch — minimal team, 1 fast cycle, low overhead"
+version: "1.0.0"
+domain: code
+includes:
+  team: team.yaml
+  workflow: workflow.yaml
+  domain: domain.yaml
+  config: config.yaml
+  archetypes: []
+requires: []
+variables:
+  max_cycles: 1            # Fast: single cycle, ship it
+  test_command: ""         # Override: pytest, cargo test, npm test, etc.
+  lint_command: ""         # Override: ruff, clippy, eslint, etc.

templates/bundles/quick-fix/team.yaml

@@ -0,0 +1,30 @@
+# Team: Quick Fix
+# Minimal team for small bug fixes. No Explorer (scope is known),
+# no Sage (quality review is overkill for a patch). Creator designs the fix,
+# Maker applies it, Guardian sanity-checks for regressions.
+
+name: quick-fix
+description: "Minimal team for small fixes: design, implement, sanity-check"
+domain: code
+
+# Plan: creator only — scope is already known for a bug fix.
+#        Creator identifies root cause and designs the fix.
+plan: [creator]
+
+# Do: maker applies the fix and runs tests.
+do: [maker]
+
+# Check: guardian only — checks for regressions, security issues, breaking changes.
+#         No Sage/Skeptic/Trickster — keep overhead minimal.
+check: [guardian]
+
+exit: all_approved
+max_cycles: ${max_cycles}
+
+# Notes:
+# - If Guardian finds 2+ CRITICALs, orchestration rule A1 escalates to standard
+#   workflow automatically (adds Sage + Skeptic for next cycle)
+# - For truly trivial fixes (typo, config change), even this may be overkill —
+#   but it ensures at least one review pass happens
+# - If the fix turns out to be more complex than expected, abort and use
+#   backend-feature bundle instead

templates/bundles/quick-fix/workflow.yaml

@@ -0,0 +1,66 @@
+# Workflow: Quick Fix
+# Fast PDCA for small bug fixes. 1 cycle, minimal team.
+# If the fix is clean, ships in a single pass.
+# If Guardian escalates (A1 rule), second cycle adds more reviewers automatically.
+
+name: quick-fix
+description: "Fast bug fix — 1 cycle, creator + maker + guardian"
+team: quick-fix
+
+phases:
+  plan:
+    archetypes: [creator]
+    parallel: false
+    description: |
+      Creator identifies root cause and designs the fix:
+      - What is the bug? (reproduce or confirm from description)
+      - Where is the root cause? (file, function, line)
+      - What is the fix? (specific change, not a rewrite)
+      - What could break? (regression risk assessment)
+      - What test proves it's fixed?
+      Keep it brief — this is a patch, not a feature.
+    inputs:
+      - "Bug report / description"
+      - "Relevant source files"
+      - "Existing tests for affected area"
+
+  do:
+    archetypes: [maker]
+    parallel: false
+    description: |
+      Apply the fix. Keep changes minimal and focused.
+      1. Make the code change
+      2. Add or update test that reproduces the bug and verifies the fix
+      3. Run tests (${test_command}) — all must pass
+      4. Run lint (${lint_command}) — no new warnings
+      5. Single commit with descriptive message
+    inputs:
+      - "Creator's fix proposal"
+      - "Affected source files"
+
+  check:
+    archetypes: [guardian]
+    parallel: false
+    description: |
+      Guardian sanity-checks the fix:
+      - Does the fix address the root cause (not just the symptom)?
+      - Are there regressions? (check test coverage of changed code)
+      - Any security implications?
+      - Any breaking changes to public API?
+      If clean: APPROVED. If 2+ CRITICALs: A1 escalation kicks in automatically.
+    inputs:
+      - "git diff from Maker"
+      - "Creator's fix proposal (regression risk section)"
+
+  act:
+    exit_when: all_approved
+    max_cycles: ${max_cycles}
+    on_reject: |
+      Guardian rejection: fix the specific issue and re-run tests.
+      If the fix is growing in scope, consider switching to backend-feature bundle.
+      A1 escalation (2+ CRITICALs) adds Sage + Skeptic — accept the cost.
+
+hooks:
+  pre_plan: []
+  post_check: []
+  post_act: []

templates/bundles/security-review/config.yaml

@@ -0,0 +1,22 @@
+# Config: security-review defaults
+# Higher budget for thorough security analysis. Guardian gets sonnet for deeper
+# vulnerability detection. Other reviewers use haiku to stay within budget.
+
+budget:
+  max_usd: 15             # 3 cycles with full team needs more budget
+  warn_at_pct: 70         # Warn earlier — security reviews should not be cut short
+
+models:
+  default: haiku           # Most analysis is pattern-matching
+  explorer: haiku          # Attack surface mapping is analytical
+  creator: haiku           # Checklist creation is structural
+  maker: haiku             # Fixes are targeted edits
+  guardian: sonnet          # Primary security gate — needs depth
+  sage: haiku              # Quality review is checklist-driven
+  skeptic: haiku           # Design review is analytical
+  trickster: haiku         # Adversarial testing is creative but bounded
+
+variables:
+  max_cycles: 3
+  target_paths: ""
+  threat_model: ""

templates/bundles/security-review/domain.yaml

@@ -0,0 +1,84 @@
+# Domain: Code (Security Focus)
+# Standard code domain with security-weighted review focus.
+# Extends the default code domain with stronger security emphasis.
+
+name: code
+description: "Software development — security-focused review configuration"
+
+concepts:
+  implementation: "code changes"
+  tests: "automated tests"
+  files_changed: "files changed"
+  test_coverage: "test coverage %"
+  code_review: "security review"
+  build: "build/compile"
+  deploy: "deploy"
+  refactor: "security hardening"
+  bug: "vulnerability"
+  feature: "feature"
+  PR: "pull request"
+
+metrics:
+  - files_changed
+  - lines_added
+  - lines_removed
+  - tests_added
+  - tests_passing
+  - coverage_delta
+  - critical_findings      # Security-specific metrics
+  - warning_findings
+  - trickster_exploits     # Adversarial findings
+
+# Security-weighted review focus — guardian and trickster have expanded checklists
+review_focus:
+  guardian:
+    - injection_vulnerabilities    # SQL, NoSQL, command, LDAP
+    - authentication_bypass
+    - authorization_flaws          # IDOR, privilege escalation
+    - sensitive_data_exposure      # PII in logs, error messages
+    - security_misconfiguration
+    - dependency_vulnerabilities   # Known CVEs
+    - breaking_changes
+    - error_handling               # Information leakage on errors
+    - input_validation
+    - output_encoding
+  sage:
+    - code_quality
+    - test_coverage
+    - error_handling_completeness
+    - logging_hygiene              # No sensitive data in logs
+    - pattern_consistency
+    - documentation
+  skeptic:
+    - design_assumptions
+    - trust_boundaries             # Are they in the right place?
+    - alternative_approaches       # Simpler = less attack surface
+    - edge_cases
+    - scalability_under_attack     # DoS resilience
+  trickster:
+    - malformed_input              # Fuzzing mindset
+    - concurrency_races            # TOCTOU, double-spend
+    - error_path_exploitation      # What leaks on failure?
+    - dependency_failures          # What happens when deps are down?
+    - abuse_scenarios              # Malicious authenticated user
+    - supply_chain_vectors         # Dependency confusion, typosquatting
+
+context:
+  always:
+    - "README.md"
+    - ".archeflow/config.yaml"
+  plan_phase:
+    - "architecture docs"
+    - "threat model if available"
+    - "relevant source files (Explorer identifies)"
+  do_phase:
+    - "review findings to fix"
+    - "security checklist from Creator"
+  check_phase:
+    - "git diff (or full files for initial review)"
+    - "attack surface map from Explorer"
+    - "security checklist from Creator"
+
+# Guardian gets sonnet for deeper security analysis
+model_overrides:
+  guardian: sonnet

templates/bundles/security-review/manifest.yaml

@@ -0,0 +1,19 @@
+# Bundle: security-review
+# Thorough security-focused code review with all reviewers including Trickster.
+# 3 PDCA cycles for maximum coverage. Higher budget to account for deeper analysis.
+
+name: security-review
+description: "Security-focused code review — full team with Trickster, 3 thorough cycles"
+version: "1.0.0"
+domain: code
+includes:
+  team: team.yaml
+  workflow: workflow.yaml
+  domain: domain.yaml
+  config: config.yaml
+  archetypes: []
+requires: []
+variables:
+  max_cycles: 3            # Thorough: 3 cycles for deep security coverage
+  target_paths: ""         # Specific paths to review (empty = entire diff)
+  threat_model: ""         # Path to threat model doc if available

templates/bundles/security-review/team.yaml

@@ -0,0 +1,32 @@
+# Team: Security Review
+# Full team with Trickster for adversarial testing. All five reviewer archetypes
+# participate in Check phase for maximum security coverage.
+# Use for: auth changes, public API, payment flows, data handling, dependencies.
+
+name: security-review
+description: "Security-focused review: full team with adversarial Trickster"
+domain: code
+
+# Plan: explorer maps attack surface and data flows,
+#        creator identifies security requirements and risk areas.
+plan: [explorer, creator]
+
+# Do: maker is not used — this is a review workflow, not implementation.
+#     If fixes are needed, maker applies them in cycle 2+.
+do: [maker]
+
+# Check: all five reviewers for thorough coverage.
+#   guardian — security vulnerabilities, auth, injection, breaking changes
+#   sage — code quality, pattern consistency, error handling completeness
+#   skeptic — design assumptions, alternative approaches, edge cases
+#   trickster — adversarial testing: malformed input, race conditions, abuse paths
+check: [guardian, sage, skeptic, trickster]
+
+exit: all_approved
+max_cycles: ${max_cycles}
+
+# Notes:
+# - Trickster is the key differentiator: actively tries to break the code
+# - Guardian fast-path (A2) is disabled for thorough workflows on first cycle
+# - Trickster is mandatory on first pass per orchestration rules
+# - If reviewing existing code (not new changes), Explorer scopes the review area

templates/bundles/security-review/workflow.yaml

@@ -0,0 +1,81 @@
+# Workflow: Security Review
+# Thorough PDCA for security-focused code review. 3 cycles with full reviewer roster.
+# Cycle 1: initial review with all reviewers. Cycle 2-3: fix and re-review.
+
+name: security-review
+description: "Security-focused review — 3 cycles, full reviewer team with Trickster"
+team: security-review
+
+phases:
+  plan:
+    archetypes: [explorer, creator]
+    parallel: false
+    description: |
+      1. explorer: Map the attack surface. Identify:
+         - Data flows (user input -> processing -> storage -> output)
+         - Authentication and authorization boundaries
+         - External dependencies and their trust levels
+         - Sensitive data handling (PII, credentials, tokens)
+         - Public-facing entry points
+         Target paths: ${target_paths} (empty = analyze full diff/codebase)
+      2. creator: Based on Explorer's map, create a security review checklist:
+         - OWASP Top 10 applicability
+         - Threat model alignment (${threat_model} if available)
+         - Priority areas for each reviewer
+         - Known risk areas flagged for Trickster
+    inputs:
+      - "Code diff or target paths for review"
+      - "Threat model (${threat_model}) if available"
+      - "Architecture docs / README"
+
+  do:
+    archetypes: [maker]
+    parallel: false
+    description: |
+      Cycle 1: No implementation — this phase passes through to Check.
+      Cycle 2+: Apply security fixes identified in Check phase.
+      Each fix must:
+        - Address one specific finding
+        - Include a test that proves the vulnerability is fixed
+        - Not introduce new attack surface
+    inputs:
+      - "Review findings from Check phase"
+      - "Creator's security checklist"
+
+  check:
+    archetypes: [guardian, sage, skeptic, trickster]
+    parallel: false  # Guardian first, then others (but A2 fast-path disabled for thorough)
+    description: |
+      guardian (first): Security vulnerabilities, injection, auth bypass, SSRF, path traversal,
+        dependency vulnerabilities, breaking changes. This is the primary security gate.
+
+      sage: Code quality issues that create security risk — error handling gaps, logging
+        of sensitive data, inconsistent validation, missing type checks.
+
+      skeptic: Design-level concerns — are the security assumptions valid? Are there
+        simpler/safer approaches? What edge cases does the design miss?
+
+      trickster (adversarial): Actively tries to break the code:
+        - Malformed/oversized/unicode input
+        - Race conditions and TOCTOU
+        - Error path exploitation (what leaks on failure?)
+        - Dependency confusion / supply chain vectors
+        - Abuse scenarios (what can a malicious authenticated user do?)
+    inputs:
+      - "Code under review (diff or full files)"
+      - "Explorer's attack surface map"
+      - "Creator's security checklist"
+
+  act:
+    exit_when: all_approved
+    max_cycles: ${max_cycles}
+    on_reject: |
+      CRITICAL findings from any reviewer: must be fixed before next cycle.
+      WARNING findings: should be fixed, can be deferred with justification.
+      INFO findings: document and track, fix if time allows.
+      Trickster findings get priority — they represent actual exploit paths.
+
+hooks:
+  pre_plan: []
+  post_check: []
+  post_act: []

templates/bundles/writing-short-story/archetypes/story-explorer.md

@@ -0,0 +1,56 @@
+---
+name: story-explorer
+description: |
+  Researches story foundations — setting, character dynamics, thematic possibilities, plot seeds.
+  Use in Plan phase for creative writing tasks.
+model: haiku
+---
+
+You are the **Story Explorer** archetype. You research the foundations a story needs before anyone writes a word.
+
+## Your Virtue: Thematic Clarity
+You see the emotional core before anyone acts. You map character dynamics, spot narrative patterns, and surface the story's central question. Without you, the Creator outlines blind and the Maker writes without direction.
+
+## Your Lens
+"What is this story really about? What makes it matter? What's the emotional engine?"
+
+## Process
+1. Read the story brief / premise carefully
+2. Read character files if they exist
+3. Read the voice profile and persona rules
+4. Identify the emotional core (what universal truth does this explore?)
+5. Map character dynamics (who wants what, who's in the way?)
+6. Sketch the setting's role (is it backdrop or character?)
+7. Identify 2-3 possible plot directions
+8. Recommend the strongest one
+
+## Output Format
+```markdown
+## Story Research: <premise>
+
+### Emotional Core
+One sentence: what this story is really about.
+
+### Characters in Play
+- Character — role, want, obstacle
+
+### Setting as Character
+How the location shapes the story.
+
+### Plot Seeds
+1. Direction A — brief pitch + why it works
+2. Direction B — brief pitch + why it works
+3. Direction C — brief pitch + why it works
+
+### Recommendation
+<one paragraph: which direction + rationale>
+```
+
+## Rules
+- Lead with emotion, not plot mechanics. Plot serves theme.
+- Keep it under 800 words. The Creator needs direction, not a novel.
+- Every recommendation must be writable in the story's target word count.
+- Reference the voice profile constraints — don't suggest things the voice forbids.
+
+## Shadow: Endless Research
+You keep exploring "one more angle" without landing on a direction. If you have 4+ plot directions or your output exceeds 1000 words — STOP. Pick the strongest direction and commit. A good-enough recommendation now beats a perfect one never.

templates/bundles/writing-short-story/archetypes/story-sage.md

@@ -0,0 +1,59 @@
+---
+name: story-sage
+description: |
+  Reviews prose quality, voice consistency, dialect authenticity, and narrative craft.
+  Use in Check phase for creative writing tasks.
+model: sonnet
+---
+
+You are the **Story Sage** archetype. You evaluate whether the prose is good enough to publish.
+
+## Your Virtue: Craft Judgment
+You hear the voice. You feel the rhythm. You know when a sentence sings and when it clunks. Without you, technically correct prose goes out without soul.
+
+## Your Lens
+"Does this sound like the author it's supposed to be? Would a reader savor this or skim it?"
+
+## Process
+1. Read the voice profile (dimensions, verboten, erlaubt, vorbilder)
+2. Read the prose
+3. Check voice consistency — does it match the profile throughout?
+4. Check prose quality — rhythm, imagery, dialogue, pacing
+5. Check dialect usage — too much? Too little? Authentic?
+6. Check for forbidden patterns (from voice profile)
+7. Deliver verdict with specific line-level feedback
+
+## Output Format
+```markdown
+## Prose Review: <story title>
+
+### Voice Consistency: PASS / DRIFT
+- Where does the voice hold? Where does it slip?
+- Specific examples with line references.
+
+### Prose Quality
+- **Rhythm**: Does sentence length vary? Do paragraphs breathe?
+- **Imagery**: Vivid and sensory, or generic?
+- **Dialogue**: Natural speech or book-speech?
+- **Pacing**: Does tension build? Are quiet moments earned?
+
+### Dialect Check
+- Frequency: too much / just right / too little
+- Authenticity: do the Einsprengsel feel natural?
+- Examples of what works, what doesn't.
+
+### Forbidden Pattern Violations
+- List any violations of the voice profile's verboten section.
+
+### Verdict: APPROVED / REVISE
+Top 3-5 specific fixes (with line references where possible).
+```
+
+## Rules
+- Max 5 fixes per review. Quality over quantity.
+- Every fix must include a concrete rewrite suggestion, not just "improve this."
+- Read the voice profile FIRST. Your standard is the profile, not your taste.
+- Dialect judgment: if it reads natural to a Münchner, it's fine.
+
+## Shadow: Literary Perfectionist
+Your prose sensitivity becomes endless revision requests. Review longer than the story? More than 5 fixes? Suggesting rewrites for lines that already work? STOP. The goal is publishable, not Pulitzer. Max 5 actionable fixes. Move on.

templates/bundles/writing-short-story/config.yaml

@@ -0,0 +1,21 @@
+# Config: writing-short-story defaults
+# Sensible defaults for short fiction. Override with --set at init time
+# or edit .archeflow/config.yaml after init.
+
+budget:
+  max_usd: 10            # Total budget ceiling for a full run
+  warn_at_pct: 80        # Warn when 80% of budget is consumed
+
+models:
+  default: haiku          # Default model for analytical/structural work
+  maker: sonnet           # Prose drafting needs quality
+  story-sage: sonnet      # Voice evaluation needs taste
+  story-explorer: haiku   # Research is analytical
+  creator: haiku          # Outlining is structural
+  guardian: haiku          # Plot checks are analytical
+
+variables:
+  target_words: 8000
+  max_cycles: 2
+  voice_profile: ""
+  dialect_density: 0.15

templates/bundles/writing-short-story/domain.yaml

@@ -0,0 +1,74 @@
+# Domain: Writing
+# Maps ArcheFlow's code-oriented defaults to creative writing terminology.
+# Used by the story-development team for short fiction workflows.
+
+name: writing
+description: "Creative writing — short stories, novellas, fiction"
+
+# Concept mapping — how generic ArcheFlow terms translate for writing
+concepts:
+  implementation: "draft/prose"
+  tests: "consistency checks"
+  files_changed: "word count delta"
+  test_coverage: "voice drift score"
+  code_review: "prose review"
+  build: "compile/export"
+  deploy: "publish"
+  refactor: "revision"
+  bug: "continuity error"
+  feature: "scene/chapter"
+  PR: "manuscript submission"
+
+# Metrics — what to track instead of lines/files/tests
+metrics:
+  - word_count
+  - voice_drift_score
+  - dialect_density
+  - scene_count
+  - dialogue_ratio
+
+# Review focus areas — override default Guardian/Sage lenses
+review_focus:
+  guardian:
+    - plot_coherence
+    - character_consistency
+    - timeline_accuracy
+    - continuity
+  sage:
+    - voice_consistency
+    - prose_quality
+    - dialect_authenticity
+    - forbidden_pattern_violations
+  skeptic:
+    - premise_strength
+    - character_motivation
+    - ending_satisfaction
+  trickster:
+    - reader_confusion_points
+    - pacing_dead_spots
+    - suspension_of_disbelief_breaks
+
+# Context injection — what extra files agents should read per phase
+context:
+  always:
+    - "voice profile YAML (profiles/*.yaml)"
+    - "persona YAML (personas/*.yaml)"
+    - "character sheets (characters/*.yaml)"
+  plan_phase:
+    - "series config (colette.yaml) if present"
+    - "previous stories (for series continuity)"
+    - "story brief / premise"
+  do_phase:
+    - "scene outline from Creator"
+    - "voice profile for style reference"
+  check_phase:
+    - "voice profile (for Sage drift scoring)"
+    - "outline (for Guardian coherence check)"
+    - "character sheets (for consistency)"
+
+# Model preferences — writing needs quality for prose generation and review
+model_overrides:
+  maker: sonnet         # Prose quality matters more than speed
+  story-sage: sonnet    # Needs taste for voice evaluation
+  story-explorer: haiku # Research is analytical, haiku suffices
+  creator: haiku        # Outlining is structural, haiku suffices

templates/bundles/writing-short-story/manifest.yaml

@@ -0,0 +1,22 @@
+# Bundle: writing-short-story
+# Complete setup for short fiction writing (5-15k words) with ArcheFlow.
+# Based on the Giesing Gschichten dogfood experience.
+
+name: writing-short-story
+description: "Short fiction writing setup — premise to polished draft (5-15k words)"
+version: "1.0.0"
+domain: writing
+includes:
+  team: team.yaml
+  workflow: workflow.yaml
+  domain: domain.yaml
+  config: config.yaml
+  archetypes:
+    - story-explorer.md
+    - story-sage.md
+requires: []  # colette.yaml recommended but not required
+variables:
+  target_words: 8000       # Target word count for the story
+  max_cycles: 2            # PDCA review cycles before forced exit
+  voice_profile: ""        # Path to voice profile YAML (optional)
+  dialect_density: 0.15    # Target dialect ratio (0 = none, 1 = full dialect)

templates/bundles/writing-short-story/team.yaml

@@ -0,0 +1,27 @@
+# Team: Story Development
+# Short fiction team — researches foundations, outlines structure, drafts prose, reviews quality.
+# Designed for 5-15k word stories. Works with or without colette.yaml.
+
+name: story-development
+description: "Kurzgeschichten-Entwicklung: Recherche, Outline, Draft, Review"
+domain: writing
+
+# Plan: story-explorer researches emotional core and plot seeds,
+#        creator designs scene outline and tension arc.
+plan: [story-explorer, creator]
+
+# Do: maker drafts the prose scene by scene.
+do: [maker]
+
+# Check: guardian validates plot coherence and continuity,
+#         story-sage evaluates prose quality and voice consistency.
+check: [guardian, story-sage]
+
+exit: all_approved
+max_cycles: ${max_cycles}
+
+# Notes:
+# - story-explorer and story-sage are custom archetypes (see archetypes/ directory)
+# - guardian uses standard archetype with writing domain review_focus overrides
+# - creator designs the outline (standard archetype, context-adapted)
+# - maker drafts the prose (standard archetype, model override to sonnet for quality)

templates/bundles/writing-short-story/workflow.yaml

@@ -0,0 +1,59 @@
+# Workflow: Kurzgeschichte
+# Short story development — from premise to polished draft.
+# Standard PDCA with 2 cycles. Suitable for 5-15k word stories.
+
+name: kurzgeschichte
+description: "Short story development — from premise to polished draft"
+team: story-development
+
+phases:
+  plan:
+    archetypes: [story-explorer, creator]
+    parallel: false
+    description: |
+      1. story-explorer: Research premise, identify emotional core, recommend plot direction.
+         Read character files, voice profile, and persona rules if available.
+      2. creator: Design scene outline with character beats, tension arc, and pacing.
+         Target: ${target_words} words across scenes.
+    inputs:
+      - "Story premise / brief"
+      - "Character files (characters/*.yaml) if available"
+      - "Voice profile (${voice_profile}) if configured"
+      - "Persona rules if available"
+
+  do:
+    archetypes: [maker]
+    parallel: false
+    description: |
+      Draft the story following the outline.
+      Write in scenes, not chapters. Commit after each scene.
+      Target word count: ${target_words} words.
+      Dialect density target: ${dialect_density} (0 = none, 1 = full).
+    inputs:
+      - "Scene outline from creator"
+      - "Voice profile for style reference"
+      - "Character files for consistency"
+
+  check:
+    archetypes: [guardian, story-sage]
+    parallel: true
+    description: |
+      guardian: Plot coherence, character consistency, timeline accuracy, continuity.
+      story-sage: Prose quality, voice consistency, dialect authenticity.
+    inputs:
+      - "Draft from maker"
+      - "Outline from creator (for guardian)"
+      - "Voice profile (for story-sage)"
+
+  act:
+    exit_when: all_approved
+    max_cycles: ${max_cycles}
+    on_reject: |
+      Route guardian findings back to creator (outline fix).
+      Route story-sage findings back to maker (prose fix).
+      Each fix must be a targeted edit, not a full rewrite.
+
+hooks:
+  pre_plan: []
+  post_check: []
+  post_act: []