Menú
Work autonomously while the user is away. Create multiple feature branches sequentially, each with a self-contained improvement.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Browse, screenshot, or visually verify a local web app using the pre-installed browser-check and playwright-cli (never install your own browser). Use when asked to screenshot, browse, open/view a page, check the UI, or confirm the site is running.
Prioritize open TODO items by effort and impact, recommend what to work on next. Add the `full` keyword to also weigh project notes and stash context.
Resume a session — read the paste-back handoff note to recall what we last worked on, falling back to a git+TODO status when none exists. Add the `full` keyword to also deep-scan project notes and memory.
Write the paste-back handoff note (scratch/resume-session.md) so the next session can hit the ground running. Add the `full` keyword to also save durable knowledge to denote notes + TODO and commit.
Get oriented on host-level, cross-project knowledge by reading the stash README map. Use when starting fresh in a container, or when you need the lay of the land for hardware, dotfiles/preferences, Emacs, Linux, or cross-project conventions that live outside the current repo.
Structured workflow for feature-sized or risky changes: short intake questions, create a branch, use TDD where applicable, commit frequently, get an external agent review, fix issues, then get a second external review and optionally open a PR. Use when the user says a task is big, multi-step, high-risk, or explicitly wants TDD, frequent commits, or multi-agent review.
| name | j-afk |
| description | Work autonomously while the user is away. Create multiple feature branches sequentially, each with a self-contained improvement. |
Work autonomously while the user is away. Create multiple feature branches sequentially, each with a self-contained improvement.
count (optional): Number of branches to create (default: 5)--prefix: Branch prefix (default: yolo)--from: Base branch (default: current branch)CRITICAL: Do everything SEQUENTIALLY. Never run parallel agents or background tasks. Token limits are a real concern.
Check TODO.org for existing tasks. Also review the codebase for improvement opportunities (failing tests, missing features, code quality, documentation gaps, etc.).
Build a plan of count independent, self-contained improvements. Each should be completable in a single branch. Prioritize:
For each improvement, run the full /j-feature-workflow sequence. The user is away, so the quality bar is higher: branch isolation, TDD where applicable, frequent commits, and two external agent reviews before declaring done. The workflow is:
a. Check out the base branch (git checkout <from>).
b. Create a feature branch (git checkout -b <prefix>/<descriptive-name>).
c. If feasible, write a failing test first.
d. Implement in small increments; commit after each coherent slice.
e. Run just test (or python -m pytest tests/) and just lint (if available); fix anything you broke.
f. First external review — pipe the diff to codex (or gemini, claude, etc.); use the lean invocation pattern from docs/agent-ops.md "Cross-Agent Reviews"; ask for the highest reasoning model.
g. Apply review fixes; commit.
h. Second external review — pipe again; different reviewer is fine.
i. Apply fixes; commit. Optionally open a draft PR if a remote is configured.
j. If this completes a TODO.org item, mark it DONE.
k. Return to the base branch before starting the next improvement (git checkout <from>).
Two reviews matter here precisely because the user is not in the loop. Skipping a review to save time defeats the point of /j-afk.
After all branches are created, print a summary:
/j-afk
/j-afk 3
/j-afk 5 --prefix experiment
/j-afk 3 --from develop