AFK implementation handoff#

Use this workflow when implementing a task from the SnagBadger foundation implementation backlog. Read foundation before changing module ownership, dependencies, loading behavior, or package structure. Read the selected issue for task-specific scope and acceptance criteria.

Read reliable agent development for current-context checks, browser verification for every change, acceptance evidence, outcome review and resumable checkpoints. Use the supported parallel worktree setup before starting servers or verification.

Select and claim#

1. Select an open, unassigned ready-for-agent implementation issue. Normally its native GitHub blockers must be closed. A wayfinder:* blocker always requires its recorded resolution; an implementation blocker can instead supply a verified branch handoff under the stacking rule below. The label alone never makes a blocked task safe to start.
2. Assign the issue to the driving developer, then run pnpm workflow:claim <issue> <thread-id> before editing; follow the thread ownership contract. Fetch the prerequisite implementations and verify their changes are present in the chosen base. If a dependency was closed without a usable implementation, record the mismatch and select independent work.
3. Work in an isolated branch/worktree. Preserve unrelated working-tree changes. Read applicable repository instructions before modifying files.

Implement#

• Satisfy the issue's observable acceptance criteria. Choose routine implementation details using the accepted foundation; do not settle unresolved product behavior by accident.
• Use deep modules, small supported interfaces, and private implementation folders. Preserve selective loading and functions-only consumption.
• Apply full production checks to all code, including prototypes. Fix failures rather than weakening checks or adding blanket suppressions.
• Select supported mutually compatible dependency versions from official documentation, pin the toolchain, and commit the lockfile. Respect the existing pins once the bootstrap task establishes them.
• Use deterministic fixtures and adapters for checks that otherwise require external credentials. Keep output, artifacts, secrets, and recordings out of source control unless explicitly intended fixtures.
• Add a regression check when correcting a meaningful defect in code or custom rules. Test lint rules with valid/invalid examples and their autofix behavior where applicable; test filesystem checks with real isolated fixture trees.
• When a missing decision changes product behavior, module responsibilities, or user authorization, record a precise question on the task and move to independent work. Do not mark unfinished work complete.

Stack implementation work while review is pending#

An open implementation blocker may be used as a base only when its author has posted a handoff containing a pushed branch/PR, exact commit, completion evidence for every acceptance criterion, and passing full verification. Check out that commit and reproduce relevant prerequisite checks before proceeding. Record the relationship and pin the prerequisite commit in the dependent task/PR. Inherit all required prerequisite changes; do not combine conflicting branches without resolving and verifying the combined base.

This allows a stack of reviewable implementations while the user is AFK. It does not resolve a product decision, accept a PR on the user's behalf, or authorize merging. If a prerequisite changes, rebase/reconcile and rerun affected checks. Issues may remain open pending review; keep their native dependency relationships intact.

Verify and hand off#

1. Run the relevant local checks while working and the repository's complete verification command before handoff. Completion requires a clean checkout to install reproducibly and pass the same checks, plus observed T3 browser evidence from the intended worktree. Validate the acceptance/evidence handoff using the reliability workflow. Report environmental blockers separately from code failures.
2. Review the diff for unintentional dependencies, artifacts, changed conventions, and unrelated edits. Include valid/invalid evidence for enforcement tasks rather than merely showing the happy path passes.
3. Produce a reviewable branch or draft PR containing the change, validation evidence, and issue links under roadmap maintenance and closure on merge. If the environment provides PR-thread linking, register the PR.
4. Leave merging, releases, and deployments to explicit authorization. For merges, require the current hosted quality gate under GitHub quality checks, including while plan restrictions prevent branch protection. Configure requested workflows without running a release or deployment. Keep implementation issues open while acceptance/merge is pending; a draft PR alone is insufficient for stacking without the verified handoff above. Reconcile affected maps at handoff and apply the linked merge-follow-up procedure when the PR merges.

Established constraints#

• One repository version; no independently versioned families.
• TypeScript, Node.js LTS, pnpm, Vite, React, Vitest, Playwright, shadcn/ui, Tailwind, and GitHub Actions/Pages are accepted directions.
• Directory/file paths in the architecture map are illustrative. An implementation can refine paths while preserving ownership; amend path-validation rules in the same change.
• Functions-only consumers load no React or CSS. Supplied components support restyling; the default skin is optional.
• Project/provider settings are shared by the in-app reporter and agent run reports; privileged credentials stay in their execution environment.
• Agent-testing code owns predictable catalog/run/artifact processing. Skills orchestrate that code rather than reimplementing it in prompts.
• The current handoff is foundation implementation. Final capture UX, report schemas, provider authentication, remote configuration semantics, browser support commitments, autonomous merge policy, and server storage remain separate decisions.