Claude Skill

public-contract-change

Change Labtasker's public Task lifecycle, HTTP API, Python API, CLI, configuration, query language, or persisted schema while keeping every public surface and invariant aligned. Do not use for internal refactors with no observable behavior change.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download luocfprime-labtasker-.agents_skills_public-contract-change-19f9599.zip · 1 KB
Part of luocfprime/labtasker — 5 skills

Install

skills CLI npx skills add https://github.com/luocfprime/labtasker/tree/main/.agents/skills/public-contract-change
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install luocfprime-labtasker@llmmart
Git git clone https://github.com/luocfprime/labtasker.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole luocfprime/labtasker collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Change the public contract

Read the relevant section of docs/reference/specification.md before editing. State the current contract, the requested change, and any unresolved behavioral choice. If the request intentionally changes a decided behavior, update the specification rather than treating the old text as an implementation obstacle.

Before implementation, present every added, removed, or observably changed public interface as a compact, separate review item. Give its exact signature, command or endpoint, inputs, defaults, output, errors and compatibility effect as applicable, then obtain the user's explicit approval. Do not infer approval for an interface because it appeared inside a long specification or broader implementation plan. A direct user request naming the exact interface change is explicit approval for that change.

Trace the complete affected slice before editing:

  • persistence model and Alembic migration, when stored data changes;
  • Server validation, service transaction, endpoint, error envelope, and OpenAPI;
  • Client boundary model, transport, public method/function, and retry behavior;
  • CLI command, stdout/stderr shape, help, and exit behavior;
  • Worker runtime, journal, fencing, or concurrency behavior when applicable;
  • user guides, references, examples, and tests.

Keep the Client and Server distributions independent; duplicate small boundary models when necessary instead of creating a shared runtime package. Preserve explicit lifecycle actions and run_id fencing. Define idempotency, concurrent state changes, uncertain transport outcomes, validation errors, and migration behavior instead of relying only on the happy path.

Add focused tests at the lowest useful layer plus at least one real boundary test for each changed public surface. Use independent SQLite connections for race or transaction claims. Verify generated OpenAPI whenever endpoint schemas or errors change.

Finish by checking the specification, implementation, tests, and user docs for the old term or behavior. Run targeted tests during development and the relevant validation matrix from AGENTS.md before handoff.

Files (labtasker)
  • SKILL.md 2.4 KB
    ---
    name: public-contract-change
    description: Change Labtasker's public Task lifecycle, HTTP API, Python API, CLI, configuration, query language, or persisted schema while keeping every public surface and invariant aligned. Do not use for internal refactors with no observable behavior change.
    ---
    
    # Change the public contract
    
    Read the relevant section of `docs/reference/specification.md` before editing.
    State the current contract, the requested change, and any unresolved behavioral
    choice. If the request intentionally changes a decided behavior, update the
    specification rather than treating the old text as an implementation obstacle.
    
    Before implementation, present every added, removed, or observably changed
    public interface as a compact, separate review item. Give its exact signature,
    command or endpoint, inputs, defaults, output, errors and compatibility effect
    as applicable, then obtain the user's explicit approval. Do not infer approval
    for an interface because it appeared inside a long specification or broader
    implementation plan. A direct user request naming the exact interface change is
    explicit approval for that change.
    
    Trace the complete affected slice before editing:
    
    - persistence model and Alembic migration, when stored data changes;
    - Server validation, service transaction, endpoint, error envelope, and OpenAPI;
    - Client boundary model, transport, public method/function, and retry behavior;
    - CLI command, stdout/stderr shape, help, and exit behavior;
    - Worker runtime, journal, fencing, or concurrency behavior when applicable;
    - user guides, references, examples, and tests.
    
    Keep the Client and Server distributions independent; duplicate small boundary
    models when necessary instead of creating a shared runtime package. Preserve
    explicit lifecycle actions and `run_id` fencing. Define idempotency, concurrent
    state changes, uncertain transport outcomes, validation errors, and migration
    behavior instead of relying only on the happy path.
    
    Add focused tests at the lowest useful layer plus at least one real boundary test
    for each changed public surface. Use independent SQLite connections for race or
    transaction claims. Verify generated OpenAPI whenever endpoint schemas or errors
    change.
    
    Finish by checking the specification, implementation, tests, and user docs for
    the old term or behavior. Run targeted tests during development and the relevant
    validation matrix from `AGENTS.md` before handoff.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related