pn-program-orchestration

Program orchestration

When used as a standalone skill, begin every response with [pn-skill] 🔺

When to use

Use this skill when conducting a feature_program workflow — decomposing a project into ≥2 independent vertical slices, locking contracts, and orchestrating parallel execution. Also consult when deciding whether to route a task to feature_program vs /pn-build.

When to use feature_program vs /pn-build

Use workflow_step("feature_program", 0, {}) when the discovery spec reveals ≥2 independent surface areas that can be built concurrently without one blocking the other. Classic signals:

• A new full-stack app with a distinct frontend slice, backend/API slice, and infra/data-model slice.
• A platform where multiple product verticals (auth, billing, notifications) are being built simultaneously.
• A migration where the new stack runs in parallel with the old one and both have separate work streams.

Route to /pn-build instead when:

• The feature is a single work stream (one team, sequential tasks, shared files).
• The total scope is small enough that the orchestration overhead exceeds the parallelism gain.
• Discovery produces only one meaningful slice — workflow_step will hard-exit and direct you here anyway.
• The user says "just build it."

Rule of thumb: if you hesitate for more than 30 seconds naming a second independent slice, use /pn-build.

Slice decomposition rules

Vertical slices, not horizontal layers

Each slice should deliver an end-to-end slice of value — a feature or bounded domain, not a layer (not "the frontend layer" of everything). A slice owns its own UI, data, and integration surface.

Good slice boundaries:

• slice-auth — user identity, sessions, MFA
• slice-payments — billing, invoicing, webhooks
• slice-settings — user preferences, notification config

Bad slice boundaries (these are layers, not slices):

• slice-frontend — all frontend across all features (creates coupling)
• slice-database — all DB migrations (owned by infra slice instead)