Session Kickoff

You are starting a work session. Your job is to surface the right context so the session begins with shared understanding — then get out of the way. Don't impose a structure on the session. The work will find its own shape.

The argument passed to this skill describes what the user wants to work on. It could be specific ("refine the hearing detail page") or open ("continue Phase 1 work") or exploratory ("think about how the email preferences UI should work").

Step 1: Gather Context

Based on what the user wants to work on, pull relevant context from across the documentation constellation. Not all sources are relevant to every session — use judgment about what to check.

Always check:

• •MEMORY.md — Scan for gotchas, lessons, and patterns related to the work area
• •CLAUDE.md — Relevant architecture sections, established patterns, known constraints
• •Recent git history — git log --oneline -20 to see what was done recently. Is this continuing previous work? Starting something new?

Check when relevant:

• •Quarterly roadmap (quarterly-roadmap-q2-2026.md) — If the session involves deciding what to work on, prioritizing between tasks, or starting a new focus area. Contains decision logic and prioritization signals.
• •planning/ — The three-tier planning system. Check based on what the session needs:
  • •planning/implementation/ for the active coding plan and page inventory (most coding sessions)
  • •planning/learning/ for research findings on a topic (if the session touches an investment area or Focus 3/4)
  • •planning/working/ and planning/reference/ for any matured topic docs
• •Design documentation — If the work has a visual, brand, or voice dimension:
  • •design-canon.md for the design system and messaging framework
  • •CLAUDE.md "Design Ethos" section for core rules
  • •External messaging docs in ~/Documents/Capitol Labs/Strategy & Updates/ (quarterly update, LinkedIn post, F&F update, email update) if the work touches how the product presents itself
• •The affected code — Skim the templates, blueprints, or modules that will be touched. Note what patterns are already established there.
• •Git diff of unstaged/uncommitted work — Is there work in progress from a previous session?

Step 2: Surface What Matters

Present a concise briefing. Not a wall of text — a focused summary that gives the session a running start. Include only what's useful:

Context (always include)

• •Where we are: What was the last work done in this area? Any unfinished business?
• •What's relevant from the docs: Key gotchas, patterns, or constraints from MEMORY.md/CLAUDE.md that apply. Quote the specific entries — don't paraphrase into vagueness.

Open Questions (include when they exist)

• •Decisions that haven't been made yet
• •Design or architectural questions that will come up during the work
• •Trade-offs the user should be aware of

Don't present these as blockers. Present them as landscape: "These will come up as we work. We can decide as we go or discuss now."

Connections (include when non-obvious)

• •Other parts of the system that relate to this work (templates that share patterns, endpoints that depend on each other, docs that should stay in sync)
• •External reference docs that might be useful ("The Q2 Investment Areas doc has a section on transcript workflow that's relevant to this")

Starting Point (always include)

One concrete suggestion for where to begin. Not a plan — a first move.

Examples:

• •"The hearing detail template is 400 lines. I'd start by reading it to understand the current structure before proposing changes."
• •"The Phase 1 doc lists 8 work items. Items 1-3 are done based on recent commits. Item 4 (sticky video player) seems like the natural next step."
• •"The weekly email already works. I'd pull up a dry run preview so we can look at it together and discuss what to refine."
• •"This is exploratory — no existing code to anchor on. I'd start by looking at how similar platforms handle this, then sketch an approach for your reaction."

Step 3: Hand Off

After presenting the briefing, stop. Don't start building. Don't propose a detailed plan. The user will direct where to go from the context you've surfaced.

The session starts when the user responds to the briefing.

What This Skill Is NOT

• •Not plan mode. Plan mode designs an implementation approach for approval. Kickoff surfaces context so the session can begin with shared understanding. The session might not need a plan at all — it might be iterative design work, or a strategic conversation, or a quick fix.
• •Not a mode selector. Don't categorize the session as "design" or "engineering" or "copy." Real sessions blend. A design session surfaces an architecture question. A copy session leads to a template change. Let it flow.
• •Not a requirements document. Don't enumerate everything that needs to happen. Surface what's relevant right now and let the work unfold.

Calibrate Depth to the Ask

• •Specific task ("fix the badge color on hearing lists"): Brief context — which template, what the current badge looks like, any related pattern in MEMORY.md. One paragraph, then start.
• •Continuing work ("let's keep going on Phase 1"): Check what was done last, what's next on the roadmap, any open issues. Short briefing.
• •Open exploration ("think about the email preferences UI"): Deeper context pull — read the Phase 3 doc, check what infrastructure exists, look at the external docs for how email is currently talked about. Present the landscape for discussion.
• •Strategic/creative ("work on how we describe the API product"): Pull messaging framework from design brief, check external docs for current language, note what the site currently says. Present as raw material for the conversation.

Reference: The Documentation Constellation