[Bug]: Generated SKILL.md always credits github-spec-kit as author, discarding the extension's declared author

[rickysullivan-gallagher]

Bug Description

Every SKILL.md generated for an extension's commands carries metadata.author: github-spec-kit, regardless of who wrote the extension. The author field an extension declares in its own extension.yml is never used for this, even though the CLI reads that field elsewhere and displays it in specify extension info.

The sibling metadata.source field is correctly namespaced to the extension (acme-demo:commands/...), so the generated file does record where the content came from. Only the attribution is wrong.

The value is a hardcoded literal in a shared helper, and the helper takes no author parameter, so no extension can override it:

# specify_cli/agents.py:439
def build_skill_frontmatter(
    agent_name: str,
    skill_name: str,
    description: str,
    source: str,
) -> dict:
    skill_frontmatter = {
        "name": skill_name,
        "description": description,
        "compatibility": "Requires spec-kit project structure with .specify/ directory",
        "metadata": {
            "author": "github-spec-kit",   # <- line 451
            "source": source,
        },
    }

The same literal appears again at specify_cli/integrations/base.py:1804 and specify_cli/integrations/hermes/__init__.py:196.

This matters because generated skills are written into the consuming team's repository and committed there. Anyone reading them sees third-party operational instructions attributed to GitHub. For extensions that carry an organisation's internal process, that attribution is actively misleading.

Steps to Reproduce

Minimal third-party extension:

mkdir -p acme-demo/commands

cat > acme-demo/extension.yml <<'EOF'
schema_version: "1.0"

extension:
  id: acme-demo
  name: "Acme Demo"
  version: "1.0.0"
  description: "Minimal extension demonstrating author attribution in generated skills."
  author: acme-corp
  license: "MIT"
  effect: "read-only"

requires:
  speckit_version: ">=1.0.0"

provides:
  commands:
    - name: speckit.acme-demo.hello
      file: commands/speckit.acme-demo.hello.md
      description: "Say hello"
EOF

cat > acme-demo/commands/speckit.acme-demo.hello.md <<'EOF'
---
description: "Say hello"
---

# Hello

Say hello.
EOF

# fresh project
cd "$(mktemp -d)"
git init -q && git commit -q --allow-empty -m init
specify init --here --force --non-interactive --integration claude --script sh
specify extension add /path/to/acme-demo --dev --force

cat .claude/skills/speckit-acme-demo-hello/SKILL.md

Expected Behavior

The generated skill should attribute the extension's own author, which the manifest already declares and the CLI already parses:

metadata:
  author: acme-corp
  source: acme-demo:commands/speckit.acme-demo.hello.md

Core Spec Kit commands would continue to read github-spec-kit, which stays correct for them.

Actual Behavior

The declared author is discarded and replaced with github-spec-kit:

---
name: speckit-acme-demo-hello
description: Say hello
compatibility: Requires spec-kit project structure with .specify/ directory
metadata:
  author: github-spec-kit
  source: acme-demo:commands/speckit.acme-demo.hello.md
---

extension.yml declares author: acme-corp. That value appears in specify extension info output but never reaches the generated skill.

Specify CLI Version

1.0.4

AI Agent

Claude Code

Operating System

macOS 26.6.2

Python Version

Python 3.11.10

Error Logs

_No error. The install succeeds and reports success; the attribution is silently wrong._

Additional Context

Scope. build_skill_frontmatter is shared across generators. I verified the extension path only, at specify_cli/extensions/__init__.py:1685. The preset path calls the same helper from four sites in specify_cli/presets/__init__.py (2568, 3087, 3745, 3803), so presets are likely affected identically, but I have not reproduced that and am not claiming it.

Suggested fix. Add an optional author parameter to build_skill_frontmatter, defaulting to github-spec-kit so core generation is unchanged, and pass the manifest's extension.author from the extension and preset call sites. This matches the shape of previously merged fixes that carried a field through skill generation rather than letting it be dropped, such as #2916 and #2978 for argument-hint.

Related. The project already treats generated-artifact provenance as a correctness concern, for example #4092 making preset provenance fail closed. This is the same class of problem in the attribution field.

I searched open and closed issues and PRs before filing, including semantic search, and did not find an existing report. Happy to open a PR if the suggested approach looks right.