Servotab

View saved version →

---
name: debug
description: "Investigate and fix bugs, failing tests, regressions, build failures, or unexpected behavior using boundary localization, evidence, and bounded hypotheses."
---

# Debug

Find the causal mechanism, then fix it with the least risky change. Be systematic without forcing a four-phase ceremony onto an obvious compiler error.

A debug request restores the verified existing or requested contract. It does not authorize adjacent features, fallback systems, broad refactors, or extra infrastructure merely because they might make the system more robust.

## 1. Define the failure

Capture:

- Observed behavior
- Expected behavior
- The required outcome independent of the current implementation mechanism
- Reproduction path
- Environment or data conditions
- Exact error plus transport, status, and capability provenance when the failure crosses a boundary
- First known bad version or recent relevant changes, when available

Read the complete error, stack trace, failed assertion, logs, or browser console output. Do not summarize away the line that identifies the failing boundary.

Do not group failures merely because the UI renders the same red box. A route `404`, template admission rejection, asset-plane failure, playback capability failure, and download capability failure are separate boundary hypotheses until evidence connects them.

If the failure is already precise and local, move directly to tracing it.

## 2. Reproduce or gather evidence

Prefer the cheapest reliable reproducer:

- A focused existing test
- A new regression test
- A minimal command or script
- A deterministic UI sequence
- A targeted log or state inspection

Choose the experiment for the causal claim, and keep final acceptance on the actual user surface. A mechanism surrogate may use another device, process, or local seam when it preserves the conditions material to the tested claim: the relevant path, configuration, protocol, and load, plus any identity the claim itself concerns. The surrogate need not reproduce attributes the claim does not depend on. State the material equivalence and its limits; a surrogate that omits a suspected host-specific condition cannot exclude that cause. The affected device need not reproduce every shared mechanism.

For a cross-boundary failure, check where each decisive probe starts, which relevant boundaries it traverses, and under what conditions. A green check that bypasses the suspected boundary cannot establish that boundary's health. Inspect inputs and outputs where they distinguish hypotheses; retain temporary instrumentation only when it remains useful observability.

Before a speculative repair, identify the predicted observation and a comparable baseline. Prefer deterministic reproduction. For intermittent failures, use bounded repeated trials with frequency and conditions; an authorized diagnostic intervention may itself establish reproducibility. Do not wait for a perfect harness or treat one successful run as proof.

If a material boundary still lacks a useful experiment, establish—or hand off as one bounded structural slice—the smallest executable seam or diagnostic that can reveal it. Avoid further patch/deploy attempts that do not narrow the hypothesis space. Do not duplicate production or create an unrelated testing programme; local evidence cannot close a named-host or owner-experience claim.

## 3. Trace the cause

Trace bad state backward:

- Where is the incorrect value or transition first observable?
- Which caller, event, mutation, or external response produced it?
- What assumption changed?
- Is there a nearby working path to compare?
- Could several visible failures share one upstream cause?

When you compare against a case that works, constrain the explanation with the closest verified-normal case rather than an arbitrary one. A shared factor can still contribute to the failure; the comparison is only useful when it explains why exposure, timing, state, or interaction makes one sid

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: delegate
description: "Choose responsibility for substantial work before deep execution: keep one responsibility's coupled parts in a single lane, and hand a bounded or independent lane to a worker when clean context, an unknown cause, independent review, or coordinator attention materially improves the outcome."
---

# Delegate

Choose responsibility before deep execution. Worker lanes move a bounded responsibility into clean agent contexts without confusing delegation with permission. Use the fewest work surfaces that materially improve the outcome.

## Responsibility choice

Decide, before committing to a deep implementation or investigation path, whether this task stays in the Coordinator lane or becomes a worker lane. This is a responsibility decision, not a parallelism switch.

- A user request to work solo, or any instruction that forbids subagents, ends the question. Do not delegate.
- Keep the coupled parts of one responsibility together in one coherent lane. Coupling alone does not force the Coordinator lane: that one lane may be a worker lane when the responsibility is substantial, uncertain, or noisy enough to repay the handoff.
- Frequent unresolved decisions that cross ownership boundaries count against delegation; those decisions need the Coordinator's context rather than a handoff.
- Serial delegation is valid. Complete one bounded lane, integrate its return, and dispatch the next only when it still repays the coordination cost. Parallelism is a separate decision about concurrency, not a condition for delegating.
- Servotab sets no model, budget, provider, or transport policy; the host and the work order own those choices.

Do not delegate an otherwise trivial task because a lane, an idle worker, or a coordination benefit happens to be available. A task must first have left the clear/direct path because the responsibility is substantive, uncertain, noisy, or otherwise meaningfully handoff-shaped.

## Capability and routing boundary

- The host and current instructions decide whether subagent tools exist, how much concurrency is available, and whether delegation is permitted. Servotab cannot create or override that capability.
- Select this method from task topology: independent substantial lanes, one noisy responsibility that benefits from clean context, a bounded unknown-root-cause investigation, distinct evidence questions after localization, or a genuinely useful independent review. Model or reasoning tier, idle slots, and a harness-initiated spawn are not evidence that this method was selected.
- In ordinary-language work, the implicit `servotab` router reads this reference and applies its contract. The explicit `delegate` leaf is a manual entry point; its name need not appear in the UI for the method to govern a delegation.
- If delegation is unavailable or forbidden, keep the same ownership boundaries while sequencing the work locally. State that the work stayed local; do not claim a lane or a parallel execution that did not occur.

## Responsibility model

- The **Requester** sets the objective and grants authority.
- The current user-facing agent is the **Coordinator**. It decomposes the outcome, protects boundaries, remains the integration owner, and accepts or rejects returns.
- A **Task Worker** owns one coherent engineering, research, audit, validation, or review lane and makes ordinary in-scope decisions. A worker does not delegate again; recursive delegation and delegation trees are out of contract.

These are responsibilities, not ranks. A fresh context is a clean workbench; it creates neither a new objective nor new permission. Keep the main conversation as the coordination and judgment surface rather than replacing it with a worker dashboard.

## Delegation gate

When delegation is available, use a lane when at least one brings material value:

- Two or more substantial domains can proceed independently.
- A noisy research or long-running responsibility benefits from clean context.
- 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: design
description: "Turn a rough feature, product interaction, or architecture idea into a concrete design. Use when meaningful decisions remain open; avoid for already-clear local edits."
---

# Design

Develop the idea far enough that implementation can proceed confidently. Preserve exploration and design pressure without turning every request into a ceremony.

## Start with context

Inspect the smallest useful set of materials:

- Applicable `AGENTS.md`
- The current implementation path
- Nearby tests, schemas, or product documents
- Existing patterns that constrain the decision

Do not scan the whole repository unless the decision is truly cross-cutting.

## Classify reference material

A product description, tutorial, screenshot, example implementation, log, or design document may be:

- **Inspiration:** inform judgment within the user's requested scope; suggested mechanisms remain proposals unless adopted.
- **Evidence:** use it to test a claim about current or desired behavior.
- **Normative:** treat it as binding only when the user or repository makes it part of the accepted contract.

Route by the requested outcome, not the artifact format. A screenshot does not automatically require design exploration, and a long tutorial does not automatically become the project specification. Explicit written instructions and corrections override inferred visual or tutorial details. Ask about the source's role only when the distinction materially changes the result and cannot be inferred safely.

These roles determine authority, not how much relevant content deserves consideration. One source can contain evidence, proposals, and settled choices; classify the content without treating its whole container as either binding or disposable.

When the commission includes deciding what specified discussions, feedback, or references should contribute to existing work, use the Incorporate method for coverage, corrections, and adoption judgment. From the router read `references/incorporate.md`; from the explicit design leaf read `../incorporate/SKILL.md`. Reading may be delegated before selecting an implementation focus. Retain the established source interpretation and project constraints here while resolving the remaining design decisions; do not restart intake.

## Reconstruct the problem

State, in compact form:

- Desired user or system outcome
- Current behavior
- Hard constraints and non-goals
- Proposed mechanism and the assumptions behind it
- Decisions already made by the user
- Material unknowns

Treat the user's existing direction as real input. Do not reopen settled choices simply to manufacture alternatives.

A proposed mechanism is not automatically a settled decision. Unless the user explicitly makes it a requirement, preserve the outcome and constraints while independently evaluating whether that mechanism is the best supported route. Preserve explicitly selected forms, media, interactions, and architecture as constraints; do not abstract them away into a generic need. Do not agree into avoidable complexity, and do not replace the proposal merely because another design is more familiar.

When the user asks to build, adapt, or borrow a named behavior, preserve that direction and explore only the decisions still needed to implement it. Do not turn an implementation request into an open-ended product workshop.

## Check the capability boundary

Before designing a new integration, transport, fallback, or abstraction, verify the assumption that makes it necessary:

- What exact current capability or policy blocks the outcome?
- Is that limitation directly observed, or inherited from one mode, old version, or earlier attempt?
- Does the repository, installed runtime, local help, or authoritative platform documentation already expose a direct supported route?
- How many owners, transports, profiles, persistent states, and trust boundaries does each viable route add?

Use readily available world knowledge to generate altern

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: execute
description: "Implement a settled request or current execution strategy through connected slices, feed observations into the same task record, and revise affected work when evidence changes."
---

# Execute

Turn a settled request or current strategy into working code. Preserve momentum while maintaining evidence and scope control.

## Load and sanity-check

Read:

- Applicable repository instructions
- The plan or settled request
- The accepted specification when the plan derives from one
- Files and tests directly named by it
- Any referenced schema or contract

Perform one sanity check before editing:

- Does the plan conflict with the current repository?
- Is a dependency missing?
- Would it cause data loss, a security regression, or a public compatibility break?
- Has the requested behavior already been implemented differently?
- If the plan claims full-spec scope, does it still cover all accepted requirements? For a bounded tranche, are its applicable requirements and dependencies settled?
- Does the plan preserve the accepted programme order and trust model under the applicable current authority?
- What present consumer, current requirement, or explicit authorization justifies any generalized protocol or infrastructure it introduces?

Correct small stale details yourself. Surface a concern only when it changes the approach materially.

A settled goal does not settle order, effort or evidence timing. Before dependent edits, use Plan when a consequential execution choice remains, a route has become invalid, or durable recovery needs reconciliation. Continue a mature applicable route directly. From the router read `references/plan.md`; from this explicit leaf read `../plan/SKILL.md`. On resumption use the selected task entry and current implementation/tests, not the newest nearby plan or old completion marks. Do not replay uncertain external effects.

