Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions .claude/.beads/.gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
# Dolt database (managed by Dolt, not git)
dolt/
dolt-access.lock

# Runtime files
bd.sock
bd.sock.startlock
sync-state.json
last-touched

# Local version tracking (prevents upgrade notification spam after git ops)
.local_version

# Worktree redirect file (contains relative path to main repo's .beads/)
# Must not be committed as paths would be wrong in other clones
redirect

# Sync state (local-only, per-machine)
# These files are machine-specific and should not be shared across clones
.sync.lock
.jsonl.lock
sync_base.jsonl
export-state/

# Ephemeral store (SQLite - wisps/molecules, intentionally not versioned)
ephemeral.sqlite3
ephemeral.sqlite3-journal
ephemeral.sqlite3-wal
ephemeral.sqlite3-shm

# Legacy files (from pre-Dolt versions)
*.db
*.db?*
*.db-journal
*.db-wal
*.db-shm
db.sqlite
bd.db
daemon.lock
daemon.log
daemon-*.log.gz
daemon.pid
beads.base.jsonl
beads.base.meta.json
beads.left.jsonl
beads.left.meta.json
beads.right.jsonl
beads.right.meta.json

# NOTE: Do NOT add negation patterns (e.g., !issues.jsonl) here.
# They would override fork protection in .git/info/exclude, allowing
# contributors to accidentally commit upstream issue databases.
# The JSONL files (issues.jsonl, interactions.jsonl) and config files
# are tracked by git by default since no pattern above ignores them.

# at the moment, we're just using beads for local development, so don't commit any jsonl
interactions.jsonl
issues.jsonl
Comment on lines +50 to +58
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Resolve contradictory guidance about JSONL tracking.

Lines 50-54 state JSONL files are tracked by default, but Lines 57-58 ignore them. Update the note so behavior and documentation match.

Suggested patch
-# NOTE: Do NOT add negation patterns (e.g., !issues.jsonl) here.
-# They would override fork protection in .git/info/exclude, allowing
-# contributors to accidentally commit upstream issue databases.
-# The JSONL files (issues.jsonl, interactions.jsonl) and config files
-# are tracked by git by default since no pattern above ignores them.
+# NOTE: Do NOT add negation patterns (e.g., !issues.jsonl) here.
+# They would override fork protection in .git/info/exclude, allowing
+# contributors to accidentally commit upstream issue databases.
+# This repository intentionally ignores local JSONL data below.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.claude/.beads/.gitignore around lines 50 - 58, The comment and patterns
contradict each other: the NOTE block claims JSONL files are tracked by default,
but the .gitignore lists interactions.jsonl and issues.jsonl; update the NOTE
text so it accurately reflects the repo behavior (e.g., state that JSONL files
are intentionally ignored for local development and should not be
tracked/committed), and ensure the explanatory paragraph references the actual
ignored filenames (interactions.jsonl and issues.jsonl) and the reason for
ignoring them rather than claiming they are tracked by default.

backup/
issues-dump.jsonl
44 changes: 44 additions & 0 deletions .claude/.beads/config.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# Beads Configuration File
# This file configures default behavior for all bd commands in this repository
# All settings can also be set via environment variables (BD_* prefix)
# or overridden with command-line flags

# Issue prefix for this repository (used by bd init)
# If not set, bd init will auto-detect from directory name
# Example: issue-prefix: "myproject" creates issues like "myproject-1", "myproject-2", etc.
# issue-prefix: ""

# Use no-db mode: load from JSONL, write back after each command
# When true, bd will use .beads/issues.jsonl as the source of truth
# instead of the Dolt database
# no-db: false

# Enable JSON output by default
# json: false

# Default actor for audit trails (overridden by BD_ACTOR or --actor)
# actor: ""

# Export events (audit trail) to .beads/events.jsonl on each flush/sync
# When enabled, new events are appended incrementally using a high-water mark.
# Use 'bd export --events' to trigger manually regardless of this setting.
# events-export: false

# Multi-repo configuration (experimental - bd-307)
# Allows hydrating from multiple repositories and routing writes to the correct JSONL
# repos:
# primary: "." # Primary repo (where this database lives)
# additional: # Additional repos to hydrate from (read-only)
# - ~/beads-planning # Personal planning repo
# - ~/work-planning # Work planning repo

