mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-20 03:40:29 +08:00
db7f2a6fd5
The official Agent Skills spec (agentskills.io/specification) whitelists exactly 6 top-level frontmatter keys (name/description/license/compatibility/metadata/ allowed-tools). A top-level `origin` key fails the official validator (anthropics/skills quick_validate.py ALLOWED_PROPERTIES; skills-ref validate). This moves `origin: X` -> `metadata.origin: X` across the canonical skills/ tree, preserving each value verbatim. Frontmatter-only, minimal diff. - 251 SKILL.md updated (242 new metadata block, 9 appended to existing metadata) - origin values preserved verbatim (verified 251/251) - YAML validated on all changed files - scoped to canonical skills/ only (docs/<lang> translations + tool mirrors .cursor/.kiro/.agents left untouched; presumably regenerated from canonical) Addresses #2233
46 lines
1.8 KiB
Markdown
46 lines
1.8 KiB
Markdown
---
|
|
name: orch-add-feature
|
|
description: Orchestrate building a brand-new feature end to end — research, plan, TDD implementation, review, and gated commit — by delegating each phase to the matching ECC agent. Use when adding a capability that does not exist yet.
|
|
metadata:
|
|
origin: ECC
|
|
---
|
|
|
|
# orch-add-feature
|
|
|
|
Actor · action · target: **orch · add · feature**. Thin wrapper over the shared
|
|
engine in [`orch-pipeline`](../orch-pipeline/SKILL.md).
|
|
|
|
## When to Use
|
|
|
|
- The user wants a capability that does **not exist yet** ("add", "build",
|
|
"implement", "support …").
|
|
- It is net-new behavior — not a correction (`orch-fix-defect`) and not an
|
|
alteration of existing behavior (`orch-change-feature`).
|
|
|
|
## Operation settings
|
|
|
|
- **Default size floor:** standard — run Research + Plan unless clearly small.
|
|
- **Phase mask:** 0 → 1 → 2 → 4 → 5 → 6 (skip 3 Scaffold; that is MVP-only).
|
|
- **First move (phase 4):** write *new* failing tests for the new behavior, then
|
|
implement to green.
|
|
|
|
## How It Works
|
|
|
|
1. Run the `orch-pipeline` engine with the settings above.
|
|
2. Classify size first; small / trivial features collapse toward 4 → 5 → 6.
|
|
3. Stop at **Gate 1** (plan approval) and **Gate 2** (pre-commit).
|
|
4. Add `security-reviewer` if the feature touches a security trigger.
|
|
|
|
> Related: `/feature-dev` is a standalone version of this flow. `orch-add-feature`
|
|
> differs by sharing the `orch-pipeline` engine — the size classifier and the two
|
|
> gates — with the rest of the family, so it right-sizes trivial features to 4 → 5 → 6.
|
|
|
|
## Example
|
|
|
|
```
|
|
orch-add-feature: add OAuth2 login to nws-poller
|
|
→ research existing auth libs → plan task_list [GATE 1: approve]
|
|
→ TDD each task → code-review (+ security-reviewer: auth path)
|
|
→ commit [GATE 2: confirm]
|
|
```
|