agentleFS
helderbertohelderberto/agent-skills/skills/guide/SKILL.md

guide

Skill19 starsChanged 32 days agoMITView on GitHub

Explain which hb skill or flow fits your situation, from a map of how the skills fit together.

  • Commits and pushes

20 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use brainstorm, plan and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • nicolasestremSkill

    brainstorm

    Structured idea generation and solution exploration with systematic analysis.

    Also in 3 projects that use this

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 3 projects that use this

  • Hugging FaceSkill

    implement

    Make tests pass. Invoke after /write-tests produces failing tests.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 15 edited versions we read keep these.

  • 1

    Distinctive

    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:

    Keep steps 2–4 in one unbroken context window, so the grill, the spec, and the tickets build on the same thinking.

    line 31
  2. Distinctive:

    Every move but Continue replaces the session with a summary of it, so rule Continue out first.

    line 84

“Common” is measured: kept by at least 6 in 10 of the 15 edited versions of this file we could read. “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

Guide

You don't remember every skill, so ask. Map $ARGUMENTS (empty → ask what the user is trying to do) to the skill or flow that fits, and end on one filled-in Next: line. Before you state what a skill does or recommend skipping one, read its SKILL.md: this map is orientation only.

The map

A flow is a path through the skills. Most work runs along the main flow; on-ramps merge onto it. Everything else is standalone, or a vocabulary layer underneath.

Main flow: idea → PR

  1. /hb:setup, once per repo, picks where specs and tickets live: local markdown in .specs/ (the default, no setup needed), GitHub, or Jira. Rerun to switch.
  2. /hb:triage classifies the input, sizes it, and names the entry. S work skips to /hb:build; M work with a crisp ticket skips to /hb:to-tickets.
  3. /hb:grill sharpens the idea by interview, in rounds over the design-tree frontier. It writes settled terms to GLOSSARY.md (via domain-modeling) and hard-to-reverse decisions to ADRs (via to-adr) as they land.
    • A question needs a runnable answer? A state model, business logic, a UI you have to see → detour through /hb:prototype, kept on a prototype/<name> branch, then back to the grill with what you learned.
  4. /hb:to-spec turns the settled conversation into a spec in the configured tracker. No interview: an open branch sends you back to /hb:grill.
  5. /hb:to-tickets slices the spec into tracer-bullet tickets in the configured tracker, each with blocking edges. Only exceptions get a hitl label.
  6. /hb:build implements the next unblocked ticket test-first through tdd, runs check, and commits. --all fans the tickets out to parallel implementer subagents, frontier by frontier, after one approval, and stops before each hitl one.
  7. /hb:review fans out parallel reviewers: correctness, standards, spec conformance with ticket checkboxes, test effectiveness with changed-line coverage, the quality bar, and the audits the diff calls for.
  8. /hb:to-pr publishes the PR: gate, an optional --safe secret scan, push, PR body with evidence and merge danger, gh pr create, CI watch. A library then runs /hb:to-release on it: version, changelog, draft release for review; rerun after the merge to tag and publish.
  9. /hb:retro closes the loop. It suggests changes to the agent's environment, not the code: navigation pointers, checks, coding standards, steering files. Mechanical mistakes become checks; judgement calls become standards.

Context hygiene

Keep steps 2–4 in one unbroken context window, so the grill, the spec, and the tickets build on the same thinking. Each /hb:build can start fresh from its ticket: the ticket is self-contained. Run /hb:retro in the session it looks back on, before /clear.

Past the window where the model still reasons sharply (~150k tokens), don't push on degraded: /compact at the nearest phase boundary.

On-ramps

  • Something's broken, flaky, or slow → /hb:debug. It builds a feedback loop that goes red on this bug before any theory, then fixes with a regression test. Then /hb:retro asks what would have prevented it; a missing seam becomes an /hb:architecture-audit run.
  • Review comments piling up on your PR → /hb:feedback sorts them into Address / Skip / Optional / Discuss, then fixes the Address items test-first.
  • A PR too big to review → /hb:to-stack rebuilds it as a stack of small PRs, each on the one below, verified layer by layer, and opens them with linked bodies.
  • Someone else's PR → /hb:code-review <PR>: quality and spec, side by side. /hb:review <PR> for the full panel.
  • Unsure a risky change is worth it — a PR, a branch, a plan → /hb:debate: advocate, skeptic, and neutral investigator argue it over two rounds, then one recommendation.
  • Existing code that needs tests, splitting, or simplifying → /hb:refactor, behavior frozen.

Codebase health

  • /hb:architecture-audit surfaces deepening opportunities in git hot spots. A picked candidate becomes an improvement PRD you slice with /hb:to-tickets, or an idea for /hb:grill.

Vocabulary underneath

Model skills that other skills pull in. Reach for them directly in plain words when the words, not the process, are the problem.

  • domain-modeling — the project's domain language in GLOSSARY.md: challenge a fuzzy term, split an overloaded word.
  • codebase-design — the deep-module vocabulary (module, interface, depth, seam, adapter, leverage, locality) for a module's shape.

Standalone

  • /hb:zoom-out — explain code with an analogy and a diagram.
  • /hb:research — a background agent reads primary sources and leaves a cited file in .specs/research/. Feed it into /hb:grill.
  • /hb:check — lint, types, tests; --check writes nothing.
  • /hb:commit — atomic commits by concern, never a push.
  • /hb:safe-repo — check a repo for secrets and sensitive data.
  • /hb:deps-audit — dependency CVEs and staleness.
  • /hb:a11y-audit — WCAG accessibility audit of frontend code.
  • /hb:i18n — hardcoded strings and translation coverage.
  • /hb:to-adr — record one architectural decision.
  • /hb:revise — restructure a draft or polish prose.
  • /hb:to-doc — turn an investigation, data, or a decision into a doc on Confluence, a GitHub issue, or Markdown; --one-pager for a five-minute read, --adr for a decision record.
  • /hb:create-skill — author a new skill.
  • /hb:handoff — a portable doc for a new harness, directory, or colleague.
  • /hb:wait-what — the last message didn't land; re-pitch it plainly in glossary terms.
  • /hb:teach — learn a concept over multiple sessions in a stateful workspace.
  • Model skills route themselves from plain words: test-first work (tdd), official-docs implementation (source-driven), UI construction (frontend-ui-engineering), bundle size, trust boundaries, a visual diff report, a browser check.

Phase boundaries

Decide at a boundary, never mid-phase: mid-phase, continue or split the rest into subagents. Work top to bottom; the first yes wins.

  1. Continue — the next phase needs this one as a primary source, or there's room left in the context window.
  2. /clear — nothing here matters to what's next.
  3. /hb:handoff — only for a new harness, a new directory, a colleague, or a side task found mid-phase.
  4. Subagent — the task can run AFK, like an automated review.
  5. /compact with an instruction (/compact we're going to QA this area).

Every move but Continue replaces the session with a summary of it, so rule Continue out first.

Next: /hb:<cmd> <args> for the skill that fits.

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.