Autonomy facet

.ade/skills/adr-nygard/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: adr-nygard
+description: Architecture Decision Records following Nygard's lightweight template
+---
+
+# Architecture Decision Records (Nygard)
+
+## When to Write an ADR
+
+- When making a significant architectural decision
+- When choosing between multiple viable options
+- When the decision will be hard to reverse
+- When future developers will ask "why did we do this?"
+
+## Template
+
+Store ADRs in `docs/adr/` as numbered markdown files: `NNNN-title-with-dashes.md`
+
+```markdown
+# N. Title
+
+## Status
+
+Proposed | Accepted | Deprecated | Superseded by [ADR-NNNN]
+
+## Context
+
+What is the issue that we're seeing that is motivating this decision or change?
+
+## Decision
+
+What is the change that we're proposing and/or doing?
+
+## Consequences
+
+What becomes easier or more difficult to do because of this change?
+```
+
+## Rules
+
+- ADRs are immutable once accepted — supersede, don't edit
+- Keep context focused on forces at play at the time of the decision
+- Write consequences as both positive and negative impacts
+- Number sequentially, never reuse numbers
+- Title should be a short noun phrase (e.g. "Use PostgreSQL for persistence")

.ade/skills/conventional-commits/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: conventional-commits
+description: Conventional Commits specification for structured commit messages
+---
+
+# Conventional Commits
+
+## Format
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+## Types
+
+- `feat`: A new feature (correlates with MINOR in SemVer)
+- `fix`: A bug fix (correlates with PATCH in SemVer)
+- `docs`: Documentation only changes
+- `style`: Changes that do not affect the meaning of the code
+- `refactor`: A code change that neither fixes a bug nor adds a feature
+- `perf`: A code change that improves performance
+- `test`: Adding missing tests or correcting existing tests
+- `chore`: Changes to the build process or auxiliary tools
+
+## Rules
+
+- Subject line must not exceed 72 characters
+- Use imperative mood in the subject line ("add" not "added")
+- Do not end the subject line with a period
+- Separate subject from body with a blank line
+- Use the body to explain what and why, not how
+- `BREAKING CHANGE:` footer or `!` after type/scope for breaking changes

.ade/skills/tanstack-architecture/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: tanstack-architecture
+description: Architecture conventions for TanStack applications
+---
+
+# TanStack Architecture Conventions
+
+## Project Structure
+
+- Use file-based routing with TanStack Router (`routes/` directory)
+- Colocate route components with their loaders and actions
+- Organize by feature, not by type (e.g. `features/auth/`, not `components/auth/`)
+
+## Data Flow
+
+- Use TanStack Query for all server state management
+- Use TanStack Router loaders for route-level data requirements
+- Keep client state minimal — prefer server state via Query
+- Use `queryOptions()` factory pattern for reusable query definitions
+
+## Module Boundaries
+
+- Each feature exports a public API via `index.ts`
+- Features must not import from other features' internals
+- Shared code goes in `lib/` or `shared/`

.ade/skills/tanstack-code/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: tanstack-code
+description: Code style conventions for TanStack applications
+---
+
+# TanStack Code Conventions
+
+## TypeScript
+
+- Enable strict mode in tsconfig
+- Infer types from TanStack APIs rather than writing manual type annotations
+- Use `satisfies` operator for type-safe object literals
+
+## Naming
+
+- Query keys: `['entity', ...params]` (e.g. `['user', userId]`)
+- Query option factories: `entityQueryOptions` (e.g. `userQueryOptions`)
+- Route files: `$param` for dynamic segments (e.g. `users/$userId.tsx`)
+- Loaders: export as named `loader` from route file
+
+## Imports
+
+- Import from `@tanstack/react-query`, `@tanstack/react-router`, etc.
+- Never import internal modules from TanStack packages
+- Use path aliases for project imports (`@/features/...`)

.ade/skills/tanstack-design/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: tanstack-design
+description: Design patterns for TanStack applications
+---
+
+# TanStack Design Patterns
+
+## Query Patterns
+
+- Define query options as standalone functions: `export const userQueryOptions = (id: string) => queryOptions({ queryKey: ['user', id], queryFn: () => fetchUser(id) })`
+- Use `useSuspenseQuery` in route components paired with `loader` for prefetching
+- Use `useMutation` with `onSettled` for cache invalidation
+
+## Router Patterns
+
+- Define routes using `createFileRoute` for type-safe file-based routing
+- Use `beforeLoad` for auth guards and redirects
+- Use search params validation with `zodSearchValidator` for type-safe URL state
+
+## Form Patterns
+
+- Use TanStack Form with Zod validators for form state and validation
+- Prefer field-level validation over form-level where possible
+- Connect form submission to `useMutation` for server sync

.ade/skills/tanstack-testing/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: tanstack-testing
+description: Testing conventions for TanStack applications
+---
+
+# TanStack Testing Conventions
+
+## Query Testing
+
+- Wrap components in `QueryClientProvider` with a fresh `QueryClient` per test
+- Use `@testing-library/react` with `renderHook` for testing custom query hooks
+- Mock at the network level with MSW, not at the query level
+
+## Router Testing
+
+- Use `createMemoryHistory` and `createRouter` for route testing
+- Test route loaders independently as plain async functions
+- Test search param validation with unit tests on the validator schema
+
+## Integration Tests
+
+- Test full user flows through route transitions
+- Assert on visible UI state, not internal query cache state
+- Use `waitFor` for async query resolution in component tests

