DEV Community: Wagglet

Give a producer a build runbook with a stop condition

Almast — Mon, 19 Oct 2026 10:15:49 +0000

AI and affiliation disclosure: This tutorial was prepared with AI for Wagglet-related marketing work. The tiny Node example is a synthetic build fixture, not a production incident.

A producer can supervise a bounded build repair when the task makes failure, scope, and acceptance visible. Asking them to keep prompting until a build turns green gives them no reliable way to distinguish a repaired import from a deleted check.

An AI game development workflow needs two descriptions of the same job. The engineer supplies the implementation context; the producer receives the short sequence they can run and the point at which they must stop.

Make the example reproducible

Create a directory containing these three files. The import intentionally uses the wrong filename.

package.json:

{"private":true,"type":"module","scripts":{"build":"node build.mjs"}}

reward-label.mjs:

export const label = 'Continue';

build.mjs:

import { label } from './reward-lable.mjs';
import assert from 'node:assert/strict';
assert.equal(label, 'Continue');
console.log('Reward label fixture passed');

Run npm run build. The initial failure should identify the missing reward-lable.mjs module. The permitted repair is to change that import to ./reward-label.mjs. Keep the assertion and both source files. Run the same command again and record its exit code. There are no package dependencies to install for this fixture.

The output checks the label through the repaired import. It does not compile a browser application or prove a game build is healthy. In an actual repository, an engineer must replace this small check with the project’s approved build and smoke commands.

Write the agent brief

Objective: repair the misspelled relative import in build.mjs.
Inputs: the three fixture files and the captured baseline failure.
Allowed edit: the import path in build.mjs.
Preserve: label value, assertion, build script and filenames.
Do not: install dependencies, disable checks, change toolchain,
        access production, or publish a build.
Delivery: diff, baseline output, final output, exit codes.
Stop if the observed failure is different from the stated one.

The engineer prepares this brief and verifies that the intended command is appropriate for the environment. The runner executes it through their own authorized tools. An agent may propose the one-line repair, but it cannot broaden the task just because another change would make the command succeed.

Give the producer the shorter runbook

Open the fixture directory and confirm the three filenames.
Run npm run build and save the failure text.
Check that the error names reward-lable.mjs.
Let the authorized runner apply the single import correction.
Run npm run build again. Save the output and exit code.
Send the diff and both command outputs to the engineer for review.

If the command is missing, a different file fails, authentication is requested, or the proposed diff removes the assertion, stop. The producer reports the discrepancy instead of choosing a new repair strategy.

Wagglet’s dual-prompt task design provides context for keeping the detailed technical brief separate from these human operating instructions.

Keep acceptance with the right reviewers

The producer confirms that the observed failure matches the task and that the requested evidence exists. The engineer checks that the path correction fixes that failure without weakening validation. The final record should say who reviewed the diff and whether they accepted it.

This arrangement does not turn the producer into a build engineer. It gives them a useful supervisory role with a concrete escalation rule. A production build may depend on signing, engine versions, native tools, or secrets; those requirements need qualified ownership before a producer can use a runbook safely.

Make an AI capacity pilot produce a reviewable receipt

Almast — Fri, 16 Oct 2026 23:34:09 +0000

Disclosure: AI drafted this tutorial for Wagglet's marketing work. All task names and monetary values below are synthetic examples, not measured savings.

A capacity pilot needs more than a list of merged patches. It needs a way to connect one bounded task, one acceptance decision, and two different measurements: human capacity recovered and actual spending avoided.

Here is a small implementation you can adapt. The example task updates a compatibility table from an existing test matrix. It deliberately excludes production deployment and dependency upgrades. To delegate AI task without sharing account credentials, pass the brief and authorized repository access; the runner uses their own provider identity and tools.

Write the task contract first

id: compatibility-table-01
requester: product-owner
runner: authorized-maintainer
reviewer: release-engineer
input: fixtures/runtime-matrix.json
output: docs/runtime-compatibility.md
scope:
  include: [document the supplied fixture, identify missing entries]
  exclude: [upgrade packages, change CI, deploy, modify credentials]
acceptance:
  - every fixture row is represented exactly once
  - unknown support is labelled unknown
  - reviewer reproduces the generator output
