Custom WorkBuddy Skill Work: The Test Before the Brief

A custom WorkBuddy Skill is worth building when a workflow has a stable input, a stable output, and steps between them that do not require judgement. Everything outside that shape is better left manual, or fixed before anyone writes code.

01 /Does your workflow actually qualify?

Three questions decide it, and they take about four minutes to answer honestly. Answer them before you write an email, because the answers change what the email should ask for. If the word Skill itself is still vague, what a Skill is covers the definition and the permissions a package can request.

Three yes answers means you have a real candidate. Two yes answers, with the third being the failure visibility question, means you have a workflow that will produce wrong files without complaining, which is worse than doing the task by hand. The ordering matters: input and output consistency are about effort, while failure visibility is about consequences.

There is a fourth question worth asking quietly, even though it does not fit in a table. How often does this workflow run? A task that happens twice a year costs more to specify than to perform, and no amount of automation changes that arithmetic.

02 /What does a minimum custom WorkBuddy Skill project look like?

Size is easier to judge from a shape than from a description, so here is the shape that counts as one project rather than three.

Input:     one folder, one file format, one field layout
Steps:     4-8 deterministic actions, each with a clear pass or fail
Output:    one file, one format, a predictable name
Failure:   stops and reports, rather than continuing on bad data
Runs on:   one machine, one OS, one WorkBuddy version

If your workflow fits that shape, it is a single piece of work. If it needs five input formats, three approval branches and a dashboard, it is not one project, and saying so early is cheaper than discovering it halfway through. Scope in stages beats a quote nobody can deliver against, and the staging conversation is usually where the real requirement surfaces.

Note the third line of the block. A predictable output name sounds trivial and is not, because it is what makes the result checkable by a script rather than by a person opening files. The fifth line is the one people argue with: Skills depend on the environment, and a package written against one client version on one operating system is not automatically portable to a second machine.

03 /What can a custom Skill not fix?

This is where most of this kind of work goes wrong, and none of it is a coding problem.

1. Inconsistent input. Half scanned PDFs and half spreadsheets will produce something that works on whichever case was tested and fails on the other. Normalising the input is real work, and it is usually the bulk of the project rather than a preliminary step.
2. Judgement at every step. If a person has to look at each item and decide, you are not automating a process, you are trying to automate a person. The hard part is the decision, not the script.
3. No acceptance criteria. If nobody can state what a correct output looks like, nobody can verify that the result is correct, so you will receive files that look plausible and cannot be trusted.
4. Credential sprawl. Any Skill touching a third-party service needs credentials, which is a security surface rather than a feature, and it grows every time another service is added.

Two of those four are usually hidden when the request arrives. The first is normally described as "it's the same format, just different suppliers", and the third is normally absent because the requester has never had to write it down. Finding both early is the difference between a two-week job and an abandoned one, and it is also why a custom WorkBuddy Skill conversation starts with samples rather than with features. The install paths page covers the other half of the problem: what happens to a package once it exists on a machine.

04 /What should you send before asking?

Four things. Without them nobody can answer specifically, and an email thread that starts with "so what do you actually need" costs a week before work begins.

1. A sample input, real data with the sensitive parts removed. Not a description of the data, the file itself.
2. A sample of the correct output, produced by hand. This is the acceptance test, and it is the single most useful attachment in the thread.
3. The edge cases you already know about. The file that is always formatted differently, the month the schema changed, the supplier who sends a scanned page.
4. Where it will run: machine, operating system and client version. Skills depend on the environment, as the shape block above says.

If all four exist, the reply can be specific about scope and about whether the workflow qualifies at all. If they do not exist yet, that is itself the finding. A workflow nobody can describe with a sample usually is not defined well enough to automate, and the useful next step is defining it, not commissioning a custom WorkBuddy Skill against a guess.

05 /How does pricing work for a custom WorkBuddy Skill?

Bring your own budget range and requirements, and the answer will say whether the two are compatible. There is no price list on this page, and deliberately no figure, because the honest reason is that a package built for one folder of consistent CSV files and a package built for eleven suppliers' PDF invoices are not the same job. A published number would overcharge the first and lose money on the second, and both outcomes are worse than asking.

So the first email should carry three things: what the workflow does by hand now, the budget range you are working within, and the four attachments above. In return you get an assessment, not a sales document.