When an approved specification governs the work, it remains the scope and acceptance authority throughout execution. A tranche controls what is being worked on now; it does not remove later scope from the complete plan. Repair a partial plan that claims full-spec coverage before relying on that claim. An explicitly requested tranche can proceed from its applicable requirements and settled dependencies without first creating a whole-program plan. Record scope or order changes as explicit deltas, and report tranche completion separately from full-spec completion.

## Complete outcome is the default

When the user asks to build, implement, adapt, or borrow a clear feature, deliver the complete requested usable outcome and the integration required for it to work in the repository. `MVP`, prototype, scaffold, placeholder, or local-only happy path is valid only when the user or accepted specification chooses that scope.

Choose the simplest implementation that satisfies the whole contract. Do not turn caution into silent product narrowing, defer an obvious core path as “later,” stop after backend scaffolding when the requested outcome is end-to-end, or report a plan as implementation. If authority, missing inputs, or an external blocker prevents completion, finish every safe in-scope part, label the result partial, and name exactly what remains.

For reference-led work:

- Carry forward established material dispositions, including remaining accepted scope and unresolved items. A selected first slice does not replace the whole request. If specified material still needs reconciliation to establish its contribution, use Incorporate before narrowing execution: from the router read `references/incorporate.md`; from the explicit execute leaf read `../incorporate/SKILL.md`. Use Design for remaining open product or architecture choices; keep the same commission.
- Treat product descriptions and tutorials as inspiration unless the user makes named behavior normative.
- Treat screenshots and mockups as contracts for visible details only when the user or accepted specificati

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: finish
description: "Finish a development change safely by inspecting the final tree, verifying at the right scope, and performing only the requested Git or PR actions."
---

# Finish

Close the work without turning completion into an automatic merge ritual.

## 1. Inspect final state

Check:

- Current branch and workspace type
- `git status --short`
- Final diff and diff statistics
- Untracked, generated, or temporary files
- Debug logging, TODOs, fixtures, snapshots, or local config accidentally changed
- Secrets or sensitive data
- Whether unrelated user changes are present
- The canonical active path and its callers, including any superseded helper, flag, test, or documentation claim left by the replacement

Do not modify or discard unrelated changes.

When replacement is complete, remove the superseded path in the same change. Retain compatibility only for an evidenced current caller or staged boundary, and name the reason and removal condition; an inert parallel implementation is not a rollback plan.

## 2. Check requirements

Map the final implementation to the requested behavior:

- Completed acceptance criteria
- Intentionally omitted items
- Plan deviations
- Alignment with the applicable authorized goal and current programme
- Compatibility or migration status
- Documentation or setup changes
- Remaining risks

Do this once. Do not reopen accepted design decisions without evidence. Treat implementation deviations as evidence to review, not as authority that settles product meaning. Before integration, require applicable approval for any change to programme order, trust boundaries, or accepted product scope.

## 3. Verify

Use a risk-matched verification ladder:

- Focused regression or behavior checks
- Adjacent suite or build for shared code
- Broad checks for integration, migration, security, or public contracts
- Manual or visual verification where relevant
- Fresh named-host acceptance after the final relevant deployment when the behavior is host-specific

Run checks after the final relevant edit. State exactly what passed and what was not run.

## 4. Review the diff

Perform a compact self-review for:

- Correctness
- Accidental scope
- Data/state consistency
- Error paths
- Compatibility
- Test value
- Avoidable complexity

For high-risk work, one independent reviewer can add value. Verify that reviewer’s findings yourself. Do not require duplicate reviewers for ordinary changes.

## 5. Documentation

Update durable documentation when the change affects:

- Public behavior or APIs
- Setup, configuration, or operations
- Data contracts or migrations
- Architecture decisions another person will need
- User-facing workflows

Do not add changelog noise for invisible local refactors unless repository policy requires it.

Close the existing task record with actual results, evidence and remaining unverified scope. Distinguish completed, paused, cancelled and superseded work; link a successor when replaced. Move lasting usage or architecture facts into their maintained documentation and link them from the plan. Do not turn historical plans into live runbooks or delete them in bulk.

## 6. Git and integration

Only commit, push, merge, or create a PR when the user requests that action or applicable repository/global instructions delegate it.

When committing:

- Preserve unrelated user changes.
- Stage intentionally, not with blind `git add .`.
- Use focused commits when it improves review or rollback.
- Follow repository message conventions.

When preparing a PR:

- Identify the correct base branch.
- Summarize behavior and risk.
- Include verification evidence.
- Mention migrations, rollout, screenshots, or follow-up where relevant.

When work remains local, report the branch and workspace path.

## Destructive cleanup

For workspace cleanup, read and apply the Worktree method’s shared removal and authorization contract before acting. From the router use `references/worktree.md`; from the explicit finish l

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: incorporate
description: "Assess, adapt, and apply specified discussions, feedback, findings, or references to existing project work. Preserve coverage, corrections, and selected intent; judge fit and carry adopted effects through the authorized result. Includes technical review feedback; incidental sources or understanding material without a target-work adoption question need no separate incorporation workflow."
---

# Incorporate

Carry specified material into existing work. Establish what its relevant contributions mean, judge their fit with the current project, and carry adopted effects through the requested outcome.

## Establish the commission

Identify the material to consider, the work it should inform, and how far the current request authorizes proceeding. The specified material defines the coverage obligation; the project supplies the adaptation context; the commission determines whether to assess, design, implement, or verify.

Keep the boundary proportional. An incidental article in a debugging task does not create a separate intake project. A request to understand sources can finish with understanding; an already approved specification follows its existing planning or execution path. Use this method when deciding what specified discussions, feedback, findings, or references should contribute to existing work is itself part of the requested result.

