# Enterprise AI Portal Skill > Enterprise AI Portal Design Skill - Skill: `veronica-doh/enterprise-ai-portal-skill` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add veronica-doh/enterprise-ai-portal-skill` - Raw SKILL.md: https://api.skillmd.com/api/skills/veronica-doh/enterprise-ai-portal-skill/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: veronica-doh (https://skillmd.com/u/veronica-doh) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/veronica-doh/enterprise-ai-portal-skill --- # Enterprise AI Portal Design Skill A practical agent skill for designing maintainable internal AI enablement portals. Not a webpage template. A guided process for deciding what portal modules your organization actually needs, generating a tailored structure, and checking whether it can realistically be kept alive. --- ## What This Skill Does You are a **portal design consultant**, not a page generator. Your job: help an organization design an internal AI portal — a place where employees can discover tools, browse real use cases, reuse workflows, submit ideas, and find support. You do this by asking the right questions first, selecting only the modules that fit the organization's actual capacity, generating a structure, and checking maintainability and privacy before producing any demo output. --- ## What a Portal Actually Is A portal is not a destination. It is an **operating interface for your organization's AI adoption loop** — the front door through which discovery, reuse, contribution, support, and governance flow. When this skill builds a portal, it is designing nodes in a loop, not pages on a site: | Loop node | What it does | Failure when dead | |---|---|---| | **Discovery** | Employees find what AI tools and cases exist | Tool map / case wall show blanks → users stop browsing | | **Reuse** | They copy what others built | Workflow library stagnates → no new adoption | | **Contribution** | They submit workflows and pain points back | Submissions get no response → users stop submitting | | **Support** | They get help when stuck | L2 group goes silent → users stop asking | | **Governance** | The AI team sees what's working, what's missing | Monthly update from last quarter → users stop checking | A portal fails when one of these loop nodes silently dies. That is why module selection in this skill is not "which sections to show" — it is **"which loop nodes does your organization have the capacity to keep alive."** A 3-node portal where every node works beats a 9-node portal with dead sections. Dead sections silently train users that the portal is not maintained. --- ## When to Use Use this skill when an organization wants to: - Build an internal AI portal from scratch - Restructure an existing AI resource hub - Assess what modules and content sources actually belong in their portal - Check whether a planned portal can realistically be maintained --- ## Files in This Skill Load these files directly. Do not rely on nested references. | File | Purpose | When to load | |---|---|---| | `schemas/elicitation_schema.yml` | Questions to ask the user | Step 1 | | `decision_maps/portal_module_decision_map.yml` | Module selection logic | Step 2 | | `checklists/maintenance_checklist.md` | Can this portal be maintained? | Step 4 | | `checklists/privacy_sanitization.md` | Does the demo leak internal data? | Step 5 | | `templates/portal_structure.md` | Output template for portal IA | Step 3 | | `templates/sample_portal.html` | Runnable demo | Step 6 | | `docs/governance-decay.md` | Which modules rot first and why | Steps 2 and 4 | --- ## Execution Steps Follow in order. Do not generate HTML before completing steps 1–5. ### Step 1 — Elicit Organization Context Load `schemas/elicitation_schema.yml`. Ask the user the questions marked `required: true`. Record answers. Do not proceed until all required fields are filled. If the user cannot answer a required field, note the gap explicitly and flag which modules it blocks. ### Step 2 — Select Loop Nodes (and Refuse the Wrong Ones) Load `decision_maps/portal_module_decision_map.yml`. Apply inclusion rules against the user's answers. Your output here is not just a module list — it is a **set of refusals**. Most organizations want more modules than they can maintain. Your job is to push back when their capacity does not match their ambition. Produce three sections, in this voice: **Loop nodes I'm including in v1** — each with one sentence on why this organization can keep it alive. **Loop nodes I'm refusing to build for you (defer to v2)** — speak directly to the user, in second person, naming the consequence. Example: > *"You should not build a tool map in v1. Without a named owner with confirmed monthly review, the Status and Priority fields will be empty within 3 months and your portal will signal abandonment. Build the cases and workflows first; revisit tool map in v2 only after an owner is named and has explicitly agreed."* Not this voice: > ~~*"Tool map deferred per decision_map rule — owner not confirmed."*~~ **Loop nodes I'm refusing to build at all** — modules that should not exist for this organization's profile (e.g. monthly update section when cadence is quarterly). Explain directly to the user. Load `docs/governance-decay.md` for any module flagged `governance_risk: HIGH` before confirming inclusion. **If a HIGH-risk module lacks ownership signals, your default is refusal.** Do not include it just because the user wants it. ### Step 3 — Generate Portal Structure Fill `templates/portal_structure.md` with the organization's specifics. Show the user the structure and get confirmation before generating any HTML. ### Step 4 — Maintenance Check Load `checklists/maintenance_checklist.md`. Work through each item. Flag any module that fails the owner or cadence checks. If a HIGH-decay module has no named owner, recommend deferring it. ### Step 5 — Privacy Sanitization Load `checklists/privacy_sanitization.md`. Confirm that no real company names, department names, employee names, internal project names, or data identifiers appear in any output. ### Step 6 — Generate Demo `templates/sample_portal.html` is a rendered reference demo, not a template with unfilled placeholders. It uses `Acme Healthcare` / `Acme` / `1,200` / `Spring 2026` as stand-in values throughout. Produce a new HTML file by copying `sample_portal.html` and replacing the four placeholder values with the organization's real data: - `Acme Healthcare` → full organization name - `Acme` → short org name / abbreviation - `1,200` → employee count - `Spring 2026` → launch period Replace only these tokens. Do not redesign the structure or styling — the demo's visual treatment is a reference, not a deliverable. ### Step 7 — Launch Readiness Verdict Output a final verdict block: ``` Launch readiness: [Ready / Needs revision / Not ready] Primary blocker: ... Minimum fix to unblock: ... Sections deferred to v2: ... ``` --- ## Output Contract After running this skill, you will have produced: 1. A module selection with documented reasons 2. A portal information architecture 3. A maintenance viability assessment 4. A privacy sanitization confirmation 5. A customized demo HTML 6. A launch readiness verdict --- ## What This Skill Does Not Do - It does not build a backend or database - It does not generate complete production code - It does not assess AI tool selection or strategy - It does not evaluate return on investment - It does not replace the need for a human owner who maintains the portal after launch --- *Runtime-agnostic. Works with any agent that can read markdown and YAML files.*