feat(skills): ship sample Parsec-native skills + bake into image

[PalmPalm7]

Follow-up to the Agent SDK migration phase 1 (#23 loader + GET /api/skills, #25 Skills UI). Those PRs added the machinery to discover and display skills, but deployed Parsec still shows an empty Skills panel — because nothing equips any skill content.

What's the problem

On parsec-dev, GET /api/skills returns {"count":0,"skills":[]} (HTTP 200 — the endpoint works, it just finds nothing). Root cause:

• the repo's skills/ root holds only .gitkeep,
• dockerfiles/Dockerfile never COPYs skills/ into the image,
• skills.plugin_paths defaults to [], and the deploy mounts no skills.

So the default skills.project_root: "skills" resolves to /app/skills, which doesn't exist in the image → zero skills discovered.

What this changes

1. Ships three real Parsec-native starter skills under skills/, mapped to existing sub-agent domains:
   • cost-spike-investigation (cost)
   • abuse-account-detection (security)
   • aap2-job-failure-triage (aap2)
2. Adds one line — COPY skills/ skills/ — to the production image, so the default project_root: "skills" (→ /app/skills) discovers them.
3. Adds tests/test_shipped_skills.py guarding the shipped skills (load_strict(), all parsec-native, zero validation warnings).

Because the content lives in the image, it auto-deploys via the existing build webhook + ImageChange rollout — no manifest or playbook change required. (Mounting external skill repos at runtime via a ConfigMap + plugin_paths remains available for environments that want it; that's a separate, manifest-level change.)

Additive and read-only. The Skills tab is display-only; nothing executes these skills yet — that's the Phase 2 adapter wiring (#24).

How to verify

# local (mirrors what GET /api/skills does on the pod: project_root "skills", cwd = repo root)
python -c "from src.skills import SkillLoader; from src.config import get_config; \
print([m.name for m in SkillLoader.from_config(get_config()).load_all()])"
# -> ['aap2-job-failure-triage', 'abuse-account-detection', 'cost-spike-investigation']

pytest tests/test_shipped_skills.py -q

Result

• Local gate green: black / ruff / mypy (src/) + pytest (89 passed, incl. the new guard).
• After merge + image rebuild, GET /api/skills returns count: 3 and the Skills sidebar lists the three cards (parsec-native badges) instead of the "No skills discovered" empty state.

[PalmPalm7]

In short, currently parsec-dev doesn't have the skills displayed because nothing puts any skill content on dev to display. The loader and UI (PRs #23/#25) work fine — /api/skills returns 200 — but it scans /app/skills, which is empty: the repo ships no SKILL.md (just a .gitkeep), the Dockerfile never copies skills/ into the image, plugin_paths is [], and the deploy mounts no skills. So it correctly finds zero skills.

[rut31337]

Code Review — PR #27

Scope: 5 files, +177 lines — 3 seed skills + Dockerfile COPY + test
Effort: High

Findings (3)

All three findings share the same root issue: allowed-tools: ["mcp__reporting__*"] is too restrictive for what the skill procedures describe. Not a problem today (skills are display-only in Phase 1), but will break when Phase 2 execution wires up.

1. cost-spike-investigation: allowed-tools too narrow (skills/cost-spike-investigation/SKILL.md:5)
Procedure requires AWS Cost Explorer (query_aws_costs), Azure billing (query_azure_costs), GCP BigQuery (query_gcp_costs), and cost-monitor tools — but allowed-tools restricts to only reporting MCP (the provision DB). The full cost agent has 11 tools beyond reporting.

2. aap2-job-failure-triage: allowed-tools too narrow (skills/aap2-job-failure-triage/SKILL.md:5)
Step 1 needs query_aap2 to resolve the job, step 2 needs query_splunk for pod logs, step 4 needs fetch_github_file to trace config files. All blocked by the restriction.

3. abuse-account-detection: allowed-tools too narrow (skills/abuse-account-detection/SKILL.md:5)
Step 2 needs query_aws_account (describe_instances) to check for GPU instances and "Web-Created-VM" names. The full security agent includes query_cloudtrail, query_aws_account, query_marketplace_agreements.

No other issues found. Dockerfile COPY placement, test imports, and frontmatter validation all look correct. Clean PR.