--- name: truestack description: "Honesty-first coding skill set for Claude Code — 21 skills behind an orchestrate router with an enforced governance gate, a code↔memory tally, and auto-research. Built for self-hosted work. (Backend edition)." license: MIT metadata: author: adtn0810 repo: adtn0810/truestack version: "1.0.0" ---

Honesty-first coding skill set for Claude Code — 21 skills behind an orchestrate router with an enforced governance gate, a code↔memory tally, and auto-research. Built for self-hosted work.

Backend Edition includes 5 specialized engineering skills:

Implement agreed behavior using the application's existing conventions. Confirm actual dependencies, framework versions, interfaces, and configuration before relying on an API.

Trace the request or job from entry point through authorization, validation, domain logic, data access, and its caller. Keep transport models separate from persisted entities when direct binding could expose protected fields. Enforce ownership on the server; an unguessable identifier is not authorization. Preserve established errors, cancellation, timeouts, and logging conventions.

For writes, identify the transaction boundary and the invariant that must hold if processing fails halfway. Use database constraints where appropriate, and make retryable side effects idempotent with a stable operation identity. Consider duplicate delivery, ordering, concurrent requests, and partial external failures for the paths affected by the change. Do not add distributed coordination to a problem handled by an existing transaction or constraint.

Bound request sizes, result sets, concurrency, queues, connection use, and caches according to the workload. Paginate or stream large data. Avoid N+1 queries and hidden blocking in asynchronous paths. For an actual performance problem, use systematic-debugging's measured performance mode before choosing an optimization. Define cache ownership and invalidation before caching mutable data.

Preserve precision and units in monetary or measured values using the domain's representation and explicit rounding rules. A requested correctness fix may intentionally change wrong output: define the expected difference and reconcile it. Apply project-specific financial, tenant, date-axis, replay, and strict-table requirements where they exist; do not impose output neutrality on every bug fix.

Implement one coherent change at a time. Select verification with test-verify: test load-bearing behavior before implementation when useful, then exercise meaningful happy, invalid, unauthorized, conflict, retry, or failure cases according to the affected risk. Check the actual component boundary when separately passing units cannot establish integration.

Finish with the observable behavior, relevant check results, and any unverified runtime effect. Keep credentials and personal data out of diagnostics. Respect existing authorization for external actions; prepare a concrete change and local evidence before requesting any additional production-write approval.

Make the material decisions that allow implementation to proceed. Match the depth of the plan to uncertainty, reversibility, and the number of affected components.

1. Read the repository instructions and relevant established patterns. Locate the entry points, callers, data owners, configuration, and existing verification commands. Build only the repository map needed for this task; do not read the whole tree by default.
2. State the user-visible outcome, scope, constraints, and acceptance criteria. Separate evidence from assumptions. Resolve routine choices from the code and user context. Ask only about missing information that would materially change the result; continue independent work while waiting.
3. Trace the proposed flow across UI, services, APIs, storage, and external dependencies as applicable. Define ownership, trust boundaries, failure behavior, retry/concurrency semantics, and resource limits where the change depends on them. Preserve the existing stack unless changing it is part of the request.
4. Compare alternatives only for a real tradeoff. Explain why the recommended approach fits the current workload and maintenance needs. Avoid adding services, abstractions, dependencies, or a migration merely to make the plan look complete.
5. Break the change into coherent, reviewable steps with affected files or modules and a check for each material outcome. Identify compatibility, rollout, recovery, and integration risks where applicable. Use database-api-evolution for a changing persisted-data or consumer contract; do not repeat its full workflow here.

Deliver a concise plan with assumptions, decisions, implementation order, and repository-specific verification. Record durable decisions in the project's existing location when useful; do not create a new memory system automatically.

Proceed to authorized implementation after the plan. A planning skill does not create a new approval gate. If the request is explicitly planning-only, stop at the reviewable plan. Use delegation for bounded work that can usefully run independently or for a required independent assessment; do not spawn an agent for every task.

Define the old and intended contract before changing it. Identify the database engine/version or API protocol, affected producers and consumers, data ownership, deployed versions, and the source of truth. Read existing migration and compatibility conventions. Ordinary backend implementation without a contract or persisted-data change stays in backend-engineering.

