Agent skill

Backend Test Worker

by CorrectRoadH in CorrectRoadH/OpenTickly

Build and verify real-Postgres Go tests and thin transport smoke for tracking behavior.

AGPL-3.0Auto-check passedDatabases

Install Backend Test Worker

skills CLI
$ npx skills add CorrectRoadH/OpenTickly --skill backend-test-worker -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install CorrectRoadH/OpenTickly backend-test-worker --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/CorrectRoadH/OpenTickly.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.factory/skills/backend-test-worker .claude/skills/backend-test-worker && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
backend-test-worker
GitHub stars
306
Token cost
~1.3k tokens
SKILL.md length
421 words
Files
1
Skills in repo
10
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Build and verify real-Postgres Go tests and thin transport smoke for tracking behavior.

  • Works in 11 steps: Read mission.md, mission AGENTS.md,… → Identify which assertions the feature… → Write failing Go tests first at the… → …
  • Databases work in your project
  • SKILL.md covers When to Use This Skill, Required Skills, Work Procedure and Example Handoff, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Backend Test Worker is an agent skill from CorrectRoadH/OpenTickly. Build and verify real-Postgres Go tests and thin transport smoke for tracking behavior.

Its SKILL.md is about 1.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Databases. It works with PostgreSQL. The repository describes itself as: Self-hosted, Toggl-compatible time tracker. The licence is AGPL-3.0.

When your agent uses it

  • Databases work in your project

Example prompts

  • “/backend-test-worker”

Workflow steps

11 steps, taken from the first numbered list in SKILL.md.

  1. Read mission.md, mission AGENTS.md, {repo-root}/.factory/services.yaml, and {repo-root}/.factory/library/architecture.md from this…
  2. Identify which assertions the feature fulfills, list every expectedBehavior bullet from the
  3. Write failing Go tests first at the narrowest effective layer
  4. Use real PostgreSQL, the dedicated test schema, and mission isolation rules
  5. Prefer direct canonical readback in assertions when the feature is about stopped-entry truth, 200 + null, or invalid-save no-mutation…
  6. Keep transport smoke thin: only prove the exact API semantic that could drift.
  7. Run the narrowest backend test packages during iteration, then rerun the broader backend command(s) affected by the feature.
  8. If any required expectedBehavior bullet or requested regression path turns out to be
  9. If the feature touches conflict behavior and the exact public rule is still ambiguous, prove consistency and return to orchestrator rather…
  10. If the requested regression mentions a specific read/write surface such as continue, restart,
  11. In the handoff, call out

What it can do on your machine

Read from SKILL.md and the folder at commit 5ffd0a0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are json).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Backend Test Worker loads about 1.3k tokens when it runs. Until then it costs about 27 tokens; SKILL.md has 421 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~27
When it runs · the whole SKILL.md, loaded when a task matches
~1.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from CorrectRoadH/OpenTickly at commit 5ffd0a0, republished under its AGPL-3.0 licence (© CorrectRoadH). 421 words, ~1,308 tokens.

