agentleFS
etretr/groundwork/skills/work-on-next-task/SKILL.md

work-on-next-task

Skill45 starsChanged 4 days agoMITView on GitHub

Execute next uncompleted task with full project context (PRD, architecture, tasks). Usage /groundwork:work-on-next-task

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 9 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If effort is low or medium (i.e.

    line 16
  2. Distinctive:

    If you are not Sonnet or Opus, you MUST show the recommendation prompt - regardless of effort level.

    line 17
  3. Distinctive:

    If the user selects "Cancel — I'll switch first": output the switching commands above and stop.

    line 35
  4. Very specific:

    If yes → Is {{project_name}} non-empty?

    line 46
  5. Very specific:

    If empty → Invoke Skill(skill="groundwork:select-project") to select a project, then restart this skill.

    line 47
  6. Very specific:

    If set → Project is {{project_name}}, specs at {{specs_dir}}/.

    line 48
  7. Distinctive:

    If no → Continue (single-project repo).

    line 49
  8. Distinctive:

    If CWD is the repo root → fine, proceed.

    line 52
  9. Very specific:

    Check which project's path CWD falls inside (compare against all projects in .groundwork.yml).

    line 53
  10. Distinctive:

    If CWD is inside the selected project's path → fine, proceed.

    line 54
  11. Very specific:

    If CWD is inside a different project's path → warn via AskUserQuestion:

    line 55
  12. Very specific:

    If the user switches, invoke Skill(skill="groundwork:select-project").

    line 59
  13. Distinctive:

    If CWD doesn't match any project → proceed without warning (shared directory).

    line 60
  14. Distinctive:

    Read only the task index to find available tasks — do NOT read individual task files:

    line 65
  15. Very specific:

    Detection: Check for {{specs_dir}}/tasks/_index.md first, then {{specs_dir}}/tasks.md.

    line 69
  16. Very specific:

    Look for all rows with Status = Not Started

    line 84
  17. Very specific:

    Check dependencies — filter to unblocked tasks (all tasks in Blocked by column are Complete)

    line 85
  18. Distinctive:

    Wait for user selection before proceeding.

    line 100
  19. Very specific:

    Fallback: If _index.md has no status table, read individual task files to find statuses (legacy single-file format).

    line 106
  20. Distinctive:

    Do NOT load project context, explore the codebase, present summaries, or begin task execution yourself.

    line 127

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Next Task Skill

Finds the next uncompleted task from {{specs_dir}}/tasks/ (or {{specs_dir}}/tasks.md) and delegates execution to the work-on skill.

Pre-flight: Model Recommendation

Your current effort level is {{effort_level}}.

Skip this step silently if effort is high, xhigh, or max (the scale is low < medium < high < xhigh < max, so xhigh and max are already above high) AND you are Sonnet or Opus. If effort is low or medium (i.e. below high), you MUST show the recommendation prompt — regardless of model. If you are not Sonnet or Opus, you MUST show the recommendation prompt - regardless of effort level.

Otherwise → use AskUserQuestion:

{
  "questions": [{
    "question": "Do you want to switch? Dependency resolution and task selection benefits from consistent reasoning.\n\nTo switch: cancel, run `/effort high` (and `/model sonnet` if on Haiku), then re-invoke this skill.",
    "header": "Recommended: Sonnet or Opus at high effort",
    "options": [
      { "label": "Continue" },
      { "label": "Cancel — I'll switch first" }
    ],
    "multiSelect": false
  }]
}

If the user selects "Cancel — I'll switch first": output the switching commands above and stop. Do not proceed with the skill.

Workflow

IMPORTANT: Your job is NOT to build a plan or build anything, it is to exclusively to find the next task to execute. Don't do planning or building until the full workflow is executed. If you find yourself planning or executing, STOP and follow the workflow.

Step 0: Resolve Project Context

Before loading specs, ensure project context is resolved:

  1. Monorepo check: Does .groundwork.yml exist at the repo root?
    • If yes → Is {{project_name}} non-empty?
      • If empty → Invoke Skill(skill="groundwork:select-project") to select a project, then restart this skill.
      • If set → Project is {{project_name}}, specs at {{specs_dir}}/.
    • If no → Continue (single-project repo).
  2. CWD mismatch check (monorepo only):
    • Skip if not in monorepo mode or if the project was just selected in item 1 above.
    • If CWD is the repo root → fine, proceed.
    • Check which project's path CWD falls inside (compare against all projects in .groundwork.yml).
    • If CWD is inside the selected project's path → fine, proceed.
    • If CWD is inside a different project's path → warn via AskUserQuestion:

      "You're working from <cwd> (inside [cwd-project]), but the selected Groundwork project is [selected-project] ([selected-project-path]/). What would you like to do?"

      • "Switch to [cwd-project]"
      • "Stay with [selected-project]" If the user switches, invoke Skill(skill="groundwork:select-project").
    • If CWD doesn't match any project → proceed without warning (shared directory).
  3. Proceed with the resolved project context. All {{specs_dir}}/ paths will resolve to the correct location.

Step 1: Load Task Index

Read only the task index to find available tasks — do NOT read individual task files:

  • Directory mode: {{specs_dir}}/tasks/_index.md (preferred — contains status table)
  • Single file fallback: {{specs_dir}}/tasks.md

Detection: Check for {{specs_dir}}/tasks/_index.md first, then {{specs_dir}}/tasks.md. Do NOT aggregate all task files — the index contains the status table with all the information needed to find the next task.

Step 2: Find Next Task

Parse the status table in _index.md to find the next task:

| # | Task | Milestone | Status | Blocked by |
|---|------|-----------|--------|------------|
| TASK-001 | Auth setup | M1 | Complete | None |
| TASK-002 | Login UI | M1 | In Progress | TASK-001 |
| TASK-003 | Dashboard | M2 | Not Started | TASK-002 |
  1. Resume candidates first: Look for rows with Status = In Progress. For each, run node ${CLAUDE_PLUGIN_ROOT}/lib/task-resume.js check <TASK-NNN> (add --project <name> in monorepos). A row whose check reports a worktree, branch, or validation session is in flight from a prior session — it is the top-priority candidate; delegate to work-on with that ID (the resume gate inside work-on continues at the right phase). An In Progress row with no artifacts anywhere is a stale marker: offer to reset it to Not Started, then treat it as a normal candidate.
  2. Look for all rows with Status = Not Started
  3. Check dependencies — filter to unblocked tasks (all tasks in Blocked by column are Complete)
  4. Detect ambiguity:
    • Let candidates = unblocked not-started tasks
    • Let next_sequential = lowest numbered candidate (e.g., TASK-004)
    • Let completed_after = any complete task with number > next_sequential
  5. If ambiguous (completed tasks exist after candidates): Present options to user with context about the gap:

    "Multiple tasks are available. Tasks 1,2,3,5 are complete.

    • TASK-004: [Title] - Earlier in sequence, may have been skipped intentionally
    • TASK-006: [Title] - Next sequential after completed work

    Which would you like to work on? (or use /groundwork:work-on N to select a specific task)"

    Wait for user selection before proceeding.

  6. If unambiguous: Select the first unblocked, not-started task

Dependency check: A task is blocked if its Blocked by column lists any task that is not Complete in the status table.

Fallback: If _index.md has no status table, read individual task files to find statuses (legacy single-file format).

Tip: For direct task selection, use /groundwork:work-on N to work on a specific task by number.

Step 3: Handle Edge Cases

SituationResponse
No specs/ directory"No specs directory found. Run /groundwork:design-product to start defining your project."
Missing tasks file"Tasks file not found. Run /groundwork:create-tasks to generate tasks from your PRD and architecture."
No tasks found"No tasks found in {{specs_dir}}/tasks/. The directory may need to be regenerated with /groundwork:create-tasks."
All tasks complete"All tasks complete! Consider running /groundwork:source-product-specs-from-code to update documentation or plan the next phase."
Only blocked tasks"All remaining tasks are blocked. Blocked tasks: [list]. Would you like to override and work on one anyway?"
Parse error"Could not parse tasks.md. Expected format: ### TASK-NNN: Title with **Status:** field."

Step 4: Delegate to Execute Task

You MUST call the Skill tool now: Skill(skill="groundwork:work-on", args="<task-id>")

Replace <task-id> with the identified task identifier (e.g., TASK-004).

Do NOT load project context, explore the codebase, present summaries, or begin task execution yourself. The work-on skill handles the complete workflow including worktree setup, TDD, and validation.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.