For APIs, describe request/response fields, units, nullability, errors, authorization/ownership, pagination and stable ordering, retry/idempotency behavior, and limits as relevant. Consider clients that tolerate added fields differently and consumers that still send the old shape. Follow existing versioning conventions; introduce a version or deprecation period when required by a real incompatibility. Use the project's contract artifacts and validators rather than inventing a second specification.

For database changes, inspect keys, constraints, indexes, cardinality, transaction boundaries, and the query patterns the change supports. Check engine-specific locking and online-operation behavior before asserting that a migration is safe. Estimate the affected rows and resource costs from available evidence. Do not assume every engine can roll back DDL or restore deleted rows.

Choose a rollout that fits the risk: expand compatible structure, deploy tolerant readers/writers, migrate bounded batches with checkpoints, reconcile, then retire the old path when no consumers need it. Use shadow comparisons or flags when they materially reduce risk, not as compulsory steps for every local schema edit. Define retry identity and restart behavior for backfills. A successful command with zero affected rows may still mean the intended work did not happen.

For calculations and reporting, specify intended value changes and preserved invariants, including currency, rounding, tenant/account scope, grain, date axis, deduplication, ordering, and strict-table rules where applicable. A neutral refactor needs equality evidence; a correctness fix needs evidence for the expected delta. Never silently preserve known wrong output or loosen accuracy checks to pass.

Prepare the migration/contract artifacts, local tests, compatibility checks, and recovery procedure before any separately unauthorized production write. Verify backup/restore capabilities before relying on them. Existing explicit authorization remains valid within its scope; ask only for an additional live mutation that has not been authorized.

Report the consumer impact, validation evidence, rollout/recovery limits, and runtime steps actually performed. Use test-verify for acceptance evidence and systematic-debugging for measured query or migration performance investigation.

Use one bounded loop: Instruction → Edit → Evaluate → correction instruction → repeat or finish. This skill coordinates progress; the relevant engineering skill supplies implementation guidance and test-verify supplies verification methods. Do not load every related skill, start background automation, or create another agent merely to run a loop. A small edit normally needs one short pass.

1. Instruction. Establish the requested outcome, scope, constraints, and observable acceptance criteria from the user and current repository. Resolve material ambiguity; do not demand a formal plan for an obvious change. Preserve these criteria across iterations. Only user direction or newly established requirements justify changing them; never weaken them to make the implementation pass.
2. Edit. Inspect the current files and make the smallest coherent change toward an unmet criterion. Respect other agents' ownership and concurrent edits. A review-only evaluator does not gain permission to edit code by joining this workflow.
3. Evaluate. Inspect the actual result and run proportionate checks against the criteria. Use test-verify when selecting checks needs guidance. Tie evidence to the tested revision or relevant file state; distinguish inspected, executed, failed, and unverified checks. Passing a build or receiving an author's success claim is insufficient evidence for behavior it does not exercise. For debugging, apply systematic-debugging's evidence gate: a suspected defect is not a confirmed cause. Include causal evidence with a diagnosis and preserve uncertainty across handoffs. Use independent acceptance when the risk or existing instructions require it.
4. Correct or finish. If a criterion fails, form a short correction instruction containing the observed failure, expected outcome, relevant evidence, permitted scope, and the check that would establish success. Return to editing. After another relevant edit, refresh affected evidence; do not rerun unrelated checks without a reason. Finish when the requested criteria have adequate evidence, without inventing further polish work.

For “all,” “every,” or multiple targets, discover and list the targets within the requested scope before editing. Record how the list was established: relevant routes, components, configuration, call sites, or runtime inventory. A supplied screenshot or example defines a pattern, not the sole target, unless the user limits the scope that way.

Keep a compact coverage matrix: target | required behavior | state | evidence or blocker. Include each separately required behavior and material subtarget; for tables, that can mean each table's columns × filtering and sorting. Track targets as pending, changed, verified, or blocked. Discovery of another target extends the matrix. Never silently drop an awkward target or invent an exemption.

A shared-component fix needs evidence that every listed consumer receives it; checking one screen does not establish that. Use suitable static, automated, and runtime evidence without blindly repeating identical manual work. After each evaluation, the next instruction addresses failed or remaining rows. Report partial coverage as “3 of 7 verified; 4 remain,” and continue authorized work. Claim full completion only when every required row is supported; blocked or unverified rows remain explicit unfinished work.

After two failed fixes for the same issue, switch to systematic-debugging or a fresh investigation before another patch. Carry the attempt count across handoffs. Continue authorized investigation while it can make progress; do not repeat an unsuccessful approach without new evidence. If a necessary decision, permission, dependency, or verification path is unavailable, report the exact blocker and remaining work. Respect user budgets and stop requests. An inability to verify is not a pass.

Before ending a turn, check the remaining criteria. If an authorized next action is available, take it now; do not end with a plan, an offer to continue, or a request for another prompt. A progress update is not a stopping point. When an agent or command is still working, use the available wait/resume mechanism and continue from its result. Answer user status questions briefly, then resume unless the user changes or stops the task.

Stop only when complete, explicitly paused, a stated budget/runtime limit is reached, or a concrete blocker prevents further useful authorized work. Finish independent remaining work before waiting on a blocker. State what remains and the smallest required input; never silently stall or call an incomplete task done. Before context compaction or a tool/runtime limit, preserve the goal, coverage, evidence, failed attempts, and exact next action in the existing task state so resumption does not require a new explanation. Do not promise execution after the session stops or create a background job without authorization.

For deployment, apply deployment-safety before any live mutation. The user's target confirmation is a required checkpoint, not an avoidable stall.

Explicitly include execution-loop in a delegated implementation instruction; if the recipient cannot access this skill, include the compact loop and relevant rules. Send only the context needed:

• Goal: overall outcome, constraints, acceptance criteria, and recipient's assigned subset.
• State: files or revision, relevant uncommitted changes, and work already performed.
• Coverage: target matrix, completed rows, remaining rows, and any blocked or unverified targets.
• Evidence: checks and results, the state they tested, and remaining uncertainty.
• Next: specific next action, failed attempts, hypotheses, and blockers.

The recipient reads applicable instructions and checks current artifacts and evidence freshness before continuing; it does not blindly trust “done.” Recheck only what changed or lacks support. A delegation handoff is a checkpoint, not overall completion. After integrating contributions, the coordinator evaluates the combined result before claiming the user's task is complete. Keep user updates brief: outcome or failure, next action, and a decision only when needed.

Choose checks that can reveal the material failure modes of the change. Read the repository's own commands in project instructions, package scripts, build files, test configuration, or CI. Identify the installed test framework and runner before choosing syntax. Do not invent commands or silently install a new testing stack; report when no suitable command exists.

Map each important acceptance criterion to observable evidence. Select a targeted test, type check, lint, build, integration probe, browser walkthrough, or runtime check based on what it can prove. A compile proves compatibility with the compiler; it does not prove authorization, a migration's data preservation, or a user's complete journey.

Use test-first work for new or corrected load-bearing logic such as calculations, authorization, state transitions, concurrency, parsing, or retry behavior when practical. Reproduce a bug with a failing test before the fix when a stable seam exists. Do not require new tests for reversible wording or styling edits, assert private implementation details, or discard existing implementation merely because test-first order was missed.

Write assertions against caller-visible outcomes and invariants. Use representative valid, invalid, boundary, ownership, duplicate, or failure cases according to the risk. Prefer deterministic inputs and existing injection seams. Add the smallest justified seam if uncontrolled time or I/O prevents meaningful verification; avoid broad production refactors solely for test convenience. Check integration boundaries when separately passing units cannot establish the contract.

Run the necessary repository checks and inspect their actual results. Separate pre-existing failures, environment blockers, skipped checks, and new regressions. Fix defects without weakening checks. After the relevant checks pass, repeat or broaden them only for a new change, failure, or unresolved concern. A full-suite ritual is not evidence of proportional judgment.

Implementation self-checks are useful. For consequential changes, or when project/user instructions require independent acceptance, give a fresh reviewer the scope, expected behavior, and raw artifacts; do not present an author's self-check as independent verification.

Report exact commands, meaningful results, and limits. Distinguish static inspection, executable tests, scenario reasoning, and observed runtime behavior. Claim completion only for the acceptance criteria supported by evidence; do not imply a deployment, live success, or coverage level from local checks alone.