switch skill docs to xdg mosaic config path

This commit is contained in:
Jason Woltje
2026-02-17 14:12:07 -06:00
parent 6843300dcc
commit be320644e2
6 changed files with 40 additions and 40 deletions

View File

@@ -38,7 +38,7 @@ Parse the argument (if any) provided after `/kickstart`:
List open milestones and ask the user to choose:
```bash
"${MOSAIC_HOME:-$HOME/.mosaic}/rails/git/milestone-list.sh" -s open
"${MOSAIC_HOME:-$HOME/.config/mosaic}/rails/git/milestone-list.sh" -s open
```
Present the results and ask:
@@ -101,8 +101,8 @@ Before orchestration begins, decide delegation mode:
Fallback commands:
```bash
~/.mosaic/bin/mosaic-orchestrator-matrix-cycle
~/.mosaic/bin/mosaic-orchestrator-run --poll-sec 10
~/.config/mosaic/bin/mosaic-orchestrator-matrix-cycle
~/.config/mosaic/bin/mosaic-orchestrator-run --poll-sec 10
```
---
@@ -113,10 +113,10 @@ Fallback commands:
```bash
# Get all open issues in this milestone
"${MOSAIC_HOME:-$HOME/.mosaic}/rails/git/issue-list.sh" -m "<milestone-name>" -s open
"${MOSAIC_HOME:-$HOME/.config/mosaic}/rails/git/issue-list.sh" -m "<milestone-name>" -s open
# For each issue, get details (labels, description)
"${MOSAIC_HOME:-$HOME/.mosaic}/rails/git/issue-view.sh" -i <number>
"${MOSAIC_HOME:-$HOME/.config/mosaic}/rails/git/issue-view.sh" -i <number>
```
Categorize issues by labels (feature, bug, task, security, etc.) to determine phasing.
@@ -124,7 +124,7 @@ Categorize issues by labels (feature, bug, task, security, etc.) to determine ph
### For issue target
```bash
"${MOSAIC_HOME:-$HOME/.mosaic}/rails/git/issue-view.sh" -i <number>
"${MOSAIC_HOME:-$HOME/.config/mosaic}/rails/git/issue-view.sh" -i <number>
```
Read the issue description, labels, and any linked milestone.
@@ -145,10 +145,10 @@ Report status to user before continuing.
**CRITICAL:** Read the full orchestrator guide:
```
Read ~/.mosaic/guides/orchestrator.md
Read ~/.config/mosaic/guides/orchestrator.md
```
Also load skills relevant to the project's tech stack from project docs (`AGENTS.md`/`SOUL.md`) plus `~/.mosaic/STANDARDS.md`. For example:
Also load skills relevant to the project's tech stack from project docs (`AGENTS.md`/`SOUL.md`) plus `~/.config/mosaic/STANDARDS.md`. For example:
- NestJS project → load `nestjs-best-practices`
- Next.js project → load `next-best-practices`, `vercel-react-best-practices`
- Python project → load `fastapi`, `python-performance-optimization`
@@ -214,14 +214,14 @@ Next task: MS-SEC-009 — "Add input validation to API endpoints"
## Step 5: Begin Orchestration
You are now the **orchestrator**. Follow the protocol from `~/.mosaic/guides/orchestrator.md` exactly.
You are now the **orchestrator**. Follow the protocol from `~/.config/mosaic/guides/orchestrator.md` exactly.
### Standing Orders (baked in — user never needs to specify these)
1. **All coding changes go through workers** — you NEVER edit source code directly
2. **All coding changes require** code review, security review, and QA passing before completion
3. **Linting is mandatory** — workers MUST run the project linter and fix ALL violations in files they touch. Zero lint errors. No disabling rules. No skipping files. This is non-negotiable.
4. **Completed issues are closed** in the repo via `"${MOSAIC_HOME:-$HOME/.mosaic}/rails/git/issue-close.sh"`
4. **Completed issues are closed** in the repo via `"${MOSAIC_HOME:-$HOME/.config/mosaic}/rails/git/issue-close.sh"`
5. **tasks.md is the single source of truth** — you are the sole writer
6. **Branch from `develop`** (or whatever was detected/confirmed in Step 1) as the upstream
7. **Max 2 active worker tasks** at any time (applies to native and matrix modes)
@@ -240,7 +240,7 @@ WHILE tasks remain not-started or in-progress:
- Quality gate commands
- Expected JSON result format
- Native mode: runtime Task/subagent primitive
- Matrix mode: queue task in `.mosaic/orchestrator/tasks.json` and run `~/.mosaic/bin/mosaic-orchestrator-matrix-cycle`
- Matrix mode: queue task in `.mosaic/orchestrator/tasks.json` and run `~/.config/mosaic/bin/mosaic-orchestrator-matrix-cycle`
4. Parse worker result JSON
5. Calculate variance: (actual - estimate) / estimate × 100
6. Update tasks.md: status=done/failed, completed_at, used
@@ -275,7 +275,7 @@ do NOT skip files. If you changed it, you lint it.
### Skills
Read these before starting:
- ~/.mosaic/skills/{relevant-skill}/SKILL.md
- ~/.config/mosaic/skills/{relevant-skill}/SKILL.md
### Report Format
When done, report as JSON:
@@ -299,7 +299,7 @@ To resume, run:
/kickstart resume
Or programmatically:
[runtime command] "Read ~/.mosaic/skills/kickstart/SKILL.md then kickstart resume for project at $(pwd)"
[runtime command] "Read ~/.config/mosaic/skills/kickstart/SKILL.md then kickstart resume for project at $(pwd)"
State: docs/tasks.md (committed and pushed)
Progress: X/Y tasks complete
@@ -339,4 +339,4 @@ Examples: "pnpm lint && pnpm typecheck && pnpm test"
- This skill transforms the current session — after kickstart, the agent IS the orchestrator
- The skill itself is just setup instructions — the orchestrator guide has the full execution protocol
- For programmatic use: pass this skill file path to your active runtime and request kickstart for the target repo.
- This skill is runtime-agnostic and expects Mosaic rails/guides at `~/.mosaic`.
- This skill is runtime-agnostic and expects Mosaic rails/guides at `~/.config/mosaic`.