stop_if:
  - repository access is missing
  - fixture contradicts the requested claim
  - acceptance requires a production change

The requester prepares this contract. The maintainer executes it with their own authorized tools. The release engineer decides whether the submitted evidence satisfies acceptance. Assign these roles before running the model so that a generated summary cannot silently become its own approval.

Store the receipt as data

Save the next file as pilot.json. The baseline is a pre-task estimate for equivalent scope. The human-hours fields are disjoint attention categories, not elapsed model runtime.

[
  {
    "id": "compatibility-table-01",
    "accepted": true,
    "baselineHours": 3,
    "briefHours": 0.4,
    "executionHours": 1,
    "reviewHours": 0.5,
    "reworkHours": 0.2,
    "cancelledPurchase": 0,
    "incrementalTools": 0,
    "incrementalPaidLabor": 0
  }
]

Use accepted: false until the reviewer records a decision. If execution stops for missing access, retain the brief and coordination time. Deleting failed attempts makes the pilot appear cheaper than it was.

Compute independent totals

Save this as pilot.mjs and run node pilot.mjs pilot.json using Node.js. It rejects missing, negative, and nonnumeric cost inputs so an incomplete receipt does not quietly become zero.

import { readFile } from 'node:fs/promises';
const rows = JSON.parse(await readFile(process.argv[2], 'utf8'));
const fields = ['baselineHours', 'briefHours', 'executionHours',
  'reviewHours', 'reworkHours', 'cancelledPurchase',
  'incrementalTools', 'incrementalPaidLabor'];
let recoveredHours = 0, avoidedSpend = 0;
for (const row of rows) {
  if (typeof row.accepted !== 'boolean') throw Error('acceptance missing');
  for (const key of fields) {
    if (!Number.isFinite(row[key]) || row[key] < 0) {
      throw Error(`${row.id}: invalid ${key}`);
    }
  }
  const attention = row.briefHours + row.executionHours +
    row.reviewHours + row.reworkHours;
  recoveredHours += (row.accepted ? row.baselineHours : 0) - attention;
  avoidedSpend += (row.accepted ? row.cancelledPurchase : 0) -
    row.incrementalTools - row.incrementalPaidLabor;
}
console.log(JSON.stringify({
  accepted: rows.filter(r => r.accepted).length,
  recoveredHours: +recoveredHours.toFixed(3),
  avoidedSpend: +avoidedSpend.toFixed(2)
}, null, 2));

For the supplied illustration, the arithmetic gives one accepted task, 0.9 recovered hours, and zero avoided spend. That is an example calculation, not evidence that the workflow saved a company money. An existing salary or subscription does not disappear because a task completes faster.

Walk the handoff through its failure path

Suppose the runner notices that the fixture has no Safari result. They should submit an explicit unknown entry and the missing-input observation. They should not invent browser coverage or broaden the task to install a new test environment without authorization.

The reviewer checks the fixture-to-document mapping and records the missing coverage. If the acceptance requirement demanded actual Safari support, the task is not accepted yet. Its consumed attention still belongs in the ledger. If the requirement was faithful documentation of the supplied matrix, a clearly labelled unknown may satisfy the task.

That distinction is why the contract comes first. A tidy article generated from incomplete evidence can still be an incorrect deliverable.

End the two weeks with a decision

Group receipts by scope and rejection reason. Report accepted output, net recovered attention, net avoided spend, and work awaiting review separately. Avoid converting hours to cash unless a real spending decision changed and the budget owner can identify it.

The Wagglet capacity handoff article describes the broader coordination opportunity. The receipt above gives a developer a smaller unit to implement and inspect. Start with one task class, retain negative outcomes, and expand only when the review cost remains visible.

An asset-export ticket needs two acceptance receipts

Almast — Thu, 15 Oct 2026 08:45:53 +0000

AI disclosure: AI prepared this article and the disposable SVG fixture. The executed checks establish dimensions and file identity in the fixture. They do not establish a production exporter repair or completed human art review.

A technical export check and an artist's visual acceptance answer different questions. A file can satisfy a dimension constraint and still look wrong. It can also look plausible in a scaled preview while carrying dimensions that break its consumer. A useful bug handoff records both questions before the work starts.

