chore: remove tracked .claude/ files (already gitignored)
These files were committed before .claude/ was added to .gitignore. Removing from tracking as they're local install artifacts. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Lex Christopherson
@@ -1,64 +0,0 @@
|
||||
---
|
||||
paths:
|
||||
- "commands/gsd/**/*.md"
|
||||
---
|
||||
|
||||
# Slash Command Rules
|
||||
|
||||
Rules for editing files in `commands/gsd/`.
|
||||
|
||||
## File Structure
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: gsd:command-name
|
||||
description: One-line description
|
||||
argument-hint: "<required>" or "[optional]"
|
||||
allowed-tools: [Read, Write, Bash, Glob, Grep, AskUserQuestion]
|
||||
---
|
||||
```
|
||||
|
||||
## Section Order
|
||||
|
||||
1. `<objective>` — What/why/when (always present)
|
||||
2. `<execution_context>` — @-references to workflows, templates, references
|
||||
3. `<context>` — Dynamic content: `$ARGUMENTS`, bash output, @file refs
|
||||
4. `<process>` or `<step>` elements — Implementation steps
|
||||
5. `<success_criteria>` — Measurable completion checklist
|
||||
|
||||
## Core Principle
|
||||
|
||||
**Commands are thin wrappers.** Delegate detailed logic to workflows.
|
||||
|
||||
Commands answer "what to do", workflows answer "how to do it".
|
||||
|
||||
## @-Reference Patterns
|
||||
|
||||
```markdown
|
||||
<execution_context>
|
||||
@~/.claude/get-shit-done/workflows/execute-phase.md
|
||||
@~/.claude/get-shit-done/templates/summary.md
|
||||
@~/.claude/get-shit-done/references/plan-format.md
|
||||
</execution_context>
|
||||
|
||||
<context>
|
||||
$ARGUMENTS
|
||||
|
||||
@.planning/PROJECT.md
|
||||
@.planning/STATE.md
|
||||
</context>
|
||||
```
|
||||
|
||||
- `execution_context`: Static resources (workflows, templates, references)
|
||||
- `context`: Dynamic project state and arguments
|
||||
|
||||
## Success Criteria Format
|
||||
|
||||
```xml
|
||||
<success_criteria>
|
||||
- [ ] Specific, measurable criterion
|
||||
- [ ] Another verifiable outcome
|
||||
</success_criteria>
|
||||
```
|
||||
|
||||
Use checkbox format. Each criterion must be objectively verifiable.
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
paths:
|
||||
- "get-shit-done/references/**/*.md"
|
||||
---
|
||||
|
||||
# Reference File Rules
|
||||
|
||||
Rules for editing files in `get-shit-done/references/`.
|
||||
|
||||
## Outer Container Pattern
|
||||
|
||||
References typically use an outer XML container related to the filename:
|
||||
|
||||
- `principles.md` → `<principles>...</principles>`
|
||||
- `checkpoints.md` → `<overview>...</overview>` then `<checkpoint_types>...</checkpoint_types>`
|
||||
- `plan-format.md` → `<overview>...</overview>` then `<core_principle>...</core_principle>`
|
||||
|
||||
Not a strict rule — check the file you're editing.
|
||||
|
||||
## Internal Structure
|
||||
|
||||
Internal organization varies. Common patterns:
|
||||
- Semantic sub-containers (`<solo_developer_claude>`, `<plans_are_prompts>`)
|
||||
- Markdown headers within XML
|
||||
- Code examples in fenced blocks
|
||||
|
||||
## Teaching Patterns
|
||||
|
||||
References often teach by contrast:
|
||||
- Show vague vs. specific examples
|
||||
- Explain WHY something is problematic
|
||||
- Provide concrete alternatives
|
||||
|
||||
## Key Principle
|
||||
|
||||
References explain concepts and patterns loaded by workflows/commands when relevant. Match the style of the specific reference you're editing.
|
||||
@@ -1,87 +0,0 @@
|
||||
# GSD Style Rules
|
||||
|
||||
These rules apply to ALL files in this repository.
|
||||
|
||||
## Language & Tone
|
||||
|
||||
**Imperative voice.** "Execute tasks", "Create file" — not "Execution is performed"
|
||||
|
||||
**No filler.** Absent: "Let me", "Just", "Simply", "Basically", "I'd be happy to"
|
||||
|
||||
**No sycophancy.** Absent: "Great!", "Awesome!", "Excellent!", "I'd love to help"
|
||||
|
||||
**Brevity with substance.** Good: "JWT auth with refresh rotation using jose library" Bad: "Phase complete"
|
||||
|
||||
## Temporal Language Ban
|
||||
|
||||
Never write: "We changed X to Y", "Previously", "No longer", "Instead of"
|
||||
|
||||
Always: Describe current state only.
|
||||
|
||||
Exception: CHANGELOG.md, git commits (their purpose IS tracking change)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
### Enterprise Patterns (Banned)
|
||||
- Story points, sprint ceremonies, RACI matrices
|
||||
- Human dev time estimates (days/weeks)
|
||||
- Team coordination, knowledge transfer docs
|
||||
|
||||
### Generic XML (Banned)
|
||||
Don't use: `<section>`, `<item>`, `<content>`
|
||||
|
||||
Use semantic tags: `<objective>`, `<verification>`, `<action>`, `<process>`
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
| Type | Convention | Example |
|
||||
|------|------------|---------|
|
||||
| Files | kebab-case | `execute-phase.md` |
|
||||
| Commands | `gsd:kebab-case` | `gsd:execute-phase` |
|
||||
| Step names | snake_case | `name="load_project_state"` |
|
||||
| Bash variables | CAPS_UNDERSCORES | `PHASE_ARG` |
|
||||
| Type attributes | colon separator | `type="checkpoint:human-verify"` |
|
||||
|
||||
## XML Conventions
|
||||
|
||||
XML tags are semantic containers. Use Markdown headers for hierarchy within.
|
||||
|
||||
```xml
|
||||
<!-- DO -->
|
||||
<objective>
|
||||
## Primary Goal
|
||||
Build authentication system
|
||||
|
||||
## Success Criteria
|
||||
- Users can log in
|
||||
</objective>
|
||||
|
||||
<!-- DON'T -->
|
||||
<section name="objective">
|
||||
<subsection name="primary-goal">
|
||||
<content>Build authentication</content>
|
||||
</subsection>
|
||||
</section>
|
||||
```
|
||||
|
||||
## @-References
|
||||
|
||||
@-references are lazy loading signals — instructions to read, not pre-loaded content.
|
||||
|
||||
```
|
||||
@~/.claude/get-shit-done/workflows/execute-phase.md # Static (always load)
|
||||
@.planning/DISCOVERY.md (if exists) # Conditional
|
||||
```
|
||||
|
||||
## Commit Format
|
||||
|
||||
```
|
||||
{type}({phase}-{plan}): {description}
|
||||
```
|
||||
|
||||
Types: `feat`, `fix`, `test`, `refactor`, `docs`, `chore`
|
||||
|
||||
Rules:
|
||||
- One commit per task
|
||||
- Stage files individually (never `git add .`)
|
||||
- Include `Co-Authored-By: Claude` line
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
paths:
|
||||
- "get-shit-done/templates/**/*.md"
|
||||
---
|
||||
|
||||
# Template Rules
|
||||
|
||||
Rules for editing files in `get-shit-done/templates/`.
|
||||
|
||||
## Structure Varies
|
||||
|
||||
Templates don't follow a uniform structure. Some patterns:
|
||||
|
||||
- Most start with `# [Name] Template` header
|
||||
- Many include a `<template>` block containing the actual template content
|
||||
- Some include examples or guidelines sections
|
||||
|
||||
## Placeholder Conventions
|
||||
|
||||
**Square brackets** for human-fillable placeholders:
|
||||
```
|
||||
[Project Name]
|
||||
[Description]
|
||||
```
|
||||
|
||||
**Curly braces** for variable interpolation:
|
||||
```
|
||||
{phase}-{plan}-PLAN.md
|
||||
.planning/phases/{phase}/
|
||||
```
|
||||
|
||||
## YAML Frontmatter in Template Content
|
||||
|
||||
Templates that define output documents often show example frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
phase: XX-name
|
||||
plan: YY
|
||||
type: execute
|
||||
---
|
||||
```
|
||||
|
||||
This is content TO BE GENERATED, not frontmatter for the template file itself.
|
||||
|
||||
## Key Principle
|
||||
|
||||
Templates show structure for generated documents. Match the style of the specific template you're editing.
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
paths:
|
||||
- "get-shit-done/workflows/**/*.md"
|
||||
---
|
||||
|
||||
# Workflow Rules
|
||||
|
||||
Rules for editing files in `get-shit-done/workflows/`.
|
||||
|
||||
## No Frontmatter
|
||||
|
||||
Workflows don't use YAML frontmatter. Content starts immediately.
|
||||
|
||||
## Common XML Tags
|
||||
|
||||
These tags appear across workflows, but not all workflows use all of them:
|
||||
|
||||
- `<purpose>` — What this workflow accomplishes
|
||||
- `<when_to_use>` — Decision criteria (some workflows use `<trigger>` instead)
|
||||
- `<required_reading>` — Files to read before starting
|
||||
- `<process>` — Container for execution steps
|
||||
- `<step>` — Individual step within process
|
||||
|
||||
Some workflows also use domain-specific tags like `<philosophy>`, `<references>`, `<planning_principles>`, `<decimal_phase_numbering>`.
|
||||
|
||||
## Step Elements
|
||||
|
||||
When using `<step>` elements:
|
||||
- `name` attribute: snake_case (e.g., `name="load_project_state"`)
|
||||
- `priority` attribute: Optional ("first", "second")
|
||||
|
||||
## Conditional Logic
|
||||
|
||||
```xml
|
||||
<if mode="yolo">
|
||||
Content for yolo mode
|
||||
</if>
|
||||
```
|
||||
|
||||
Conditions reference `.planning/config.json` values.
|
||||
|
||||
## Key Principle
|
||||
|
||||
Workflows contain detailed execution logic. Commands are thin wrappers that delegate to workflows.
|
||||
|
||||
Match the style of the specific workflow you're editing — patterns vary across files.
|
||||
Reference in New Issue
Block a user