# Integration settings (access with 'bd config get/set')
# These are stored in the database, not in this file:
# - jira.url
# - jira.project
# - linear.url
# - linear.api-key
# - github.org
# - github.repo
no-git-ops: true
backup.enabled: false # in v0.57 the backup seems to automatically add stage the files into git, bypassing the .gitignore I tried to set up, so disabling for now (also we don't really need backup anyway if we're not pushing into git, but this would be nicer long term than having to run the export command manually all the time)
8 changes: 8 additions & 0 deletions .claude/.beads/metadata.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
{
"database": "dolt",
"jsonl_export": "issues.jsonl",
"backend": "dolt",
"dolt_mode": "server",
"dolt_server_host": "beads-dolt",
"dolt_database": "beads_work"
}
167 changes: 167 additions & 0 deletions .claude/commands/add-command.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,167 @@
---
description: Guide for creating new slash commands
argument-hint: <command-name> <description>
---

## General Guidelines

### Output Style

- **Never explicitly mention TDD** in code, comments, commits, PRs, or issues
- Write natural, descriptive code without meta-commentary about the development process
- The code should speak for itself - TDD is the process, not the product

Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).

## Plan File Restriction

**NEVER create, read, or update plan.md files.** Claude Code's internal planning files are disabled for this project. Use other methods to track implementation progress (e.g., comments, todo lists, or external tools).

# Slash Command Creator Guide
Comment on lines +6 to +20
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Fix heading order to satisfy markdownlint MD041.

Line 6 starts with an H2 before the first H1 (Line 20), which triggers first-line-heading. Put the H1 first after frontmatter.

Suggested patch
-## General Guidelines
+# Slash Command Creator Guide
+
+## General Guidelines
@@
-# Slash Command Creator Guide
-
 ## How This Command Works
🧰 Tools
🪛 markdownlint-cli2 (0.21.0)

[warning] 6-6: First line in a file should be a top-level heading

(MD041, first-line-heading, first-line-h1)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.claude/commands/add-command.md around lines 6 - 20, The Markdown violates
markdownlint MD041 because an H2 ("## General Guidelines") appears before the
first H1 ("# Slash Command Creator Guide"); reorder the headings so the first
visible heading after any frontmatter is the H1 by moving "# Slash Command
Creator Guide" above "## General Guidelines" (ensure the H1 is the first
top-level heading and retain the existing content and heading hierarchy).


## How This Command Works

The `/add-command` command shows this guide for creating new slash commands. It includes:

- Command structure and syntax
- Common patterns and examples
- Security restrictions and limitations
- Frontmatter options

**Note for AI**: When creating commands, you CAN use bash tools like `Bash(mkdir:*)`, `Bash(ls:*)`, `Bash(git status:*)` in the `allowed-tools` frontmatter of NEW commands - but ONLY for operations within the current project directory. This command itself doesn't need bash tools since it's just documentation.

## Command Locations

- **Personal**: `~/.claude/commands/` (available across all projects)
- **Project**: `.claude/commands/` (shared with team, shows "(project)")

## Basic Structure

```markdown
---
allowed-tools: Read, Glob, Grep, Bash(git status:*), Task
description: Brief description of what this command does
argument-hint: [required-arg] [optional-arg]
---

# Command Title

Your command instructions here.

**User arguments:**

Add-command: $ARGUMENTS

**End of user arguments**

File reference: @path/to/file.js

Bash command output: (exclamation)git status(backticks)
```

## ⚠️ Security Restrictions

**Bash Commands (exclamation prefix)**: Limited to current working directory only.

- ✅ Works: `! + backtick + git status + backtick` (in project dir)
- ❌ Blocked: `! + backtick + ls /outside/project + backtick` (outside project)
- ❌ Blocked: `! + backtick + pwd + backtick` (if referencing dirs outside project)

**File References (`@` prefix)**: No directory restrictions.

- ✅ Works: `@/path/to/system/file.md`
- ✅ Works: `@../other-project/file.js`

## Common Patterns

### Simple Command

```bash
echo "Review this code for bugs and suggest fixes" > ~/.claude/commands/review.md
```

### Command with Arguments

**Note for AI**: The example below uses a fullwidth dollar sign ($, U+FF04) to prevent interpolation in this documentation. When creating actual commands, use the regular `$` character.

```markdown
Fix issue $ARGUMENTS following our coding standards
```

### Command with File References

```markdown
Compare @src/old.js with @src/new.js and explain differences
```

### Command with Bash Output (Project Directory Only)

```markdown
---
allowed-tools: Bash(git status:*), Bash(git branch:*), Bash(git log:*)
---
Current status: (!)git status(`)
Current branch: (!)git branch --show-current(`)
Recent commits: (!)git log --oneline -5(`)

