Takes something built and gets it into the market — tiering the launch to match what it actually warrants, sequencing internal readiness before external announcement, preparing sales and support to answer the questions it creates, choosing the date for a reason, and measuring adoption rather than announcement reach. Use this to plan a launch, right-size one that is consuming more than it deserves, work out why a released feature nobody uses was launched loudly, or run the weeks after launch day.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
A launch is not an announcement. The announcement is the cheapest part and the part most likely to be mistaken for the whole thing, which is how features get press coverage and no adoption.
Not everything deserves the same treatment, and treating everything as major is how a team burns its own attention and its audience's.
Agree the tier before work starts, and expect the pull toward tier one from whoever built it. Effort spent above the tier is taken from somewhere else, usually from the next launch.
The order matters and gets reversed constantly. Support and sales find out from the announcement, then spend launch week answering questions they were never briefed on, badly.
Before anything external: documentation exists, support can answer the top questions, sales knows who it is for and who it is not for, pricing and packaging are decided and configured, and the thing works for the accounts that will try it first.
Have someone outside the team use it from scratch. The team cannot see the first-run experience any more, and the first-run experience is what everyone else gets.
A launch aimed at everyone lands on no one. Name the segment, the problem it solves, and what changes for them — and say explicitly who should not use it yet. Sales will otherwise sell it to whoever asks, and the earliest customers will be the worst-fit ones.
Launch dates get set by an event, a quarter, or a promise. Whatever fixes it, write down the criteria that must hold to launch on it — quality bar, documentation, support readiness — and treat those as the real gate.
Launching before support readiness is the most expensive way to save a week. The cost lands as a bad first impression on exactly the customers most interested in the thing.
Most launch plans end on launch day, which is where the work starts. Schedule the follow-through: a second wave for people who missed the first, in-product prompts for users who have not tried it, outreach to accounts that fit, and a check on the questions arriving in support.
Watch the first support tickets closely. They are the fastest signal about what the launch got wrong, and they arrive before any dashboard moves.
Reach, impressions and press mentions measure the announcement. What matters is whether the intended people are using the thing and whether it did what the roadmap claimed.
Decide the number before launch — how many of which accounts, doing what, by when. A launch evaluated on engagement metrics chosen afterward is always a success and teaches you nothing.
references/sources.md in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Designs and audits who can reach what — authentication, authorization models, privileged access, service credentials, and joiner-mover-leaver process. Use this to design a permissions model, run an access review, reduce standing privilege, handle offboarding, set up SSO or MFA, manage service and machine credentials, or diagnose why permissions have sprawled.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Concentrates marketing and sales effort on a named set of accounts rather than on volume — qualifying whether the model fits your economics at all, building the account list and the buying group inside each, tiering effort against account value, coordinating so the account experiences one campaign rather than several, and measuring account progression instead of leads. Use this to decide whether to run an account-based program, build one, or work out why an existing one produces activity and no pipeline.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Gets new users from signup to first real value — signup flow, onboarding, time-to-value, and the early experience that determines whether someone becomes a user or a lapsed account. Use this to design or fix signup and onboarding, diagnose why signups do not convert to active use, reduce time-to-value, or decide what a new user must accomplish first.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Designs orchestrator-and-subagent hierarchies for a repository — splitting agents by exclusive write surface, pairing every producer with an independent auditor, and enforcing the split with a script that runs in CI. Use this whenever the user wants to set up, expand, audit, or fix a multi-agent or subagent structure for a codebase; asks how to divide work between agents; wants agent charters, roles, or a surface map written; or is hitting agents that collide on the same files, review their own work, or drift from their remit. Also use when sizing a roster or deciding whether a new agent is justified.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Governs models and AI systems in production — intended use, evaluation, monitoring, human oversight, documentation, and the decision to deploy or retire. Use this before deploying a model or AI feature, when defining evaluation criteria, when a model's behavior has drifted, when assessing AI risk or regulatory exposure, or when deciding whether an AI system is fit for a consequential decision.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Produces executive-level research — market sizing, competitor mapping, trend analysis, and strategic intelligence — grounded in cited sources with the confidence in each claim made explicit. Use this to analyze a market or industry, map competitors, evaluate a market-entry or build-versus-buy decision, produce a research brief, or assemble evidence for a decision. Also use when comparing options that need a structured, evidence-based verdict rather than an opinion.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.