Preserve accepted scope, explicit write limits, and existing task state. Resolve only material ambiguity that cannot be inferred from the request and prior decisions. Do not restart an interview or request permission already granted.

## Establish coverage before narrowing the work

Read across the requested material before selecting implementation focus or dispatching a narrowed implementation lane. A reading or investigation lane may establish that coverage first. Do not substitute the latest summary, most polished proposal, easiest fix, or final topic for the relevant whole. For an explicitly bounded question, cover its material and dependencies rather than auditing every source.

- Keep material goals, constraints, selected forms, rationale, examples, dependencies, and open questions. Merge repetition without losing the distinct contribution of an earlier topic.
- Attribute statements to their speaker and context. Distinguish a report, proposal, hypothetical, quoted old instruction, owner choice, and the current agent's inference. A model-written “final specification” gains no authority from its title or recency.
- Follow corrections at their actual scope. A revision may replace a mechanism, narrow a claim, change priority, or introduce an exception while preserving an outcome. Recency alone does not erase earlier independent goals. Leave incompatible claims unresolved when the evidence does not settle them.
- Apply assent to what it clearly refers to. Approval of one visual property does not approve every adjacent implementation proposal; clear acceptance of an identified complete proposal does count. Do not demand a second approval because the proposal originated with an assistant.
- Separate an outcome from a mechanism only while that mechanism remains open. Preserve the user's explicitly selected form, medium, interaction, architecture, and experience as constraints. Do not turn a requested graphical treatment into generic “clarity” and silently deliver a different form.
- Keep useful source anchors: existing message or section identifiers, file locations, or short decisive excerpts. Preserve the surrounding exchange when it determines meaning. Name unavailable, unread, or truncated material and limit dependent conclusions.

An unresolved idea can supply a design question, hypothesis, useful criterion, or next experiment. Develop it when it matters to the current request; do not automatically convert it into a requirement, a backlog item, or a question for the user.

## Delegate a coherent responsibility when useful

Use the `delegate` contract when a 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: plan
description: "Form and maintain execution strategy when order, effort, evidence timing or recovery materially affects the outcome, even with a settled goal. Reuse durable task records when continuity needs them; keep clear work direct."
---

# Plan

Form and maintain an execution strategy: choose order, effort, evidence timing and continuity to improve the complete requested result. A settled goal can still leave those choices open. Clear local work and mature routes with applicable evidence can proceed directly.

## Enter with the current commission

Recover the requested outcome, acceptance, settled choices, permissions, selected task record, relevant implementation and important unknowns. Inspect enough code to name real touchpoints; use an identified area when exact paths remain unknown. Distinguish the user's chosen result, a proposed mechanism, observed facts and ordinary details left to the implementer. A polished brief is not verified repository design. Investigate searchable facts yourself without re-interviewing settled goals.

Use this method when an unresolved execution choice materially affects downstream work, quality, evidence or handoff: a shared unverified assumption, consequential ordering, meaningful stages or recovery, or new evidence invalidating the current route. Explicit planning requests also enter here. File count, tool count, prompt length and the label “complex” are not sufficient triggers. An ongoing causal investigation stays with Debug; add Plan only for the resulting execution or recovery arrangement.

Keep existing owners and lanes. Plan organizes execution; Design resolves material product/architecture choices, Spec Chain owns approved-spec coverage, Execute implements and returns observations, Delegate owns actual dispatch, and Verify/Finish govern acceptance and closure. Do not turn this into a new supervisory pipeline.

## Preserve outcome and authority

- Plan the complete usable outcome, including integrations, states and acceptance. A prototype, MVP or partial slice is a scope choice for the user or governing specification, not a shortcut for the implementer.
- Use the least complex implementation that satisfies that contract. Preserve accepted programme order when it carries product meaning; record a proposed scope/order delta and obtain applicable authority before adopting it. A newer plan, evidence or already-written code cannot approve itself.
- With an approved specification, reuse Spec Chain's complete coverage ledger and stable requirement IDs. Keep the current tranche inside that full scope. An explicitly bounded tranche needs only its applicable requirements, dependencies and existing complete-plan link; do not rebuild the programme or claim full completion.
- Only block work that depends on a missing decision. Make ordinary reversible implementation choices within current authority; return unresolved product meaning, consequential tradeoffs or external actions to the appropriate owner. Planning-only and read-only limits remain in force. Saving a permitted document does not authorize commit or publication.

## Choose an actionable strategy

Resolve the judgments that can change the next meaningful result. These are not mandatory form fields:

- **Value and effort:** identify where additional making, understanding or validation most improves the outcome. Quality can justify substantial early effort, not just risk reduction. Allocate unevenly while retaining all acceptance requirements.
- **Dependencies:** include implementation dependencies and judgment dependencies. Real content, decisive assets and an interaction lifecycle may need to appear together before quality is assessable. Respect necessary infrastructure and migration prerequisites.
- **Commitment:** preserve accepted decisions, ground choices with expensive downstream consequences, and leave ordinary internals to the executor near implementation. Do not exhaust every future branch for “decision complete.

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: review
description: "Review a diff, commit, branch, PR, or implementation for actionable correctness and risk issues without duplicate reviewer loops or invented findings."
---

# Review

Review the code against its intended behavior and repository reality. Findings come before praise, process narration, or stylistic preference.

