一键在 Manus 中运行任何 Skill

align-user-journey

星标16

分支1

更新时间2026年6月19日 01:34

Before building a feature, state the user-experience it produces (what the person sees, does, and gets, step by step) and get the user to confirm that experience is right before writing code. Use this whenever the user asks to build a feature, flow, or product surface ("build the signup", "add a connect-your-account flow", "make the onboarding") without having specified what the end user should experience. Use it even when the implementation seems obvious, because the obvious implementation often encodes a user-experience the user never actually signed off on. This skill aligns on what the *end user* of the feature will see and do — for teaching the *developer* an unfamiliar standard or protocol before they build on it, use [[teach-the-mechanism]] instead.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

Alexanderdunlop

Alexanderdunlop/skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Align User Journey

Claude builds the wrong thing correctly. The user asks for "a connect-your-account flow", Claude builds a clean OAuth integration, and only when the user tries it do they realise they wanted a magic-link step first, or no consent screen, or the tokens stored differently. The code works. The experience is wrong. By then it's built, and unwinding a working implementation costs more than the two minutes of agreeing the journey up front would have.

When to run this

The user asks to build a feature or flow that a person will move through: signup, onboarding, a connect-an-integration flow, a checkout, a settings surface.
The request names the feature but not the experience: "build the login", "add Google Analytics connection", "make the upload work" — the what, not the what-the-user-sees.
There's more than one reasonable user-experience and the user hasn't said which. A connect flow can ask for consent or not, log the user in first or not, redirect or stay in-page.
Do NOT run this for a pure mechanism with no human in the loop (a cron job, a data transform, an internal API endpoint nothing renders), or when the user has already spelled out the experience they want.

The process

State the journey as numbered steps from the user's seat. "1. User clicks Connect Google Analytics. 2. Redirected to Google's consent screen. 3. Approves. 4. Lands back on your settings page, account now shows Connected." Concrete, real screen names, real buttons. Not the architecture, the experience.
Surface the forks where the experience could go either way. Name the decisions that change what the user feels, not the ones that only change the code: "Do they consent every time or just the first connect? Do they stay on your page or see Google's? Does a failed connect drop them back to settings or to an error page?" These are the choices that are expensive to reverse once built.
State the one-line scope boundary. What experience this does NOT cover, so the user can catch a missing surface now: "This covers connecting an account. It does not cover disconnecting or re-authing an expired one."
Stop and wait for confirmation on the journey, then build autonomously. Once the user signs off on the experience, implement the whole thing. Do not re-check at every step.

The trap to avoid

This is not align-first and it is not a permission-loop. It aligns on one thing only: the user-visible experience. It is not a re-litigation of the technical plan, the file structure, or the library choice. State the journey, get a yes, then make every implementation decision yourself without checking back. If you find yourself asking the user to approve the database schema or the function names, you've slipped out of this skill and into nagging.

Second trap: don't describe the journey in architecture terms. "The client hits the well-known endpoint, exchanges the code" is the mechanism, not the experience. The user in this skill is signing off on what their user sees, so the steps must be in user-visible language. The mechanism is yours to decide once the experience is agreed.

What good looks like

The user says "add a flow to connect GA4 and Search Console." Instead of building the OAuth integration straight away, Claude lays out the journey: user opens settings, clicks Connect Google Analytics, hits Google's consent screen, approves, returns to settings showing Connected, repeats for Search Console. It flags the forks (consent once or every time, in-page or redirect, where a failure lands them) and the boundary (covers connecting, not disconnecting). The user catches that they wanted both connected in one consent pass, says so, and Claude builds it right the first time instead of shipping two separate flows that have to be torn apart.

同仓库更多 Skills

同仓库

teach-the-mechanism

Alexanderdunlop/skills

