fix(project): refuse to re-init a project that lost its config.yaml

[salmonumbrella]

Type

• Bug fix
• Small improvement (docs, typo, minor refactor)
• Feature proposal (proposals/ only — see CONTRIBUTING.md)

Linked Issue

Split out of #258 at your request — this is the missing-config guard on its own, with none of the visible-directory changes. #258 will be rebased on top of this so the feature can be reviewed separately.

Problem

Every project-mode command auto-initializes when .skillshare/config.yaml is missing. That is right for a repository with no project directory at all, and for the shared skills repo produced by init -p --config local, which gitignores config.yaml so each developer regenerates their own.

It was wrong for the case in between. A .skillshare/ that already held skills or agents, whose config.yaml was simply gone, was re-initialized into an empty config: every configured target dropped, target symlinks left behind pointing at a project the config no longer described, exit code 0, nothing reported.

Approach

A new ensureProjectConfig helper in cmd/skillshare/mode.go replaces the open-coded if !projectConfigExists { performProjectInit } pattern at every project entry point (17 call sites across 13 files — the same sites #258 touched, minus everything visible-directory related).

It initializes exactly as before when there is no project directory, and when config.yaml is covered by .skillshare/.gitignore — so both intentional auto-init cases are unchanged. When the directory holds skills or agents and its config is neither present nor gitignored, it returns an error pointing at version control or an explicit skillshare init -p instead of writing over the project.

Two deliberate details:

• The gitignore check is treated as inconclusive on error, so a repository that cannot be inspected is guarded rather than overwritten.
• Dotfile-only entries under skills/ or agents/ do not count as content, so an effectively-empty directory still repairs silently.

Test coverage

cmd/skillshare/require_project_config_test.go covers the guard in all four states — initialized project, no project directory (still bootstraps), gitignored-config shared repo (still repairs, content untouched), and a content-bearing project without a config (errors, writes nothing) — plus agents-only content, an empty project directory, and a command-level regression test that status -p refuses rather than overwriting.

gofmt, go vet ./... and go build ./... are clean. go test ./... shows no failures beyond the two that already fail on unmodified main in my environment (TestCommitSourceFiles_CommitFailureIsReturned and TestGitRootMismatch, both host-git-config dependent — same two noted in #258).

Checklist

• I've read CONTRIBUTING.md
• Tests included and passing — for code changes
• No unrelated changes in the diff
• Scope is focused — one concern per PR

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.