Create commit for these changes.
```

**Note**: Only works with commands in the current project directory.

### Namespaced Command

**Note for AI**: The example below uses a fullwidth dollar sign ($, U+FF04) to prevent interpolation in this documentation. When creating actual commands, use the regular `$` character.

```bash
mkdir -p ~/.claude/commands/ai
echo "Ask GPT-5 about: $ARGUMENTS" > ~/.claude/commands/ai/gpt5.md
# Creates: /ai:gpt5
```

## Frontmatter Options

- `allowed-tools`: Tools this command can use
- **Important**: Intrusive tools like `Write`, `Edit`, `NotebookEdit` should NEVER be allowed in commands unless the user explicitly requests them. These tools modify files and should only be used when the command's purpose is to make changes.
- ✅ Safe for most commands: `Read`, `Glob`, `Grep`, `Bash(git status:*)`, `Task`, `AskUserQuestion`
- `description`: Brief description (shows in /help)
- `argument-hint`: Help text for arguments
- `model`: Specific model to use

## Best Practices

### Safe Commands (No Security Issues)

```markdown
# System prompt editor (file reference only)
(@)path/to/system/prompt.md

Edit your system prompt above.
```

### Project-Specific Commands (Bash OK)

```markdown
---
allowed-tools: Bash(git status:*), Bash(npm list:*)
---
Current git status: (!)git status(`)
Package info: (!)npm list --depth=0(`)

Review project state and suggest next steps.
```

### Cross-Directory File Access (Use @ not !)

```markdown
# Compare config files
Compare (@)path/to/system.md with (@)project/config.md

Show differences and suggest improvements.
```

## Usage

After creating: `/<command-name> [arguments]`

Example: `/review` or `/ai:gpt5 "explain this code"`
57 changes: 57 additions & 0 deletions .claude/commands/commit.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---
description: Create a git commit following project standards
argument-hint: [optional-commit-description]
---

## General Guidelines
Comment on lines +1 to +6
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Add a top-level heading to satisfy markdownlint MD041.

The current file starts with frontmatter and then jumps to ##. Add an H1 immediately after frontmatter.

Proposed fix
 ---
 description: Create a git commit following project standards
 argument-hint: [optional-commit-description]
 ---
 
+# Commit Command
+
 ## General Guidelines
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
---
description: Create a git commit following project standards
argument-hint: [optional-commit-description]
---
## General Guidelines
---
description: Create a git commit following project standards
argument-hint: [optional-commit-description]
---
# Commit Command
## General Guidelines
🧰 Tools
🪛 markdownlint-cli2 (0.21.0)

[warning] 6-6: First line in a file should be a top-level heading

(MD041, first-line-heading, first-line-h1)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.claude/commands/commit.md around lines 1 - 6, Add a top-level H1 heading
immediately after the YAML frontmatter to satisfy markdownlint MD041: insert a
single line like "# Commit" (or a project-appropriate H1 title) directly
following the existing frontmatter block so the document no longer jumps
straight to "## General Guidelines" — update the file
".claude/commands/commit.md" by adding that H1 header.


### Output Style

- **Never explicitly mention TDD** in code, comments, commits, PRs, or issues
- Write natural, descriptive code without meta-commentary about the development process
- The code should speak for itself - TDD is the process, not the product

Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).

## Plan File Restriction

**NEVER create, read, or update plan.md files.** Claude Code's internal planning files are disabled for this project. Use other methods to track implementation progress (e.g., comments, todo lists, or external tools).

Create a git commit following project standards

**User arguments:**

Commit: $ARGUMENTS

**End of user arguments**

## Commit Message Rules

Follows [Conventional Commits](https://www.conventionalcommits.org/) standard.

1. **Format**: `type(#issue): description`
- Use `#123` for local repo issues
- Use `owner/repo#123` for cross-repo issues
- Common types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`

2. **AI Credits**: **NEVER include AI credits in commit messages**
- No "Generated with Claude Code"
- No "Co-Authored-By: Claude" or "Co-Authored-By: Happy"
- Focus on the actual changes made, not conversation history

3. **Content**: Write clear, concise commit messages describing what changed and why

## Process

1. Run `git status` and `git diff` to review changes
2. Run `git log --oneline -5` to see recent commit style
3. Stage relevant files with `git add`
4. Create commit with descriptive message
5. Verify with `git status`

## Example

```bash
git add <files>
git commit -m "feat(#123): add validation to user input form"
```
Loading
Loading