Skip to content

Commit 544349a

Browse files
authored
Feature/resolve main conflicts (#59)
1 parent 9190071 commit 544349a

1,214 files changed

Lines changed: 233306 additions & 19713 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

.claude/settings.json

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
{
2+
"permissions": {
3+
"allow": [
4+
"Bash(npm run typecheck)",
5+
"Bash(npm run test)",
6+
"Bash(npm run db:generate)",
7+
"Bash(git add *)",
8+
"Bash(git commit *)",
9+
"Bash(git checkout *)",
10+
"Bash(git branch *)",
11+
"Bash(git status)",
12+
"Bash(git diff *)",
13+
"Bash(git log *)",
14+
"Bash(cd apps/*)",
15+
"Bash(cd scripts/*)",
16+
"mcp__playwright__browser_press_key"
17+
],
18+
"defaultMode": "acceptEdits",
19+
"model": "sonnet"
20+
}
21+
}
Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
---
2+
name: checklist-creator
3+
description: "Converts a user-provided list of issues, bugs, or tasks into a structured markdown checklist file in docs-md/. Trigger phrases: create checklist, make a checklist, turn these into a checklist, create todo file, checklist from these items. Do NOT invoke for: executing/working through checklist items, editing existing checklists, or general markdown file creation."
4+
---
5+
6+
# Checklist Creator Skill
7+
8+
Converts a freeform list of issues, tasks, or bugs into a structured markdown
9+
checklist file with rich context for each item.
10+
11+
## Output Format
12+
13+
The output file follows this exact structure:
14+
15+
```markdown
16+
# [System/Feature Name]: [Checklist Purpose]
17+
18+
[1-2 sentence description of what this checklist tracks.]
19+
20+
---
21+
22+
## [Category Section]
23+
24+
### 1. [ ] [Short descriptive title]
25+
**Area:** [Component area — e.g. "Frontend — Component Name" or "Backend — Service Name"]
26+
**Problem:** [What's wrong or what needs to happen, written clearly.]
27+
**Expected:** [What the correct behavior or outcome should be.]
28+
**Key file:** `[path/to/relevant/file]`[brief note on where to look.]
29+
30+
### 2. [ ] [Next item...]
31+
...
32+
33+
---
34+
35+
## Key Files Reference
36+
37+
| Area | Files |
38+
|------|-------|
39+
| ... | ... |
40+
```
41+
42+
## Workflow
43+
44+
1. Read the user's list of items carefully.
45+
2. Determine a logical grouping/categorization for the items (by area, component, severity, etc.).
46+
3. For each item, derive:
47+
- A short descriptive title
48+
- The affected area (Frontend/Backend/Temporal/etc. + specific component)
49+
- Problem description (expand on what the user said, add technical context)
50+
- Expected behavior or resolution
51+
- Key files to investigate (use codebase knowledge or search if needed)
52+
4. If an item is purely informational (e.g. "explain X to me"), use **Action:** instead of **Expected:** and note that no code changes are needed.
53+
5. If the user provides log output or error messages with an item, include them in the problem description as a code block.
54+
6. Build a Key Files Reference table at the bottom covering all areas mentioned.
55+
7. Ask the user for the output filename if not obvious from context. Default location is `docs-md/`.
56+
8. Write the file.
57+
58+
## Rules
59+
60+
- Items are numbered sequentially across all sections (not restarting per section).
61+
- All checkboxes start unchecked: `[ ]`.
62+
- Use `###` for individual items, `##` for category sections.
63+
- Include `---` horizontal rules between sections.
64+
- Do NOT invent issues the user didn't mention — only structure what they gave you.
65+
- DO use codebase knowledge to fill in key files and technical context.
66+
- Keep problem/expected descriptions concise but complete enough for someone to implement without re-asking the user.
67+
- If the user specifies a context (e.g. "benchmarking system"), include it in the title and description.
Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
---
2+
name: checklist-executor
3+
description: "Works through a markdown checklist file, implementing each unchecked item sequentially. Trigger phrases: work through checklist, execute checklist, fix checklist items, work on the checklist, continue the checklist, next checklist item. Do NOT invoke for: creating new checklists (use checklist-creator), general code changes not tied to a checklist file."
4+
---
5+
6+
# Checklist Executor Skill
7+
8+
Reads a structured markdown checklist file and works through unchecked items
9+
one at a time, implementing fixes and marking items complete.
10+
11+
## Workflow
12+
13+
1. **Load the checklist.** Read the checklist file specified by the user (or find
14+
the most recent one in `docs-md/` if not specified).
15+
16+
2. **Find the next unchecked item.** Scan for the first `[ ]` item in the file.
17+
If all items are checked, inform the user that the checklist is complete.
18+
19+
3. **Start working immediately.** Show the user which item you're working on
20+
(number and title), then begin implementing right away without asking for
21+
confirmation.
22+
23+
4. **Implement the fix.** Follow the item's Problem/Expected/Key file guidance:
24+
- Read the relevant files mentioned in the item.
25+
- Investigate the issue as described.
26+
- Implement the fix following project conventions (CLAUDE.md rules apply).
27+
- For backend changes: create/update tests and run them.
28+
- For frontend changes: verify the component renders correctly.
29+
- For items marked **Action:** (informational only): research and explain
30+
to the user, no code changes.
31+
32+
5. **Mark complete.** After the fix is implemented and verified:
33+
- Update the checklist file, changing `[ ]` to `[x]` for the completed item.
34+
- Summarize what was done.
35+
36+
6. **Continue.** Immediately proceed to the next unchecked item. Keep going
37+
until all items are complete or the user interrupts.
38+
39+
## Rules
40+
41+
- Work on ONE item at a time. Do not batch multiple items.
42+
- Always read the checklist file fresh before starting each item (it may have
43+
been modified externally).
44+
- Follow all CLAUDE.md instructions (no placeholders, no backwards compat,
45+
proper typing, update tests, update docs-md).
46+
- If an item requires clarification, ask the user before implementing.
47+
- If an item turns out to be already fixed or not reproducible, mark it `[x]`
48+
and note that it was already resolved.
49+
- Do not skip items without user approval.
50+
- If implementing an item reveals new issues, mention them to the user but
51+
do NOT add them to the checklist — let the user decide.
52+
- Keep the checklist file's formatting intact when marking items complete
53+
(only change `[ ]` to `[x]`, nothing else on that line).
Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
name: create-skill
3+
description: "Create a new Claude Agent Skill. Auto-invoke when the user asks to create a skill, make a new skill, or scaffold a workflow automation. Do NOT invoke for general coding tasks."
4+
---
5+
6+
# Create Skill
7+
8+
Scaffold a new Claude Agent Skill using the architecture below.
9+
10+
## Skill Architecture
11+
12+
Every skill lives at `.claude/skills/[SkillName]/` and uses
13+
progressive disclosure — Claude loads only what each task needs:
14+
15+
- **Tier 1 — frontmatter (~100 tokens):** Always in memory
16+
- **Tier 2 — SKILL.md body (<5k tokens):** Loaded on trigger
17+
- **Tier 3 — Workflow + resource files:** Loaded on demand
18+
19+
## Directory Layout
20+
21+
```
22+
23+
.claude/skills/[SkillName]/
24+
├── SKILL.md ← required, entry point
25+
├── CONVENTIONS.md ← if the domain has style/format rules
26+
├── Workflows/
27+
│ ├── [Action1].md ← one file per distinct task
28+
│ └── [Action2].md
29+
└── scripts/ ← optional, only if no existing scripts suffice
30+
└── [script].sh ← shell commands, never inline them
31+
32+
```
33+
34+
## What Goes in Each File
35+
36+
**SKILL.md** — frontmatter + routing table + always-follow rules
37+
- `name`: kebab-case skill name
38+
- `description`: what it does, exact trigger phrases, and explicit
39+
exclusions ("Do NOT invoke for...").
40+
**IMPORTANT:** The description MUST be a single-line quoted string, NOT a YAML
41+
multiline block (`>` or `|`). Multiline descriptions break skill detection.
42+
Example: `description: "Does X. Trigger phrases: a, b. Do NOT invoke for: c."`
43+
- Body: index of Workflows with links, and any rules that apply
44+
to ALL workflows
45+
46+
**CONVENTIONS.md** — domain-specific rules Claude must always follow
47+
- Formatting, file naming, forbidden patterns
48+
- Write specific checkable rules, not vague guidance
49+
- Referenced in SKILL.md "Always Follow" so it's loaded every time
50+
51+
**Workflows/[Action].md** — step-by-step instructions for one task
52+
- Numbered steps in order
53+
- Bash commands in code blocks, referencing scripts/ by path
54+
- "Common Pitfalls" section at the bottom
55+
56+
**scripts/[script].sh** — actual shell commands (only if needed)
57+
- Before creating any script, search the repo for existing scripts,
58+
build tools, npm scripts, or Makefiles that already do the job
59+
- If an existing script exists (e.g., `docs/build.sh`, `npm run build`),
60+
reference it directly in Workflows instead of creating a duplicate
61+
- Only create a new script when no existing tool covers the need
62+
- When creating: start with `#!/bin/bash` and `set -e`
63+
- Always cd to project root: `cd "$(git rev-parse --show-toplevel)"`
64+
- Called from Workflows via: `bash .claude/skills/[SkillName]/scripts/[script].sh`
65+
- Scripts run via bash — their code never enters Claude's context,
66+
only their output does
67+
68+
## Steps to Create a New Skill
69+
70+
1. Ask the user:
71+
- What does the skill automate? (tool, project, or domain)
72+
- What are the distinct actions it needs to handle? (each = one Workflow)
73+
- Are there domain conventions to follow? (yes → CONVENTIONS.md)
74+
- When should it auto-invoke, and when should it stay dormant?
75+
76+
2. Search the repo for existing shell scripts, npm scripts, Makefiles,
77+
and build tools that relate to the skill's domain. List what you find
78+
and plan to reference them in Workflows instead of creating duplicates.
79+
80+
3. Summarize the planned structure and confirm with the user
81+
82+
4. Create all files — SKILL.md first, then Workflows, then CONVENTIONS.md.
83+
Only create scripts/ if no existing scripts cover the need.
84+
85+
4. After creating, tell the user:
86+
- The full file tree of what was created
87+
- Example prompts that will trigger the new Skill
Lines changed: 151 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,151 @@
1+
# Documentation Site Conventions
2+
3+
## Page Structure
4+
5+
Every page in `docs/_pages/` is an **HTML fragment** — no doctype, html, head, or body tags.
6+
7+
```html
8+
<!-- TITLE: My Page Title -->
9+
<!-- NAV: mypagename -->
10+
11+
<h1>My Page Title</h1>
12+
<p>Introductory paragraph.</p>
13+
14+
<!-- Section content below -->
15+
```
16+
17+
## CSS Classes Reference
18+
19+
### Alerts (callouts)
20+
```html
21+
<div class="alert alert-info">...</div> <!-- Blue — tips, info -->
22+
<div class="alert alert-warning">...</div> <!-- Yellow — cautions -->
23+
<div class="alert alert-success">...</div> <!-- Green — confirmations -->
24+
```
25+
26+
Alert inner structure:
27+
```html
28+
<div class="alert alert-info">
29+
<div class="alert-icon">
30+
<svg ...>...</svg>
31+
</div>
32+
<div>
33+
<strong>Title</strong><br>
34+
Body text here.
35+
</div>
36+
</div>
37+
```
38+
39+
### Cards
40+
```html
41+
<div class="card">...</div> <!-- Default (blue left border) -->
42+
<div class="card card-gold">...</div> <!-- Gold left border -->
43+
```
44+
45+
Custom border: `<div class="card" style="border-left-color: #22c55e;">`
46+
47+
### Clickable Cards
48+
```html
49+
<a href="page.html" class="card-link">
50+
<div class="card">
51+
<h3>Title</h3>
52+
<p>Description</p>
53+
<div class="card-arrow">Learn More →</div>
54+
</div>
55+
</a>
56+
```
57+
58+
### Grid Layouts
59+
```html
60+
<div class="grid grid-2">...</div> <!-- 2 columns -->
61+
<div class="grid grid-3">...</div> <!-- 3 columns -->
62+
<div class="grid grid-4">...</div> <!-- 4 columns -->
63+
```
64+
65+
All grids collapse to single column on mobile (≤768px).
66+
67+
### Feature Icons
68+
```html
69+
<div class="feature-icon gold">...</div>
70+
<div class="feature-icon blue">...</div>
71+
<div class="feature-icon green">...</div>
72+
<div class="feature-icon purple">...</div>
73+
```
74+
75+
### Badges
76+
```html
77+
<span class="badge badge-gold">Gold</span>
78+
<span class="badge badge-blue">Blue</span>
79+
```
80+
81+
### Hero Section
82+
```html
83+
<div class="hero">
84+
<span class="badge badge-gold">Featured</span>
85+
<h1>Hero Title</h1>
86+
<p>Subtitle text.</p>
87+
</div>
88+
```
89+
90+
### Stats
91+
```html
92+
<div class="card" style="text-align: center; border-left: none; border-top: 4px solid var(--bc-gold);">
93+
<div class="stat-number">42</div>
94+
<div class="stat-label">Total Items</div>
95+
</div>
96+
```
97+
98+
### Collapsible Sections
99+
```html
100+
<details>
101+
<summary style="cursor: pointer; color: var(--bc-blue-light); font-weight: 600;">
102+
Click to expand
103+
</summary>
104+
<div style="margin-top: 1rem;">
105+
Content here.
106+
</div>
107+
</details>
108+
```
109+
110+
### Code
111+
- Inline: `<code>some code</code>`
112+
- Block: `<pre>multi-line code</pre>`
113+
114+
### Tables
115+
```html
116+
<table>
117+
<tr><th>Header</th><th>Header</th></tr>
118+
<tr><td>Cell</td><td>Cell</td></tr>
119+
</table>
120+
```
121+
122+
### Images
123+
```html
124+
<div class="img-container">
125+
<img src="assets/image.svg" alt="Description">
126+
<p style="color: var(--text-secondary); font-size: 0.875rem; margin-top: 0.5rem;">Caption</p>
127+
</div>
128+
```
129+
130+
## Design System Colors
131+
132+
| Variable | Hex | Usage |
133+
|----------|-----|-------|
134+
| `--bc-blue` | `#003366` | Primary, nav, headings |
135+
| `--bc-gold` | `#fcba19` | Accents, highlights |
136+
| `--bc-blue-light` | `#1a5a96` | Links, interactive |
137+
| `--bc-blue-dark` | `#002244` | Dark backgrounds |
138+
| `--text-primary` | `#313132` | Body text |
139+
| `--text-secondary` | `#606060` | Secondary text |
140+
141+
Additional colors used inline: `#22c55e` (green), `#8b5cf6` (purple), `#0ea5e9` (sky blue), `#ef4444` (red).
142+
143+
## Rules
144+
145+
1. **No framework tags** — pure HTML only, no JSX, no web components
146+
2. **No external CSS/JS imports in pages** — all styles come from `_partials/header.html`
147+
3. **Use semantic HTML**`h1``h2``h3` hierarchy, `<table>`, `<ul>`/`<ol>`
148+
4. **One `<h1>` per page** — matching the TITLE metadata
149+
5. **SVG icons inline** — use Lucide-style SVGs (24x24 viewBox, stroke-based)
150+
6. **Links between pages** — use relative paths: `href="authentication.html"`
151+
7. **Assets** — place in `docs/assets/`, reference as `assets/filename.ext`

0 commit comments

Comments
 (0)