## Establish the review target

Determine:

- Diff, commit range, branch, PR, or files in scope
- Requested behavior or acceptance criteria
- Applicable repository instructions
- Relevant tests, schemas, or contracts
- Baseline branch when needed
- The applicable authorized goal and programme authority when the change can reorder work, widen a trust boundary, or introduce generalized infrastructure

Inspect enough surrounding code to understand the change. Do not review a diff in isolation when its correctness depends on state or callers.

## Review priorities

Look for:

1. **Correctness**
   - Wrong state transitions
   - Stale or inconsistent data
   - Edge cases
   - Error handling
   - Partial failure behavior

2. **Data and compatibility**
   - Schema drift
   - Migration safety
   - Backward compatibility
   - Serialization or pagination contracts
   - Idempotency

3. **Security and privacy**
   - Authorization
   - Input validation
   - Secret or sensitive data exposure
   - Injection or unsafe execution
   - Trust-boundary errors

4. **Concurrency and performance**
   - Races
   - Lost updates
   - Unbounded work
   - N+1 behavior
   - Expensive hot paths

5. **Tests and verification**
   - Missing regression coverage
   - Tests that cannot catch the bug
   - Assertions tied to implementation details
   - Unverified platform or migration behavior

6. **Complexity**
   - New abstractions without a present use
   - Duplicate sources of truth
   - Hidden coupling
   - A simpler implementation that reduces risk

Ignore cosmetic style unless it obscures behavior, violates an enforced convention, or creates maintainability risk.

## Goal integrity

When a change could alter product meaning, programme order, trust boundaries, or generalized infrastructure, choose exactly one goal-integrity verdict for each implicated scope. Apply the first matching verdict in this order:

- **authority unclear:** the governing authority or accepted goal cannot be determined from the available evidence.
- **diverges:** authority is known and the change contradicts, displaces, or self-reorders the applicable authorized programme.
- **advances:** authority is known and the change stays within the applicable authorized goal and current programme.
- **research-only:** authority is known and the work is technically useful and compatible with the current programme, but has not been adopted as a product dependency or current programme step.

Agent-authored specifications, decision logs, handoffs, PR descriptions, and implementation commits do not approve themselves. Review implementation quality and goal integrity separately: clean code and green CI can still be `research-only` or `diverges`.

Do not combine verdicts for the same scope. For a mixed change, record separate verdicts for materially different scopes when one label would hide the difference between authorized work and speculative additions. Omit the verdict when the change does not implicate a goal-integrity boundary.

## Validate each finding

Before reporting an issue:

- Identify the exact location.
- Trace the triggering path.
- Check whether existing code or tests already handle it.
- Distinguish a real bug from a hypothetical preference.
- Assess severity based on impact and likelihood.

Do not report speculative concerns as facts.

## Severity

Use:

- **P0:** Immediate data loss, security compromise, or system-wide outage risk.
- **P1:** Likely incorrect behavior, broken contract, serious regression, or blocked release.
- **P2:** Real but bounded defect, fragile behavior, meaningful test gap, or maintainability problem likely to cause errors.

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: review-feedback
description: "Evaluate and act on code-review feedback with technical judgment. Use before applying external suggestions, especially when feedback is ambiguous, broad, or may conflict with repository constraints."
---

# Review Feedback

Treat review feedback as technical input to verify, not commands to obey blindly or social cues to praise.

## Normalize the feedback

Break feedback into independent items. For each item record:

- Requested change
- Claimed problem
- Affected files or behavior
- Whether it is blocking, optional, or unclear
- Any dependency on another item

Do not implement a vague bundle such as “clean this up” without identifying the concrete behavior or quality concern.

## Authority boundary

- Review feedback is technical evidence, not authority by authorship or placement alone. A review comment, PR description, or decision-log edit may propose a scope, order, or trust-boundary change without approving it.
- Direct current instructions from an applicable authorized party, repository governance, or an explicitly adopted specification can authorize such a change. Verify that authority before implementing feedback that changes product meaning, programme order, trust boundaries, or shared infrastructure.
- When feedback exposes a real defect in the current programme, fix the defect within the accepted goal or surface the required decision; do not let the proposed implementation self-authorize a different programme.

## Verify against the repository

For each item:

1. Read the referenced code and surrounding path.
2. Reproduce or trace the claimed issue where practical.
3. Check existing tests and constraints.
4. Look for compatibility, platform, or historical reasons for the current design.
5. Decide whether the proposal solves the real problem with acceptable trade-offs.

Classify the item:

- **Accept:** technically correct and appropriately scoped.
- **Accept with adjustment:** the concern is valid, but the suggested implementation is not the best fit.
- **Verify further:** plausible but evidence is incomplete.
- **Reject:** incorrect, harmful, redundant, or contrary to an explicit decision.
- **Defer:** valid but outside the current change and not release-blocking.

## Ambiguity

Ask for clarification only when the missing answer materially changes behavior or scope and cannot be inferred safely.

Otherwise state the interpretation, choose the safest reversible implementation, and proceed.

## Implementation order

Handle:

1. P0/P1 correctness or security issues
2. Simple independent fixes
3. Deeper refactors or design changes
4. Optional cleanup

Test each meaningful behavior change. Batch tightly related items when separate changes would create temporary inconsistency.

## Pushback

Push back with evidence when:

