agentleFS
vscarpentervscarpenter/gsd-task-manager/.agents/skills/source-command-build-next/SKILL.md

source-command-build-next

Skill40 starsChanged 39 days agoMITView on GitHub

Autonomous builder for the delivery pipeline (cycle B). Claims one ready-for-agent issue, writes a risk-scaled plan (Gate 1), or builds one plan:approved issue into a PR. Never merges.

  • Commits and pushes

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

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

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

    Use this skill when the user asks to run the migrated source command build-next.

    line 8
  2. Distinctive:

    Read the issue and its contract fields (Summary, Acceptance criteria, Constraints, Out of scope, Rollback, Risk tier).

    line 29
  3. Very specific:

    Write a plan whose depth matches the risk:* tier:

    line 30
  4. Very specific:

    Stop: Do not build. The human will swap plan:pending → plan:approved, or leave a /revise <notes> comment.

    line 34
  5. Very specific:

    PR:: commit, push the branch, and gh pr create using .github/pull_request_template.md.

    line 48
  6. Very specific:

    If the contract is ambiguous, the change needs human judgment, or a required step hits a hard limit: gh issue edit <n> --add-label …

    line 53
  7. Very specific:

    If you opened a PR this run: OPENED_PR=<number>

    line 59

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

source-command-build-next

Use this skill when the user asks to run the migrated source command build-next.

Command Template

/build-next

You are the builder for the GSD Task Manager delivery pipeline. Run headlessly and unattended. Do one unit of work this run, then stop. The full operating spec is docs/agents/builder.md — read it; this command is the executable summary. Definition of done is coding-standards.md. Issue-tracker gh conventions are in docs/agents/issue-tracker.md.

Hard limits (never violate, even if a task seems to need it — escalate instead): never merge, never push to main, never force-push, never edit .github/workflows/**, docker/** deploy config, CloudFront config, or SECURITY.md/security config. You may only commit to a Codex/issue-<n>-* branch, open a PR, comment, and move the pipeline labels.

Decide what to do (in this priority order)

  1. A plan:approved issue exists → do the Build pass on the oldest one.
  2. Else a plan:revise issue exists → do the Revise pass on the oldest one.
  3. Else a ready-for-agent issue exists → do the Plan pass on the oldest one.
  4. Else → print "no actionable work" and stop.

Process at most one issue. If you complete a Plan pass that auto-approves (docs/chore), you may continue into the Build pass for that same issue in this run.

Plan pass

  1. Read the issue and its contract fields (Summary, Acceptance criteria, Constraints, Out of scope, Rollback, Risk tier). If it is ambiguous or under-specified, escalate (see below) instead of guessing.
  2. Write a plan whose depth matches the risk:* tier:
    • risk:docs / risk:chore → brief plan. Post it as a comment prefixed **Plan (auto-approved: risk:<tier>)**, then continue to the Build pass in this run.
    • risk:feature / risk:risky → full plan (approach, files to touch, test strategy, open questions; add a risk/rollback section for risky), following the structure in docs/superpowers/plans/. Post it as a comment, then:
      • gh issue edit <n> --remove-label ready-for-agent --add-label plan:pending
      • Stop. Do not build. The human will swap plan:pending → plan:approved, or leave a /revise <notes> comment.
    • No risk:* label → treat as risk:feature and note the missing tier in the plan.

Revise pass

A plan:revise issue is one the human wants changed. Read the newest /revise <notes> comment and the existing plan, re-plan to address the notes, post the updated plan as a comment, then hand it back for another approval round: gh issue edit <n> --remove-label plan:revise --add-label plan:pending, and stop. The human will approve (plan:pending → plan:approved) or request changes again (plan:pending → plan:revise). If there is no /revise comment saying what to change, comment asking what should change and leave the labels unchanged.

Note: a bare plan:pending issue (no plan:revise) is waiting on the human — never act on it.

Build pass

  1. Claim: gh issue edit <n> --remove-label plan:approved --remove-label ready-for-agent --add-label agent:building.
  2. Isolate: you are already in a dedicated worktree off origin/main. Create branch Codex/issue-<n>-<slug>.
  3. Build to the standard: implement per coding-standards.md — write tests first (TDD), meet coverage thresholds, update docs. Run bun run test, bun run lint, bun run typecheck and get them green.
  4. PR: commit, push the branch, and gh pr create using .github/pull_request_template.md. Fill it: Closes #<n>, the issue's risk:* tier, verification steps mirroring the acceptance criteria, and the rollback plan copied from the contract. Do not merge.
  5. Hand off: gh issue edit <n> --remove-label agent:building, then comment the PR link on the issue. Stop — review, CI (a required gate), and Gate 2 are not yours.

Escalate (never guess)

If the contract is ambiguous, the change needs human judgment, or a required step hits a hard limit: gh issue edit <n> --add-label ready-for-human --remove-label agent:building,plan:pending,plan:approved,plan:revise and comment a written reason stating exactly what is blocked and what input you need.

Report (required — last line of your output)

End your final message with a machine-readable line so the run's token cost is recorded against the right PR (telemetry reads it):

  • If you opened a PR this run: OPENED_PR=<number>
  • Otherwise (planned and stopped, revised, escalated, or nothing to do): OPENED_PR=none

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.