piotrekno1/second-shift

Same agent. Same task. Every week?
Put it on a schedule with SecondShift.
Your coding agents can review production errors, investigate CI failures, and
check monitoring coverage. Stop reminding them. Commit a skill, set a schedule,
and get the findings delivered.
Your team controls their access. Every run leaves an audit trail.
https://github.com/user-attachments/assets/73cbd504-2a13-4a99-bf95-d7a5c3745e28
Commit a skill and its schedule alongside your code, connect a model, and
approve the services it may use. Reports arrive in Slack or another webhook
destination. Commands run in an isolated sandbox. Each run records its Git
revision, tool activity, and model cost.
## Try it out now
Install uv and start Docker,
then run:
bash
# Install SecondShift
release=https://github.com/piotrekno1/second-shift/releases
uv tool install --force --python 3.13 \
"$release/download/v0.1.0a6/secondshift-0.1.0a6-py3-none-any.whl"
# Start SecondShift
secondshift up
Upgrading from an earlier alpha? Read
installed builds first.
Once started, the console shows:
text
SecondShift is running at http://127.0.0.1:8000
Sign in with this link. It works once, within 15 minutes:
http://127.0.0.1:8000/-/sign-in/ /
Run secondshift login for a new link. Press Ctrl+C to stop.
SecondShift is in alpha, distributed through
GitHub Releases until it is
available on PyPI.
## What you can do
See what is on duty. The control room shows upcoming shifts, recent runs,
failures, and model spend.
Manage schedules from Git. Discover jobs from .secondshift.yaml, review
their skills and schedules, and enable or run them manually.
Connect models and report destinations. Add a model provider and webhook,
then approve each job's notification access. Connections remain separately
revocable.
Give skills live data. Connect GitHub, Sentry, any MCP server (OAuth or a
token), or an HTTP API from its OpenAPI spec. Choose which tools jobs may use,
then approve each job's request. Calls run outside the sandbox.
Follow every run. Inspect its Git revision, execution timeline, report,
token usage, and model cost.
## Put recurring reviews on duty
Write a skill for a recurring problem your team needs to investigate. Connect
the services it needs through MCP or an HTTP API, then approve the job's access.
| Review | What the skill can investigate | Data it needs |
| Recurring CI failures | Which failures keep blocking builds, when they started, and which changes may explain them. | Build history and failure logs through an API or MCP connection, plus repository code. |
| Production errors | Which Sentry errors are new or worsening and which recent code changes may be related. | Issues, events, or traces through the built-in Sentry connection, plus repository code. |
| Monitoring coverage | Whether removed alerts, paused rules, or changed thresholds leave important failure paths uncovered. | Monitoring rules and their change history through an API or MCP connection, or configuration committed to the repository. |
| Release readiness | Whether a planned release needs migration steps, configuration changes, or rollout instructions that are missing. | Repository changes and release plans, with an API or MCP connection for plans kept outside Git. |