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:

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.

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.