When the user is about to build something on an unfamiliar standard, protocol, or architecture, explain the user-visible flow first and map each step to the mechanism underneath before writing any code. Use this whenever the user asks how to implement something they say is new to them ("new standard", "still learning", "I don't fully get it"), asks "can you explain X instead of building it", or asks for the user process / user journey of a system. Use it even when the user originally asked for an implementation and working code would technically answer them, if there's any signal they don't yet hold the mental model. This skill teaches the *developer* an unfamiliar protocol so they can debug what gets built — for aligning on what the *end user* will experience in a feature, use [[align-user-journey]] instead.

2026-06-1916

audit-skill

Alexanderdunlop/skills

Score an existing SKILL.md line-by-line and flag the dead weight using the would-have-anyway and trigger tests. Use this whenever the user wants to audit, review, score, or sanity-check a skill, says "is this skill any good" or "why isn't this triggering", or hands you a skill file expecting a verdict. Use it even when they don't say "audit" — if they're staring at a skill file asking what's wrong with it, this is the job.

2026-06-1016

explore-options

Alexanderdunlop/skills

Before implementing anything with a design choice in it, lay out 2-3 real approaches with tradeoffs and a recommendation, then wait for the user to pick. Use this whenever the task introduces or reshapes a pattern, references a feature the codebase already has, or asks "how should I build X" — even if the user didn't phrase it as a design question. Use it even when the answer seems obvious; the obvious approach is usually the over-engineered one, and the most expensive mistakes look confident.

2026-06-1016

create-skill

Alexanderdunlop/skills

Create a new agent skill that actually triggers and actually changes behaviour. Use this whenever the user wants to create, write, build, or rewrite a skill, says "turn this into a skill" or "make this a skill", or describes a repetitive workflow they keep re-explaining to Claude. Use it even when they don't say the word "skill" but are clearly describing a reusable process they want followed consistently.

2026-06-1016

claude-md

Alexanderdunlop/skills

Generate or update a project's CLAUDE.md file using structured interrogation of the codebase and user. Follows Apple's leaked CLAUDE.md patterns and Anthropic's best practices. Use when user wants to create, update, improve, audit, or rewrite their CLAUDE.md file, or when starting a new project that needs AI context.

2026-05-0216

test-interrogate

Alexanderdunlop/skills

Interrogate the user on what unit tests to write for their recent changes. Walks through the diff branch-by-branch, surfacing assumptions, edge cases, and business logic that need test coverage. Use when user says "test interrogate", "interrogate me on tests", or wants to stress-test their testing plan after a PR.

2026-04-2916

name

align-user-journey

description

Align User Journey

When to run this

The user asks to build a feature or flow that a person will move through: signup, onboarding, a connect-an-integration flow, a checkout, a settings surface.
The request names the feature but not the experience: "build the login", "add Google Analytics connection", "make the upload work" — the what, not the what-the-user-sees.
There's more than one reasonable user-experience and the user hasn't said which. A connect flow can ask for consent or not, log the user in first or not, redirect or stay in-page.
Do NOT run this for a pure mechanism with no human in the loop (a cron job, a data transform, an internal API endpoint nothing renders), or when the user has already spelled out the experience they want.

The process

State the journey as numbered steps from the user's seat. "1. User clicks Connect Google Analytics. 2. Redirected to Google's consent screen. 3. Approves. 4. Lands back on your settings page, account now shows Connected." Concrete, real screen names, real buttons. Not the architecture, the experience.
Surface the forks where the experience could go either way. Name the decisions that change what the user feels, not the ones that only change the code: "Do they consent every time or just the first connect? Do they stay on your page or see Google's? Does a failed connect drop them back to settings or to an error page?" These are the choices that are expensive to reverse once built.
State the one-line scope boundary. What experience this does NOT cover, so the user can catch a missing surface now: "This covers connecting an account. It does not cover disconnecting or re-authing an expired one."
Stop and wait for confirmation on the journey, then build autonomously. Once the user signs off on the experience, implement the whole thing. Do not re-check at every step.