Reproduce one constraint failure

The synthetic source is a 128 by 128 SVG badge with viewBox="0 0 128 128". The deliberately broken export declares a width and height of 64. Its paths and viewBox remain unchanged. A browser can still show a recognizable badge, so visual recognition alone does not detect the failed size contract.

The fixture's checker extracts the root dimensions, compares them with 128 by 128, and records a SHA-256 digest. It rejects broken-export.svg and accepts corrected-export.svg. The corrected file matches the source digest exactly. That is a measured result for generated example files; it is not evidence that a real design tool was fixed.

source.svg             128 × 128    PASS
broken-export.svg       64 × 64      FAIL
corrected-export.svg    128 × 128    PASS
source == corrected: SHA-256 match

The browser fixture renders both declared sizes without resizing the images to match one another. It labels the corrected version “visual acceptance pending.” That label matters: a dimension check should not impersonate the art owner's judgment.

A ticket template with enough context to run

Asset: synthetic badge; expected canvas 128 × 128.
Symptom: exported root dimensions are 64 × 64.
Reproduce: inspect root width/height and render at intrinsic size.
Allowed repair: correct the export configuration or serializer.
Preserve: paths, viewBox, colors and intended transparent margin.
Technical receipt: dimensions, output hash, exact command/version.
Visual receipt: before/after at intrinsic size in the target UI.
Stop: ask before changing the source artwork or intended canvas.
Acceptance: engineer checks file contract; artist checks appearance.

For a real ticket, attach the actual source and exporter version. Include the smallest input that still reproduces the fault and state which configuration produced it. The sample files here intentionally avoid confidential artwork and an unspecified production toolchain.

Separate preparation, execution and acceptance

The artist or QA reporter prepares the source, failed output and expected canvas contract. An authorized engineer or agent reproduces the issue with their own tools and makes the bounded repair. The engineer checks integration and file-format concerns; the artist judges whether the asset still has the right appearance and margins. A producer can coordinate these steps without becoming the person who approves every technical and visual claim.

An agent should return the commands it ran, the actual results and the changed output. If it cannot reproduce the production exporter, it should say that directly. Substituting a corrected example file is useful for explaining a contract, but cannot establish that the real failure is resolved.

Keep the evidence tied to the artifact

A screenshot can become stale when the asset changes. Put the output filename and digest beside the captured state. Record whether the preview is shown at intrinsic size, scaled for display or rendered inside the target control. A screenshot of a scaled browser image is not a reliable dimension measurement.

This is one practical boundary in a game studio AI workflow: preparation makes the task reproducible, execution produces evidence, and the named reviewers decide acceptance. Credentials remain with their authorized users and environments.

Limits before using this in a real pipeline

The example checks integer root dimensions in three known SVG files. It is not a general SVG parser, sanitizer or security validator. It does not inspect embedded scripts, external references, filters, color profiles, font substitution or raster compression. Production SVG handling should use the project's established parser and security controls.

To apply the lesson, agree on the actual export contract, reproduce the fault in the real pipeline, and collect both receipts. Keep the ticket open if the dimensions pass but the art owner has not reviewed the target UI.

Open the export fixture · Download the source and executed checks.

Two prompts for one coding-agent task: implementation and supervision

Almast — Thu, 08 Oct 2026 06:37:42 +0000

AI assistance disclosure: This article was prepared with AI assistance. The example is illustrative.

A coding task often has one long prompt that mixes implementation instructions with managerial decisions. That makes the handoff brittle. The implementer needs a precise scope and tests; the reviewer needs a short record of what changed, what evidence exists, and when to stop the run. These are different documents for different readers.

Here is a small example: a team wants a feature flag around a new checkout summary. The flag must default off. A coding agent can prepare the change, but the release owner must decide whether it goes live. This is an illustrative task template, not a report of a completed rollout.

Prompt A: the execution brief