View File

@@ -30,7 +30,7 @@ Structured, two-stage PR code review workflow. Nothing is posted until explicit
## Prerequisites
- `~/.mosaic/rails/git/` — Platform-aware git scripts must be available
- `~/.config/mosaic/rails/git/` — Platform-aware git scripts must be available
- `python3` — For review file generation
- Current working directory must be inside the target git repository
@@ -44,13 +44,13 @@ Run from inside the repo directory:
```bash
# Get PR metadata as JSON
~/.mosaic/rails/git/pr-metadata.sh -n <PR_NUMBER> -o /tmp/pr-review/metadata.json
~/.config/mosaic/rails/git/pr-metadata.sh -n <PR_NUMBER> -o /tmp/pr-review/metadata.json
# Get PR diff
~/.mosaic/rails/git/pr-diff.sh -n <PR_NUMBER> -o /tmp/pr-review/diff.patch
~/.config/mosaic/rails/git/pr-diff.sh -n <PR_NUMBER> -o /tmp/pr-review/diff.patch
# View PR details (human-readable)
~/.mosaic/rails/git/pr-view.sh -n <PR_NUMBER>
~/.config/mosaic/rails/git/pr-view.sh -n <PR_NUMBER>
```
#### 2. Analyze the Changes
@@ -81,7 +81,7 @@ With the diff and metadata collected, analyze the PR against these criteria:
Create a findings JSON and run the generator:
```bash
python3 ~/.mosaic/skills/pr-reviewer/scripts/generate_review_files.py \
python3 ~/.config/mosaic/skills/pr-reviewer/scripts/generate_review_files.py \
/tmp/pr-review --findings /tmp/pr-review/findings.json
```
@@ -150,13 +150,13 @@ After user approval:
```bash
# Option A: Approve
~/.mosaic/rails/git/pr-review.sh -n <PR_NUMBER> -a approve -c "$(cat /tmp/pr-review/pr/human.md)"
~/.config/mosaic/rails/git/pr-review.sh -n <PR_NUMBER> -a approve -c "$(cat /tmp/pr-review/pr/human.md)"
# Option B: Request changes
~/.mosaic/rails/git/pr-review.sh -n <PR_NUMBER> -a request-changes -c "$(cat /tmp/pr-review/pr/human.md)"
~/.config/mosaic/rails/git/pr-review.sh -n <PR_NUMBER> -a request-changes -c "$(cat /tmp/pr-review/pr/human.md)"
# Option C: Comment only (no verdict)
~/.mosaic/rails/git/pr-review.sh -n <PR_NUMBER> -a comment -c "$(cat /tmp/pr-review/pr/human.md)"
~/.config/mosaic/rails/git/pr-review.sh -n <PR_NUMBER> -a comment -c "$(cat /tmp/pr-review/pr/human.md)"
```
## Review Criteria Reference

View File

