feat(engine): stage skill: property — programmatic plugin skill binding

[iamcxa]

Problem

Workflow plugins (like ship-flow) provide stage-specific skills, but there's no structured way for the engine to tell an ensign which plugin skill to load for a given stage. Currently ensigns improvise from README prose — unreliable for complex stages.

Solution

Three small changes that enable structured skill binding:

1. Commission template: skill: stage property

- name: plan
  skill: ship-flow:ship-plan   # ← new
  model: sonnet

Commission now documents skill: alongside existing properties (worktree, gate, agent, model).

2. Status parser: preserve skill: in stage dict

# bin/status line 261
for optional_field in ('feedback-to', 'agent', 'fresh', 'model', 'skill'):

One field added to the optional list.

3. claude-team build: inject Skill() into ensign prompt

stage_skill = stage_meta.get('skill')
if stage_skill:
    prompt_parts.append(
        f'**Before starting work**, invoke `Skill("{stage_skill}")` to load '
        f'the stage skill. Follow its instructions for this stage.\n'
    )

Ensign prompt now gets a structured Skill() instruction before the stage definition.

Verified

Tested against a live ship-flow workflow (4 stages: sharp/plan/execute/ship). All 4 stages correctly inject their Skill() call into the ensign prompt with the matching model dispatch.

Diff

• skills/commission/SKILL.md: +3 lines (skill: property in template + prose instruction)
• skills/commission/bin/status: +1 field in optional_fields list
• skills/commission/bin/claude-team: +6 lines (skill injection in prompt assembly)

Total: 10 insertions, 2 deletions.

[iamcxa]

Re-audited this PR's scope per your feedback on other PRs in this batch:

• Commits: 2 (c73ab9be programmatic skill binding + 000163df commission skill: property)
• Files: skills/commission/bin/claude-team, skills/commission/bin/status, skills/commission/SKILL.md
• All in-scope for the title — no infrastructure noise from other feature branches.

Ready for review when you get a chance. #134 and #135 have now been rebased independently (each containing only their claimed scope). #130 still pending a separate scope decision (your suggestion to move it to its own skill).

[clkao]

can you see if referencing the skill in the stage definition works?