How skills interact

How skills interact

Flow

The sylva-docs roadmap and this handbook are the context you (and the agent) use to decide what to do. The sylva-github umbrella skill points to the right focused skill and page. Focused skills drive GitHub as the execution surface (PRs, releases, issue cleanup, Projects v2 exports via gh).

flowchart LR
  docs[sylva_docs_handbook_and_roadmap]
  umbrella[sylva_github_SKILL]
  shipSkill[ship_ready_changes]
  prSkill[sylva_pr_workflow]
  relSkill[sylva_release_notes]
  hygSkill[sylva_github_hygiene]
  projSkill[sylva_github_projects]
  gh[GitHub]
  docs --> umbrella
  umbrella --> shipSkill
  umbrella --> prSkill
  umbrella --> relSkill
  umbrella --> hygSkill
  umbrella --> projSkill
  shipSkill --> gh
  prSkill --> gh
  relSkill --> gh
  hygSkill --> gh
  projSkill --> gh

Ship ready (commit + push + sync)

When you want the agent to finish the job on disk and on GitHub, invoke ship-ready-changes. It always posts a markdown shipping table (Field | Value, four rows) then the line Do you want to ship the changes as indicated?—no extra prose in between—then AskQuestion (Confirm / Wait — revise) before any git add / git commit / git push (no exceptions). Wait — revise means no git writes until you explain what to fix; then a new table + question + buttons. After shipping: git pull --ff-only, clean git status, optional SCM refresh reminder.

For every workspace, paste the plain-text block from ~/.cursor/skills/ship-ready-changes/USER-SETTINGS-SNIPPET.md into Cursor → Settings → Rules (Ship ready). See Where things live for paths.

How to use the umbrella

1. Invoke the sylva-github skill (or ask the agent to follow it) when you are unsure which workflow applies.
2. The umbrella does not replace the focused skills—it routes: “if PR → use sylva-pr-workflow + PR and branching”, etc.
3. Deep policy (multi-repo habits, release wording, issue closure templates) lives in this handbook, not in long SKILL.md files.

Order of operations (multi-repo feature)

1. Plan in roadmap / triage docs if the feature is non-trivial (Roadmap authority).
2. Branch per repository you touch; open draft PRs early and link them in descriptions (PR and branching).
3. Verify with smoke / acceptance paths; merge when green enough for your solo bar.
4. Ship with a release or deploy process per repo; update Shipped narrative in roadmap when appropriate (Releases and changelog).
5. Tidy GitHub: close superseded issues with links to docs (GitHub hygiene).