chore(#163): default split-portfolio sibling repo to <fork>-portfolio#164
Merged
atlas-apex merged 1 commit intoMay 4, 2026
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #163. Defaults the split-portfolio sibling repo name to
<fork>-portfolio(e.g.your-org/apexyard-portfoliofor the canonical fork name). The previous default —your-org/opsplus a bareportfolio/directory — was too generic: adopters running multiple ops setups hit naming collisions, and a bareportfolio/dir gives no signal about which framework it belongs to.The new default makes the relationship to the public fork self-documenting on disk and on GitHub. If the fork is renamed (
your-org/cos,your-org/apex), the portfolio defaults tocos-portfolio/apex-portfolio. Adopters who picked a different name keep working — theportfolio:config block resolves whatever path they configured.Mechanism unchanged. This is a default-suggestion + example-prose update only.
Files changed
docs/multi-project.md— split-portfolio layout diagrams, setup walkthrough, config-block / symlink examples, daily-workflow cd commands, cross-machine clone command. The two remainingyour-org/opsreferences at lines 52 + 64 are FORK-rename examples (renaming the fork itself); those stay valid (renaming a fork toopswould just produceops-portfoliofor the sibling, still self-documenting)..claude/skills/setup/SKILL.md— Step 2b's "default suggestion" for the private repo name is nowyour-org/<fork>-portfolio, computed dynamically viagh repo view --json name -q .nameso the suggestion stays correct even when the fork was renamed. Clone command drops the second arg (repo name IS the directory name now)..claude/skills/split-portfolio/SKILL.md— Step 3's suggested-name template is now<account>/<fork>-portfoliowith the same dynamic-fork-name resolution.Testing
grep -rn "your-org/ops" docs/ .claude/skills/returns only the two intentional FORK-rename examples (docs/multi-project.md:52,:64,docs/getting-started.md:20). No prose references toyour-org/opsremain in the split-portfolio walkthrough.grep -rn "../portfolio/" docs/ .claude/skills/returns 0 matches. All split-portfolio config-block / symlink examples use../apexyard-portfolio/.apexyard.projects.yaml.exampleunchanged — uses "ops repo" as generic terminology for the framework fork; not a name.Glossary
<fork>-portfolio<fork>is the public-fork repo name (e.g.apexyard,cos,apex). Both the GitHub repo and the local sibling-clone dir use this name.<fork>at runtime viagh repo view --json name -q .name, so the suggestion is correct whether the fork isapexyardor has been renamed. Adopters never have to manually substitute.portfolio:config block in.claude/project-config.jsonstill takes any path. Adopters with existingops/setups keep working — only the default suggestion + example prose changes.~/Projects/<orgname>/showsapexyard/andapexyard-portfolio/next to each other; the relationship is obvious without reading any docs. The previous bareportfolio/lost that signal as soon as another unrelatedportfolio/dir landed nearby.🤖 Generated with Claude Code