Area
Developer tooling
Problem
Dogfood app files under examples/ appeared as untracked changes while working on CLI and skill updates.
That makes it easy to accidentally mix app implementation files into CLI/docs PRs and weakens the separation between generated CLI/spec files, skill/docs changes, local dogfood artifacts, and future reusable examples/templates.
Proposal
Isolate local dogfood app artifacts from normal CLI changes by either ignoring those directories or moving them to a clearly non-PR workspace.
If reusable examples are intended to be tracked later, define a separate template/demo policy. .gitignore or repo docs should make it clear which app artifacts should never be committed.
Alternatives considered
Keep local dogfood apps in examples/ and rely on manual review. That makes git status noisy and increases PR scope risk.
Compatibility and migration
This should affect repository hygiene only. PRs for CLI/skill changes should become easier to review without unrelated examples/ noise.
Acceptance criteria:
- Local dogfood app directories are ignored or moved to a clearly non-PR workspace.
- Reusable examples have a separate template/demo policy if they will be tracked later.
.gitignore or docs clarify which app artifacts should never be committed.
- CLI/skill PRs can be reviewed without unrelated
examples/ changes.
Contribution
I can provide product feedback
Checklist
Area
Developer tooling
Problem
Dogfood app files under
examples/appeared as untracked changes while working on CLI and skill updates.That makes it easy to accidentally mix app implementation files into CLI/docs PRs and weakens the separation between generated CLI/spec files, skill/docs changes, local dogfood artifacts, and future reusable examples/templates.
Proposal
Isolate local dogfood app artifacts from normal CLI changes by either ignoring those directories or moving them to a clearly non-PR workspace.
If reusable examples are intended to be tracked later, define a separate template/demo policy.
.gitignoreor repo docs should make it clear which app artifacts should never be committed.Alternatives considered
Keep local dogfood apps in
examples/and rely on manual review. That makesgit statusnoisy and increases PR scope risk.Compatibility and migration
This should affect repository hygiene only. PRs for CLI/skill changes should become easier to review without unrelated
examples/noise.Acceptance criteria:
.gitignoreor docs clarify which app artifacts should never be committed.examples/changes.Contribution
I can provide product feedback
Checklist