feat: add enterprise architecture methodology (#359)

Add capability and portfolio mapping, state transitions, operating models, decision rights, stakeholder information, templates, evals, and neighboring-owner routing.\n\nAI-assisted: Jasper orchestrated implementation and verification with OpenCode.

Signed-off-by: Magnus Hedemark <magnus919@pm.me>

.claude-plugin/marketplace.json

@@ -365,6 +365,15 @@
       "strict": false,
       "description": "Send and diagnose transactional email through Twilio SendGrid from a terminal or agent: send messages, check deliverability (bounces and spam reports), and verify Signed Event Webhook signatures (ECDSA P-256) — with a bundled email-cli script that is read-only by default and gates every send behind a --dry-run/--yes confirmation. Use when an agent needs to send a transactional email, triage bounces or spam complaints, or confirm an inbound SendGrid webhook is authentic. Do not use for marketing or bulk email campaigns (that is SendGrid Marketing Campaigns), building email template systems, or other email providers (that is their own tooling)."
     },
+    {
+      "name": "enterprise-architecture",
+      "source": "./",
+      "skills": [
+        "./enterprise-architecture"
+      ],
+      "strict": false,
+      "description": "Design and evolve enterprise architectures by connecting business capabilities, value streams, applications, information, technology, operating models, and transition choices. Use when mapping an enterprise portfolio, comparing current and target states, sequencing transition architectures, or defining federated architecture decision rights and stakeholder communication. Do not use for system or solution design, API or data-platform design, organizational or talent design, product roadmaps, technology adoption, or corporate strategy; route those to the named specialist skills."
+    },
     {
       "name": "epub",
       "source": "./",

.codex-plugin/plugin.json

@@ -58,6 +58,7 @@
     "./dsm5",
     "./dspy",
     "./email",
+    "./enterprise-architecture",
     "./epub",
     "./esp32-development",
     "./financial-modeling",

README.md

@@ -163,6 +163,10 @@ An expert-level skill for **programmatic prompt optimization** with Stanford's D
 
 Send and diagnose transactional email through Twilio SendGrid: send with `--dry-run`/`--yes` confirmation, check deliverability (bounces and spam reports), and verify Signed Event Webhook signatures with a self-contained ECDSA P-256 verifier. Ships a bounded stdlib CLI with `--json` and `--limit`.
 
+### [enterprise-architecture](enterprise-architecture/SKILL.md)
+
+Connect enterprise outcomes to capabilities, value streams, application and information portfolios, operating models, decision rights, and feasible transition architectures. Keeps system design, organization design, product roadmaps, technology posture, and corporate strategy with their neighboring owners.
+
 ### [epub](epub/SKILL.md)
 
 EPUB file format expert — read, write, edit, convert, and repair EPUB2/EPUB3 ebooks.

enterprise-architecture/README.md

@@ -0,0 +1,50 @@
+# enterprise-architecture: Connect enterprise change to capabilities and decisions
+
+## Why Install This Skill
+
+Enterprise initiatives often fail because capabilities, applications, operating
+responsibilities, and investments are described in separate conversations. This
+skill helps an agent create a coherent view of what the organization can do, what
+supports it today, what should change, and which decisions must be made along the
+way.
+
+It is useful when a portfolio contains duplicated applications, when a target
+architecture is too distant to adopt directly, or when architecture governance is
+either a bottleneck or too vague to resolve conflicts. The output is designed to be
+used by executives, domain owners, product leaders, architects, and delivery teams.
+
+## What You Get
+
+| Path | Purpose |
+|---|---|
+| `SKILL.md` | Workflow, output contract, and ownership routing |
+| `references/` | Focused methods for mapping, states, operating models, governance, and engagement |
+| `templates/` | Fillable context brief, portfolio view, and transition roadmap |
+| `evals/evals.json` | Nine output-quality cases, including boundary and near-miss routing |
+
+## Quick Start
+
+Ask for a concrete artifact, for example:
+
+```text
+Map the capabilities and applications involved in our claims intake modernization,
+show duplication and ownership gaps, and propose a transition sequence.
+```
+
+Expect a decision-oriented result with evidence, assumptions, owners, dependencies,
+and explicit handoffs rather than a generic framework summary.
+
+## Triggers
+
+- Enterprise capability or value-stream mapping
+- Application, information, or technology portfolio alignment
+- Current, target, or transition architecture across domains
+- Enterprise architecture operating model or architecture roles
+- Federated architecture governance and decision rights
+- Architecture stakeholder engagement or accessible architecture information
+
+## Requirements
+
+- No runtime dependencies or API keys
+- Access to the organization's portfolio, ownership, strategy, and delivery evidence improves results
+- Specialist skills may be needed for system design, data, APIs, organization design, product roadmaps, technology posture, or corporate strategy

enterprise-architecture/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: enterprise-architecture
+description: >-
+  Design and evolve enterprise architectures by connecting business capabilities,
+  value streams, applications, information, technology, operating models, and
+  transition choices. Use when mapping an enterprise portfolio, comparing current
+  and target states, sequencing transition architectures, or defining federated
+  architecture decision rights and stakeholder communication. Do not use for
+  system or solution design, API or data-platform design, organizational or talent
+  design, product roadmaps, technology adoption, or corporate strategy; route
+  those to the named specialist skills.
+license: MIT
+compatibility: Platform-agnostic methodology. No runtime dependencies.
+metadata:
+  tags: enterprise-architecture, capability-mapping, value-streams, application-portfolio, operating-model, decision-rights
+---
+
+# Enterprise Architecture
+
+Use this skill to make enterprise-wide structure and change legible without turning
+architecture into a shelf of diagrams. Connect outcomes to capabilities, value
+streams, applications, information, technology, ownership, and a feasible sequence
+of change.
+
+## Workflow
+
+1. **Frame the enterprise question.** State the outcome, scope, time horizon,
+   stakeholders, constraints, authority, and evidence gaps. Separate strategy,
+   product commitments, operational facts, and architectural hypotheses.
+2. **Map the landscape.** Identify capabilities and value streams, then relate
+   applications, information objects, technology dependencies, owners, costs,
+   risks, duplication, and lifecycle status. Use
+   `references/capability-value-stream-and-portfolio-mapping.md`.
+3. **Describe states.** Record the current state from evidence, define a target
+   state from explicit principles and outcomes, and identify constraints that make
+   a direct jump unsafe or unrealistic. Use
+   `references/current-target-and-transition-architecture.md`.
+4. **Choose the operating model.** Compare centralized, federated, and hybrid
+   arrangements against decision locality, coordination cost, required coherence,
+   skills, and risk. Do not prescribe reporting lines or compensation. Use
+   `references/enterprise-operating-model-and-roles.md`.
+5. **Make authority executable.** Assign decision rights, consultation, standards,
+   exceptions, escalation, and feedback to named roles. Use
+   `references/federated-governance-and-decision-rights.md`.
+6. **Engage and publish for use.** Adapt views to stakeholder jobs, make uncertainty
+   and provenance visible, and maintain accessible, findable information with a
+   review owner. Use `references/stakeholder-engagement-and-architecture-information.md`.
+7. **Sequence change.** Connect transition increments to capabilities, outcomes,
+   dependencies, investment assumptions, and exit evidence. Use
+   `templates/transition-architecture-roadmap.md`; hand approved delivery plans to
+   `implementation-planning` or `migration-engineering` as appropriate.
+
+## Output Contract
+
+Produce an enterprise context brief, capability/application portfolio view,
+current-target-transition assessment, operating-model and decision-rights record,
+or transition roadmap. Every material claim must be labeled as evidence,
+assumption, decision, or open question and have a source or named owner.
+
+## Ownership Boundaries
+
+- System boundaries, runtime behavior, architecture characteristics, and solution
+  tradeoffs belong to `software-architecture`.
+- API contracts and API portfolio mechanics belong to `api-design-and-evolution`.
+- Data platforms, data products, data models, and data governance belong to
+  `data-architect`.
+- Reporting structures, team topology, talent, compensation, and culture belong to
+  `org-design`; this skill records organizational dependencies without designing HR
+  systems.
+- Product bets, product outcomes, and product sequencing belong to
+  `product-roadmapping-and-portfolio`.
+- Technology adoption posture, build-versus-buy, standards, and technology
+  governance mechanics belong to `technology-radar`.
+- Corporate direction, competitive choices, capital allocation, and M&A belong to
+  `strategy-frameworks`.
+- Process optimization and operational execution belong to `operational-design`;
+  enterprise architecture may use its findings as evidence.
+- Approved cross-system execution belongs to `implementation-planning` and
+  `migration-engineering`, not this skill.
+
+## When Not To Use
+
+Use the narrow owner when the request has no enterprise portfolio, cross-domain
+alignment, operating-model, or transition-architecture question. Do not use this
+skill to produce a solution design, organization chart, product roadmap, technology
+radar entry, data architecture, API contract, or corporate strategy verdict.
+
+## Reference Guide
+
+| Decision point | Load |
+|---|---|
+| Mapping capabilities, value streams, applications, information, or duplication | `references/capability-value-stream-and-portfolio-mapping.md` |
+| Comparing current, target, and transition states | `references/current-target-and-transition-architecture.md` |
+| Selecting an enterprise operating model and defining architecture roles | `references/enterprise-operating-model-and-roles.md` |
+| Assigning decision rights, standards, exceptions, or escalation | `references/federated-governance-and-decision-rights.md` |
+| Interviewing stakeholders or publishing usable architecture information | `references/stakeholder-engagement-and-architecture-information.md` |
+| Establishing scope and evidence | `templates/enterprise-context-brief.md` |
+| Creating a portfolio view | `templates/capability-portfolio-view.md` |
+| Sequencing target-state change | `templates/transition-architecture-roadmap.md` |
+| Checking provenance and transformation constraints | `references/source-index.md` |
+
+## Completion
+
+Stop when the enterprise scope and decision owner are explicit, the portfolio and
+state claims have evidence or named gaps, transition increments have dependencies
+and exit evidence, decision rights include conflict handling, and specialist
+handoffs are recorded. Escalate unresolved authority or strategy conflicts rather
+than resolving them by assumption.

enterprise-architecture/evals/evals.json

@@ -0,0 +1,104 @@
+{
+  "schema_version": 1,
+  "skill_name": "enterprise-architecture",
+  "evals": [
+    {
+      "id": "capability-application-duplication",
+      "prompt": "Our claims intake capability is supported by three applications with overlapping names. One serves a regulated region, one owns customer notifications, and one is a legacy batch system. Build a portfolio view and say whether we should consolidate them.",
+      "expected_output": "An evidence-labeled capability/application portfolio view that treats duplication as a hypothesis, checks authority and constraints, and recommends an investigation or bounded action rather than automatic consolidation.",
+      "assertions": [
+        "The output distinguishes capability, value-stream stage, application, and information authority",
+        "It tests duplication against scope, jurisdiction, consumers, ownership, lifecycle, and integration evidence",
+        "It does not recommend consolidation solely because application names overlap",
+        "It identifies accountable owners and evidence gaps"
+      ],
+      "case_set": "regression"
+    },
+    {
+      "id": "operating-model-choice",
+      "prompt": "Five domains need architecture decisions. Local teams move quickly, but incompatible customer identity and reporting choices are creating duplicated spend. Compare centralized, federated, and hybrid enterprise architecture operating models and recommend a conditional choice.",
+      "expected_output": "A comparison grounded in decision locality, coordination cost, coherence, evidence, and risk, with a conditional recommendation and explicit role/authority implications without designing reporting lines.",
+      "assertions": [
+        "All three operating-model options are compared with benefits and costs",
+        "The recommendation is tied to cross-domain duplication and shared identity/reporting constraints",
+        "Roles and decision rights are named without becoming an organization-chart or compensation exercise",
+        "The output states what evidence would cause a different choice"
+      ],
+      "case_set": "regression"
+    },
+    {
+      "id": "decision-rights-conflict",
+      "prompt": "The security team says it owns identity standards, the customer platform team says it owns the identity service, and regional business units need different verification rules. Define an enterprise decision-rights and conflict-resolution record.",
+      "expected_output": "A decision record that separates outcome, enterprise constraint, implementation, and regional operating responsibilities; names consultation and authority; and provides exception and escalation paths.",
+      "assertions": [
+        "The conflict is decomposed into distinct decision and responsibility types",
+        "The record names accountable authority, consultees, affected parties, and escalation",
+        "Regional variation is handled as an explicit constraint or exception rather than silently overridden",
+        "Technology standards and security implementation are handed to their specialist owners"
+      ],
+      "case_set": "regression"
+    },
+    {
+      "id": "transition-architecture",
+      "prompt": "We want a single customer profile platform, but four products still write different profile stores and a regulatory migration cannot happen in one release. Create a transition architecture roadmap with intermediate states, coexistence assumptions, exit evidence, and a safe execution handoff.",
+      "expected_output": "A current/target/transition roadmap that makes authority, dependencies, coexistence, reversibility limits, exit evidence, owners, and migration-engineering handoff explicit.",
+      "assertions": [
+        "Current, target, and at least two useful intermediate states are distinguished",
+        "Data authority, dual-write or coexistence assumptions, and reconciliation evidence are addressed",
+        "The roadmap includes stop/defer conditions and does not claim rollback is always possible",
+        "Approved execution is routed to migration-engineering and implementation-planning"
+      ],
+      "case_set": "regression"
+    },
+    {
+      "id": "org-design-near-miss",
+      "prompt": "Redesign our reporting structure, team topology, compensation bands, and succession plan so the architecture group can scale.",
+      "expected_output": "A routing response to org-design that does not invent an enterprise architecture operating model or HR methodology.",
+      "assertions": [
+        "Reporting structure, team topology, compensation, and succession are routed to org-design",
+        "The enterprise-architecture skill does not produce an organization redesign"
+      ],
+      "case_set": "regression"
+    },
+    {
+      "id": "product-roadmap-near-miss",
+      "prompt": "Turn these ten product ideas into a Now/Next/Later roadmap with confidence, capacity, and continue-or-kill criteria.",
+      "expected_output": "A routing response to product-roadmapping-and-portfolio, with no capability portfolio or enterprise transition method substituted.",
+      "assertions": [
+        "Product bets and outcome sequencing are routed to product-roadmapping-and-portfolio",
+        "The response does not reframe a product roadmap as an enterprise architecture roadmap"
+      ],
+      "case_set": "regression"
+    },
+    {
+      "id": "technology-radar-near-miss",
+      "prompt": "Evaluate whether we should adopt Kafka, compare it with two alternatives, and place the result on an Adopt/Trial/Assess/Hold technology radar.",
+      "expected_output": "A routing response to technology-radar for technology adoption posture and radar mechanics, optionally noting enterprise capability context as an input.",
+      "assertions": [
+        "Technology adoption comparison and radar placement are routed to technology-radar",
+        "The enterprise-architecture skill does not reproduce a technology radar method"
+      ],
+      "case_set": "regression"
+    },
+    {
+      "id": "software-architecture-near-miss",
+      "prompt": "Design the runtime architecture for a new order service, including service boundaries, synchronous versus asynchronous calls, consistency, retries, and failure recovery.",
+      "expected_output": "A routing response to software-architecture because the task is system-level runtime and failure design, not enterprise portfolio alignment.",
+      "assertions": [
+        "Runtime boundaries, consistency, retries, and failure behavior are routed to software-architecture",
+        "The response does not produce an enterprise capability map as a substitute"
+      ],
+      "case_set": "regression"
+    },
+    {
+      "id": "strategy-near-miss",
+      "prompt": "Choose whether to enter the healthcare market, acquire a competitor, or focus on our current segment using competitive analysis and capital allocation.",
+      "expected_output": "A routing response to strategy-frameworks for corporate direction, competitive choices, acquisition, and capital allocation.",
+      "assertions": [
+        "Corporate strategy, market entry, acquisition, and capital allocation are routed to strategy-frameworks",
+        "The enterprise-architecture skill does not answer the corporate strategy decision"
+      ],
+      "case_set": "regression"
+    }
+  ]
+}

enterprise-architecture/references/capability-value-stream-and-portfolio-mapping.md

@@ -0,0 +1,48 @@
+# Capability, Value-Stream, and Portfolio Mapping
+
+Use this reference when an enterprise question concerns what the organization does,
+how value moves, or which applications and information support it.
+
+## Map in layers
+
+1. Name the outcome or stakeholder need. A capability is an enduring ability, not a
+   project, team, system, or slogan.
+2. Describe the value stream as a sequence of stakeholder-visible stages that turns
+   a need into an outcome. Keep it outcome-oriented; do not confuse it with an
+   internal process map.
+3. Decompose capabilities only until owners can assess health and investment. Stop
+   before the map becomes an implementation work breakdown.
+4. Link each capability to applications, information assets, technology dependencies,
+   owners, consumers, lifecycle status, cost evidence, and known risks.
+5. Record confidence and provenance for every relationship. A plausible relationship
+   is not observed evidence.
+
+## Portfolio questions
+
+For each capability, ask: How important is it to the stated outcome? How differentiated
+or commodity is it? What is its health and change pressure? Which applications support
+it, and are they authoritative, duplicative, overlapping, or merely adjacent?
+
+Treat duplication as a hypothesis requiring comparison of scope, users, data
+authority, lifecycle, integration cost, and contractual constraints. Do not recommend
+consolidation merely because two systems have similar names. A shared capability may
+legitimately have multiple implementations when jurisdictions, risk, latency, or
+customer commitments differ.
+
+## Minimum portfolio fields
+
+| Field | Question |
+|---|---|
+| Capability | What enduring ability is being assessed? |
+| Value-stream stage | Which stakeholder-visible outcome stage needs it? |
+| Application | Which product or system supports it? |
+| Authority | Which system or role owns the authoritative decision/data? |
+| Relationship | Supports, consumes, duplicates, constrains, or depends on |
+| Health | Evidence of fitness, risk, cost, or change pressure |
+| Owner | Accountable business and technology roles |
+| Decision | Invest, contain, converge, replace, retain, or investigate |
+| Confidence | High, medium, or low with a reason |
+
+Keep application architecture and API contract detail with their specialist owners.
+This view is for enterprise alignment and investment conversation, not low-level
+solution design.

enterprise-architecture/references/current-target-and-transition-architecture.md

@@ -0,0 +1,47 @@
+# Current, Target, and Transition Architecture
+
+Use this reference when a desired enterprise state spans multiple domains or cannot
+be reached safely in one change.
+
+## Describe each state
+
+- **Current:** observed capabilities, applications, information, technology,
+  dependencies, constraints, pain, and ownership. Mark unknowns instead of filling
+  gaps with a preferred future.
+- **Target:** the future arrangement tied to outcomes, principles, measurable
+  constraints, ownership, and decision rights. It is a hypothesis until adopted and
+  funded.
+- **Transition:** a stable intermediate arrangement that reduces risk or unlocks the
+  next change. It must be useful on its own, not a disguised project phase.
+
+For every target difference, record the dependency, affected capability, change
+owner, reversibility, customer or operational impact, and evidence that would permit
+the next move.
+
+## Choose transitions
+
+Prefer increments that remove a material constraint, establish missing ownership,
+reduce duplicated investment, or create evidence for a disputed target. Compare
+options by value, dependency order, disruption, reversibility, coexistence burden,
+and ability to stop safely. A transition may retain legacy components deliberately
+when replacement would create greater risk.
+
+Do not promise rollback when data, contracts, training, or operating behavior have
+irreversibly changed. Name roll-forward, containment, or retirement alternatives and
+route execution to `migration-engineering` after the target is approved.
+
+## Transition quality check
+
+Each increment should state:
+
+- entry conditions and the capability/outcome it advances;
+- systems, information, roles, and decisions affected;
+- dependencies and coexistence assumptions;
+- user, operational, cost, and risk consequences;
+- exit evidence and a named accountable owner;
+- stop, defer, or proceed conditions;
+- next transition enabled and residual debt accepted.
+
+Architecture decides the coherent sequence and guardrails. Product owns product
+commitments, strategy owns corporate choices, organization design owns people
+changes, and delivery/migration owners execute approved work.

enterprise-architecture/references/enterprise-operating-model-and-roles.md

@@ -0,0 +1,34 @@
+# Enterprise Operating Model and Roles
+
+Use this reference when architecture work is blocked by unclear ownership or when
+the organization must choose how much decision authority to centralize.
+
+## Compare operating models
+
+| Model | Strength | Cost or risk | Fit signal |
+|---|---|---|---|
+| Centralized | Coherent enterprise standards and clear escalation | Slow local decisions and distance from domain context | Shared constraints are high and local variation is costly |
+| Federated | Domain expertise and faster local decisions | Divergence, duplication, and coordination burden | Domains own outcomes and can honor shared contracts |
+| Hybrid | Central guardrails with local design authority | Boundary ambiguity unless rights are explicit | Enterprise coherence matters but domain variation is real |
+
+Choose from the work: decision frequency, reversibility, cross-domain coupling,
+regulatory exposure, scarce expertise, and the cost of divergence. Do not select a
+model from organization size or fashion alone. Reassess when evidence shows that a
+decision is repeatedly escalated, duplicated, delayed, or made without affected
+owners.
+
+## Define roles without designing the organization
+
+Name the accountable enterprise sponsor, capability owner, domain architect,
+technology or platform owner, information owner, product owner, operations owner,
+and delivery owner only where their decision or evidence is relevant. For each role,
+state the decision or promise, authority boundary, required consultees, evidence
+owed, and escalation route. This is an architecture operating contract, not a
+reporting structure, compensation plan, or talent model; route those to `org-design`.
+
+## Test the choice
+
+Ask whether local teams can make safe decisions with the available context, whether
+shared standards are enforceable, whether exceptions are visible, and whether anyone
+is accountable for cross-capability outcomes. If the answer is no, record a maturity
+or capability gap rather than inventing a council that has no authority.

enterprise-architecture/references/federated-governance-and-decision-rights.md

@@ -0,0 +1,36 @@
+# Federated Governance and Decision Rights
+
+Use this reference when multiple domains must remain coherent without routing every
+choice through a central board.
+
+## Start with the decision
+
+For each decision record its scope, affected capabilities, reversibility, blast
+radius, regulatory obligations, evidence, and accountable owner. Then select a path:
+
+- **Local decision:** the domain owns the outcome and compatibility is bounded.
+- **Federated decision:** a domain decides within published enterprise constraints
+  and affected peers can raise a conflict.
+- **Advice process:** the proposer owns the choice after consulting those bearing
+  material consequences; advice is not an unrecorded veto.
+- **Central decision:** a named authority decides when impact, irreversibility,
+  mandatory control, or unresolved cross-domain conflict exceeds local authority.
+
+These are governance choices, not maturity levels. Automate objective checks where
+possible, but do not turn a judgment into a false pass/fail rule.
+
+## Make conflicts resolvable
+
+Every standard or decision should name the proposer, accountable owner, affected
+parties, required consultation, decision authority, evidence threshold, exception
+path, expiry or revisit trigger, and appeal/escalation route. When two owners have
+legitimate authority over the same boundary, first separate the decision into
+outcome, constraint, implementation, and operating responsibilities. If authority
+still conflicts, escalate to the named enterprise sponsor; never silently choose.
+
+Review feedback from delivery, operations, cost, incidents, adoption, and exceptions.
+Revise or retire a control when it no longer prevents a meaningful failure. Keep the
+historical decision and reason for change visible.
+
+Technology standards and radar posture remain with `technology-radar`; durable
+decision history remains with `adr-authoring`.

enterprise-architecture/references/source-index.md

@@ -0,0 +1,28 @@
+# Public Source Index and Transformation Boundary
+
+This skill is an original, task-centered methodology. Public sources provide
+terminology and prompts for comparison; they are not reproduced as instructional
+text.
+
+| Source | Use in this skill | URL |
+|---|---|---|
+| ISO/IEC/IEEE 42010 overview | Stakeholders, concerns, viewpoints, and architecture descriptions | https://www.iso.org/standard/74393.html |
+| ArchiMate specification | Public notation vocabulary for relationships among motivation, strategy, business, application, and technology views | https://www.opengroup.org/archimate-forum/archimate-overview |
+| TOGAF public overview | Enterprise architecture lifecycle vocabulary and governance context only | https://www.opengroup.org/togaf |
+| Wardley Mapping public guide | Capability positioning and dependency conversation prompts; no prescribed map is reproduced | https://learnwardleymapping.com/ |
+| Thoughtworks Technology Radar | Technology adoption and uncertainty vocabulary; portfolio governance remains with `technology-radar` | https://www.thoughtworks.com/radar |
+| W3C Web Content Accessibility Guidelines | Accessible information and communication requirements | https://www.w3.org/TR/WCAG22/ |
+
+## Transformation boundary
+
+Purchased ebooks and the private synthesized comparison report may inform research
+only. This repository does not reproduce their prose, tables, diagrams, examples,
+taxonomies, chapter order, or distinctive presentation. The deliverable was written
+from user tasks, public sources, repository ownership boundaries, and fresh examples.
+Do not read or quote purchased ebooks while using or extending this skill.
+
+The method keeps only cross-source decision pressures: connect capability to
+outcome, distinguish evidence from aspiration, choose a reachable transition, place
+authority near the decision while protecting enterprise coherence, and publish
+information that people can actually use. Future edits should be rewritten from the
+user task if they resemble a source's distinctive structure or wording.

enterprise-architecture/references/stakeholder-engagement-and-architecture-information.md

@@ -0,0 +1,33 @@
+# Stakeholder Engagement and Architecture Information
+
+Use this reference when the architecture must be understood and used by people
+with different decisions, vocabulary, access needs, or levels of technical detail.
+
+## Engage by decision job
+
+Identify who decides, who supplies evidence, who is affected, who operates the
+result, and who can block adoption. Ask each stakeholder what decision they need to
+make, what evidence would change it, and what consequence they cannot accept. Use
+`product-discovery` for raw product or stakeholder discovery when that is the primary
+task; this reference focuses on architecture alignment.
+
+Create audience-specific views from one traceable model:
+
+- executive: outcome, material choices, investment, risk, and unresolved authority;
+- capability owner: health, dependencies, applications, and decision rights;
+- product or delivery team: transition slice, constraints, dependencies, and exit evidence;
+- operator: runtime ownership, support impact, recovery assumptions, and signals.
+
+## Publish information people can use
+
+Every view should have an owner, purpose, scope, as-of date, evidence links,
+confidence, decision status, and next review trigger. Prefer plain language, stable
+terms, text alternatives for diagrams, headings that expose structure, keyboard- and
+screen-reader-friendly tables in rendered outputs, sufficient contrast, and no
+meaning conveyed by color alone. Link related views rather than copying facts into
+multiple uncontrolled documents.
+
+Architecture information is successful when a stakeholder can find the relevant
+decision, understand what is known versus proposed, identify their responsibility,
+and challenge it through a visible route. A polished repository with no user or
+review behavior is not an architecture capability.

enterprise-architecture/templates/capability-portfolio-view.md

@@ -0,0 +1,24 @@
+# Capability Portfolio View
+
+## Scope
+- Outcome or value stream:
+- Assessment date:
+- Portfolio owner:
+- Evidence limitations:
+
+## View
+| Capability | Value-stream stage | Applications and relationship | Information authority | Owners | Health/risk/cost evidence | Decision | Confidence |
+|---|---|---|---|---|---|---|---|
+| | | | | | | | |
+
+## Duplication hypotheses
+| Items compared | Similarity observed | Material difference or constraint | Evidence needed | Proposed action | Owner |
+|---|---|---|---|---|---|
+| | | | | | |
+
+## Portfolio decisions
+- Invest:
+- Contain:
+- Converge or retire:
+- Investigate:
+- Decisions routed to `software-architecture`, `data-architect`, `api-design-and-evolution`, or `technology-radar`:

enterprise-architecture/templates/enterprise-context-brief.md

@@ -0,0 +1,30 @@
+# Enterprise Context Brief
+
+## Decision and outcome
+- Enterprise question:
+- Desired outcome:
+- Decision owner and authority:
+- Scope and exclusions:
+- Decision horizon:
+
+## Context
+- Strategic or product inputs (link):
+- Current operational evidence (link):
+- Regulatory, contractual, or customer constraints:
+- Known dependencies:
+
+## Stakeholders
+| Stakeholder | Decision or evidence needed | Consequence | Engagement owner |
+|---|---|---|---|
+| | | | |
+
+## Evidence ledger
+| Claim | Type (evidence/assumption/decision/open) | Source or gap | Confidence | Owner |
+|---|---|---|---|---|
+| | | | | |
+
+## Boundaries and handoffs
+- Enterprise architecture owns:
+- Specialist owners:
+- Unresolved authority conflict:
+- Next validation:

enterprise-architecture/templates/transition-architecture-roadmap.md

@@ -0,0 +1,26 @@
+# Transition Architecture Roadmap
+
+## Target and constraints
+- Target outcome and principles:
+- Current-state constraints:
+- Non-negotiable safety or compliance conditions:
+- Target owner:
+
+## Transition increments
+| Increment | Capability/outcome advanced | Systems, information, and roles affected | Dependencies | Coexistence assumption | Exit evidence | Owner | Stop/defer condition |
+|---|---|---|---|---|---|---|---|
+| | | | | | | | |
+
+## Sequence rationale
+- Why this order:
+- Options rejected and why:
+- Customer and operational impact:
+- Reversibility, roll-forward, or containment path:
+
+## Governance and handoffs
+- Decision rights and escalation:
+- Product commitments: `product-roadmapping-and-portfolio`
+- Organization changes: `org-design`
+- Technology posture: `technology-radar`
+- Approved implementation/migration execution: `implementation-planning` / `migration-engineering`
+- Review trigger and date:

llms.txt

@@ -42,6 +42,7 @@
 - [dsm5](dsm5/SKILL.md): Assess and explain questions about mental health and neurocognitive conditions against DSM-5-TR diagnostic criteria, and guide evidence-based conversations for clinicians, patients, and family members. Use when someone asks about symptoms, possible conditions, differential diagnoses, diagnostic criteria, prevalence, specifiers, or wants to understand or explain a mental health or neurological condition in plain language. Do not use for formal diagnosis, treatment decisions, crisis intervention, legal or insurance determinations, or any situation that requires a licensed clinician's judgment.
 - [dspy](dspy/SKILL.md): Expert skill for programming—not prompting—language models with Stanford's DSPy framework. Signatures, modules (Predict, ChainOfThought, ReAct), optimizer/teleprompter selection, compilation, caching, evaluation. Use when doing programmatic prompt optimization or building compiled prompt programs.
 - [email](email/SKILL.md): Send and diagnose transactional email through Twilio SendGrid from a terminal or agent: send messages, check deliverability (bounces and spam reports), and verify Signed Event Webhook signatures (ECDSA P-256) — with a bundled email-cli script that is read-only by default and gates every send behind a --dry-run/--yes confirmation. Use when an agent needs to send a transactional email, triage bounces or spam complaints, or confirm an inbound SendGrid webhook is authentic. Do not use for marketing or bulk email campaigns (that is SendGrid Marketing Campaigns), building email template systems, or other email providers (that is their own tooling).
+- [enterprise-architecture](enterprise-architecture/SKILL.md): Design and evolve enterprise architectures by connecting business capabilities, value streams, applications, information, technology, operating models, and transition choices. Use when mapping an enterprise portfolio, comparing current and target states, sequencing transition architectures, or defining federated architecture decision rights and stakeholder communication. Do not use for system or solution design, API or data-platform design, organizational or talent design, product roadmaps, technology adoption, or corporate strategy; route those to the named specialist skills.
 - [epub](epub/SKILL.md): EPUB file format expert — read, write, and edit EPUB2/EPUB3 ebooks. Extract text, metadata, structure, and knowledge from EPUB files for enrichment or memory. Create valid EPUBs from scratch. Validate against the EPUB specification. Use when the user mentions epub, ebook, EPUB file, ebook format, read epub, write epub, create ebook, extract from epub, epub to text, or ebook structure.
 - [esp32-development](esp32-development/SKILL.md): Build, configure, flash, test, debug, and recover firmware for ESP32-family boards, including ESP-IDF C/C++, Arduino/PlatformIO, MicroPython, CircuitPython, ESPHome, Zephyr, Rust, and NuttX. Use when identifying an ESP32 board, choosing a framework, wiring GPIO or peripheral buses, integrating sensors or actuators, diagnosing serial/boot/power/network failures, or planning OTA and production security. Do not use as a substitute for the exact board schematic, SoC datasheet, or attached component datasheet.
 - [financial-modeling](financial-modeling/SKILL.md): Build and review assumptions-led financial models, unit economics, pricing, fundraising scenarios, and SaaS operating metrics. Use when calculating CAC, LTV, payback, runway, ARR, churn, NDR, Rule of 40, or sales efficiency; when modeling revenue, costs, cash flow, pricing, cap tables, or financing.

references/skill-triggers.md

@@ -23,6 +23,7 @@ Each skill's `description` field is the canonical routing contract. This conveni
 | "traefik", "reverse proxy", "load balancer", "API gateway", "Let's Encrypt", "ACME", "Docker routing", "traefik.yml", "entry point", "middleware", "TLS termination", "forward auth", "rate limit" | [traefik](../traefik/SKILL.md) |
 | "reverse-engineer", "understand this codebase", "PRD from code", "architecture document", "architecture health", "coupling analysis", "modularity", "decomposition readiness", "data ownership map", "distributed workflow analysis", "reconciliation path" | [software-architecture-analysis](../software-architecture-analysis/SKILL.md) |
 | "software architecture design", "greenfield architecture", "target architecture", "architecture tradeoff", "modular monolith", "service decomposition decision", "distributed workflow design", "architecture fitness function", "architecture drift", "architecture review" | [software-architecture](../software-architecture/SKILL.md) |
+| "enterprise architecture", "enterprise capability map", "capability mapping", "value-stream architecture", "application portfolio", "information portfolio", "business technology alignment", "current-state architecture", "target-state enterprise architecture", "transition architecture", "enterprise architecture operating model", "cross-domain architecture decision rights", "enterprise architecture governance", "architecture stakeholder engagement" | [enterprise-architecture](../enterprise-architecture/SKILL.md) |
 | "data architecture", "data platform", "data strategy", "data mesh", "governance" | [data-architect](../data-architect/SKILL.md) |
 | "AI governance", "AI governance program", "responsible AI", "model risk", "AI risk tier", "AI risk tiering", "use-case risk tier", "governance operating model", "AI decision rights", "AI governance council", "AI risk framework", "NIST AI RMF", "ISO 42001", "AI lifecycle gate", "AI fairness review", "AI transparency", "explainability review", "LLM governance review", "agent safety review", "prompt injection governance", "AI regulatory compliance", "EU AI Act", "AI compliance plan", "GxP AI governance", "ALCOA+", "data integrity governance", "computerized system validation", "AI in regulated life sciences", "AI QMS interface", "governance maturity assessment", "AI board reporting", "board AI governance", "third-party AI due diligence", "model card" | [ai-governance](../ai-governance/SKILL.md) |
 | "de-spin", "is this spin", "propaganda", "misdirection", "true lies", "what is this leaving out", "misleading claim", "selective framing", "evidence theater", "separate what is true false complicated" | [de-spin](../de-spin/SKILL.md) |
@@ -65,7 +66,7 @@ Each skill's `description` field is the canonical routing contract. This conveni
 | "product experiment", "experiment design", "A/B test design", "hypothesis test product", "feature experiment", "fake door test", "concierge test", "assumption test", "experiment brief", "experiment guardrail", "experiment readout", "ship decision", "no-ship decision", "experiment ethics", "prototype test experiment", "qualitative experiment", "stopping rule experiment", "method selection experiment", "underpowered experiment" | [product-experimentation](../product-experimentation/SKILL.md) |
 | "product lifecycle", "product life cycle", "lifecycle phase", "lifecycle routing", "product phase", "phase entry evidence", "phase handoff", "lifecycle evidence ledger", "product lifecycle bundle", "cross-phase routing", "product lifecycle management", "evaluate a new product idea", "product retirement decision", "continue pivot or retire", "product delivery handoff" | [product-lifecycle](../product-lifecycle/SKILL.md) |
 | "product lifecycle learning", "lifecycle learning", "post-launch review", "outcome review", "feature health", "retirement decision", "feature retirement", "deprecation plan", "sunset plan", "assumption ledger", "retained learning", "launch-to-learning", "continue improve harvest pivot pause retire", "migration path retirement", "customer treatment sunset", "epistemic discipline", "expected vs observed" | [product-lifecycle-learning](../product-lifecycle-learning/SKILL.md) |
-| "product operations", "product governance", "operating model", "decision rights", "product council", "intake review", "portfolio review cadence", "launch review", "experiment review governance", "lifecycle review governance", "evidence standard product", "exception record", "escalation record", "product decision authority", "governance cadence", "product operating model", "lightweight governance", "high-assurance governance", "cross-functional operating contract" | [product-operations-and-governance](../product-operations-and-governance/SKILL.md) |
+| "product operations", "product governance", "product decision rights", "product council", "intake review", "portfolio review cadence", "launch review", "experiment review governance", "lifecycle review governance", "evidence standard product", "exception record", "escalation record", "product decision authority", "governance cadence", "product operating model", "lightweight product governance", "high-assurance product governance", "cross-functional product operating contract" | [product-operations-and-governance](../product-operations-and-governance/SKILL.md) |
 | "product roadmap", "outcome roadmap", "Now/Next/Later", "strategic bet", "bet record", "portfolio roadmap", "roadmap review cadence", "continue/pause/kill criteria", "scenario planning roadmap", "dependency mapping portfolio", "portfolio capacity allocation", "roadmap stakeholder communication" | [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md) |
 | "product UX", "product design", "interaction design", "information architecture", "task flow", "user flow", "state model", "recovery path", "interface contract", "UX handoff", "usability study plan" | [product-design-and-ux](../product-design-and-ux/SKILL.md) |
 | "production excellence", "production gate", "launch decision gate", "go no-go defer exception", "production acceptance", "cross-domain evidence", "production evidence packet", "operational handoff", "post-launch learning", "production gate review", "gate model", "escalation decision", "production exception", "cost SLO conflict", "readiness gate", "migration gate review", "recovery evidence gate" | [production-excellence](../production-excellence/SKILL.md) |
@@ -92,7 +93,7 @@ Each skill's `description` field is the canonical routing contract. This conveni
 | "adr-authoring", "adr authoring", "architecture decision record", "fitness function", "decision confirmation" | [adr-authoring](../adr-authoring/SKILL.md) |
 | "c4-diagramming", "c4 diagramming" | [c4-diagramming](../c4-diagramming/SKILL.md) |
 | "capacity engineering", "cost engineering", "capacity model", "capacity planning", "unit cost", "cost per request", "cost per user", "budget threshold", "spending alert", "spending cap", "rate limit enforcement", "quota management", "load test plan", "soak test plan", "capacity projection", "growth forecast capacity", "peak sizing", "degraded capacity", "SLO cost tradeoff", "cost attribution", "cost anomaly review", "cost-aware architecture", "cost-performance tradeoff" | [capacity-and-cost-engineering](../capacity-and-cost-engineering/SKILL.md) |
-| "technology-radar", "technology radar", "architecture governance", "proportional governance", "advice process", "federated architecture decision", "architecture exception", "technology standards" | [technology-radar](../technology-radar/SKILL.md) |
+| "technology-radar", "technology radar", "technology portfolio governance", "proportional technology governance", "technology advice process", "federated technology decision", "technology standards exception", "technology standards" | [technology-radar](../technology-radar/SKILL.md) |
 | "strategy", "strategic planning", "OKRs", "strategic narrative", "Five Forces", "Blue Ocean", "competitive positioning", "moat", "Ansoff", "Three Horizons", "market entry", "capital allocation", "M&A evaluation", "BCG Matrix", "portfolio management" | [strategy-frameworks](../strategy-frameworks/SKILL.md) |
 | "Supabase", "Supabase CLI", "supabase start", "supabase migration", "Supabase Auth", "Supabase RLS", "Supabase Storage", "Supabase Realtime", "Edge Functions", "self-host Supabase", "self-hosted Supabase", "Supabase Docker", "Supabase backup", "Supabase restore", "Supabase upgrade" | [supabase](../supabase/SKILL.md) |
 | "Vercel Eve", "eve agent", "eve dev", "eve build", "eve start", "Eve self-hosting", "durable Eve session", "Eve sandbox", "Eve Workflow", "Eve subagent", "Eve agent skills", "Eve deployment", "Eve reverse proxy" | [vercel-eve](../vercel-eve/SKILL.md) |

technology-radar/SKILL.md

@@ -15,7 +15,7 @@ CTO methodology for making technology decisions, governing architecture, measuri
 
 ## When Not to Use
 
-- Route enterprise capability maps, operating-model design, and current/target-state roadmaps to the appropriate enterprise-architecture owner. This skill stays focused on technology portfolio posture and governance mechanics; use [`software-architecture`](../software-architecture/SKILL.md) for system-level target design.
+- Route enterprise capability maps, operating-model design, and current/target-state roadmaps to [`enterprise-architecture`](../enterprise-architecture/SKILL.md). This skill stays focused on technology portfolio posture and governance mechanics; use [`software-architecture`](../software-architecture/SKILL.md) for system-level target design.
 - Route the durable record of one consequential decision to `adr-authoring`; use this skill to choose the governance path and connect the decision to standards or radar feedback.
 - Route system design and code changes to the relevant engineering skill, security requirements and threat modeling to `secure-software-engineering`, and live operations or SLO work to `site-reliability-engineering`.
 

technology-radar/evals/evals.json

@@ -78,6 +78,7 @@
       "expected_output": "No. Enterprise capability mapping and target-state roadmaps belong to enterprise architecture; ADR structure belongs to ADR authoring; and incident response/runbooks belong to operations or SRE. Technology-radar may supply technology portfolio posture, governance-mode selection, standards, exceptions, and feedback links at the boundaries, but it should not absorb those neighboring workflows.",
       "assertions": [
         "Enterprise capability and target-state roadmap work is routed away from technology-radar",
+        "The enterprise-architecture owner is named for capability and target-state work",
         "ADR authoring is identified as a separate neighboring owner",
         "Incident response and operational runbooks are identified as separate operational ownership",
         "The response preserves technology-radar's technology portfolio and governance boundary"