agentleFS
atgreenatgreen/hackinator/AGENTS.md

hackinator

AGENTS.md1 starsChanged 3 months agoMITView on GitHub

Hackinator skills guide technique; they do not grant permissions or outrank active system, user, host, or repository policy. - Continue autonomously on reversible, in-scope work when the goal is clear. Ask when a missing choice would materially change the result, or before destructive, externally visible, security-sensitive, or paid actions that lack authority. - An explicit request to implement a clear, bounded change supplies implementation intent; do not manufacture another approval gate. Commit, sync, and push only when active policy or…

  • Deletes or force-pushes
  • Commits and pushes

The file

Show its rules and text

We split this AGENTS.md into the rules it gives an agent

14 rules. About 0 are common, 5 are distinctive, and 9 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 9

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use subagents, worktrees, and independent reviewers when the host supports them and the benefit justifies the cost.

    line 14
  2. Very specific:

    Use bd for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists

    line 83
  3. Very specific:

    Run bd prime for detailed command reference and session close protocol

    line 84
  4. Very specific:

    Use bd remember for persistent knowledge — do NOT use MEMORY.md files

    line 85
  5. Very specific:

    Conservative (default): Use bd for task tracking. Do not run git commits, git pushes, or Dolt remote sync unless explicitly asked.

    line 93
  6. Very specific:

    Minimal: Keep tool instruction files as pointers to bd prime.

    line 94
  7. Distinctive:

    Team-maintainer: Only when the repository explicitly opts in, agents may close beads, run quality gates, commit, and push as part of …

    line 95
  8. Distinctive:

    File issues for remaining work: - Create beads for anything that needs follow-up

    line 101
  9. Distinctive:

    Do not commit or push without clear authority from the active profile or the current user request.

    line 119
  10. Distinctive:

    If a required sync or push is blocked, stop and report the exact command and error.

    line 120
  11. Very specific:

    Use Beads (bd) for durable task tracking in repositories that include it.

    line 126
  12. Very specific:

    Use bd for all task tracking.

    line 140
  13. Very specific:

    Run bd prime when Beads context is missing or stale.

    line 141
  14. Very specific:

    Keep persistent project memory in Beads via bd remember.

    line 142

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md 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
AGENTS.md

Agent Instructions

Authority and adaptation

Hackinator skills guide technique; they do not grant permissions or outrank active system, user, host, or repository policy.

  • Continue autonomously on reversible, in-scope work when the goal is clear. Ask when a missing choice would materially change the result, or before destructive, externally visible, security-sensitive, or paid actions that lack authority.
  • An explicit request to implement a clear, bounded change supplies implementation intent; do not manufacture another approval gate. Commit, sync, and push only when active policy or the user authorizes them.
  • Use subagents, worktrees, and independent reviewers when the host supports them and the benefit justifies the cost. Serial work, the current workspace, and adversarial self-review are valid fallbacks.
  • Match verification breadth to risk while working, then run fresh, relevant evidence before claiming success or landing a change.

This project uses bd (beads) for issue tracking. Run bd prime for full workflow context.

