Coding

Slurpyb's session baseline for working on software. Use it to orient the task and choose guidance; a question, investigation, plan, or review can be the complete deliverable. Reuse context already established instead of restarting this workflow on every turn.

The user's request and applicable project instructions govern the work. Keep the working project distinct from this guidance collection: inspect and run project commands in the intended checkout; resolve reference links relative to the document containing them.

Workflow

1. Understand the outcome. Identify what the user needs, what must remain true, and what would count as done. Read an existing brief or task before inventing another. Ask a focused question when the answer changes correctness, scope, authorization, or a consequential decision; otherwise proceed with a stated, reversible assumption.
2. Establish context. Read the working project's applicable AGENTS.md or host-equivalent instructions, including relevant nested instructions, unless already supplied in context. Then inspect relevant code and documentation, installed versions, scripts, and existing changes. Follow the affected behavior far enough to understand its callers and boundaries. Preserve unrelated work and its staged/unstaged distinction; ownership is not implied by a dirty working tree.
3. Select guidance. Open the relevant reference below before making the specialist decision. Use the directory for other domains. Read the selected skill and its applicable references, then stop expanding when the task has enough guidance. A readable skill need not be registered as a native command; selecting it grants neither new tools nor additional permissions.
4. Choose a proportional approach. Reuse existing briefs, tasks, and formats; keep enough structure for dependencies, risk, and resumption. Create planning artifacts or delegate when the task or project calls for them. If a consequential workflow choice is not settled by the request or project instructions, bring a recommendation, the relevant trade-off, and one focused question. Reviews explain findings before any separately authorized edits. Keep unresolved product choices visible.
5. Work in coherent increments. Reuse appropriate platform capabilities and established project facilities. Prefer understandable domain code and meaningful responsibility boundaries over extra layers or speculative infrastructure. Preserve intended behavior unless changing it is the task. Adapt as evidence changes; pause the affected action when scope, ownership, or permission becomes unclear. Inspect unfamiliar helpers before executing them, including their data disclosure and external effects.
6. Verify from requirements, in fresh context. Derive expected outcomes from requirements or a consumer contract, then choose a check that could expose the feared mistake. Keep focused author checks during implementation. When completion calls for verification, use a separate verifier with fresh context through Testing, not another pass in the implementation conversation. Report unavailable independent verification as pending. Distinguish exploration, verification, and durable regression protection; expand evidence by impact and required project gates. Module loading, mocks, or a green compiler alone establish narrower claims than a working integration.

Completion

Deliver the requested answer, artifact, or change. State the important decisions, observed checks and results, remaining uncertainty, and any blocked work. Keep the report proportional; identify what was left alone when it matters.

Commits, publishing, destructive cleanup, and persistent settings changes need authorization covering those actions; implementation alone does not supply it. For a handoff or interrupted task, retain the goal, current state, evidence, and next action in the project's existing mechanism. Stop when the requested outcome is supported rather than expanding into adjacent improvements.

References

Load only relevant branches. Sibling-plugin links assume the collection remains available on disk. If a target is missing, state the gap and use available project evidence, or ask when the missing guidance is essential; follow the directory's availability guidance for setup decisions.

• Project planning — read for scoped outcomes, briefs/tasks, acceptance, dependencies, milestones, or replanning.
• Software design — read for behavior, interfaces, ownership boundaries, architecture alternatives, and trade-offs.
• Testing and independent verification — read when choosing meaningful checks, authoring regressions, or verifying results in fresh context.
• Secret management — read for credential storage/injection, missing access, lifecycle changes, or suspected exposure.
• Search and investigation — read when locating code, tracing behavior, researching external contracts, or resolving an evidence gap.
• TypeScript development — read for TypeScript conventions, contracts, Node.js, Bun, Bunup, Vite, and related design decisions.
• Git workflows — choose the procedure for an authorized commit, logical commit series, worktree, GitHub action, or release note.
• Specialist directory — choose guidance for planning, investigation, documentation, refactoring, frameworks, platforms, automation, and agent tooling.
• Maintaining Slurpyb skills — read when changing this collection's skills, plugins, reference routing, or distribution.
• Personalizing this workflow — read only when Jordan is revising the working agreement; it records confirmed guidance and contextual decision points, not an onboarding questionnaire.