Download SKILL.mdSave it as .claude/skills/backend-test-worker/SKILL.md (or your agent's skills folder).
name
backend-test-worker
description
Build and verify real-Postgres Go tests and thin transport smoke for tracking behavior.

Backend Test Worker

NOTE: Startup and cleanup are handled by worker-base. This skill defines the work procedure.

When to Use This Skill

Use for features that add or fix Go unit/application tests, real-Postgres integration tests, thin transport/contract smoke, conflict regressions, and historical-fact retention coverage.

Required Skills

None.

Work Procedure

  1. Read mission.md, mission AGENTS.md, {repo-root}/.factory/services.yaml, and {repo-root}/.factory/library/architecture.md from this repository checkout (not any personal ~/.factory location).
  2. Identify which assertions the feature fulfills, list every expectedBehavior bullet from the feature, and convert each one into an explicit backend acceptance case before editing code. Do not stop after proving only one invalid-input variant if the feature or contract names more than one.
  3. Write failing Go tests first at the narrowest effective layer:
    • application/service tests for business rules and canonical readback
    • transport smoke only when the contract needs HTTP/body semantics
  4. Use real PostgreSQL, the dedicated test schema, and mission isolation rules:
    • never target the development business schema
    • keep data isolated by Workspace + User
    • keep async real, but ensure test-owned queues and drain-to-idle before final assertions where relevant
  5. Prefer direct canonical readback in assertions when the feature is about stopped-entry truth, 200 + null, or invalid-save no-mutation semantics.
  6. Keep transport smoke thin: only prove the exact API semantic that could drift.
  7. Run the narrowest backend test packages during iteration, then rerun the broader backend command(s) affected by the feature.
  8. If any required expectedBehavior bullet or requested regression path turns out to be impossible under the current documented/API contract, stop and return to orchestrator with the exact boundary instead of deleting the failing case and marking the feature complete.
  9. If the feature touches conflict behavior and the exact public rule is still ambiguous, prove consistency and return to orchestrator rather than inventing a new rule.
  10. If the requested regression mentions a specific read/write surface such as continue, restart, or batch mutation, locate that exact documented/API contract boundary first. If you cannot find a real boundary and only see nearby internal APIs that approximate it, return to orchestrator instead of inferring semantics from those internal calls.
  11. In the handoff, call out:
Show full SKILL.md (67 more words)Show less
  • the dedicated test-schema path used
  • whether async drain-to-idle was necessary
  • the exact canonical fields/read models that were verified

Example Handoff

json
{
  "salientSummary": "Added real-Postgres tracking lifecycle tests for stopped-entry create/edit/readback, invalid time rejection, and idle current-timer `200 + null` semantics. Also kept transport smoke thin by proving the current-timer body shape without moving business logic into handler tests.",
  "whatWasImplemented": "Expanded backend coverage for tracking time-entry lifecycle using the dedicated test schema on the shared external PostgreSQL service. The new tests prove canonical direct readback after create and edit, preserve prior state on invalid save attempts, and lock down the documented idle current-timer semantic with a thin HTTP smoke check.",
  "whatWasLeftUndone": "",
  "verification": {
    "commandsRun": [
      {
        "command": "go test ./apps/backend/internal/tracking/... -count=1 -parallel 4",
        "exitCode": 0,
        "observation": "Tracking application tests passed with the new lifecycle coverage."
      },
      {
        "command": "go test ./apps/backend/internal/bootstrap/... -count=1 -run 'TestPublicTrackTracking|TestRouteHandlers'",
        "exitCode": 0,
        "observation": "Thin transport smoke for current-timer semantics passed."
      }
    ],
    "interactiveChecks": [
      {
        "action": "Manually inspected one representative current-timer HTTP response after clearing running state.",
        "observed": "The endpoint returned HTTP 200 with literal null body and the direct read model remained idle."
      }
    ]
  },
  "tests": {
    "added": [
      {
        "file": "apps/backend/internal/tracking/application/update_time_entry_test.go",
        "cases": [
          {
            "name": "rejects invalid stop before start without mutating the persisted entry",
            "verifies": "VAL-ENTRY-003"
          },
          {
            "name": "materializes start plus duration without stop as a stopped entry",
            "verifies": "VAL-ENTRY-005"
          }
        ]
      }
    ]
  },
  "discoveredIssues": []
}

When to Return to Orchestrator

  • The feature requires changing the dedicated test-schema topology or mission database boundaries
  • The exact public behavior is not documented enough to write a truthful regression without inventing semantics
  • A necessary runtime dependency on Postgres or Redis is unavailable and cannot be restored

© CorrectRoadH, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .factory/skills/backend-test-worker of CorrectRoadH/OpenTickly.

Open the folder on GitHubat commit 5ffd0a0

Compare with similar skills

Backend Test Worker next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Backend Test Worker compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Backend Test Worker this skillCorrectRoadH/OpenTickly306—~1.3kAutomated safety check: PassAGPL-3.0
Ef Core Migrationsjihadkhawaja/Egroo178—~673Automated safety check: PassApache-2.0
Add Oliphaunt Extensionf0rr0/oliphaunt105—~1.4kAutomated safety check: PassMIT
Diagnose Cloud SessionFreakStudioCN/mpy-hardware-extension132—~809Automated safety check: NotesCustom licence
DB AdminEliasOulkadi/shokunin114—~2kAutomated safety check: NotesMIT
Postgresql Table Designynulihao/AgentSkillOS61715 repos~4kAutomated safety check: PassNone

Similar skills

  • Ef Core Migrations

    jihadkhawaja/Egroo

    Handle EF Core schema changes in Egroo. An agent skill from jihadkhawaja/Egroo.

    178 GitHub stars~673 tokensUpdated 6 mo ago
    DatabasesAuto-check passed
  • Add, update, or remove an Oliphaunt PostgreSQL contrib or external extension, including source pins, build recipes, target support, SDK metadata, release products, carrier identities, and package…

    105 GitHub stars~1.4k tokensUpdated today
    DatabasesAuto-check passed
  • Diagnose Cloud Session

    FreakStudioCN/mpy-hardware-extension

    用户报告 Blockless 扩展在云端实测时出问题(卡死/灰屏/跳步/构建失败),但本地复现不了、日志不在本地文件里时,用这个从云端托管数据库拉真实 session 定位症状与根因 / Use when a user reports an in-product Blockless bug from live cloud-backend testing and the real session…

    132 GitHub stars~809 tokensUpdated 9 days ago
    DatabasesAuto-check: notes
  • DB Admin

    EliasOulkadi/shokunin

    PostgreSQL database administration — backup/restore (pgdump, PITR, WAL archiving), health monitoring (connections, bloat, cache hit ratio, dead tuples), connection pooling (PgBouncer), replication…

    114 GitHub stars~2k tokensUpdated 3 days ago
    DatabasesAuto-check: notes
  • Postgresql Table Design

    ynulihao/AgentSkillOS

    Design a PostgreSQL-specific schema. An agent skill from ynulihao/AgentSkillOS.

    617 GitHub starsUsed in 15 repos~4k tokens
    DatabasesAuto-check passed
  • Postgres Patterns

    ThibautBaissac/rails_ai_agents

    PostgreSQL database patterns for query optimization, schema design, indexing, and security.

    665 GitHub starsUsed in 7 repos~922 tokens
    DatabasesAuto-check passed

More from CorrectRoadH/OpenTickly

All 10 skills in this repo
  • Frontend Test Worker

    CorrectRoadH/OpenTickly

    Build and verify page-flow and E2E coverage for the tracking browser surface.

    306 GitHub stars~1.4k tokensUpdated 5 days ago
    Auto-check passed
  • Fullstack Regression Worker

    CorrectRoadH/OpenTickly

    Build cross-layer regression coverage that ties browser-visible behavior to backend truth.

    306 GitHub stars~1.1k tokensUpdated 5 days ago
    Auto-check passed
  • Test Platform Worker

    CorrectRoadH/OpenTickly

    Harden shared test infrastructure, runtime readiness, schema setup, and parallel lane behavior.

    306 GitHub stars~1.2k tokensUpdated 5 days ago
    Auto-check passed
  • Tracking Backend Worker

    CorrectRoadH/OpenTickly

    Update backend timer/time-entry contracts, regressions, and source docs for the timer refactor mission.

    306 GitHub stars~1.2k tokensUpdated 5 days ago
    Auto-check passed
  • Tracking Doc Worker

    CorrectRoadH/OpenTickly

    Audit and finalize inline source-document status blocks for the timer refactor mission.

    306 GitHub stars~819 tokensUpdated 5 days ago
    Auto-check passed
  • Tracking Frontend Worker

    CorrectRoadH/OpenTickly

    Refactor and verify website timer/time-entry surfaces on the reused local runtime.

    306 GitHub stars~1.2k tokensUpdated 5 days ago
    Auto-check passed

Works with

Categories

Questions about Backend Test Worker

What does Backend Test Worker do?

Build and verify real-Postgres Go tests and thin transport smoke for tracking behavior. Backend Test Worker is an agent skill from CorrectRoadH/OpenTickly. Build and verify real-Postgres Go tests and thin transport smoke for tracking behavior.

When should I use Backend Test Worker?

Backend Test Worker fits situations like: databases work in your project.

How do I install Backend Test Worker in Claude Code?

Run `npx skills add CorrectRoadH/OpenTickly --skill backend-test-worker -a claude-code`. Or copy the skill folder (.factory/skills/backend-test-worker in CorrectRoadH/OpenTickly) into .claude/skills/backend-test-worker in your project. Claude Code loads it when a task matches its description.

How do I install Backend Test Worker in Codex?

Run `npx skills add CorrectRoadH/OpenTickly --skill backend-test-worker -a codex`. Or copy the skill folder (.factory/skills/backend-test-worker in CorrectRoadH/OpenTickly) into .agents/skills/backend-test-worker in your project. Codex loads it when a task matches its description.

Can I use Backend Test Worker in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add CorrectRoadH/OpenTickly --skill backend-test-worker -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/backend-test-worker, .gemini/skills/backend-test-worker, .github/skills/backend-test-worker and .opencode/skills/backend-test-worker in your project.

What does Backend Test Worker need to run?

SKILL.md names no scripts, command-line tools or credentials: Backend Test Worker is instructions for the agent only.

Does Backend Test Worker access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Backend Test Worker safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Backend Test Worker use?

Backend Test Worker is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Backend Test Worker use?

About 1.3k tokens (SKILL.md is roughly 5.2k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Backend Test Worker?

Skills that share tags, products or a category with Backend Test Worker: Ef Core Migrations (jihadkhawaja/Egroo, 178 stars), Add Oliphaunt Extension (f0rr0/oliphaunt, 105 stars), Diagnose Cloud Session (FreakStudioCN/mpy-hardware-extension, 132 stars) and DB Admin (EliasOulkadi/shokunin, 114 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Backend Test Worker?

CorrectRoadH (a GitHub user) maintains it in CorrectRoadH/OpenTickly, which has 306 GitHub stars. The repository holds 10 skills in this directory. The repository was last updated on October 2, 2026.

Source: CorrectRoadH/OpenTickly on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.