Task: Put the new checkout summary behind `checkout_summary_v2`.
Scope: Change only the summary component, its flag lookup, and focused tests.
Starting point: Work from a clean branch. First locate the current summary
and the project's flag abstraction; report both paths before editing.
Behavior: With the flag off, keep the current summary. With it on, show the
new summary. Keep totals, tax, and accessibility labels unchanged.
Verification: Run the focused component tests and the relevant type check.
Record exact commands, exit codes, and any test failures. If you cannot run
them, say why; do not infer success from code inspection.
Pause when: the existing flag abstraction is absent; totals calculation
would change; tests require unavailable credentials; or a dependency needs
an upgrade outside scope. Ask the task owner for a decision.
Deliver: diff, test evidence, remaining risks, and a rollback note.
Do not merge, enable the flag, or deploy.

The brief supplies the agent with observable boundaries. A pause point is an instruction to stop and ask, not an invitation to choose a convenient workaround. The runner uses its own authorized repository and tool access. The person preparing this brief does not provide their login or tokens to the runner.

Prompt B: the human supervision note

Owner: product engineer who prepared the task.
Review gate 1 — scope: Does the diff touch only the approved files? If not,
request a narrower patch or an explicit scope decision.
Review gate 2 — evidence: Are the test commands and outputs attached? Re-run
the critical checkout path in the review environment.
Review gate 3 — expertise: Have a payments-qualified reviewer examine any
change to price, tax, or transaction semantics. The task owner alone should
not approve those changes.
Acceptance: Reviewer records pass/fail against the flag-off baseline and
flag-on behavior. A delivered patch is not an accepted release.
Release: Only the release owner merges, schedules enablement, observes
metrics, and decides whether to roll back.

This note is intentionally shorter. It says who judges acceptance and names decisions that an agent's test output cannot settle. A product or engineering lead prepares the handoff; the agent or teammate executes with their own permissions; a qualified human reviews the evidence and signs off. The separation is the core of human supervised AI execution.

Worked handoff

Suppose the runner finds that checkout_summary_v2 already exists. It changes the component and adds two tests: flag off retains the old layout; flag on renders the new layout. It then discovers a screenshot baseline differs because a test fixture has an obsolete tax label. The correct next action is a pause with the failed command and diff attached. Updating tax labels quietly would cross the brief's boundary.

The reviewer can now distinguish three outcomes: implementation is ready for review, evidence is incomplete, or the task needs a new decision. None is the same as deployment. That is why this dual-prompt design for human and agent tasks is useful context for teams building a handoff process.

The example does not prove that two prompts prevent every mistake. It does make the stop condition visible before the work begins. For a small change, the two notes may fit in one task. For a risky change, add a named reviewer, a test environment, and a rollback owner before anyone claims it.

A claim state that stops two AI agents from doing the same backlog task

Almast — Wed, 07 Oct 2026 07:30:58 +0000

Two agents can both be “available” and still be a bad match for the same task. If each reads a backlog row and starts work without an atomic claim, they may both edit the same files, both spend model time, and produce two deliveries that a reviewer must reconcile. The fix is a state transition, not a longer prompt.

The minimal state diagram

OPEN --claim(runner, revision)--> CLAIMED
CLAIMED --release(runner)-------> OPEN
CLAIMED --deliver(evidence)-----> DELIVERED
DELIVERED --request changes-----> CLAIMED
DELIVERED --accept(reviewer)---> DONE

Only one runner owns CLAIMED at a time. DELIVERED means evidence is ready for review; it does not mean the change has merged or deployed. A second agent reading an old OPEN snapshot must lose its claim attempt when the record's revision has changed.

Here is an original task template for a small engineering team:

task: "Add an empty state to the billing history view"
scope:
  files: ["src/BillingHistory.tsx", "src/BillingHistory.test.tsx"]
  excluded: ["billing API", "payment settings"]
access: "runner has repository access through their own account"
acceptance:
  - "No invoices: show the approved empty-state copy"
  - "Invoices present: preserve current list and pagination"
  - "Keyboard focus remains in a sensible order"
evidence:
  - "diff or branch"
  - "commands and actual test output"
  - "real screenshots at 390px and 1280px"
reviewer: "named frontend maintainer"

The preparer supplies the scope, approved copy, and reviewer. The runner can execute only with their own authorized tools. The reviewer judges whether the delivered evidence meets the acceptance criteria. If the runner cannot access the repo, the task stays unclaimed; sharing another person's token is not a workaround.

