d29cf651c7
* fix(skills): move version into metadata and normalize to semver 29 skills declared `version` at the top level of their frontmatter. The schema reads it from `metadata`, so tooling that follows the schema either misses it or has to special-case the top level. Three motion skills also declared `version: 1.0`, which is not a valid semantic version; normalized to `1.0.0`. No behavioral change — frontmatter metadata only. * fix(skills): state activation triggers in skill descriptions 148 skills described what they cover but never named the situation that should trigger them. Since the description is what Claude matches against to decide whether to load a skill, a description without a trigger makes activation guesswork — the skill is either missed or loaded at the wrong time. Added a "Use when ..." clause to each, derived from the skill's own body (most already stated the trigger under "## When to Use" or in the opening line; that intent is now reflected in the frontmatter where it is actually read from). Descriptions were only appended to; no existing wording was removed. * fix(skills): sync activation triggers into the Codex skill mirror 10 of the skills whose descriptions changed are also mirrored under `.agents/skills/`, where the description was previously a verbatim copy. Left alone, the two surfaces would disagree about when the skill applies. Only the description line is synced; the Codex copies keep their reduced frontmatter, since that validator accepts only name, description, metadata, license, and allowed-tools. * fix(skills): correct three activation clauses from review - autonomous-loops: the clause pulled new loop work into a skill that its own body marks as a compatibility shim retained for one release. It now points at the canonical continuous-agent-loop instead. - continuous-learning: the description carried the v1 routing directive twice; collapsed to one. - homelab-pihole-dns: the clause fired on any broken home DNS. Narrowed to tasks that actually involve Pi-hole. * chore: retain current main lockfile --------- Co-authored-by: Çağrı Solakoğlu <cagri.solakoglu@vtcenerji.com> Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
6.2 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| orch-pipeline | Shared orchestration engine for the orch-* skill family. Defines the gated Research-Plan-TDD-Review-Commit pipeline, the size classifier, the agent map, and the two human gates that the orch-* operation skills delegate to. Not usually invoked directly. Not usually invoked directly; it applies when an orch-* skill delegates its gated Research-Plan-TDD-Review-Commit pipeline. |
|
Orchestrator Pipeline (shared engine)
The orch-* skills are thin wrappers. They do not re-implement any work — they
classify the request, choose which phases of this pipeline run, and delegate
each phase to an existing ECC agent or command. This file is that pipeline.
Invoke an operation skill (
orch-add-feature,orch-fix-defect, …) rather than this engine directly. This file is the reference they point at.
When to Use
- Loaded indirectly whenever an
orch-*operation skill runs. - Read directly only when adding a new operation to the family or tuning the shared phases, gates, or agent map.
The operation family
| Skill | Operation | Trigger | First move |
|---|---|---|---|
orch-add-feature |
feature | capability does not exist yet | research + plan a new slice |
orch-change-feature |
tweak | works, but desired behavior differs | amend existing behavior and its tests |
orch-fix-defect |
fix | broken; behavior is wrong | reproduce as a failing test, then fix |
orch-refine-code |
refactor | behavior stays, structure improves | restructure while keeping tests green |
orch-build-mvp |
mvp | bootstrap from a design/spec doc | ingest doc → vertical slices |
These wrappers compose existing ECC commands rather than replace them:
/feature-dev,/plan,/code-review,/build-fix,/refactor-clean, and/gan-build, plus thetdd-workflowskill. The orch-* family adds the shared size classifier and the two gates on top of them, so one umbrella covers all five operations consistently.
Step 0 — Classify size (right-sizing)
Ceremony scales to blast radius. Score the request on three signals, take the highest tier any signal reaches, and state the result in one line so the user can override:
| Tier | Files touched | New dependency / contract | Design ambiguity | Phases that run |
|---|---|---|---|---|
| trivial | 1, a few lines | none | none — the change is obvious | 4 → 5 → 6 |
| small | 1 file / 1 function | none | clear once you read the code | (1 light) → 4 → 5 → 6 |
| standard | 2–5 files | maybe a new internal module | one real choice to make | 1 → 2 → 4 → 5 → 6 |
| large | many / cross-cutting | new external dep, public API, or a spec doc | multiple open questions | 1 → 2 → (3) → 4 → 5 → 6 |
Phase 0 (Intake) always runs and is omitted from the mask column above. The tie-breaker: anything touching a security trigger (below) or a public API / contract is at least standard, regardless of file count.
The phases
Each phase delegates — it does not do the work inline.
- 0. Intake — restate the request. For
orch-build-mvp, read the spec/design doc and extract scope, locked decisions, and a feature list. - 1. Research & Reuse — per
rules/common/development-workflow.md:gh search repos/gh search code, then Context7 / vendor docs, then package registries, then Exa. Prefer adopting a proven implementation over net-new code. - 2. Plan — delegate to the
planneragent (orarchitect/code-architectfor structural decisions). Output atask_listordered as thin vertical slices. → GATE 1. - 3. Scaffold —
orch-build-mvponly: stand up the first end-to-end slice. - 4. Implement (TDD) — drive each task through the
tdd-guideagent (or thetdd-workflowskill): red → green → refactor. Honor the operation's first-move rule. - 5. Review —
code-revieweragent //code-review. Addsecurity-reviewerwhenever the diff touches a security trigger (below). - 6. Commit — conventional commits (
feat:/fix:/refactor:/ …), one per logical chunk. → GATE 2.
The two gates
This family is gated, not autonomous:
- GATE 1 — after Plan. Present the
task_list; do not write implementation code until the user approves. - GATE 2 — before Commit. Present the diff summary and proposed messages; do not commit until the user confirms.
Everything between the gates flows without stopping.
Agent / command map
| Phase | Primary | Fallback / escalation |
|---|---|---|
| Intake / understand | code-explorer |
trace existing paths before a tweak, fix, or refactor |
| Plan | planner |
architect, code-architect for structural calls |
| Implement | tdd-guide (or tdd-workflow skill) |
build-error-resolver / /build-fix on build breaks |
| Review | code-reviewer / /code-review |
language reviewer (python-reviewer, typescript-reviewer, …) |
| Security | security-reviewer |
— |
| MVP inner loop | /gan-build "<brief>" --skip-planner |
drives gan-generator → gan-evaluator; tune --max-iterations / --pass-threshold |
Match the language reviewer to the repo (see the repo's own CLAUDE.md).
Security-review trigger
Pull in security-reviewer when the diff touches any of: authentication or
authorization, user-input handling, database queries, file-system paths,
external API calls, cryptography, or secrets / credentials. (Per rules/common/security.md.)
Handoff artifacts
The pipeline carries no hidden state — the planning docs are the handoff:
task_list(from Plan) drives the Implement loop.- Larger work may also emit PRD / architecture / system_design under the repo's
docs/perrules/common/development-workflow.md. - Review findings (CRITICAL / HIGH) must be resolved before Gate 2.
Verification
- size tier was stated and matched the work
- Gate 1 (plan) and Gate 2 (commit) were both honored
security-reviewerran iff a security trigger was touched- commits are conventional and scoped to one logical change
- new / changed behavior has tests; coverage ≥ 80% per
rules/common/testing.md