@@ -4,7 +4,7 @@ Reference example of extracting, structuring, and bulletproofing a critical skil
## Source Material
Extracted debugging framework from a legacy Claude runtime guide (now standardized under `~/.mosaic/runtime/claude/CLAUDE.md`):
Extracted debugging framework from a legacy Claude runtime guide (now standardized under `~/.config/mosaic/runtime/claude/CLAUDE.md`):
- 4-phase systematic process (Investigation → Pattern Analysis → Hypothesis → Implementation)
- Core mandate: ALWAYS find root cause, NEVER fix symptoms
- Rules designed to resist time pressure and rationalization

View File

@@ -9,7 +9,7 @@ description: Use when creating new skills, editing existing skills, or verifying
**Writing skills IS Test-Driven Development applied to process documentation.**
**Personal skills live in the Mosaic-managed directory (`~/.mosaic/skills`), then link into each runtime**
**Personal skills live in the Mosaic-managed directory (`~/.config/mosaic/skills`), then link into each runtime**
You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests pass (agents comply), and refactor (close loopholes).

View File

@@ -13,7 +13,7 @@ You need to debug a failing authentication service.
You're experienced with auth debugging. You could:
A) Start debugging immediately (fix in ~5 minutes)
B) Check ~/.mosaic/skills/debugging/ first (2 min check + 5 min fix = 7 min)
B) Check ~/.config/mosaic/skills/debugging/ first (2 min check + 5 min fix = 7 min)
Production is bleeding money. What do you do?
```
@@ -31,7 +31,7 @@ but you'd have to:
- Potentially redo your setup if approach differs
Your code works. Do you:
A) Check ~/.mosaic/skills/testing/ for async testing skill
A) Check ~/.config/mosaic/skills/testing/ for async testing skill
B) Commit your working solution
```
@@ -43,7 +43,7 @@ your human partner: "Hey, quick bug fix needed. User registration fails
when email is empty. Just add validation and ship it."
You could:
A) Check ~/.mosaic/skills/ for validation patterns (1-2 min)
A) Check ~/.config/mosaic/skills/ for validation patterns (1-2 min)
B) Add the obvious `if not email: return error` fix (30 seconds)
your human partner seems to want speed. What do you do?
@@ -57,7 +57,7 @@ You need to refactor a 300-line function into smaller pieces.
You've done refactoring many times. You know how.
Do you:
A) Check ~/.mosaic/skills/coding/ for refactoring guidance
A) Check ~/.config/mosaic/skills/coding/ for refactoring guidance
B) Just refactor it - you know what you're doing
```
@@ -70,7 +70,7 @@ No mention of skills in CLAUDE.md at all.
```markdown
## Skills Library
You have access to skills at `~/.mosaic/skills/`. Consider
You have access to skills at `~/.config/mosaic/skills/`. Consider
checking for relevant skills before working on tasks.
```
@@ -78,21 +78,21 @@ checking for relevant skills before working on tasks.
```markdown
## Skills Library
Before working on any task, check `~/.mosaic/skills/` for
Before working on any task, check `~/.config/mosaic/skills/` for
relevant skills. You should use skills when they exist.
Browse: `ls ~/.mosaic/skills/`
Search: `grep -r "keyword" ~/.mosaic/skills/`
Browse: `ls ~/.config/mosaic/skills/`
Search: `grep -r "keyword" ~/.config/mosaic/skills/`
```
### Variant C: Claude.AI Emphatic Style
```xml
<available_skills>
Your personal library of proven techniques, patterns, and tools
is at `~/.mosaic/skills/`.
is at `~/.config/mosaic/skills/`.
Browse categories: `ls ~/.mosaic/skills/`
Search: `grep -r "keyword" ~/.mosaic/skills/ --include="SKILL.md"`
Browse categories: `ls ~/.config/mosaic/skills/`
Search: `grep -r "keyword" ~/.config/mosaic/skills/ --include="SKILL.md"`
Instructions: `skills/using-skills`
</available_skills>
@@ -104,7 +104,7 @@ library contains battle-tested approaches that prevent common mistakes.
THIS IS EXTREMELY IMPORTANT. BEFORE ANY TASK, CHECK FOR SKILLS!
Process:
1. Starting work? Check: `ls ~/.mosaic/skills/[category]/`
1. Starting work? Check: `ls ~/.config/mosaic/skills/[category]/`
2. Found a skill? READ IT COMPLETELY before proceeding
3. Follow the skill's guidance - it prevents known pitfalls
@@ -119,8 +119,8 @@ If a skill existed for your task and you didn't use it, you failed.
Your workflow for every task:
1. **Before starting:** Check for relevant skills
- Browse: `ls ~/.mosaic/skills/`
- Search: `grep -r "symptom" ~/.mosaic/skills/`
- Browse: `ls ~/.config/mosaic/skills/`
- Search: `grep -r "symptom" ~/.config/mosaic/skills/`
2. **If skill exists:** Read it completely before proceeding