Refactor commands to thin wrappers invoking skills

[arittr]

Summary

Refactored the spectacular plugin architecture to implement a pure skills-based design pattern. Commands are now thin wrappers (~5 lines) that invoke skills, with all orchestration logic moved into self-contained skill modules. This reduces cognitive load on users and improves maintainability.

Key Changes

• Commands refactored to thin wrappers: init.md, plan.md, execute.md, and spec.md now simply invoke their corresponding skills rather than containing full implementation logic
• Skills contain all logic: Created/updated skills to be self-contained:
  • validating-environment - Environment validation (replaces init.md logic)
  • decomposing-tasks - Plan generation (replaces plan.md logic)
  • executing-plan - Execution orchestration (replaces execute.md logic)
  • writing-specs - Spec generation (replaces spec.md logic)
• Multi-repo support documented: Added comprehensive section explaining workspace structure, auto-detection, per-repo requirements, and execution behavior for features spanning multiple repositories
• Architecture documentation updated: Clarified command vs skill distinction and updated plugin structure diagram to show the new pure skills architecture
• Development guidelines added: New section on multi-repo feature development workflow

Implementation Details

• Commands now follow a consistent pattern: read input, invoke skill, report results
• Skills are invoked using the Skill tool and followed exactly as presented
• Multi-repo mode auto-detects based on directory structure (multiple .git/ subdirs)
• Plans in multi-repo mode include repo: field for each task
• Parallel phases can execute tasks across different repos simultaneously
• Each repo maintains its own git-spice stack (cannot stack across repos)

Benefits

• Reduced cognitive load: Users see focused command descriptions instead of 300+ line implementations
• Better skill reusability: Skills can be invoked by multiple commands or other skills
• Improved maintainability: Orchestration logic changes don't affect command interfaces
• Clearer separation of concerns: Commands handle user interaction, skills handle implementation
• Multi-repo scalability: Architecture supports complex features spanning multiple repositories