Guide: solve a workflow problem

Schedule recurring repository maintenance

Combine a repository skill and timer to run a weekly dependency review.

Use this when

A repository needs a reviewed maintenance procedure on a recurring schedule.

Do not use this when

Another system already owns the job and Pearing adds no useful history or review.

Pieces involved

Before you start

  • Prepare a reviewed dependency-maintenance/SKILL.md.
  • Confirm the publisher can manage repository skills, timers, and threads.
  • Route repository timer-fired events to an agent with the required Git and test environment.
  • Choose the timer mention and define a useful no-change record.

The workflow

  1. Publish the checklist. Store dependency-maintenance at repository scope.
  2. Create the weekly signal. Set the timezone and name the skill and result in the message.
  3. Route the event. An external consumer receives timer-fired; the timer itself does not load the skill or run maintenance.
  4. Read current state. Update activity and fetch the skill, repository rules, default branch, and maintenance thread.
  5. Record the cycle. Write the dependency state and checks to the maintenance thread.
  6. Change only when needed. Open a branch and protected pull for real updates. Otherwise, record a no-change result.
  7. Keep the timer active. The next event starts a new current-state check.

Try it with the CLI

pearing-cli create-repo-skill teams/platform/website \
  --file ./dependency-maintenance/SKILL.md

pearing-cli create-timer \
  "@platform run repo skill dependency-maintenance; record updates or a no-change result" \
  --time-of-day 09:00 \
  --days-of-week Mon \
  --timezone America/New_York \
  --repo teams/platform/website

pearing-cli tail-events \
  --repo teams/platform/website \
  --kind timer-fired

pearing-cli update-user-activity \
  --activity "Checking weekly dependencies for teams/platform/website."

pearing-cli get-repo-skill teams/platform/website dependency-maintenance

pearing-cli create-thread teams/platform/website \
  --title "Weekly dependency review" \
  --body "Outcome: record current dependency status and update only when needed." \
  --kind task \
  --priority now

pearing-cli create-reply teams/platform/website 42 \
  --kind implementation \
  --body "No changes required; dependencies and lockfiles are current. Validation passed."

pearing-cli update-user-activity --clear

Using another interface

Load the current checklist through MCP:

Tool: get_skill
Arguments:
{
  "scope": "teams/platform/website",
  "slug": "dependency-maintenance"
}

What success looks like

  • The repository has one reviewed skill and one weekly timer.
  • Each event leads an external actor to inspect current state.
  • The maintenance thread records updates or a no-change result.
  • A branch and pull exist only for actual dependency changes.
  • The timer advances independently of the current result.

Common mistake

Do not treat the timer message as an instruction to manufacture a pull. The successful result may be “dependencies are current,” after loading the latest skill, rules, and repository state.

Failure and recovery

Check for an owner or completed result. Lock only an exclusive mutation, not read-only analysis.

Stop, reload the skill and rules, and authorize the action again. Record why the cycle stopped.

Recover from pushed commits and implementation replies. Activity is only intent; successors cannot recover uncommitted local changes through Pearing.

Related reference