저장소 README를 불러오는 중…
수집된 skill 226개 중 40개를 표시합니다.
How QA checks a shipped release on the live product as the product's QA account: open it in the run's browser, look, act, screenshot what proves each acceptance line, record every line with record_live_check, then show each feature seen as a demo a product…
원문 언어: 영어
How a message or thread in the connected chat (Slack first; Teams and others later) becomes exactly one request record: who asked, where, their words kept verbatim, the thread's link kept as evidence, an acknowledged reaction left on the message, and a check…
원문 언어: 영어
What to do the moment a person asks for something new in conversation — a feature, a fix, a change, a rename. The answer is never a paragraph promising to file it and never a silent write: it is a card in the conversation the person can approve to start the…
원문 언어: 영어
Given an incident or a reported production error — a 500, a screenshot, a route, a time — read what Sentry recorded, map the stack to the repository, say what caused it from the evidence, and end with a move written on the incident — first saying whether it…
원문 언어: 영어
Once a request that changes what people see has shipped: the after-shot taken from the live product, attached to the request, attached to the issue the asker filed, and offered to the thread they asked in with the live URL and one line of what changed. Read…
원문 언어: 영어
What the designer reads before drawing a mockup for a request that came from chat or from the tracker: the asker's own screenshots and files, then the live screen, then the component's source on the code host. What is copied from each and what is ignored.…
원문 언어: 영어
The two lines the Release engineer writes on a pull request whose check is red: which of the four causes it is, quoting the log line that settles it, and the one move that answers it. Where the explanation goes (`repo.comment_pull`), what it is never allowed…
원문 언어: 영어
The status post for an environment that is down or a deploy that failed: what is down, since when, what the recovery has tried, the next move, and when the next update comes. Drafted by the Release engineer as a `chat.post_message` card to the bound channel,…
원문 언어: 영어
How an issue a client filed on the connected issue tracker (Jira first; Linear, Azure Boards and others later) becomes exactly one request, or is matched to the one that already covers it: the issue read live rather than from the index, its key kept on the…
원문 언어: 영어
How the reviewer reads a pull request's checks from the code host rather than from the engineer's report: the failing step and its log, which of the four causes it is (the change, a flaky test, a red default branch, the pipeline), and the rule that a…
원문 언어: 영어
Which state of a request maps to which status on the connected issue tracker, when the issue moves, what else is mirrored (the release as the issue's version, the factory pull request as a link) and what is never mirrored (the factory's own retries and…
원문 언어: 영어
What the engineer reads before changing a file: the contract first and in full, then the issue the client filed and its comments, then the thread the ask came from. What counts as a contract conflict, and that a conflict is an ask filed, never a guess made.…
원문 언어: 영어
The shape of the engineer's report, written on the pull request where the reviewer and the person who merges read it: the request and the issue key, each acceptance criterion with how the diff meets it, the checks that ran and their result, every assumption…
원문 언어: 영어
How QA's verdict reaches the pull request: `record_verdict` records it in Vocion and files its mirror as a review on the code host (`repo.submit_review`), so the engineer reads the findings where the diff is. What goes in the review body, how a finding…
원문 언어: 영어
One page: the question the Release engineer seat is judged by, what an answered pipeline failure is made of, and the ways the pipeline has stalled work. Read before diagnosing a red CI or a failed deploy.
원문 언어: 영어
Where a reply to the person who asked goes (the thread they asked in, the issue they filed, the mailbox or store it came from), the three kinds of message and what each must carry, the one piece of evidence every reply links, and why a person releases every…
원문 언어: 영어
How a request that changes what people see gets a visual a person decides against — the outcome drawn as the product's own UI (`draw_mockup`), or one flow diagram — and how the same request is closed with an after-shot from the running product. Covers when a…
원문 언어: 영어
How a release's notes and its announcement are written: from the tasks the release carried and the requests it closed — never from the diff — naming what a person can now do and which request asked for it, in the house voice, with no internal task ids or…
원문 언어: 영어
The reviewer's procedure for a finished engineering task: what is read and what is deliberately not, the order that makes the review cheap (paths, checks, criteria, then the request), how findings are keyed to the contract, the three verdicts and what each…
원문 언어: 영어
One page: the question the Eng seat is judged by, what a verifiable change carries, and the ways this seat has failed. Read at the start of every worker run and before completing it.
원문 언어: 영어
How to turn a brief or a named request into an engineering task contract a headless worker can execute in isolation and a machine can check when it is done: what one task is, what the objective, allowed paths, acceptance criteria and required checks have to…
원문 언어: 영어
How to decide whether a piece of work needs a plan before it is built, and how to write one a person will actually read: the gating rule and the five triggers that make a plan required, the ui and logic case where a plan is offered and may be declined with a…
원문 언어: 영어
How a request — a bug report, a store review, a support email, a chat message, an incident, a dogfood note — is read once and ends in exactly one of three places: an engineering task, an honest written answer, or a link to the open request it duplicates.…
원문 언어: 영어
One page: the question the Design seat is judged by, the states a design must cover before build starts, and the ways this seat has failed. Read before drawing, and before calling a design done.
원문 언어: 영어
One page, not a manifesto: the question the PM seat is judged by, the five things a decision-ready card must carry, and the ways this seat has actually failed. Read before filing any recommendation, and again when one is returned.
원문 언어: 영어
One page: the question the QA seat is judged by, what an independent verdict is made of, and the ways this seat has failed. Read before every review and before writing a verdict.
원문 언어: 영어
The standard every page in this product is held to. Index pages display decisions and meaning; detail pages display records and evidence. A missing optional capability makes the interface smaller, not fuller. And each of the four surfaces answers one question…
원문 언어: 영어
How a product's open requests are scored and ordered: against the product's written promises, the operating intent, how many real people asked, and evidence from an analytics source when one exists — with the score and its reasons written on the request…
원문 언어: 영어
The five names one piece of work carries and the different job each one does: the request title in the asker's words, the task title naming the change literally in the imperative, the commit subject in Conventional Commits form, the pull request title…
원문 언어: 영어
The standing rule that the number a piece is judged on, its baseline, its source and its attribution model are fixed before the work starts — and that "we cannot measure this" is a complete and acceptable answer, written down rather than worked around with a…
원문 언어: 영어
The standing rule for everything this team makes: one piece carries one claim to one audience, every part of it renders that claim, and a second claim is a second brief. Attached to briefing, production and the gate so the same rule is applied at all three…
원문 언어: 영어
What each class of claim needs behind it before it may go out, and who has to be involved: descriptive, instructional, comparative, performance and regulated, ordered by what a retraction costs. The plugin ships the shape and the classes; a workspace replaces…
원문 언어: 영어
The editor's procedure: what is read and what is deliberately not, the cheap order (do-not-claim, then acceptance, then every claim against the evidence, then the staleness pin), why one do-not-claim hit ends the read, the three verdicts and the three-fix…
원문 언어: 영어
How a team adds a teammate to itself: naming the gap before the role, why the evidence is briefs that waited rather than a feeling about capacity, choosing from the catalog rather than inventing a role, why the daily allowance is part of the hire and not a…
원문 언어: 영어
How to execute one growth brief into a deliverable: reading the brief as a contract rather than a suggestion, landing its single claim, citing only the evidence it carries, what to do when the brief does not say, why the assumptions list and the…
원문 언어: 영어
How the queue of briefs is ordered and bounded: the three inputs a rank is scored on and the ones it is not, why a closed brief's verdict outranks a fresh idea, the three limits that decide whether anything is promoted at all (decision minutes, spend, one big…
원문 언어: 영어
How a published brief is judged: when the reading is due and why the date is written in advance, taking it from the source and under the attribution model the brief named, establishing normal variation before calling anything a change, checking the boring…
원문 언어: 영어
How to turn evidence of demand into a growth brief a producer can execute without asking a question and an analyst can judge months later: what one brief is, why the objective is a number and not a deliverable, how the single claim and its evidence are…
원문 언어: 영어
How to research a question for the workspace and land the standing part in the wiki: read the wiki first, then the knowledge index, the data rooms and the web; answer with sources; offer a page whenever a conversation produces a standing fact or a plan; write…
원문 언어: 영어
Write, revise and verify a paginated, print-ready client document — a proposal, scope doc or partnership update — in the house sheet framework, grounded in the client's data room. Read before the first sheet, and again before changing one: it carries the…
원문 언어: 영어
이 프롬프트를 복사해 사용 중인 AI 어시스턴트에 입력하세요.
Follow https://skillsmp.com/skill-install/prompt.md to install Agent Skills from https://github.com/vocion/vocion-core.README를 불러오지 못했습니다. 아래의 저장소 Skill 목록은 계속 이용할 수 있습니다.