The handoff in practice

Imagine agents A and B both poll at 09:00. Each sees revision 18. A submits claim(task, A, expectedRevision=18) and the server records revision 19. B submits the same transition with revision 18 and receives a stale-revision response. B rereads the task, sees A as the runner, and selects another item. This is a compare-and-swap pattern; it requires the task store to enforce the transition atomically. A spreadsheet status cell edited by hand does not provide the same guarantee.

A then changes the empty state and attaches a branch, a real test log, and screenshots. The task moves to DELIVERED. The reviewer notices that the empty state disappears when the network request fails, which was outside the original happy-path proof but within the UI's expected behavior. They request a fix. A revises the change and resubmits. Only the reviewer moves the task to DONE after checking it. That review may still be separate from merge and release.

This kind of shared AI execution capacity is useful only when the ownership boundary is explicit. The Wagglet workflow guide gives context for separating a request, a prepared task, delivery, and acceptance. The state diagram above is a portable design example; it is not a claim that every backlog tool implements exactly these transitions.

Failure cases to keep visible

Claim timeouts need a deliberate policy. Do not silently reclaim a task just because a runner was quiet for ten minutes; the runner may have work in progress. A human can inspect the attempt and release or reassign it. Retries need idempotency so a network timeout cannot create duplicate deliveries. A reviewer also needs authority to reject thin evidence instead of accepting a polished summary.

If you keep those rules in the task system, two agents can look at the same queue safely. They will still make mistakes in the work itself. The claim transition only removes one avoidable class of waste.

AI disclosure: This article was prepared with AI assistance. The example state machine is an illustrative design, not a report of a shipped implementation.

Move a Claude Code task to a teammate without sharing a login

Almast — Mon, 05 Oct 2026 10:47:20 +0000

A coding task often stalls because the person who wrote the brief cannot run it right now. Passing a provider login to someone else blurs who executed the work and what access they had. A better handoff transfers the task specification, then lets the next person work with their own authorized tools.

Here is a small template for doing that. It works as a Markdown issue even if your team never adopts a task platform.

The handoff file

# Task: Add an empty-state message to the projects list

## Outcome
When the API returns zero projects, show:
“No projects yet. Create one to get started.”

## Scope
- Change the projects-list component and its focused tests.
- Keep loading and API-error states distinct from the empty state.
- Do not change the API or create a project automatically.

## Starting point
- Repository: <repo URL>
- Base branch or commit: <exact ref>
- Relevant paths: <component>, <tests>
- Command to run: <project's documented test command>

## Access
- Author may write the brief and review the result.
- Executor uses their own repository and Claude Code access.
- Executor stops if either permission is missing.
- No provider credentials, session cookies, or personal tokens are included.

## Evidence to return
- Commit or pull-request URL
- Files changed
- Test command and actual output
- Screenshot only if captured from the running app
- Any untested behavior or remaining risk

## Acceptance
A reviewer checks the empty, loading, and error states,
then accepts or returns the task with specific changes.

The exact repository paths and command belong in the real task. Leaving them vague forces the executor to rediscover scope and makes review harder.

A worked handoff

Suppose Maya prepares this brief but has no time to implement it. Arun has authorized access to the repository and uses his own Claude Code account. Maya gives Arun the task, not her login. Arun checks out the stated base ref, inspects the three UI states, edits the component, and runs the repository's documented tests.

His delivery should identify the changed files and real commit, name the exact test command and result, and say whether he performed a visual check. Those details must come from the actual run. “Tests passed” is not acceptable unless the executor ran them and can identify the command that produced the result.

Maya then reviews the diff and evidence. If the empty message appears while the API is still loading, she returns the task with that finding. If it meets the acceptance criteria, she accepts it. Delivery and acceptance are different events.

What the separation buys you

This pattern gives a team shared AI execution capacity through transferable work while keeping each person's account and permissions separate. The author owns scope and acceptance criteria. The executor owns the work performed with their own authorized environment. The reviewer owns the verdict.

A task system can preserve those boundaries and make the handoff easier to inspect; Wagglet's discussion of AI task handoffs is one example. The same discipline still matters in a plain issue tracker.