- The suggestion breaks existing behavior.
- It adds an unused “professional” abstraction.
- The reviewer missed a repository constraint.
- The proposed fix treats a symptom.
- It conflicts with user-approved architecture.
- Its cost or compatibility impact exceeds the demonstrated problem.

State the technical reason and, when possible, offer a narrower alternative.

## Communication

Avoid performative agreement. Useful responses include:

- “Confirmed: this path can return stale state after mutation. I changed X and added Y.”
- “The concern is valid, but the proposed cache invalidation would break Z; I used A instead.”
- “I could not reproduce this under B. The remaining unverified condition is C.”
- “This endpoint has no callers and adding the abstraction would be speculative, so I left it unchanged.”

## Completion

Report each item's disposition and the evidence or change associated with it. Do not claim all feedback is resolved when some items remain unverified or intentionally rejected.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: servotab
description: "Use for hands-on repository work when a quiet, risk-scaled engineering method can improve design, execution strategy, implementation, material incorporation, debugging, review, delegation, workspace lifecycle, or verification. Keep clear local changes direct, preserve the complete requested outcome, and add method only where risk or uncertainty justifies it. Do not use for general technical explanations, simple file lookup, casual discussion, or non-engineering writing."
---

# Servotab

Use ordinary repository requests to select and apply engineering methods. The user need not name a skill. Keep communication quiet; keep the requested outcome complete.

## Before the first consequential action

- Read applicable instructions and the smallest relevant implementation, tests, and accepted contract. Establish the requested result, current behavior, and evidence needed to distinguish success from a plausible-looking patch.
- Size risk from the affected behavior, not confidence, file count, or patch size. Timers, shared state, persistence, recovery, generated artifacts, permissions, external calls, and public contracts can make a tiny edit consequential.
- Preserve explicit corrections and accepted scope. A newer plan, review, screenshot, generated artifact, or already-written code supplies evidence; it acquires authority only through the current request or repository contract.
- When asked to incorporate specified discussions, feedback, or references into existing work, read `references/incorporate.md` when reconciliation governs the result. Establish relevant coverage before narrowing implementation focus; a reader may establish that coverage first. Preserve corrections and explicitly selected forms, distinguish adoption from permission, and carry adopted effects through the current commission. Incidental sources do not create a separate intake workflow.
- Keep clear local work direct. Before consequential action, a settled goal can still leave material choices about order, effort, evidence or continuity. Read `references/plan.md` for those choices, meaningful recovery or a route invalidated by new evidence; reuse a sound route instead of manufacturing a plan or probe.
- Choose responsibility before deep execution. Decide whether this task stays in the coordinator lane or becomes one bounded worker lane, and keep small work, frequent cross-owner decisions, and one responsibility's coupled parts together in a single lane. Coupling alone does not force the coordinator lane. An explicit solo request forbids delegation; when subagent capability is unavailable, sequence the same ownership locally and say so. Reuse a worker that already owns the lane instead of duplicating it.

## Resolve decisions at their dependencies

When a material decision remains open, read `references/design.md` before committing to the dependent approach.

- Investigate repository and environmental facts yourself. Ask the user for intent or value choices that materially change the outcome and cannot safely be inferred.
- Ask only questions whose prerequisites are settled; include a grounded recommendation. Recompute dependent choices after an answer changes an assumption. An unresolved branch does not stop independent safe work.
- Use delegated reversible choices and explicit best-effort assumptions where authorized. Do not turn the absence of a prewritten design into a request for approval.
- Stop questioning when the current work is decision-ready. Do not exhaust unrelated future branches or reopen settled product decisions without contradictory evidence.

## Search before new common machinery

Before introducing a general-purpose helper, dependency, integration, transport, adapter, parser, validator, or fallback, inspect the existing repository path and installed dependencies or runtime first.

- Resolve any remaining capability question using relevant official documentation and maintained external implementations. Do not cl

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 15 — file references are metadata, not package contents.

View saved version →

---
name: spec-chain
description: "Preserve an approved specification through a complete implementation plan and execution. Use for major refactors, migrations, or multi-session work when a confirmed spec is authoritative; keep scope and order changes explicit."
---

# Spec Chain

Preserve an approved specification from planning through execution. The specification defines the required outcome and acceptance contract; the plan defines implementation order and technique.

## Authority

- Treat the accepted specification as the canonical authority for **what** must be implemented, **why** it exists, and **how completion is accepted**.
- Agent-authored specifications, plans, decision logs, handoffs, PR descriptions, and implementation commits are derived material. An agent-authored artifact does not become approved authority merely because it is newer, more detailed, executable, or already implemented; require evidenced applicable approval when it changes programme order, trust boundaries, or product meaning.
- A plan presented as the implementation plan for that specification must cover its entire accepted implementation scope.
- A phase, milestone, or current tranche may subdivide execution, but it may not replace the complete implementation plan or be presented as though it covers the whole specification.
- Keep explicit non-goals excluded. Keep unresolved decisions inside the full plan as decision-closing prerequisites or blockers; do not make them disappear by narrowing the plan.
- Preserve settled semantics such as naming, cardinality, ownership, compatibility, and migration behavior. Implementation convenience is not authority to reopen them.

## Establish the source contract

Before planning or editing, identify:

- Canonical specification path
- Accepted revision or commit
- Approval state and any named open decisions
- Repository baseline the specification was grounded against
- Current implementation state where it may have moved
- Present consumer, current requirement, and authorization provenance when the specification proposes a generalized protocol, new infrastructure, or a programme reorder

