wipnote orchestration patterns for AI-assisted development. Use when working on code in an wipnote project — provides delegation patterns, model selection, quality gates, and work tracking guidance. Activate when planning work, delegating to agents, debugging, building features, or managing tasks.

2026-06-223

orchestrator-directives-skill

shakestzd/wipnote

2026-06-223

orchestrator-directives-skill

Plan development work using a triage-gated, blocks-first interview. Classify scope as trivial/standard/complex, then run 0/3/4 staged interview rounds through the current harness native ask-user tool when available, or plain conversation when it is not. Each stage elicits the VISUAL block first (file-tree, api-endpoint, data-model, wireframe/diagram) and derives the prose slice fields (what/why/done_when) from it — blocks are authored inline as the YAML is built, not in a post-pass. Produces slice-card YAML with grounded visual blocks and visible research provenance for external claims; pauses for human review; promotes approved slices to features. Use when asked to plan, create a development plan, or build a feature with design clarity first.

2026-06-213

wipnote-visual-plan

shakestzd/wipnote

SECONDARY enrichment path — add or revise structured visual blocks (data-model, api-endpoint, file-tree, wireframe, diagram, tabs) on an EXISTING wipnote plan. Use for legacy plans drafted before blocks-first existed, or for ad-hoc later block additions/revisions — NOT for primary planning. New plans get blocks authored inline during the wipnote:plan interview (blocks-first); only reach for this skill when a plan already exists and needs blocks added or changed after the fact. Reads the live block catalog from wipnote plan blocks, adds grounded blocks to slices, regenerates the plan HTML, and links to the dashboard.

2026-06-213

wipnote-visual-recap

shakestzd/wipnote

Generate a grounded visual recap for a work item, git range, or session. Runs wipnote recap to produce a self-contained HTML artifact grounded in the real diff, reads the artifact, writes an outcome narrative (secrets redacted), and links to the dashboard recap URL. Use when asked to recap, summarize, or visualize completed work.

2026-06-203

name	wipnote:arch-bootstrap
description	Bootstrap architectural memory for a repo — generates starter cards from a structured brief

Architectural Memory Bootstrap

Use this skill to populate a project's architectural memory from scratch. It runs the bootstrap command, reads the brief, and authors starter arch cards via the validated add path.

Trigger keywords: bootstrap arch, bootstrap architectural memory, starter cards, arch bootstrap, initialize arch cards

Step 1: Generate the Brief

wipnote arch bootstrap

Read the full output. It contains:

Repo Layout — top-level directories and Go module names
Existing Docs — CLAUDE.md / AGENTS.md content (instructions, not architecture)
Lineage Hotspots — files touched most in the last 90 days (signals where arch cards are most valuable)
Authoring Instructions — card kinds, constraints, command template

Step 2: Author Cards

For each major subsystem, invariant, or hazard you identify from the brief, run:

wipnote arch add <slug> \
  --kind <kind> \
  --created-by agent \
  --paths "<glob1>,<glob2>" \
  --body "<body up to 120 words>"

Card kinds:

subsystem-map — what a subsystem does and its boundaries
invariant — a constraint that must always hold
hazard — a known failure mode or sharp edge
decision — a recorded architectural decision

Rules:

Body: max 120 words
Slug: lowercase letters, digits, hyphens only
Globs: use ** for recursive match (e.g. internal/**, cmd/wipnote/*.go)
Name and path-glob set must each be unique across all cards

Aim for 3–8 cards covering the top subsystems visible in the hotspot list.

Do NOT mechanically import CLAUDE.md content — those are instructions, not architecture. Focus on structural facts: what systems exist, what invariants must hold, what hazards to avoid.

Step 3: Validate

wipnote arch validate

Fix any reported errors (body too long, missing required fields, invalid kind).

Step 4: Review

wipnote arch list
wipnote arch show <slug>

Verify the cards describe real structural facts about the codebase, not process instructions.