.agentskills/skills/adr-nygard/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: adr-nygard
+description: Architecture Decision Records following Nygard's lightweight template
+---
+
+# Architecture Decision Records (Nygard)
+
+## When to Write an ADR
+
+- When making a significant architectural decision
+- When choosing between multiple viable options
+- When the decision will be hard to reverse
+- When future developers will ask "why did we do this?"
+
+## Template
+
+Store ADRs in `docs/adr/` as numbered markdown files: `NNNN-title-with-dashes.md`
+
+```markdown
+# N. Title
+
+## Status
+
+Proposed | Accepted | Deprecated | Superseded by [ADR-NNNN]
+
+## Context
+
+What is the issue that we're seeing that is motivating this decision or change?
+
+## Decision
+
+What is the change that we're proposing and/or doing?
+
+## Consequences
+
+What becomes easier or more difficult to do because of this change?
+```
+
+## Rules
+
+- ADRs are immutable once accepted — supersede, don't edit
+- Keep context focused on forces at play at the time of the decision
+- Write consequences as both positive and negative impacts
+- Number sequentially, never reuse numbers
+- Title should be a short noun phrase (e.g. "Use PostgreSQL for persistence")

.agentskills/skills/commit/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: commit
+description: "Always apply this skill when committing to git"
+---
+
+Create a conventional commit message with the following body:
+
+```markdown
+## Intent
+
+<!-- Describe the intent of the commit. What problem does it solve? What was the motivation to introduce this change? -->
+
+## Key changes
+
+<!-- High level *conceptual* overview of the intended changes. Describe how the system behaves differently now. Do *not* list files -->
+
+## Dependencies and side effects
+
+<!-- only if applicable: Describe any effects this commit has on other parts of the system -->
+```

.agentskills/skills/tdd/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: tdd
+description: "Apply this when developing new features that add to or change the business logic of the system"
+---
+
+Apply TDD with agents:
+
+1. Ask an agent to write a failing test (RED phase). The agent shall commit this as WIP.
+2. Ask an agent to write the actual code to make the test pass (GREEN phase). The agent shall commit this as WIP.
+3. Ask an agent to judge the previous two commits: The GREEN phase commit must not have changed semantics of tests implemented in the RED phase.

.beads/README.md

@@ -0,0 +1,85 @@
+# Beads - AI-Native Issue Tracking
+
+Welcome to Beads! This repository uses **Beads** for issue tracking - a modern, AI-native tool designed to live directly in your codebase alongside your code.
+
+## What is Beads?
+
+Beads is issue tracking that lives in your repo, making it perfect for AI coding agents and developers who want their issues close to their code. No web UI required - everything works through the CLI and integrates seamlessly with git.
+
+**Learn more:** [github.com/steveyegge/beads](https://github.com/steveyegge/beads)
+
+## Quick Start
+
+### Essential Commands
+
+```bash
+# Create new issues
+bd create "Add user authentication"
+
+# View all issues
+bd list
+
+# View issue details
+bd show <issue-id>
+
+# Update issue status
+bd update <issue-id> --status in_progress
+bd update <issue-id> --status done
+
+# Sync with git remote
+bd sync
+```
+
+### Working with Issues
+
+Issues in Beads are:
+
+- **Git-native**: Stored in `.beads/issues.jsonl` and synced like code
+- **AI-friendly**: CLI-first design works perfectly with AI coding agents
+- **Branch-aware**: Issues can follow your branch workflow
+- **Always in sync**: Auto-syncs with your commits
+
+## Why Beads?
+
+✨ **AI-Native Design**
+
+- Built specifically for AI-assisted development workflows
+- CLI-first interface works seamlessly with AI coding agents
+- No context switching to web UIs
+
+🚀 **Developer Focused**
+
+- Issues live in your repo, right next to your code
+- Works offline, syncs when you push
+- Fast, lightweight, and stays out of your way
+
+🔧 **Git Integration**
+
+- Automatic sync with git commits
+- Branch-aware issue tracking
+- Intelligent JSONL merge resolution
+
+## Get Started with Beads
+
+Try Beads in your own projects:
+
+```bash
+# Install Beads
+curl -sSL https://raw.githubusercontent.com/steveyegge/beads/main/scripts/install.sh | bash
+
+# Initialize in your repo
+bd init
+
+# Create your first issue
+bd create "Try out Beads"
+```
+
+## Learn More
+
+- **Documentation**: [github.com/steveyegge/beads/docs](https://github.com/steveyegge/beads/tree/main/docs)
+- **Quick Start Guide**: Run `bd quickstart`
+- **Examples**: [github.com/steveyegge/beads/examples](https://github.com/steveyegge/beads/tree/main/examples)
+
+---
+
+_Beads: Issue tracking that moves at the speed of thought_ ⚡