Use a stable path plus revision or commit. Do not calculate a hash unless an actual identity or integrity decision needs it.

If several documents contribute requirements, name one primary specification and list the exact normative companions. Do not silently choose whichever document makes the next slice smaller.

If artifacts disagree, resolve their authority rather than using recency or implementation completeness as a proxy for approval. A research implementation may remain valuable evidence while staying outside the accepted product programme.

## Build the complete implementation plan

When the request is for the full specification, create one program-level plan over the full accepted scope. An explicitly bounded tranche request needs only its applicable requirements, dependencies, and stopping point. Link an existing complete plan; if absent, note that fact and resolve only dependencies that block the tranche. Do not expand the request into whole-program planning. Retain the existing status of other requirements; do not replan them or imply they were delivered in this request.

For a full-spec plan:

1. Extract normative requirements, settled decisions, acceptance criteria, migrations, compatibility obligations, and retained non-goals.
2. Refer to existing IDs or headings instead of copying specification prose. When the specification lacks stable identifiers, create compact plan-local IDs tied to its headings.
3. Map every accepted requirement to an implementation slice and verification outcome.
4. Order slices by real dependencies. A different order from the specification is allowed only when the plan records the dependency rationale and preserves the same outcome.
5. Identify the current execution tranche without removing later slices from the program plan.
6. Include decision-closing work before any slice that depend

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: tdd
description: "Apply risk-based test-driven development to bugs, domain logic, state transitions, parsers, contracts, migrations, and behavior where a failing test sharpens the design."
---

# TDD

Use tests as design and evidence. Preserve strict red-green discipline where it pays off, and use lighter verification where the ceremony would add little signal.

## Choose the testing mode

### Strict red-green

Prefer for:

- Bug fixes with a reproducible failure
- Domain rules and calculations
- State machines and mutations
- Parsers, serializers, validators, and data transforms
- API contracts and compatibility behavior
- Migrations
- Concurrency or race-condition fixes
- Security-sensitive behavior

Cycle:

1. Write the smallest behavior-focused test.
2. Execute it once and verify that the failure matches the intended behavioral gap.
3. Implement the minimum coherent change.
4. Run the focused test and confirm it passes.
5. Refactor while keeping it green.
6. Run nearby tests.

### Characterization-first

Use for legacy code whose behavior is poorly documented.

1. Add tests that capture relevant current behavior.
2. Add a failing test for the behavior that must change.
3. Implement the change.
4. Keep unrelated characterized behavior stable.

### Test-alongside

Reasonable for:

- Pure styling and visual polish
- Copy changes
- Simple configuration or wiring
- Generated files
- Small adapters already covered by higher-level tests
- Prototypes or short-lived spikes

Use the most meaningful existing checks. Add automated tests when there is a real regression surface, not to satisfy a quota.

## Existing implementation

Do not delete valid work merely because implementation preceded the test.

When code already exists:

- Reproduce the bug against the current code.
- Add a test that fails on the current behavior when possible.
- If the fix has already been applied, temporarily revert or mutate the narrow change only when safe and efficient to prove the test catches it.
- Otherwise document why red-state proof was impractical and use strong behavior verification.

## Test quality

Prefer tests that:

- Assert externally meaningful behavior
- Fail for one understandable reason
- Are deterministic
- Use real code through stable boundaries
- Survive internal refactoring
- Cover important edge and error paths
- For optional host capabilities, distinguish absence (no doomed action plus useful degradation), rejection, cancellation, policy denial, and success when those are separate observable results

Avoid:

- One test for every trivial function
- Snapshot tests that hide semantic changes
- Mocking the unit under test
- Asserting private implementation details
- Huge fixtures when a focused case works
- Adding sleeps for asynchronous behavior when a condition can be awaited

## Mocks and fakes

Use real collaborators when cheap and deterministic. Mock or fake:

- Network boundaries
- Time
- Randomness
- External services
- Slow or destructive infrastructure

Keep mocks at stable interfaces. If every internal call must be mocked, reconsider coupling.

## Regression proof

For a bug fix, the ideal evidence is:

- Test fails before fix for the expected reason
- Test passes after fix
- Nearby suite remains green

Do not perform risky repository surgery merely to reenact red-green after the fact. Evidence should increase confidence, not damage the workspace.

## Completion checklist

Before claiming test-backed behavior:

- The test targets the requested behavior.
- Failure and success reasons are understood.
- Important boundary cases are represented.
- Focused tests pass after the final relevant change.
- Broader checks were run when risk justifies them.
- Any untested area is stated honestly.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: verify
description: "Verify code or product claims after changes using fresh, risk-matched evidence. Use before saying a bug is fixed, tests pass, requirements are met, or a branch is ready."
---

# Verify

Evidence must support the exact claim. Fresh verification is required after the final relevant change, but verification scope should match risk rather than defaulting blindly to the largest test suite.

## Define the claims

List the claims that matter, such as:

- The original bug no longer reproduces.
- A new behavior matches acceptance criteria.
- Targeted tests pass.
- The module builds or type-checks.
- No existing behavior in the affected area regressed.
- A migration is safe.
- The branch is ready to integrate.

For each claim, identify the command, inspection, or manual scenario that proves it. For decisive cross-boundary probes, name their entry point, relevant path, and material conditions. Freshness and a shared environment do not make a check that bypasses the failing boundary evidence of that boundary's health. A brief coverage note is enough; do not create a second ledger.

## Evidence budget

