07e46dce56
- Added YAML frontmatter to all 8 polish-* skills and sweep skill so Claude can auto-invoke them - New bitcoin-conventions skill with PROUX UX methodology, sats display, address validation, Tor preferences, Lightning patterns - Path-specific rules for containers (security hardening) and frontend (Vue/glassmorphism conventions) - Gitea Actions: nightly security review and weekly dependency audit Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
110 lines
4.1 KiB
Markdown
110 lines
4.1 KiB
Markdown
---
|
||
name: polish
|
||
description: Production polish orchestrator for Archipelago. Coordinates all polish sub-skills by reading plan.md and executing the current week's tasks. Use when user says "polish", "production polish", "overnight polish", or "run the polish plan".
|
||
---
|
||
|
||
# Skill: Production Polish (Overnight Orchestrator)
|
||
|
||
Main entry point for the Archipelago production polish plan. Reads `plan.md` at the project root, determines the current week based on today's date, and executes the tasks for that week.
|
||
|
||
## How It Works
|
||
|
||
1. Read `plan.md` from the project root
|
||
2. Determine the current week from the schedule:
|
||
- Week 1: March 10–16 — Silent Failures & Error Handling
|
||
- Week 2: March 17–23 — Loading States & Visual Feedback
|
||
- Week 3: March 24–30 — Form Validation & Input Quality
|
||
- Week 4: March 31 – April 6 — Backend Robustness
|
||
- Week 5: April 7–13 — WebSocket & Real-Time Quality
|
||
- Week 6: April 14–20 — Deployment & Infrastructure Hardening
|
||
- Week 7: April 21–27 — Accessibility, Polish & Edge Cases
|
||
- Week 8: April 28 – May 4 — Integration Testing, Final Sweep & ISO
|
||
3. Execute tasks for the current week, in order
|
||
4. After completing tasks, run `/sweep` to verify
|
||
5. Deploy and verify with `/deploy` then `/check-server`
|
||
|
||
## Execution Flow
|
||
|
||
### Step 1: Read the plan
|
||
```
|
||
Read plan.md and find the current week's section
|
||
```
|
||
|
||
### Step 2: Check what's already done
|
||
Run the verification checks for the current week's tasks. For example in Week 1:
|
||
- Count remaining `.catch(() => {})` patterns
|
||
- Count remaining `console.log` outside dev guards
|
||
- Count remaining `unwrap()` in backend production code
|
||
- Check if hardcoded credentials still exist
|
||
|
||
### Step 3: Work on the next incomplete task
|
||
Pick the first task in the current week that still has violations (hasn't met its acceptance criteria). Fix violations one file at a time:
|
||
1. Read the file
|
||
2. Apply the fix following the pattern described in the task
|
||
3. Verify the fix compiles/type-checks
|
||
4. Move to the next violation
|
||
|
||
### Step 4: Verify after each batch of fixes
|
||
After fixing all violations for a task:
|
||
- Frontend: `cd neode-ui && npx vue-tsc --noEmit`
|
||
- Backend: `ssh archipelago@192.168.1.228 "cd ~/archy && cargo check"`
|
||
- Run the task's specific acceptance grep/check
|
||
|
||
### Step 5: Deploy when a task is complete
|
||
When all violations for a task are fixed and verified:
|
||
```bash
|
||
./scripts/deploy-to-target.sh --live
|
||
```
|
||
Then verify:
|
||
```bash
|
||
ssh -i ~/.ssh/archipelago-deploy archipelago@192.168.1.228 "systemctl is-active archipelago && curl -s http://localhost:5678/health"
|
||
```
|
||
|
||
### Step 6: Move to the next task
|
||
Repeat Steps 3-5 for the next incomplete task in the current week.
|
||
|
||
### Step 7: When all tasks are done
|
||
Run `/sweep` for a full quality report. If clean, the week is complete.
|
||
|
||
## Rules
|
||
|
||
- **Never change functionality** — only improve quality of existing code
|
||
- **Never change the design** — use existing glassmorphism classes, color tokens, and layout patterns
|
||
- **Always deploy after changes** — don't leave undeployed code
|
||
- **Always verify after deploy** — check server health
|
||
- **Build Rust on the dev server** — never compile Rust on macOS
|
||
- **Commit after each completed task** — atomic commits with `fix:` or `refactor:` prefix
|
||
- **If something breaks, revert** — don't push forward with broken code
|
||
|
||
## Arguments
|
||
|
||
If `$ARGUMENTS` is provided:
|
||
- `week N` — Force execution of week N regardless of date
|
||
- `task N.M` — Execute only task N.M (e.g., `task 1.3`)
|
||
- `status` — Show completion status for all weeks without executing
|
||
- `sweep` — Run sweep only, no fixes
|
||
|
||
## Example Usage
|
||
|
||
```
|
||
/polish # Auto-detect week, work on next incomplete task
|
||
/polish week 1 # Force Week 1 tasks
|
||
/polish task 1.3 # Work on just task 1.3
|
||
/polish status # Show what's done and what's left
|
||
/polish sweep # Just run the quality sweep
|
||
```
|
||
|
||
## For Overnight TUI
|
||
|
||
Launch with:
|
||
```
|
||
/loop 30m /polish
|
||
```
|
||
|
||
Each 30-minute cycle:
|
||
1. Checks current week
|
||
2. Finds next incomplete task
|
||
3. Fixes as many violations as possible in the time available
|
||
4. Deploys and verifies
|
||
5. Reports progress
|