It does not solve missing access, unclear requirements, or unreliable tests. When those are absent, improve the brief or stop the run. Borrowing another person's credentials is not a fix.

This article was drafted with AI assistance.

A reviewable task bounty for a game team's non-engineering work

Almast — Fri, 02 Oct 2026 12:32:38 +0000

Imagine a five-person game team preparing a playtest. A producer needs 30 issue reports sorted into reproducible bugs, design feedback, and duplicates. A developer can write a classifier, but the judgment about whether each report is useful belongs to the producer. This is bounded technical work for non engineers: the task touches a technical workflow, yet the acceptance test has to make sense to the person who owns the outcome.

A bounty can help if it pays for an accepted result. It becomes noisy if it pays for claims, submissions, or a score that only approximates usefulness. The design problem is an acceptance contract, not a leaderboard.

Write the contract before opening the task

Here is a compact format I would use for this hypothetical playtest job:

task: Triage 30 playtest reports
owner: playtest producer
worker: one assigned contributor using their own authorized tools
input: reports exported by the producer, with personal data removed
scope:
  include: reproducible bugs, design feedback, duplicates
  exclude: player identity research, account access, production changes
deliverables:
  - triage.csv with report_id, category, duplicate_of, rationale
  - review.md listing uncertain cases and decisions needed
acceptance:
  mechanical:
    - 30 input ids appear exactly once
    - category is one of bug, feedback, duplicate
    - duplicate_of points to an input id or is empty
  human:
    - producer samples 5 records and reviews every uncertain case
    - producer accepts or returns the work with specific corrections
reward_rule: release only after acceptance, never on submission count
review_budget_minutes: 20

The mechanical checks catch missing rows and broken references. They do not decide whether the triage is good. The producer still reads uncertain cases and a sample. For a safety-sensitive task, a five-record sample would be far too weak; the reviewer would need a different process or should decline the bounty entirely.

Make evidence cheap to inspect

The submission should point the reviewer to the work, rather than asking them to trust a summary. A small script can check shape before a person spends review time:

function checkTriage(inputIds, rows) {
  const ids = new Set(inputIds);
  const seen = new Set();
  const allowed = new Set(['bug', 'feedback', 'duplicate']);
  const errors = [];

  for (const row of rows) {
    if (!ids.has(row.report_id)) errors.push(`unknown id: ${row.report_id}`);
    if (seen.has(row.report_id)) errors.push(`duplicate row: ${row.report_id}`);
    seen.add(row.report_id);
    if (!allowed.has(row.category)) errors.push(`bad category: ${row.report_id}`);
    if (row.duplicate_of && !ids.has(row.duplicate_of)) {
      errors.push(`bad duplicate target: ${row.report_id}`);
    }
  }
  for (const id of ids) if (!seen.has(id)) errors.push(`missing id: ${id}`);
  return errors;
}

This is a shape check, not a quality score. A clean result means the producer can begin review; it does not mean the bounty is complete. In a real implementation, also reject a report that marks itself as its own duplicate and validate the CSV parser's handling of quoted fields.

Keep the reward behind review

A practical state sequence is open → claimed → submitted → reviewed → accepted or returned. Record who changed the state and link the evidence used at each step. A submission is a request for review, not an automatic pass. If a worker corrects returned work, keep both revisions visible so the reviewer can see what changed.

I would track three separate numbers for a pilot: accepted tasks, reviewer minutes, and corrections requested. Do not collapse them into one score. A high submission count paired with a growing review queue is a warning, even if every participant appears busy. Review time is part of the bounty's cost, and the producer needs room to stop a task whose acceptance criteria proved too vague.

The same pattern applies to a release-note draft, asset naming audit, or support FAQ cleanup. It is a poor fit for security decisions, player safety reports, or anything requiring private account access. In those cases, a named owner and a more controlled review path matter more than a bounty mechanic.

For a broader discussion of gamification, AI work bounties, and evidence-based rewards, see Wagglet's workflow article. I work with the Wagglet team. This guide is an illustrative implementation sketch; it does not report results from a live bounty program. AI generated the initial draft.