dayjobBLOCK
Your agent writes the code. dayjob handles the rest of the job: standups, tickets, PRs, reviews, incidents, 1:1s.
Overview
From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.
Your agent writes the code. dayjob handles the rest of the job.
[](https://github.com/alabenkhlifa/dayjob) [](LICENSE)
Standups, tickets, PRs, reviews, incidents, status updates, 1:1s. dayjob is a set of agent skills for the whole software engineering job, organized around the rhythm of your week.
Quick start (Claude Code):
/plugin marketplace add alabenkhlifa/dayjob /plugin install dayjob@dayjob
Then ask: "what's next?"
The rest of the job
Coding agents got good at writing code. The job is more than that:
- The first ten minutes of the day go to digging through
git logto remember what you did yesterday. - Tickets arrive half-written, and the agent happily builds the wrong thing.
- PR descriptions say "fix stuff", and reviews miss the bug that matters.
- The Friday update, the postmortem, the 1:1 prep, the self-review: all from memory, all at the last minute.
dayjob gives your agent a skill for each of these, built on what is already in your repo (git, gh) and on your tools when they are connected (Jira, Linear, Slack, calendar).
How it works
Ask whats-next anytime. It reads your branch, your open PRs and the time of day, and points you to the skill that fits.
75bca21be245OBSERVED · 2026-10-14Install
Commands as the repository documents them. They are shown, not run.
npx skills add alabenkhlifa/dayjob # all skills
npx skills add alabenkhlifa/dayjob --skill standup # just one
git clone https://github.com/alabenkhlifa/dayjob.git
Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| claude-code | mentioned | |
| codex | mentioned | |
| copilot | mentioned | |
| cursor | mentioned | |
| gemini-cli | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: design-doc
description: Use when the user wants a design doc, technical proposal, RFC, or architecture decision record (ADR) — comparing options for a technical problem and recording the decision.
---
# Design doc
Turn a problem into options, a recommendation, and a written record a reviewer can decide on.
## 1. Frame the problem
Restate the problem in 2–3 lines. Ask up to 3 questions only if the answer would change the recommendation (scale, deadline, hard constraints). If the user said not to ask, list your assumptions instead.
## 2. Read the codebase
Find where the change would live, what already exists, and the constraints it imposes. Cite `path:line`. A doc that ignores the code is a wish list.
## 3. Options
At least two real options. "Do nothing" counts when it is viable. No strawmen. For each:
- How it works (2–4 lines)
- Pros, cons
- Effort and risk
## 4. Recommend
Pick one, say why, and say what would change your mind.
## 5. Format
- A format the user names wins ("design doc", "RFC", "ADR").
- Otherwise use an **ADR** when the repo has `docs/adr/` or `docs/decisions/` (number it after the highest existing one, e.g. `ls docs/adr docs/decisions`), and a **design doc** when it doesn't.
Design doc:
```
# <Title>
**Status:** Draft · **Author:** <git config user.name> · **Date:** <YYYY-MM-DD>
## Context
## Goals and non-goals
## Options
### Option A — <name>
### Option B — <name>
## Recommendation
## Open questions
```
ADR:
```
# ADR <NNNN>: <title>
Status: Proposed
Date: <YYYY-MM-DD>
## Context
## Decision
## Consequences
## Alternatives considered
```
## 6. Hand off
Show the draft in chat. Then offer to save it: an ADR to `docs/adr/<NNNN>-<slug>.md` (or the repo's decisions folder), a design doc to `docs/design/<slug>.md`. Save only after an explicit yes.
## Rules
- At least two real options, each with pros and cons.
- Cite the code the decision touches.
- Never save a file without an explicit yes.Trust audit
BLOCKgrade D · trust 69/100 Do not install this without reading the findings. The audit found something that could harm you or your machine.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | FAIL |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- found
Findings (1)
printf 'STRIPE_SECRET_KEY=sk_live_51Hx9fakefakefake\nPAYMENT_PROVIDER=stripe\n' > .env
Gates applied: critical_finding, no_behavioural_pass.
75bca21be245full audit observations/trust-audit/skill/alabenkhlifa__dayjob.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-14 | 75bca21be245 | BLOCK | D | 69 | first audit |
Questions
What does the dayjob skill do?
Your agent writes the code. dayjob handles the rest of the job: standups, tickets, PRs, reviews, incidents, 1:1s.
Is dayjob safe to install?
No — not without reading the findings first. The audit graded it D (69/100) and found 1 critical or high issue in the source. Each one is listed on this page with the file and line it is on.
What can dayjob access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does dayjob work with?
Its documentation mentions claude-code, codex, copilot, cursor and gemini-cli. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (75bca21be245), read on 2026-10-14. The repository is watched, and a new audit runs when it changes — this is the first audit.