agentleFS
HenryQWHenryQW/skills/issue-workbench/SKILL.md

issue-workbench

Skill1 starsChanged 4 months agoApache-2.0View on GitHub

Implement one GitHub issue in a guarded feature branch. Use when asked to build or fix one issue, run review-checkpoint, publish a PR, or return a Shipyard integration handoff path.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

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

    Default lite mode handles one issue only.

    line 26
  2. Distinctive:

    Stop on unclear acceptance or product behavior, unrelated dirty changes, forbidden-path changes not explicitly required, or required …

    line 27
  3. Distinctive:

    Do not add compatibility, migration, aliases, fallbacks, dependencies, or future-proofing without an explicit requirement.

    line 30
  4. Distinctive:

    If truncation hides scope, rerun with larger limits.

    line 41
  5. Distinctive:

    Use git add -N for new files.

    line 62

≈ “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

Issue Workbench

Implement one actionable issue with the smallest intentional diff. $review-checkpoint owns blocker actionability; $pr-launchpad owns PR publication; Shipyard owns integration.

Inputs

  • issue_number is required.
  • base_branch defaults to the repository default; branch_slug is optional.
  • worktree_path is optional in pull-request mode and is prepared by Shipyard in integration mode.
  • max_iterations and review_base pass through to $review-checkpoint.
  • handoff_mode is pull_request (default) or integration_branch.
  • integration_branch and Shipyard's prepared worktree_path are required in integration mode.

Memory

Direct invocation owns issue-scoped $agent-memory; integration mode defers it to Shipyard.

Boundaries

  • Default lite mode handles one issue only; do not invoke Blueprint, Shipyard, parent/child planning, or final_check.
  • Stop on unclear acceptance or product behavior, unrelated dirty changes, forbidden-path changes not explicitly required, or required unrelated refactoring.
  • Modify only issue-owned files. Do not touch secrets, env, generated, lock, .agents/, infrastructure, or .context/ files unless explicitly required or a verified review blocker requires it.
  • .context/ may contain only local progress, review, memory, decision, and handoff artifacts. Keep progress to goal, current_step, artifacts, blockers, and validation; never commit it.
  • Do not add compatibility, migration, aliases, fallbacks, dependencies, or future-proofing without an explicit requirement. Use Conventional Commits and stage only inspected paths.
  • Integration children send no interim status, never push their local branches, and never run pr-launchpad.

Workflow

  1. In integration mode, enter Shipyard's existing worktree_path; require its current branch to match issue-<issue_number>(-<slug>)?, require integration_branch to be its ancestor, and never create or switch the child branch. Then require a clean worktree and read the issue with:

    python3 <skill_dir>/scripts/issue_snapshot.py <issue_number>

    If truncation hides scope, rerun with larger limits. Extract requirements and constraints; do not invent behavior.

  2. In pull-request mode, prepare the branch with:

    python3 <skill_dir>/scripts/start_issue_branch.py <issue_number> [--base-branch <base_branch>] [--branch-slug <branch_slug>] [--worktree-path <worktree_path>]

    review_base defaults to integration_branch in integration mode and origin/<base_branch> otherwise. Preserve any initialized five-field progress file.

  3. Inspect relevant code, callers, existing patterns, and tests. Select the public behavior seam and smallest meaningful validation; do not add implementation-detail tests when no useful seam exists. Implement only the issue.
  4. Inspect the complete diff and run the path guard, which includes untracked files:

    git status --short
    git diff --stat
    git diff
    python3 <skill_dir>/scripts/diff_guard.py --base <review_base>

    Use git add -N for new files. Allow a blocked path only after tracing it to an explicit issue requirement or verified review blocker. Run the smallest relevant validation, commit inspected paths, and bind its command and result to validated_head=$(git rev-parse HEAD).

  5. Capture pre_review_head, then run $review-checkpoint with mode=fix_loop, review_base, and max_iterations; do not pass Shipyard's shared manifest from a child worktree. Return BLOCKED with its findings instead of treating it as PASS. Continue only after the latest completed review returns PASS with no later commit. If HEAD changed, rerun diff_guard.py and use the review fix's check evidence for the new validated_head; otherwise reuse Step 4 evidence.
  6. Finish according to mode.

Handoff

In pull-request mode, after PASS, invoke nested $pr-launchpad with validated_head and its validation commands/results, then return only the PR URL.

In integration mode, pass inspected facts to the helper; it writes the canonical .context/integration-handoff.json through Shipyard's manifest interface:

# PASS
python3 <skill_dir>/scripts/integration_child.py finish --review-base <review_base> --review PASS --check "<cmd>" --known-skip "<reason>"

# defect owned by another child
python3 <skill_dir>/scripts/integration_child.py finish --review-base <review_base> --review FAIL --needs-child-fix '#123'

Return only the helper's absolute path; never reconstruct, copy, or extend its payload or choose a Shipyard child status.

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.