Org patterns
Small instructions that scale with the org
Patterns are not vendor “skills”. They are versioned markdown in this repo — onboarding playbooks, scheduled cloud roles, and lane playbooks (seeded from the reference org stack). Agents adapt the text to Cursor, Cloud Code, or whatever runtime you run.
Why
Distributed improvements
One manifest points at files under prompts/. Merge review is your moderation gate: proposals land as normal PRs, then every project that pins this repo sees the update.
Neutral shape
Runtime-agnostic
No generator layer: agents already reshape markdown for their host. You keep one canonical source; each runtime carries its own adapter habits.
Discovery
List + body API
Pair ship patterns list with ship docs search when you need fuzzy match; use ship patterns show <id> when you already know the id.
How teams use this
- 1
Pin the repo (or subtree)
Treat
patterns/manifest.jsonas the manifest index. Your fork owns the manifest; upstream Ship can be merged like any other dependency. - 2
Give agents a standing policy
In your root agent instructions: before a task, call the methodology API — list patterns, optionally search, fetch the body, compare to what the workspace already cached, then adapt locally.
- 3
Change through PRs only
Agents may open branches and propose edits; humans merge. That keeps the pattern set moderated without banning automation from the author seat.
Operational detail for ElMundi-style wiring lives in documentation/examples/elmundi.
Index
Every pattern in this repo
Reviewable instruction slices for agents: onboarding, scheduled cloud roles, and lane playbooks aligned to the SDLC grid (file names A1–A12 remain for reference). Currently 23 entries.
- Onboarding
Adopt Ship (baseline)
Primary onboarding playbook before any org-specific addendum.
onboardingadoption - Onboarding
Adopt Ship (reference org)
Queue names, digest/retro, QA-first habits; apply after the baseline playbook.
onboardingreference-org - Cloud agent
Shared base
Cross-role guardrails and tone for scheduled cloud agents.
guardrailstone - Cloud agent
Intake
Role prompt for intake lane on the SDLC grid.
intaketriage - Cloud agent
Clarification
Structured follow-ups when requirements are incomplete.
clarificationrequirements - Cloud agent
BA / specification
Specification and handoff quality before implementation picks.
baspec - Cloud agent
Developer
Implementation role: branch contract, PR shape, evidence.
implementationpr - Cloud agent
QA architect
Test strategy and automation hooks for delivery quality.
test-strategyautomation - Cloud agent
Tech architect
Architecture audits and tech-debt lane findings.
architecturetech-debt - Cloud agent
Security officer
Security lane: findings routed without stealing delivery throughput.
securityfindings - Cloud agent
Workflow self-heal
Repair signals from CI and config drift without colliding with intake.
cidrift - Lane prompts
Structured intake
Idempotent intake: classify, structure, stage labels on Todo.
intakelabels - Lane prompts
Requirement clarification
Clarification pass when human or upstream left gaps.
clarificationgaps - Lane prompts
BA specification
BA spec depth, acceptance language, handoff readiness.
baacceptance - Lane prompts
Developer execution
Developer execution pattern aligned to pick windows.
implementationpick-window - Lane prompts
PR self-review
Self-review checklist before human review load.
prself-review - Lane prompts
CI failure recovery
Recover from red checks without spamming the board.
cirecovery - Lane prompts
Preview smoke check
Verify preview is live and key flows work after deploy.
previewsmoke - Lane prompts
Preview failure triage
When preview is flaky or red: narrow signal vs product defect vs infra.
previewtriage - Lane prompts
Acceptance verification
Verify acceptance criteria on In Review issues after preview passed.
acceptancein-review - Lane prompts
Human handoff
Clean escalation when automation must stop.
escalationhandoff - Lane prompts
Retry sweep
Bounded retry logic without hero agents.
retrybounded - Lane prompts
Learning capture
Capture what changed in policy or prompts after incidents.
retropolicy
Ship CLI
Patterns commands
Run these from the Ship repository root (where package.json defines npm run ship). The CLI talks to the same methodology API as agents — start uvicorn first (see manual). API base defaults to http://127.0.0.1:8100; override with --base-url or SHIP_API_BASE.
List pattern ids
npm run ship -- patterns list
Print one pattern (markdown body)
npm run ship -- patterns show catalog-a1-intake
Semantic search (optional)
npm run ship -- docs search "intake idempotency Todo" --top-k 6
Machine-readable JSON
npm run ship -- patterns list --json
Other manifest CLIs: Tools · Workflows · Collections. HTTP for agents and CI (GET /patterns, POST /search, …): Companion API · Manual → Backend API (source on GitHub).