feat(skills): curate the core first-party engineering skill candidates from staging #10

Summary

Review and promote the six broadly reusable first-party engineering skill
candidates that are required by Aether's staged generic custom agents. Bring
them into the canonical library using the same contracts, provenance,
progressive-disclosure, and evaluation standards as the stabilized architecture
suite.

The six candidates are:

• skill-authoring
• github-issue-authoring
• implementation-planning
• bug-fixing
• repository-cleanup
• test-engineering

Evidence from the current repository

• All six exist under .staging/skills/ but not in the canonical library.
• Staged generic agents reference five of them directly through consumer paths
  under .agents/skills/.
• Older or semantic-overlap copies also exist under .staging/todo/skills/,
  including github-issue, create-skill, and repository-audit variants.
• The staged candidates do not yet have a canonical Aether catalog identity,
  normalized metadata, governing spec relationship, complete eval coverage, or
  release lifecycle.
• Publishing generic agents before their skills exist would create broken or
  duplicated behavior.

Goal

Add six high-value, provider-neutral, first-party skills to Aether without
expanding into the entire staged skill collection.

Required work

For each candidate:

1. Establish authorship/provenance. Confirm it is Ego Hygiene first-party
   content or document the exact source and license before adaptation.
2. Compare all direct and legacy staged variants. Produce a short source-delta
   record describing what was adopted, rewritten, or rejected.
3. Choose one stable identity and directory name. Avoid synonym duplicates such
   as github-issue and github-issue-authoring unless they own genuinely
   different workflows.
4. Place the canonical source under the architecture-approved domain within
   library/organization/skills/.
5. Normalize SKILL.md to the current Agent Skills specification and Aether
   metadata/catalog contract.
6. Ensure the skill is provider-neutral. Provider-specific instructions belong
   in references or generated integration profiles, not in the core workflow.
7. Add focused references, templates/assets, and scripts only when they reduce
   repeated work or make behavior deterministic.
8. Add structured evaluations equivalent to the requirements from issue 008,
   including positive, negative, insufficient-evidence, boundary, and update
   cases.
9. Add a governing specification only if the workflow needs a normative
   contract that is not already owned elsewhere. Do not create specs merely for
   symmetry.
10. Register each skill in the first-party catalog with lifecycle state
    experimental or the accepted equivalent until consumer tests pass.
11. Update the staging disposition ledger. Once unique content and provenance
    are preserved, remove only the exact Aether-owned staged candidate copies
    covered by this issue.

Skill-specific boundaries

skill-authoring

Own creation and maintenance of portable skill packages, including trigger
descriptions, progressive disclosure, evals, scripts, licensing, and validation.
Do not become a generic plugin installer.

github-issue-authoring

Own transformation of evidence, specs, audits, and brain dumps into copy-ready,
implementation-scoped GitHub issues. Preserve the user's formatting preference:
inner code examples use four-space indentation when fenced blocks would break
copying/rendering.

implementation-planning

Own dependency-aware implementation plans from accepted requirements and
architecture. It must not silently implement code or reopen accepted decisions.

bug-fixing

Own reproduce -> diagnose -> minimal fix -> regression test -> validate. Keep
diagnosis separate from implementation when the request authorizes only an
investigation.

repository-cleanup

Own behavior-preserving hygiene and consistency work. It must not become a
license to redesign architecture or delete uncertain files.

test-engineering

Own meaningful deterministic test design and implementation. It must not chase
coverage percentages by weakening assertions or testing implementation trivia.

Validation

Run:

aether validate --format "text"
aether eval run --mode "deterministic" --format "text"

Use the accepted current command names if they differ.

Also verify that no canonical agent/skill reference resolves to the old staged
paths and no synonym identity was created accidentally.

Acceptance criteria

• Six canonical first-party skill packages exist with unique stable identities.
• Every package satisfies the Agent Skills and Aether metadata contracts.
• Provenance/authorship and license are explicit for every adopted package.
• Each package has focused progressive-disclosure resources where needed.
• Each package has complete deterministic eval coverage.
• Generic behavior is provider-neutral.
• Synonym/legacy variants have an explicit source-delta disposition.
• The first-party catalog contains all six as experimental or the accepted equivalent.
• Only the covered Aether-owned staged copies are removed after preservation.
• Flutter, Mindgarden, external, and unrelated staged skills remain untouched.
• Validator and deterministic evals pass.

Non-goals

• Curating all staged skills
• Creating custom agents
• Installing skills into every repository
• Publishing a release
• Adopting Flutter, knowledge-extraction, synapse, marketing, design, security,
  or other external/domain-specific skill collections

Dependencies

• Issue 006: catalog/provenance contracts
• Issue 007: deterministic validator
• Issue 008: executable eval harness

Copilot execution instructions

• Do not infer first-party ownership merely because a file is in .staging.

• Preserve unique content before removing a staged copy.

• Keep this PR limited to the six named skills.

• Use a conventional commit such as:

  feat(skills): curate core engineering skill suite
  

• Include a six-row provenance, identity, resource, eval, and staging-disposition
  matrix in the PR body.