Skip to content

chore(#163): default split-portfolio sibling repo to <fork>-portfolio#164

Merged
atlas-apex merged 1 commit into
me2resh:devfrom
atlas-apex:feature/GH-163-fork-portfolio-naming-default
May 4, 2026
Merged

chore(#163): default split-portfolio sibling repo to <fork>-portfolio#164
atlas-apex merged 1 commit into
me2resh:devfrom
atlas-apex:feature/GH-163-fork-portfolio-naming-default

Conversation

@atlas-apex

Copy link
Copy Markdown
Collaborator

Summary

Closes #163. Defaults the split-portfolio sibling repo name to <fork>-portfolio (e.g. your-org/apexyard-portfolio for the canonical fork name). The previous default — your-org/ops plus a bare portfolio/ directory — was too generic: adopters running multiple ops setups hit naming collisions, and a bare portfolio/ 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 to cos-portfolio / apex-portfolio. Adopters who picked a different name keep working — the portfolio: 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 remaining your-org/ops references at lines 52 + 64 are FORK-rename examples (renaming the fork itself); those stay valid (renaming a fork to ops would just produce ops-portfolio for the sibling, still self-documenting).
  • .claude/skills/setup/SKILL.md — Step 2b's "default suggestion" for the private repo name is now your-org/<fork>-portfolio, computed dynamically via gh repo view --json name -q .name so 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>-portfolio with the same dynamic-fork-name resolution.

Testing

  • Grep verificationgrep -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 to your-org/ops remain in the split-portfolio walkthrough.
  • Path consistencygrep -rn "../portfolio/" docs/ .claude/skills/ returns 0 matches. All split-portfolio config-block / symlink examples use ../apexyard-portfolio/.
  • AgDR-0010 unchanged — historical decision record reference to "ops-fork" is generic terminology (the framework fork's role), not a name; kept as-is.
  • apexyard.projects.yaml.example unchanged — uses "ops repo" as generic terminology for the framework fork; not a name.
  • Visual review of the rendered docs (manual) — confirm the layout diagrams + walkthrough flow read cleanly with the new naming.

Glossary

Term Definition
<fork>-portfolio The new default sibling-repo / sibling-dir name for split-portfolio mode. <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.
Dynamic fork-name resolution The skill computes <fork> at runtime via gh repo view --json name -q .name, so the suggestion is correct whether the fork is apexyard or has been renamed. Adopters never have to manually substitute.
Mechanism unchanged The portfolio: config block in .claude/project-config.json still takes any path. Adopters with existing ops/ setups keep working — only the default suggestion + example prose changes.
Self-documenting on disk A directory listing of ~/Projects/<orgname>/ shows apexyard/ and apexyard-portfolio/ next to each other; the relationship is obvious without reading any docs. The previous bare portfolio/ lost that signal as soon as another unrelated portfolio/ dir landed nearby.

🤖 Generated with Claude Code

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants