User Story

As a split-portfolio adopter, I want my private repo to host template overrides for the framework's templates (PRD, AgDR, technical design, C4, vision, investigation, etc.) so that when a framework skill that consumes a template runs, it picks up MY company's customised version if present, else falls back to the framework default. This means I can ship a company-specific PRD shape, vision-doc shape, investigation shape, etc. without forking the skill itself — and without losing future framework upgrades to the skill.

Acceptance Criteria

Storage layout in the private repo

• Private repo gains a top-level custom-templates/ dir that mirrors the framework's templates/ shape:
  • custom-templates/prd.md overrides templates/prd.md
  • custom-templates/agdr.md overrides templates/agdr.md
  • custom-templates/architecture/c4-context.md overrides templates/architecture/c4-context.md
  • …same path-mirroring rule for any deeper directory
• Empty custom-templates/README.md shipped explaining the override semantics + path convention

Helper

• _lib-portfolio-paths.sh exposes portfolio_resolve_template <relative_path> (e.g. portfolio_resolve_template architecture/vision.md):
  • Returns the absolute path of <private_repo>/custom-templates/<relative_path> if it exists
  • Otherwise returns the absolute path of <ops_root>/templates/<relative_path>
  • Returns empty + nonzero exit if neither exists (caller decides what to do)

Every consuming skill resolves through the helper

Audit + update each skill that currently reads a template directly:

• /decide (templates/agdr.md)
• /write-spec (templates/prd.md)
• /feature, /bug, /task, /migration, /spike (their respective ticket-shape templates if any are file-backed)
• /c4 (templates/architecture/c4-context.md, c4-container.md)
• /journey (templates/journey-related)
• /handover (writes the architecture stub from a template)
• /migration (templates/agdr-migration.md)
• New /investigation and /vision skills consume through the helper from inception

Each updated skill, when invoked from a fork with custom-templates present, picks up the override; when invoked from a fork without custom-templates (single-fork mode or no override authored), behaves identically to today.

Single-fork mode unaffected

• Adopters without a portfolio block see ZERO behaviour change. portfolio_resolve_template falls straight through to <ops_root>/templates/<relative_path>.

Tests

• _lib-portfolio-paths.sh tests cover portfolio_resolve_template: present custom → returns custom path; absent custom → returns framework path; absent both → returns empty + nonzero exit
• Smoke test on at least one skill: invoke /decide from a sandbox with a custom-templates/agdr.md present; confirm the AgDR header reflects the override

Docs

• docs/multi-project.md § "Split-portfolio mode" gains a "Custom templates" subsection
• templates/README.md (or new file if absent) explains the override semantics + path-mirroring convention

Design Notes

Why override semantics instead of additive. Templates are forms, not content. An adopter who authors custom-templates/prd.md deliberately wants their PRD shape used in place of the framework's, not appended to it. Additive templating doesn't make sense for this asset class.

Path-mirroring is the discovery mechanism — no frontmatter, no config table. If you want to override templates/architecture/c4-context.md, you put your version at custom-templates/architecture/c4-context.md. Same shape as how handbooks/<dim>/... discovery works (#232).

Foundational for #B (investigation) and #C (vision skills). Both new skills depend on this resolver. Logical order: this PR ships first → #B + #C can ship in parallel after.

Out of Scope

• Per-project template overrides (still framework-wide / org-wide only)
• Template versioning / migration when the framework's template shape changes (operator's responsibility — diff their override against the new framework version manually)
• Variable substitution / templating engine on top of markdown (templates stay as plain markdown with {placeholder} text the operator hand-edits)
• Encrypted custom templates

Effort Estimate

TBD — likely 0.5-1 day. Most of the work is the audit + per-skill update; the helper itself is ~10 lines bash.