What the exchange covers, in order.

1. Whether the workflow qualifies at all, using the three-question test above. Some requests stop here, and that is a useful outcome rather than a rejection.
2. Scope: what is in a first version, and explicitly what is not.
3. Whether the stated budget range and the required scope can meet. If they cannot, saying so early is cheaper for both sides.
4. What happens if the samples turn out to differ from the description, which is common and should be priced as a possibility rather than discovered as a surprise.

Two things are not offered at this stage: a quote before a sample has been seen, and a delivery date before scope is fixed. Both would be guesses presented as commitments, and a missed date is worse than a date that was never promised.

The boundary of what is claimed here, checked on 2026-11-10: the three-question test, the four refusals and the shape of a minimum project are the whole of the offer. There is no claim about a delivered result on this page, no list of past projects, and no estimate of how long anything takes before the input exists. If a future version of this page says more, it will be because something was finished and could be described.

06 /Email template

Copy this, fill the brackets, and it is a usable first message. Sending it in this shape is the fastest way to get a specific reply rather than a request for clarification.

Subject: Custom WorkBuddy Skill - [one-line workflow description]

What the workflow does now, by hand:
  [2-3 sentences]

Input:   [format, rough size, how often it arrives]
Output:  [format, who uses it, what makes a result correct]
Volume:  [how many files or rows per run]
Runs on: [OS, client version if known]
Budget:  [your range, and whether it is fixed or a preference]
Edge cases I already know about:
  [the ones that always break]
Attached: [sample input] [sample expected output]

Send it to [email protected]. Plain text is fine, and attachments are better than links if the data is sensitive and you would rather not host it.

07 /Open source versus custom

The question that always arrives: if some Skills are published openly, why would anyone commission one.

Because the published ones are built for a generic version of a problem. Yours is the specific one: your column names, your approval rules, your edge cases, the one supplier who formats things differently. That version takes time with your actual data, and it is the only version that runs on a Monday morning without a human standing next to it.

Open source does not reduce the value of commissioned work; it demonstrates the capability. The public package is the evidence that the approach works. The commissioned build is the part that fits one particular workflow, and it is also the part that can be checked against your sample.

08 /What will not get built

Three refusals, stated in advance so nobody spends a week on a brief that ends badly.

• Anything touching financial operations without a small-scale test first. Tencent's own guidance says the same about bulk writes and financial actions, and it is correct.
• A Skill that continues on bad data because stopping looked like failure. A package that halts with a clear error is more useful than one that produces forty plausible files and one wrong one.
• A claim that it works on your workflow before it has run on your samples. That claim is only available after the test, and any supplier who offers it earlier is describing an intention rather than a result.

Who writes these pages, and what stays unverified on them, is set out on the about page. The short version is that a bounded claim with a date beats a confident one without.

09 /Frequently asked questions

How long does a custom WorkBuddy Skill take?

Scope comes before any date, so a number given before scope is agreed would be invented. What can be said is the shape: work that fits the minimum project block above is a single engagement, while work that needs several input formats and approval branches is staged, and each stage is only estimated once its input exists. If a date matters more than the scope, the scope is what will move.

Do I need to know how to code to commission one?

No, and the four items on the list before the brief are deliberately not technical. A sample input, a hand-made correct output, the known edge cases and the target environment are things the person doing the task by hand already knows. What is required is that the workflow exists in reality rather than as an intention.

Can a custom Skill call our internal systems?

It can, in the same way any script on your machine can, which means the credential and permission questions come back immediately. A custom WorkBuddy Skill that reaches an internal service inherits the same authorisation the client already has, and the package will contain whatever credential handling the design requires. That is a security decision for your side, not a detail to settle at the end.

What if my workflow does not qualify?

Then the useful answer is the reason, and it is usually one of the four items above: inconsistent input, judgement at every step, no acceptance criteria, or credentials spreading across services. Each of those is fixable before automation, and fixing it makes the manual version cheaper in the meantime, which is a reasonable outcome even if nothing gets built.

10 /Where should you go next?

• What a Skill is, and the permissions it can request: WorkBuddy Skills
• The three install paths, and what each one trusts: Skill install
• Who writes these pages, and what stays unverified: About WorkBuddy Central
• If the client is not installed yet: WorkBuddy download