Integrations · Hub

The tools your team already uses.

The framework is the boundary object. The platform is the home. The integration is what stops the brief getting dropped.

A creative-direction brief that lives in a doc no one opens is decoration. The integration pages show how to put that brief inside the primitives the team is already opening every day: Epics, Projects, databases, libraries, repositories. Each page maps the brief to the platform's real shape, ships templates the reader can copy, and names the specific ways the integration goes wrong in real teams.

The shape

Framework, integration, workflow.

Six integrations

The platforms most teams open every week.

The six covered below are the ones that show up in real brand and product work. Each page is platform-specific: Jira reads bureaucratic, Linear reads modern-startup, Notion reads docs-first, Figma reads designer, GitHub reads engineering. The agile page is platform-agnostic and covers how the brief lives across the sprint cycle no matter which tracker the team uses.

What every integration page does

The brief is the boundary object.

A creative-direction brief is the artifact that has to survive the team's default toolchain. The risk in every integration is the same: the brief gets produced, lives somewhere unreadable to the rest of the work, and stops being consulted. Six weeks later, the team is shipping competent and incoherent output, and no one can point at where the drift started.

Every integration page solves the same shape of problem, with platform-specific mechanics. The brief becomes a primitive the platform indexes (Epic, Project, database row, library description, repository document). The four axes become structured properties on that primitive (custom fields, labels, Select properties, token name prefixes, story categories). Downstream artifacts get queryable backlinks to the brief. The team's existing review ceremonies (sprint review, cycle review, design review, code review) gain one new question: does this answer the brief?

The mapping is what makes the brief load-bearing instead of decorative. Pick the integration page closest to the team's primary platform and adapt the patterns. The concepts transfer; the syntax differs.

In progress

Coverage we are still working on.

Slack, ClickUp, Asana, and Confluence are scoped for follow-up. The patterns transfer cleanly because the framework is the boundary object, not the tooling, but the platform-specific shape (Slack canvas vs ClickUp custom fields vs Asana sections) deserves its own page. If a platform is missing here that the team relies on, the existing pages translate well enough to ship a first draft of the integration internally.

Per-skill platform pages (a separate page for the brand-voice skill in Jira, the brand-voice skill in Linear, the brand-voice skill in Notion, and so on) are deliberately out of scope for this surface. The matrix gets large fast, and most of the value lives at the framework-to-platform level documented here.

Continue reading.

Frequently asked questions.

What is an integration page in RampStack?
A pattern document that explains how RampStack skill output (a creative-direction brief, a brand-voice doc, a brand-identity system) lands inside the primitives a specific platform already exposes (Jira Epics, Linear Projects, Notion databases, Figma libraries, GitHub repos). The page maps RampStack output to platform primitives, ships templates the reader can copy, and names the failure modes that show up when teams try the integration without the patterns.
Which platforms have integration pages right now?
Six. Agile sprints (platform-agnostic), Jira, Linear, Notion, Figma, and GitHub. The choice covers the platforms most teams running brand and product work touch every week. Slack, ClickUp, Asana, and other platforms are scoped for follow-up work; the patterns from the existing six transfer cleanly because the framework is the boundary object, not the tooling.
Do I need RampStack to use these patterns?
No. The skills are open source under MIT and the patterns work whether the brief was generated by Claude using the creative-direction skill or written by a human using the same framework. The integration pages assume the brief exists; they do not assume how it got produced. Teams that already write briefs in some other format can translate to the four-axis format and gain queryable structure without changing tools.
How do these integration pages compose with the framework pages?
The framework pages explain the four axes and the brief format. The skill pages explain how to produce the brief and the downstream artifacts. The integration pages explain where those artifacts land inside the team's existing tools. Read framework first if the four-axis vocabulary is new. Read skills next if the question is what gets produced. Read integrations when the question is how to make the existing toolchain stop dropping the brief.