refactor(dev): restructure Claude commands/skills directories
All checks were successful
CI / check (push) Successful in 3m16s

Correct terminology mismatch:
- Rename skills/ to commands/ (these are user-invokable commands)
- Create new skills/ for reference materials
- Move bd_workflow.md to skills/ (it's reference material)
- Add micro-skills and formulas directories
- Update default.nix to install both commands and skills

Commands → ~/.claude/commands/ (invokable as /command-name)
Skills → ~/.claude/commands/skills/ (reference materials)
Formulas → ~/.beads/formulas/ (workflow templates)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
2026-01-15 17:16:55 -08:00
parent f472aa9b3d
commit 7903b2dfd0
17 changed files with 632 additions and 7 deletions

View File

@@ -0,0 +1,123 @@
---
description: How to structure research and plan artifacts in thoughts/
---
# Artifact Format
Standardized format for thoughts/ artifacts. All beads-related artifacts should follow these conventions for consistency and machine parseability.
## Frontmatter (Required)
Every artifact MUST include YAML frontmatter:
```yaml
---
date: 2026-01-15T10:00:00-08:00 # ISO 8601 with timezone
bead_id: project-abc # Bead identifier
bead_title: "Title of the bead" # Human-readable title
author: claude # Who created this
git_commit: abc123def # Commit hash at creation
branch: main # Branch name
repository: repo-name # Repository name
status: draft|complete # Artifact status
---
```
### Gathering Metadata
```bash
git rev-parse HEAD # Current commit
git branch --show-current # Current branch
basename $(git rev-parse --show-toplevel) # Repo name
date -Iseconds # ISO timestamp
```
## Research Artifact Structure
Location: `thoughts/beads-{bead-id}/research.md`
```markdown
# Research: {bead title}
**Bead**: {bead-id}
**Date**: {timestamp}
**Git Commit**: {commit hash}
## Research Question
{Original question from bead description}
## Summary
{2-3 sentence overview answering the research question}
## Key Discoveries
- {Finding with file:line reference}
- {Pattern or convention found}
- {Architectural decision documented}
## Architecture
{Current patterns and conventions in the codebase}
## Code References
- `path/to/file.py:123` - Description of relevance
- `another/file.ts:45-67` - Description of relevance
## Open Questions
{Areas needing further investigation or human clarification}
```
## Plan Artifact Structure
Location: `thoughts/beads-{bead-id}/plan.md`
```markdown
# {Title} Implementation Plan
## Overview
{What we're implementing and why - 1-2 sentences}
## Current State
{What exists now, key constraints discovered}
### Key Discoveries
- {Finding with file:line reference}
- {Pattern to follow}
## Desired End State
{Specification of what success looks like}
## What We're NOT Doing
{Explicitly list out-of-scope items}
## Phase 1: {Descriptive Name}
### Overview
{What this phase accomplishes}
### Changes
- [ ] {Specific change with file path}
- [ ] {Another change}
### Success Criteria
#### Automated
- [ ] Tests pass: `{test command}`
- [ ] Lint passes: `{lint command}`
#### Manual
- [ ] {Human verification step}
## Phase 2: {Descriptive Name}
{Repeat structure...}
## References
- Bead: {bead-id}
- Research: `thoughts/beads-{bead-id}/research.md`
```
## Key Principles
1. **Always include file:line references** - Makes artifacts actionable
2. **Separate automated vs manual verification** - Enables agent autonomy
3. **Use checkboxes for phases** - Enables resumability after interruption
4. **Keep frontmatter machine-parseable** - Enables tooling integration
5. **Link related artifacts** - Research links to plan, plan links to bead

View File

@@ -0,0 +1,121 @@
---
description: How to create effective implementation plans with phased delivery and clear success criteria
---
# Planning
Create implementation plans that enable incremental, verifiable progress.
## Core Principles
1. **Incremental delivery**: Each phase should produce working, testable changes
2. **Clear checkpoints**: Success criteria that can be verified without ambiguity
3. **Buy-in before detail**: Confirm understanding and approach before writing specifics
4. **Explicit scope**: State what we're NOT doing to prevent scope creep
## Plan Document Structure
```markdown
# {Feature} Implementation Plan
## Overview
{1-2 sentences: what we're building and why}
## Current State Analysis
{What exists now, key constraints, file:line references}
## Desired End State
{Specification of outcome and how to verify it}
## What We're NOT Doing
{Explicit out-of-scope items}
## Phase 1: {Descriptive Name}
### Overview
{What this phase accomplishes - should be independently valuable}
### Changes Required
{Specific files and modifications with code snippets}
### Success Criteria
#### Automated Verification
- [ ] Tests pass: `{test command}`
- [ ] Lint passes: `{lint command}`
#### Manual Verification
- [ ] {Human-observable outcome}
## Testing Strategy
{Unit tests, integration tests, manual testing steps}
## References
{Links to research, related files, similar implementations}
```
## Phase Design
Good phases are:
- **Self-contained**: Completable in one session
- **Testable**: Has clear pass/fail criteria
- **Reversible**: Can be rolled back if needed
- **Incremental**: Builds on previous phases without requiring all phases
Bad phases are:
- "Refactor everything" (too broad)
- "Add helper function" (too granular)
- Phases that only work if ALL phases complete
## Success Criteria Guidelines
**Automated Verification** (agent-runnable):
- Test commands: `make test`, `npm test`, `nix flake check`
- Lint/format: `make lint`, `cargo fmt --check`
- Type checking: `make typecheck`, `tsc --noEmit`
- Build verification: `make build`, `nix build`
**Manual Verification** (requires human):
- UI/UX functionality and appearance
- Performance under realistic conditions
- Edge cases hard to automate
- Integration with external systems
**From Contribution Guidelines** (if CONTRIBUTING.md exists):
- Include any testing requirements specified
- Reference the guideline: "Per CONTRIBUTING.md: {requirement}"
## Presenting Understanding
Before writing the plan, confirm alignment:
```
Based on the requirements and my research, I understand we need to [summary].
I've found that:
- [Current implementation detail with file:line]
- [Relevant pattern or constraint]
- [Potential complexity identified]
Questions my research couldn't answer:
- [Specific technical question requiring judgment]
```
Only ask questions you genuinely cannot answer through code investigation.
## Design Options Pattern
When multiple approaches exist:
```
**Design Options:**
1. [Option A] - [1-sentence description]
- Pro: [benefit]
- Con: [drawback]
2. [Option B] - [1-sentence description]
- Pro: [benefit]
- Con: [drawback]
Which approach aligns best with [relevant consideration]?
```
Get buy-in on approach before detailing phases.

View File

@@ -0,0 +1,68 @@
---
description: How to write comprehensive PR descriptions that help reviewers understand changes
---
# PR Description
Write PR descriptions that help reviewers understand what changed and why.
## Structure
Use this standard structure for PR descriptions:
```markdown
## Summary
<1-3 bullet points of what changed and why>
## Context
<Why this change was needed - the problem being solved>
<Link to related issues/tickets>
## Changes
<Detailed breakdown by area/component>
- Area 1: What changed and why
- Area 2: What changed and why
## Testing
<How this was verified>
- Automated: Tests added/updated, CI status
- Manual: Steps to verify functionality
## Screenshots (if UI changes)
<Before/after screenshots if applicable>
```
## Guidelines
### Lead with WHY, not WHAT
- The diff shows WHAT changed - your description explains WHY
- Start with the problem being solved
- Explain the approach chosen and alternatives considered
### Link to context
- Reference related issues: `Fixes #123` or `Relates to #456`
- Link to design docs or discussions
- Mention dependent PRs if any
### Call out review areas
- Highlight areas needing careful review
- Note any tricky or non-obvious code
- Point out architectural decisions
### Note breaking changes prominently
- Use a dedicated "Breaking Changes" section if applicable
- Explain migration path for consumers
- List any deprecations
### Be scannable
- Use bullet points over paragraphs
- Keep sections focused and concise
- Put the most important info first
## Anti-patterns to Avoid
- Empty descriptions or just "fixes bug"
- Repeating the commit messages verbatim
- Including irrelevant implementation details
- Missing context on why the change was made
- Forgetting to mention breaking changes

View File

@@ -0,0 +1,49 @@
---
description: How to spawn and coordinate research sub-agents
---
# Research Agents
Use parallel sub-agents for efficient codebase research.
## Available Agents
| Agent | Purpose |
|-------|---------|
| codebase-locator | Find WHERE files and components live |
| codebase-analyzer | Understand HOW specific code works |
| codebase-pattern-finder | Find examples of existing patterns |
| thoughts-locator | Discover relevant documents in thoughts/ |
## Spawning Protocol
1. **Decompose** - Break the research question into 3-5 specific questions
2. **Spawn parallel** - Use one Task call with multiple agents
3. **Be specific** - Include directories and file patterns in prompts
4. **Wait for all** - Do not synthesize until ALL agents complete
5. **Synthesize** - Combine findings into coherent summary with file:line references
## Example
```
Task(codebase-locator, "Find all files related to authentication in src/")
Task(codebase-analyzer, "Explain how JWT tokens are validated in src/auth/")
Task(codebase-pattern-finder, "Find examples of middleware patterns in src/")
Task(thoughts-locator, "Find documents about auth design decisions in thoughts/")
```
## Key Principles
- **Parallel when different** - Run agents in parallel when searching for different things
- **WHAT not HOW** - Each agent knows its job; tell it what you need, not how to search
- **Document, don't evaluate** - Agents should describe what exists, not critique it
- **Specific directories** - Always scope searches to relevant directories
- **File references** - Include specific file:line references in synthesis
## Agent Prompts
When spawning agents, include:
- The specific question or goal
- Relevant directories to search
- Reminder to document (not evaluate) what they find
- Request for file:line references in findings