Ucsd Cms

UCSD CMS (Hannon Hill Cascade) Authoring

Help users create, edit, publish, and maintain pages on UC San Diego websites managed in Hannon Hill Cascade CMS (Blink and many *.ucsd.edu department sites), following the campus authoring workflow and quality requirements.

This skill is a navigator over the official Blink CMS training. For step-level UI detail, fetch the linked Blink page rather than relying on memory — Blink is the source of truth and is updated by the campus web team.

• Training hub:

When to use

• Adding, editing, moving, or deleting a page or folder on a UCSD Cascade site.
• Choosing a template or module for new content.
• Writing or fixing page metadata (title, summary, display name, system name).
• Reviewing a page before publish (accessibility, SEO, links, headings).
• Publishing to stage or live, unpublishing, or rolling back a version.
• Managing site users, navigation, or QA via SiteImprove.
• Onboarding: requesting CMS training and access.

Core terminology (quick reference)

| Term | What it is | |---|---| | Site | A collection of pages under one domain (e.g. sitename.ucsd.edu). | | Page | One webpage within a site. | | System name | Lowercase, hyphenated; determines the page's URL slug. | | Display name | Metadata; determines how the page appears in navigation menus. | | Metadata | Title, summary, author, display name attached to a page. | | Template | Pre-built page layout selected at creation time. | | Module | Reusable content block placed on a page. | | Drawer / Tab | Interactive sections that reveal additional content in place. | | Shortlink | Same-subdomain redirect using go in the URL. | | Vanity URL | Separate-subdomain redirect; needs coordination. |

Full list: Basic Terminology.

How to use this skill

Identify which workflow the user is in, then walk through the matching steps below. When a step requires UI specifics, fetch the linked Blink page for current instructions.

1. Get access (first time)

1. Training and access — complete required training before access is granted.
2. Logging in, Dashboard, Navigation screen, User settings.
3. Roles and responsibilities — confirm the user has the right role for what they're trying to do.

2. Create new content

1. Plan the page — purpose, audience, where it lives in the site hierarchy.
2. Add a new page or folder, or copy an existing one.
3. Choose a template — match the template to the page type; don't fight the template with manual formatting.
4. Set metadata: title, summary, display name (nav label), and a lowercase-hyphenated system name (URL slug).

3. Edit a page

1. Editing workflow → edit the page.
2. Use the right primitives:

• Headings — exactly one H1, no skipped levels.
• Formatting, Links, Tables.
• Modules for reusable blocks.
• Images and files via the file chooser.

1. Preview every change.
2. Submit (save) the draft.
3. For Blink editors: review the common revisions list before submitting.

4. Publish

1. Publish to stage or live. Always preview before publishing live.
2. Mind publishing relationships — changing a shared asset republishes everything that uses it.
3. To retire content: unpublish (keeps the asset) or disable publishing.
4. Publish the entire site only when a site-wide change requires it.

5. Advanced operations

Version rollback · Asset audit · Site navigation menus · Reorder pages · Embed video · Move asset · Delete asset · Recover deleted asset · Analytics · Embed code · Kitchen Sink (all components, one page).

6. Manage the site

• Add-ons & tools
• SiteImprove — broken links, accessibility, QA monitoring.
• Accessibility — site-level improvements.
• SEO
• Site organization
• User management
• QA review
• AI tools

7. Writing for the web

• Philosophy & writing style
• Editorial style guide

Pre-publish checklist

Before publishing live, confirm:

• [ ] Template matches the page type; no custom CSS hacks to fake another template.
• [ ] System name is lowercase, hyphenated, stable (changing it breaks the URL).
• [ ] Display name is short, scannable, matches site nav style.
• [ ] Metadata title and summary are filled in (SEO + previews depend on these).
• [ ] Headings start at H1, no skipped levels, structure reflects content hierarchy.
• [ ] Links are descriptive (no "click here"); internal links use the file chooser, not pasted URLs.
• [ ] Images have meaningful alt text; decorative images marked accordingly.
• [ ] Tables are used for tabular data only (not layout); have headers.
• [ ] Files uploaded via the file chooser; PDFs are accessible (tagged, not scanned images).
• [ ] Previewed in the CMS preview before submit.
• [ ] Accessibility — run SiteImprove or the current UCSD accessibility guidance before publishing high-traffic pages.
• [ ] Data classification — no P3/P4 data on a public page; use the ucsd-data-classification skill if installed, otherwise UC IS-3 guidance.
• [ ] Brand & voice — for visual/voice review, use the ucsd-branding skill if installed.

Guardrails

• Never publish without previewing first. The CMS preview is the only reliable check.
• Never change a system name on a live page without a redirect plan — it breaks every link to that URL.
• Never paste raw HTML into the editor to bypass the template unless explicitly required and reviewed; templates encode accessibility and brand defaults.
• Never upload images or files outside the CMS file chooser — broken links and missing asset audit otherwise.
• Never put P3/P4 data (FERPA student records, PII, secrets, etc.) on a public CMS page. Use the ucsd-data-classification skill to assess, if installed.
• Never disable accessibility features (alt text, headings, tab order) to make a page look a certain way.
• Never bulk-delete assets without checking publishing relationships — deletes can cascade.
• Don't guess UI steps — when the user needs the exact click path, fetch the matching Blink page.

When to escalate

Route to the campus web team / your site's CMS administrator rather than guess when:

• The user needs a new template, module, or site (not authorable by editors).
• A vanity URL or new subdomain is needed (cross-team coordination).
• A page won't publish after troubleshooting, or publishing relationships are unclear.
• The user lacks the role required for an action.
• Content involves regulated data — assess with the ucsd-data-classification skill first, then escalate to the security office.

Sources & currency

Current as of 2026-06-26.

All content is mirrored from the UCSD Blink CMS training hub. Prefer fetching the linked Blink page over relying on this skill's summaries when UI specifics matter — Blink reflects the current Cascade version and campus policy.

• Training hub:
• Release notes / upgrade guide
• FAQ
• Platform: Hannon Hill Cascade CMS (per Basic Terminology).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: dbalders
• Source: dbalders/UCSD-Skills-Library
• License: MIT

Install and usage instructions live in the source repository linked above.