Skip to content

AGENTS.md

Latest commit

 

History

History
145 lines (99 loc) · 4.48 KB

AGENTS.md

File metadata and controls

145 lines (99 loc) · 4.48 KB

Dotfiles Configuration

Summary

  • [project] dotfiles - Personal configuration files for Arch Linux with Hyprland #main
  • [type] Configuration Management #architecture
  • [stack] Dotter, ZSH, Neovim, Hyprland, Modern CLI tools #tech

Development Workflow

  • [workflow] Always use dotter tool for linking config from this repo! dotter manages these dotfiles project and we should be dog-fooding it as much as possible #tooling
  • [workflow] You can check and confirm changes before deployment with dotter -v -d or even with -vv for more verbosity #tooling

Documentation

@docs/README.md

Issue Tracking with bd (beads)

IMPORTANT: This project uses bd (beads) for ALL issue tracking. Do NOT use markdown TODOs, task lists, or other tracking methods.

Why bd?

  • Dependency-aware: Track blockers and relationships between issues
  • Git-friendly: Dolt-powered version control with native sync
  • Agent-optimized: JSON output, ready work detection, discovered-from links
  • Prevents duplicate tracking systems and confusion

Quick Start

Check for ready work:

bd ready --json

Create new issues:

bd create "Issue title" --description="Detailed context" -t bug|feature|task -p 0-4 --json
bd create "Issue title" --description="What this issue is about" -p 1 --deps discovered-from:bd-123 --json

Claim and update:

bd update <id> --claim --json
bd update bd-42 --priority 1 --json

Complete work:

bd close bd-42 --reason "Completed" --json

Issue Types

  • bug - Something broken
  • feature - New functionality
  • task - Work item (tests, docs, refactoring)
  • epic - Large feature with subtasks
  • chore - Maintenance (dependencies, tooling)

Priorities

  • 0 - Critical (security, data loss, broken builds)
  • 1 - High (major features, important bugs)
  • 2 - Medium (default, nice-to-have)
  • 3 - Low (polish, optimization)
  • 4 - Backlog (future ideas)

Workflow for AI Agents

  1. Check ready work: bd ready shows unblocked issues
  2. Claim your task atomically: bd update <id> --claim
  3. Work on it: Implement, test, document
  4. Discover new work? Create linked issue:
    • bd create "Found bug" --description="Details about what was found" -p 1 --deps discovered-from:<parent-id>
  5. Complete: bd close <id> --reason "Done"

Quality

  • Use --acceptance and --design fields when creating issues
  • Use --validate to check description completeness

Lifecycle

  • bd defer <id> / bd supersede <id> for issue management
  • bd stale / bd orphans / bd lint for hygiene
  • bd human <id> to flag for human decisions
  • bd formula list / bd mol pour <name> for structured workflows

Auto-Sync

bd automatically syncs via Dolt:

  • Each write auto-commits to Dolt history
  • No manual export/import needed!

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/SYNC_CONCEPTS.md for details and anti-patterns.

Important Rules

  • ✅ Use bd for ALL task tracking
  • ✅ Always use --json flag for programmatic use
  • ✅ Link discovered work with discovered-from dependencies
  • ✅ Check bd ready before asking "what should I work on?"
  • ❌ Do NOT create markdown TODO lists
  • ❌ Do NOT use external issue trackers
  • ❌ Do NOT duplicate tracking systems

For more details, see README.md and docs/QUICKSTART.md.

Session Completion

When ending a work session, you MUST complete ALL steps below. Work is NOT complete until git push succeeds.

MANDATORY WORKFLOW:

  1. File issues for remaining work - Create issues 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. PUSH TO REMOTE - This is MANDATORY:

    git pull --rebase
git push
git status  # MUST show "up to date with origin"

  5. Clean up - Clear stashes, prune remote branches

  6. Verify - All changes committed AND pushed

  7. Hand off - Provide context for next session

CRITICAL RULES:

  • Work is NOT complete until git push succeeds
  • NEVER stop before pushing - that leaves work stranded locally
  • NEVER say "ready to push when you are" - YOU must push
  • If push fails, resolve and retry until it succeeds