| name | rl-work |
| description | Execute concrete tasks the user delegates to the AI — the "act" arm of the life-harness loop, done on the computer — grounded in their philosophy and goals, with the task brief and every artifact kept in the same repo under work/ so this and future agents inherit full context. Use when the user runs /rl-work, hands over a task to do, or asks the AI to build, research, draft, or fix something toward a goal. Reads philosophy/, goals/, actions/; writes to work/open/ and work/closed/. |
| metadata | {"loop":"life-harness","step":"3.5-work"} |
rl-work — do the delegated work, in the repo, on the record
This is the act arm of the loop, done on the computer by the AI. The user
delegates concrete tasks; the AI does them — grounding each in the user's
philosophy and goals, keeping the record and every artifact inside the
workspace under work/ so future agents inherit full context, and linking the
work to the goal it serves. Where rl-plan plans steps and rl-review observes
them, this is where the AI does the computer-side ones — and leaves a record
honest enough to review. You are still the honest mirror: flag a task that serves
no goal or cuts against a principle, and record what actually got done (partial as
partial, blocked as blocked), not an impressive summary.
Input
Whatever the user typed after /rl-work is a seed, not a strict argument: one
or more tasks to do (optionally tied to a goal), or nothing → scan work/open/
for unfinished items and actions/open/ for delegatable steps, and ask what to
take on. Pin down what "done" means before starting.
Steps
-
Locate the workspace (see rl-init conventions); if none is found, tell the
user to run /rl-init and stop. Ensure work/open/ and work/closed/ exist
(create with a .gitkeep if the workspace predates them).
-
Ground the task — honestly. Read the relevant philosophy/ and, if the
task relates to a goal, that goals/open/<slug>.md and its action file. Which
goal or step does this serve? If none, say so — is it worth delegating, or
off-lens busywork? Don't refuse ad-hoc tasks, but don't launder off-lens work
into looking goal-serving; if a task cuts against a principle, flag it first.
-
Pin down "done" — grill the ambiguity out. Restate the concrete deliverable
and definition of done in a line or two, then hand it to the grilling skill
(model-invocable; not the human-only grill-me) to interrogate them until
nothing ambiguous remains. Let it run, confirm the sharpened result, then move
on. If grilling isn't installed, say so and interrogate it yourself. A task
you can't tell is finished can't be reviewed.
-
Open the work record at work/open/<slug>/ (kebab-case) with a task.md
brief (shape below). Keeping it here, not in scratch space, is the point — brief
and artifacts sit together for the next agent. Timestamps per the workspace
convention.
-
Do the work — in the repo. Produce artifacts inside work/open/<slug>/. If
the deliverable must land elsewhere in a real project, still record in the brief
what you changed and where, and link it. Keep decisions and dead-ends in the log.
-
Log honestly — and keep the record lean (enforce this every write).
Append one delta-only, budgeted entry to ## Log — a heading line + ≤5
one-sentence bullets, no paragraphs or numbered sub-lists (the same discipline
/rl-review uses): what you did, what's done / partial / blocked /
deferred, decisions and why, and anything the user must decide or verify.
Don't overstate. Then roll the log before you finish: task.md's ## Log
keeps only the last ~3 entries — cut older ones and append them verbatim to
task.log.md beside it (create it if absent; append-only, never auto-loaded),
leaving a one-line pointer. Nothing trims this automatically, so it is your
step, not the harness's — a task.md that only grows is the bug this prevents.
Keep the brief itself current-truth-only: when a slice finishes, collapse it to
a one-line pointer rather than leaving its full narrative (deep detail lives in
notes/). Keep ## Artifacts to one line each, and bump updated.
-
Hand back and link to the loop. Tell the user what's done, what needs their
input, what remains. If the task served a goal, make sure this record's goal:
(and action:) names it so /rl-review picks it up as evidence — the AI's own
work isn't part of the activity the user reports on, so this record is the
evidence. Surface the outcome in the goal's action-file ## Log if worth a line
— one short entry, rolling older entries past ~3 to actions/history/<slug>.md.
When finished or dropped, set status and move the folder to
work/closed/<slug>/, keeping its goal:/action: pointed at wherever those
files now live (open/ or closed/). If the goal closes while this task is
still open, the goal's close sweep moves and repoints this record too (rl-init →
Closing a goal).
task.md shape:
# Work — <task title>
- status: active # active | done | abandoned
- created: YYYY-MM-DD HH:MM ±HH:MM (Zone/Name)
- updated: YYYY-MM-DD HH:MM ±HH:MM (Zone/Name)
- goal: goals/open/<slug>.md # the goal this serves — or "none (ad-hoc)"
- action: actions/open/<slug>.md # the step it advances, if any
## Task
What the user delegated (their words) + your restatement of the deliverable and
definition of done. Current-truth only — collapse a finished slice to a one-line pointer.
## Plan
Brief steps you'll take (for anything non-trivial).
## Artifacts
Files produced here (and any real-project paths touched), one line each.
## Log
Last ~3 entries; older → task.log.md (beside this file). Each = heading + ≤5 one-sentence bullets, delta-only.
YYYY-MM-DD HH:MM ±HH:MM (Zone/Name) — what you did, done/partial/blocked, decisions, what's next.