Architecture in one line: Issues live in a local Dolt database (.beads/dolt/); cross-machine sync uses bd dolt push/pull (a git-compatible protocol), stored under refs/dolt/data on your git remote — separate from refs/heads/* where your code lives. .beads/issues.jsonl is a passive export, not the wire protocol.

See sync-concepts for the one-screen overview and anti-patterns (don't treat JSONL as the source of truth; don't bd import during normal operation; don't reach for third-party Dolt hosting before trying the default).

Quick Reference

bd ready              # Find available work
bd show <id>          # View issue details
bd update <id> --claim  # Claim work atomically
bd close <id>         # Complete work
bd dolt push          # Push beads data to remote

Non-Interactive Shell Commands

ALWAYS use non-interactive flags with file operations to avoid hanging on confirmation prompts.

Shell commands like cp, mv, and rm may be aliased to include -i (interactive) mode on some systems, causing the agent to hang indefinitely waiting for y/n input.

Use these forms instead:

# Force overwrite without prompting
cp -f source dest           # NOT: cp source dest
mv -f source dest           # NOT: mv source dest
rm -f file                  # NOT: rm file

# For recursive operations
rm -rf directory            # NOT: rm -r directory
cp -rf source dest          # NOT: cp -r source dest

Other commands that may prompt:

  • scp - use -o BatchMode=yes for non-interactive
  • ssh - use -o BatchMode=yes to fail instead of prompting
  • apt-get - use -y flag
  • brew - use HOMEBREW_NO_AUTO_UPDATE=1 env var
<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:46cd31e7 -->

Beads Issue Tracker

This project uses bd (beads) for issue tracking. Run bd prime to see full workflow context and commands.

Quick Reference

bd ready              # Find available work
bd show <id>          # View issue details
bd update <id> --claim  # Claim work
bd close <id>         # Complete work

Rules

  • Use bd for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists
  • Run bd prime for detailed command reference and session close protocol
  • Use bd remember for persistent knowledge — do NOT use MEMORY.md files

Architecture in one line: issues live in a local Dolt DB; sync uses refs/dolt/data on your git remote; .beads/issues.jsonl is a passive export. See https://github.com/gastownhall/beads/blob/main/docs/core-concepts/sync-concepts.md for details and anti-patterns.

Agent Context Profiles

The managed Beads block is task-tracking guidance, not permission to override repository, user, or orchestrator instructions.

  • Conservative (default): Use bd for task tracking. Do not run git commits, git pushes, or Dolt remote sync unless explicitly asked. At handoff, report changed files, validation, and suggested next commands.
  • Minimal: Keep tool instruction files as pointers to bd prime; use the same conservative git policy unless active instructions say otherwise.
  • Team-maintainer: Only when the repository explicitly opts in, agents may close beads, run quality gates, commit, and push as part of session close. A current "do not commit" or "do not push" instruction still wins.

Session Completion

This protocol applies when ending a Beads implementation workflow. It is subordinate to explicit user, repository, and orchestrator instructions.

  1. File issues for remaining work - Create beads for anything that needs follow-up
  2. Run quality gates (if code changed) - Tests, linters, builds
  3. Update issue status - Close finished work, update in-progress items
  4. Handle git/sync by active profile:
    # Conservative/minimal/default: report status and proposed commands; wait for approval.
    git status
    
    # Team-maintainer opt-in only, unless current instructions forbid it:
    git pull --rebase
    bd dolt push
    git push
    git status
  5. Hand off - Summarize changes, validation, issue status, and any blocked sync/commit/push step

Critical rules:

  • Explicit user or orchestrator instructions override this Beads block.
  • Do not commit or push without clear authority from the active profile or the current user request.
  • If a required sync or push is blocked, stop and report the exact command and error.
<!-- END BEADS INTEGRATION --><!-- BEGIN BEADS CODEX SETUP: generated by bd setup codex -->

Beads Issue Tracker

Use Beads (bd) for durable task tracking in repositories that include it. Use the beads skill at .agents/skills/beads/SKILL.md (project install) or ~/.agents/skills/beads/SKILL.md (global install) for Beads workflow guidance, then use the bd CLI for issue operations.

Quick Reference

bd ready                # Find available work
bd show <id>            # View issue details
bd update <id> --claim  # Claim work
bd close <id>           # Complete work
bd prime                # Refresh Beads context

Rules

  • Use bd for all task tracking; do not create markdown TODO lists.
  • Run bd prime when Beads context is missing or stale. Codex 0.129.0+ can load Beads context automatically through native hooks; use /hooks to inspect or toggle them.
  • Keep persistent project memory in Beads via bd remember; do not create ad hoc memory files.

Architecture in one line: issues live in a local Dolt DB; sync uses refs/dolt/data on your git remote; .beads/issues.jsonl is a passive export. See https://github.com/gastownhall/beads/blob/main/docs/core-concepts/sync-concepts.md for details and anti-patterns.

<!-- END BEADS CODEX SETUP -->

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.

Reviews can't be read right now.

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.