- Run a check only when its result supports a named claim or can change the next action.
- Do not calculate hashes without an identity or integrity decision that will use them.
- Do not rerun unchanged checks or add a second acceptance loop merely to restate existing proof.
- Stop when every material claim has proportionate fresh evidence; more commands do not automatically create more confidence.

## Evidence maturity without ceremony

Keep capability and effectiveness claims separate:

- A file, rule, tool, or configured capability proves that it exists, not that the task can reach it.
- A reachable route proves wiring, not successful use or delivery.
- A focused exercise or passing test proves current behavior under its observed conditions, not general runtime effectiveness. Keep mechanism repair and whole-user-experience recovery separate; residual symptoms do not automatically invalidate a verified contributing fix.
- A repair verified in the current task proves repair state. Only a later comparable outcome can support a claim that the workflow improved over time.
- Missing observation is `Not verified`, not automatically a defect.

These are claim boundaries, not a required scorecard, ledger, report, or extra review loop.

## Host-boundary evidence ladder

For a host-specific claim, keep these rungs distinct:

1. Source contract
2. Process-level behavior test
3. Built artifact or image identity
4. Activated runtime identity
5. Exact named-host surface
6. Owner-observed behavior

Each rung supports the next investigation step, not the claim above it. Local or dev-browser success is not named-host acceptance; a successful build is not proof that the intended runtime is active; deployment is not owner-observed behavior. After the final relevant change, verify the artifact and activated runtime identities, then obtain fresh acceptance on the exact named host when that is the contract. If the required deployment or owner observation is not authorized or available, mark the higher claim `Not verified`.

## Verification ladder

### Level 1: Focused

Use for local, low-risk changes:

- Regression test
- Affected test file
- Component or module check
- Targeted type-check or lint
- Focused manual interaction

### Level 2: Adjacent

Add when the change touches shared code or several consumers:

- Package or feature suite
- Integration tests around the boundary
- Build for the affected application
- Representative platform or browser check

### Level 3: Broad

Use for high-risk or integration-ready changes:

- Full relevant test suite
- Full build
- Migration dry run
- End-to-end path
- Security or compatibility checks
- Multiple environments when the risk requires it

Do not run Level 3 merely to make a small change look rigorous. Do not stop at Level 1 when shared state, data, security, or public contracts are inv

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: worktree
description: "Choose, reuse, restore, park, or clean up Git workspaces while preserving work and host ownership. Create isolation only when it resolves a real conflict; inspection does not authorize creation or deletion."
---

# Worktree

Choose, resume, and retire repository workspaces without losing work or multiplying unnecessary checkouts. Isolation is one tool; an existing suitable workspace is often enough.

## Start from intent

Explicit use of this method does not request creation or deletion by itself. Match the actual task:

- **Inspect or organize:** inventory relevant workspaces and recommend what to keep, resume, park, or remove. Inspection alone authorizes no mutation.
- **Start or resume:** find the task's existing workspace before creating another. Create only when requested or when a concrete conflict makes isolation useful.
- **Park:** release a paused task's working directory while preserving its work and a usable restoration route. Integration is not required.
- **Finish or clean up:** resolve the named resources under the removal contract below. A request to tidy up is not permission to discard unique work.

Small local edits and read-only workers normally stay in the current workspace. Dirty state, duration, risk, and worker count are signals to inspect, not automatic reasons to create. Identify the actual conflict: unrelated edits, simultaneous writers to the same files or index, incompatible baselines, or an experiment that needs independent verification. Different branch names in one checkout do not separate working files or the index.

## Find the right workspace

Before creating, resuming, or planning cleanup, inspect the current repository and its relevant worktrees; do not scan every repository for an ordinary edit.

- Establish the repository root, common Git directory, current branch or detached HEAD, and whether this is the main checkout, a linked worktree, or a submodule. Resolve paths with Git rather than inferring ownership from directory names.
- Use `git worktree list --porcelain` (with `-z` for machine parsing) and available host/task state to find existing task workspaces, locks, and missing registrations. Deep-inspect only candidates relevant to the request.
- Check the candidate's branch/tip, task purpose, intended integration target, current changes, and known writer or host ownership. Neither an old commit nor absence of a lock proves inactivity.
- Reuse a suitable workspace belonging to this task. Do not take over another active task's checkout. If a prior creation returned ambiguously, inspect Git and host state before retrying; do not manufacture a duplicate.
- Distinguish host-managed, workflow-created, and explicitly user-selected pre-existing resources. Missing host evidence is uncertainty, not evidence of abandonment.

Prefer the host's supported workspace or handoff action for host-managed state. Confirm the actual tool's capabilities; clients may differ in placement, transfer of dirty changes, persistence, and cleanup. Do not manually remove a host-managed worktree behind the host's lifecycle. If the needed host action is unavailable, report that item's limitation and continue independent work.

## Create or restore only the needed state

Before creation, identify the required starting revision and any uncommitted prerequisites. Ordinary `git worktree add` checks out a revision; it does not copy the source checkout's dirty changes. A host transfer may behave differently. Verify the resulting files and tip before continuing the task. Do not silently commit, stash, reset, or copy private environment data to fill a baseline gap; use an authorized transfer or report the missing prerequisite.

When manual Git handling is appropriate:

1. Follow repository naming and location conventions. Prefer an existing ignored `.worktrees/` or `worktrees/` location, or a suitable sibling/user workspace location outside tracked source.
2. Check that a project-local destinatio

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.