elias/everything-claude-code
1
0
Fork 0
mirror of https://github.com/affaan-m/everything-claude-code.git synced 2026-06-19 11:20:48 +08:00
Code Issues Packages Projects Releases Wiki Activity
everything-claude-code/skills/orch-change-feature/SKILL.md
BERORINPO db7f2a6fd5 fix(skills): move top-level origin frontmatter key under metadata 
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
2026-06-11 21:12:21 +09:00

1.7 KiB
Raw Blame History

name, description, metadata
name description metadata
orch-change-feature Orchestrate altering an existing, working feature to new desired behavior — update its tests to the new spec, change the implementation to match, review, and gated commit. Use when behavior is not broken but should be different.
origin
ECC

orch-change-feature

Actor · action · target: orch · change · feature. Thin wrapper over the shared engine in orch-pipeline.

When to Use

  • An existing feature works, but the desired behavior is different ("change", "adjust", "make it also …", "instead of X do Y").
  • Distinguish from siblings:
    • not broken → not orch-fix-defect (no bug to reproduce).
    • not new → not orch-add-feature (the capability already exists).

Operation settings

  • Default size floor: small — most tweaks are a function or two.
  • Phase mask: 0 → (1 only if the new behavior needs research) → light 2 → 4 → 5 → 6.
  • First move (phase 4): update the existing tests to express the new desired behavior, then change the implementation until they pass. Changing the tests first is what separates a tweak from a fix.

How It Works

  1. Run the orch-pipeline engine with the settings above.
  2. Keep the plan light — only standard+ size warrants the full planner pass.
  3. Stop at Gate 1 (plan / changed-test approval) and Gate 2 (pre-commit).
  4. Add security-reviewer if the change touches a security trigger.

Example

orch-change-feature: make nws-poller alert at 2 warnings instead of 3
→ update threshold tests to new spec → change impl to green
→ code-review → commit  [GATE 2: confirm]