mathiasandClaude Opus 4.8
b7d8cfc3cc
release / tag (push) Successful in 1s
- telos-load: harness-agnostic TELOS session context loading (closes #4) - regulatory-risk-assessment: CAD compliance gate + risk register (closes #3) Bump-Type: minor Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
96 lines
5.4 KiB
Markdown
96 lines
5.4 KiB
Markdown
# Engineering Skills Index
|
|
|
|
This index lists all available engineering skills. Load the full SKILL.md on demand.
|
|
|
|
| Skill | Description | Use when |
|
|
|-------|-------------|----------|
|
|
| `tdd` | Test-Driven Development enforcement | Starting any new feature or fixing a bug |
|
|
| `clean-code` | Clean code principles with Go adaptation | Code review, refactoring, new code |
|
|
| `solid` | SOLID principles with Go examples | Design review, architecture decisions |
|
|
| `code-review` | Code smell detection + Go-specific checklist | Pre-merge review |
|
|
| `refactoring` | Systematic refactoring methodology (Fowler) | When improving existing code |
|
|
| `test-design` | Dave Farley test design scoring (Farley Index) | Reviewing or writing tests |
|
|
| `cognitive-load` | Cognitive complexity analysis (CLI score) | Identifying hotspots, before refactoring |
|
|
| `problem-analysis` | Deep problem understanding before coding | Starting any non-trivial task |
|
|
| `user-stories` | Elephant Carpaccio story slicing | Breaking down features |
|
|
| `atdd` | Acceptance Test-Driven Development workflow | Feature development with acceptance criteria |
|
|
| `spec-driven-dev` | Spec-driven development for PMs | Writing specs and requirements |
|
|
| `planning` | Planning and task breakdown | Sprint planning, task decomposition |
|
|
| `gitea-ci` | Gitea CI/CD pipeline with act_runner, buildah, k3s, GitHub mirror | Setting up or debugging CI on this infra |
|
|
| `debug` | Hypothesis-first debugging discipline | Any test failure or bug whose cause is not immediately obvious |
|
|
| `feature-spec` | Implementation-level feature spec (tighter than spec-driven-dev) | Scoping one feature inside an already-specced project |
|
|
| `playwright` | Playwright E2E testing — setup, HTMX patterns, SSE streams, CI wiring | Adding browser tests to any project with a web UI |
|
|
| `session-retrospective` | Surface non-obvious learnings from a session log | After a coding session ends, before context is lost |
|
|
| `trainer` | Two-phase brain curation (score candidates, write past quality gate) | Periodic brain pruning and curation |
|
|
| `grill-me` | Structured plan interrogation — Quick Poke, Full Grill, Pre-mortem | Stress-testing a plan before committing; end of Diamond 1; before promoting to pre-prod |
|
|
| `telos-load` | Load TELOS intention substrate at session start | Starting any koala session; before architectural decisions; CAD pipeline entry |
|
|
| `regulatory-risk-assessment` | Structured risk register for regulated-industry features | Filing a CAD issue (needs Risk: level); features touching payments, auth, external APIs, user data |
|
|
|
|
## Wiring into tools
|
|
|
|
The canonical home is `~/dev/.skills/`. Per-tool surfacing is handled by
|
|
`~/dev/.context/wire-skills.sh`:
|
|
|
|
- **Claude Code** — each git repo under `~/dev/` gets a `<repo>/.claude/skills`
|
|
symlink pointing at `~/dev/.skills/`. The symlink is excluded by
|
|
`**/.claude/skills` in `~/.config/git/ignore`, so it never lands in commits.
|
|
- **Crush** — per-skill symlinks under `~/.config/crush/skills/<name>`, added
|
|
alongside existing entries (e.g., `mstack/*`). Skills already present as
|
|
real directories or non-canonical symlinks are preserved.
|
|
|
|
Run `bash ~/dev/.context/wire-skills.sh --dry-run` to preview, then drop the
|
|
flag to apply. The script is idempotent.
|
|
|
|
## Skill Relationships
|
|
|
|
```
|
|
problem-analysis
|
|
│
|
|
└── user-stories
|
|
│
|
|
├── spec-driven-dev (PM-kickoff lifecycle)
|
|
│ │
|
|
│ └── feature-spec (per-feature, mid-implementation)
|
|
│ │
|
|
│ └── planning
|
|
│ │
|
|
│ └── atdd ──→ tdd (foundation)
|
|
│ ├──→ debug (when tests fail)
|
|
│ ├──→ clean-code (REFACTOR phase)
|
|
│ └──→ test-design (review)
|
|
│
|
|
└── planning
|
|
|
|
code-review ──→ refactoring ──→ clean-code
|
|
└──→ solid
|
|
|
|
(post-session)
|
|
session-retrospective ──→ trainer ──→ brain (via brain_write)
|
|
|
|
(planning & convergence)
|
|
grill-me ──→ planning (after plan is sharpened)
|
|
──→ spec-driven-dev (after hypothesis is validated)
|
|
```
|
|
|
|
## Quick Triggers
|
|
|
|
| Situation | Load |
|
|
|-----------|------|
|
|
| "Build this feature" | `problem-analysis` → `spec-driven-dev` → `planning` → `atdd` |
|
|
| "Fix this bug" | `tdd` |
|
|
| "Review this code" | `code-review` |
|
|
| "Refactor this" | `refactoring` + `clean-code` |
|
|
| "Design this system" | `solid` + `problem-analysis` |
|
|
| "Break this down into stories" | `user-stories` |
|
|
| "Write a spec" | `spec-driven-dev` |
|
|
| "This code is hard to understand" | `cognitive-load` |
|
|
| "Review these tests" | `test-design` |
|
|
| "Set up CI for this project" | `gitea-ci` |
|
|
| "CI pipeline is failing / not triggering" | `gitea-ci` |
|
|
| "Commit directly to main? Or branch?" | TBD: commit to main unless parallel agents are active (see `gitea-ci` SKILL §Trunk-Based Development) |
|
|
| "Grill me / stress-test this / is this ready?" | `grill-me` |
|
|
| "End of Diamond 1 — should we build this?" | `grill-me` (Full Grill) |
|
|
| "About to promote to pre-prod" | `grill-me` (Pre-mortem) |
|
|
| "What are the risks?" / "compliance gate" / "risk register" | `regulatory-risk-assessment` |
|
|
| "Start of session" / "load TELOS" / "what are we optimizing toward?" | `telos-load` |
|