⌨️

Claude Code in Practice

Setup, workflows, plugins, security & lessons learned

Internal Knowledge Sharing · ~50 min · Gemma Analytics

What we'll cover

📄

CLAUDE.md & Permissions
The foundation — project context, permission model, security defaults

~10 min

🧠

Modes & Prompting Patterns
Plan mode, the interview pattern, context-window discipline

~10 min

🔌

Plugins & Skills
From instructions to capabilities — what we use and what to build

~10–15 min

🚀

Production Workflows & Lessons Learned
Worktrees, the dbt refactor case study, what broke, security architecture

~15 min

🎯 Live showcases throughout · Open discussion at the end

1 · CLAUDE.md & Permissions

CLAUDE.md: The Foundation

The CLAUDE.md file is Claude's project context — it tells Claude what the project is, how to work in it, and where to look for more detail.

Philosophy: keep it short. Use pointers.

Project purpose & architecture overview
Dev commands (build, test, lint)
Key conventions & constraints
Pointers to deeper docs — not duplication

⚠️ A giant CLAUDE.md becomes counterproductive — Claude spends tokens processing instructions instead of doing work. Point to docs; don't paste them in.

Instruction precedence:

~/.claude/CLAUDE.md Personal (global) │ ▼ ./CLAUDE.md Project root │ ▼ ./subdir/CLAUDE.md Subdirectory (additive) │ ▼ Project documentation README, ARCHITECTURE.md, etc. │ ▼ Actual code / data / tooling What Claude reads at runtime

Project-level overrides personal. Subdirectory CLAUDE.md adds context when Claude works in that path.

1 · CLAUDE.md & Permissions

Our CLAUDE.md

🖥️ Showcase

## What is Tundri

Tundri is a Python CLI tool that manages
Snowflake database objects and permissions
declaratively.

## Development Commands

uv sync
uv run pytest -v
uv run ruff check .
uv run ruff format .

## Architecture

cli.py   → Argparse CLI entry point
core.py  → Main logic: inspect, compare, DDL
parser.py→ Parse Permifrost YAML specs
objects.py→ Frozen dataclasses for SF objects

## Conventions

- Use uv for all Python operations
- Type hints throughout
- Frozen dataclasses with custom equality
- Never commit directly to main

What's included — and what's not:

✓ Included

One-sentence purpose
Dev commands (copy-paste ready)
Module map (what's where)
Key conventions
Version constraints

✗ Deliberately left out

Full API documentation
Usage examples & tutorials
Deployment procedures
Detailed architecture deep-dives
Changelog / release history

These live in dedicated docs. CLAUDE.md points to them.

1 · CLAUDE.md & Permissions

Permissions: Don't Give Claude the Keys

🖥️ Showcase

Security first, convenience second.

What Claude can do (by default) ├── ✓ Read any file in the project ├── ✓ Run allowed shell commands ├── ✓ Edit files └── ✓ Search / navigate code What requires approval ├── ? Run unknown shell commands ├── ? Install packages └── ? Access external services What is blocked ├── ✗ Database queries (on API) ├── ✗ Reading .env / secrets ├── ✗ Production data access └── ✗ Push to main

Permission mode: --dangerously-skip-permissions only in our controlled Slack bot environment with system-prompt-level restrictions.

The critical separation:

Code access ≠ Data access

Our approach:

Anthropic API — code work only
Read/write source code, run tests, create PRs

AWS Bedrock — code + data access
All traffic stays within our AWS account.
Database queries, dbt show, client data.

Switch with provider bedrock in our Slack bot, or claude-db in the terminal.

DEMO PREPARATION: - Have the Slack bot ready in a thread - Show: typing a normal code question works (API mode) - Show: typing `provider bedrock` switches to Bedrock - Show: the data protection policy blocks database queries on API mode WHAT TO POINT OUT: - We use --dangerously-skip-permissions in the bot, but the system prompt enforces restrictions. This is because the bot runs non-interactively. - The system prompt explicitly blocks: database connections, reading .env files, reading client data files, dbt show - Provider switching is per-session, not global - GitHub Actions workflows also use Bedrock (eu-central-1) via OIDC KEY INSIGHT: The permission model isn't just about what Claude Code CAN do technically — it's about what it SHOULD do given the data sensitivity context. BACKUP: Show the data protection policy text from the system prompt.

2 · Modes & Prompting Patterns

Plan Before You Build

🖥️ Showcase

Plan Mode = Claude explores and thinks without modifying anything.

Question / task │ ▼ Explore read code, grep, understand │ ▼ Plan propose approach, trade-offs │ ▼ Review / align human checks the plan │ ▼ Implement Claude writes code │ ▼ Validate tests, review, verify

Why this matters:

Claude reads the codebase before writing
Surfaces dependencies you forgot about
You catch wrong assumptions before they become code
The plan becomes documentation

Without planning:
Claude implements the first approach that seems plausible.
You spend 20 minutes debugging a wrong assumption.

With planning:
Claude explores 3 approaches, explains trade-offs.
You pick the right one. Implementation is clean.

Commands: Shift+Tab toggles Plan Mode · /plan in prompt

DEMO PREPARATION: - Pick a realistic task: e.g. "Add a new Snowflake object type to tundri" - Have the repo cloned and ready DEMO FLOW: 1. First: paste the task directly → Claude starts implementing immediately Point out: it picks an approach without exploring alternatives 2. Then: same task with "First explore the codebase and create a plan. Don't implement anything yet." Point out: Claude reads existing patterns, identifies the files involved, proposes an approach with trade-offs WHAT TO POINT OUT: - Plan mode output is richer: it maps dependencies, shows what will change - The plan catches edge cases the immediate approach misses - Total time is often shorter because you don't backtrack - We use `superpowers:writing-plans` for complex features to save plans as docs EXPECTED RESULT: The planned version identifies more files, considers more edge cases, and produces a clearer implementation path. TIME: Keep to 3 minutes max. The contrast matters more than the full demo.

2 · Modes & Prompting Patterns

Stop Guessing: "Interview Me"

🖥️ Showcase

❌ Ambiguous prompt

"Add logging to the pipeline"

Claude guesses: which pipeline? what level? what format? where to log? Produces something that works but isn't what you wanted.

✓ Interview prompt

"I need to add logging to the pipeline.
Before you implement anything, interview
me about the requirements. Ask me about
scope, format, destination, and any
constraints I haven't mentioned."

Claude asks 4–6 targeted questions. You clarify. Then it builds exactly what you need.

Why this works

Exposes hidden assumptions — yours and Claude's
Clarifies scope — "all pipelines" vs "just the failing one"
Surfaces constraints — "we already use structlog" etc.
Reduces rework — get it right the first time

Pattern variations:

"Before implementing, ask me 5 questions about what I actually need"
"Interview me about the requirements — don't assume anything"
"What questions do you have before starting?"

Works especially well for: new features, refactoring scope, data model changes, API design decisions.

DEMO PREPARATION: - Have a Claude Code session ready - Prepare an intentionally ambiguous task, e.g.: "Add error handling to the data connector" DEMO FLOW: 1. Show the ambiguous prompt → Claude starts implementing something generic 2. Same prompt with "Interview me first" → Claude asks: "Which connector? What types of errors? Retry logic? Should errors be logged, raised, or both? What's the current error handling?" 3. Show how the answers lead to a much more targeted implementation WHAT TO POINT OUT: - Claude's questions often reveal things YOU hadn't thought about - The interview takes 2 minutes; the rework it prevents takes 20 - This is especially valuable when you're not the domain expert (e.g. analytics engineer asking about infrastructure) CONCRETE EXAMPLE: "Add error handling" → Claude adds try/except everywhere After interview: "Only handle API rate limits on the REST source, retry 3x with exponential backoff, log to structlog, raise after exhaustion" → Claude writes exactly that, no more, no less. TIME: 2–3 minutes. The "aha" moment is quick.

2 · Modes & Prompting Patterns

Context Is a Resource

Context window ≈ 200k tokens Fresh session ┌─────────────────────────────────────┐ │ ██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │ Clean └─────────────────────────────────────┘ After heavy exploration ┌─────────────────────────────────────┐ │ ████████████████████████░░░░░░░░░░░ │ Filling up └─────────────────────────────────────┘ Compaction kicks in ┌─────────────────────────────────────┐ │ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │ Summarized └─────────────────────────────────────┘ ↑ Earlier context is compressed Details may be lost

Signs a session is going off track:

Claude re-reads files it already explored
Suggestions contradict earlier decisions
Responses become generic / less specific
Claude "forgets" constraints you stated earlier

Context discipline

Continue when:

Working on related changes in the same area
Iterating on a specific implementation
Claude still references earlier context accurately

Start fresh when:

Switching to a different task / area of code
Context feels degraded
You've been in the same session for 20+ exchanges
The task is complete and you're starting something new

Useful commands:

/cost — check token usage & cost
/compact — manually trigger compaction
/clear — reset context in current session
Ctrl+C × 4 — exit and start fresh

💡 Sometimes the best prompt is a fresh session.

3 · Plugins & Skills

From Instructions to Capabilities

Mechanism	What it does	When to use
`CLAUDE.md`	Persistent project instructions — always loaded	Project context, conventions, constraints
Prompt	Task-specific direction — one-shot	Specific task, question, or request
Skill	Reusable workflow with scripts & templates	Repeatable multi-step process
Plugin	Packaged set of skills, hooks, agents & references	Domain-specific capability bundle
Hook	Shell command triggered by Claude events	Validation, guards, automation
Agent	Sub-agent with scoped tools & system prompt	Parallelism, specialised reviewer, focused exploration

Escalation path: If you're repeating a prompt → make it a CLAUDE.md instruction If it has steps → make it a skill If it spans a domain → make it a plugin

Think of this as a capability ladder. Most things start as a prompt. When you find yourself typing the same prompt repeatedly, it should become a CLAUDE.md instruction. When it has multiple steps or needs scripts, it becomes a skill. When you have a whole domain with multiple skills, hooks, and references, it becomes a plugin. The key distinction between a skill and a prompt: - A prompt is text. A skill can include executable scripts, templates, reference documentation, and structured output. - A skill can be invoked with /skill-name — it's a command, not a conversation. Hooks are the automation layer — they fire on events like SessionStart, PreToolUse, PostToolUse. We use them for things like the data protection policy (injected on session start) and validation guards.

3 · Plugins & Skills

What We Actually Use

🖥️ Showcase

Anthropic built-in

/code-review — diff-based review
/simplify — cleanup & refactor
/init — bootstrap CLAUDE.md
/security-review — security audit
/deep-research — multi-source research

Third-party

superpowers — plans, sub-agent dev
dbt-agent-skills — dbt workflow

Gemma custom

gemma-dbt — base models, source files, repo validation
gemma-dlt — connector creation & debugging
gemma-snowflake — tundri setup, keypair management
gemma-airflow — DAG creation, CI/CD setup
gemma-kimball — dimensional modelling
gemma-deployment-security — infra audits
gemma-prs — PR review & implementation
gemma-commercial — proposals, contracts

All 20+ custom plugins live in gemma-agentic-toolkit — a monorepo with independent semver versioning per plugin. Auto-loaded into every Gemmbot session via --plugin-dir. Skills invoked with /plugin-name:skill-name.

DEMO PREPARATION: - Pick ONE plugin to demo. Recommended: gemma-dbt:create-base-models or gemma-dlt:create-dlt-connector - Have a target repo ready DEMO FLOW: Show a concrete problem → invoke the skill → show the result. Example: "I need to create dbt base models for a new Snowflake source" → /gemma-dbt:create-base-models → Claude scaffolds the models, schema.yml, and source definitions WHAT TO POINT OUT: - The skill encapsulates a multi-step workflow that would take 30+ minutes manually - It follows our conventions automatically (naming, documentation, testing patterns) - The plugin includes reference docs that Claude loads contextually - Skills can call scripts (Python via uv, shell) for non-LLM tasks The agentic toolkit is structured as a Claude Code plugin marketplace: - Each plugin has plugin.json (metadata), skills/, hooks/, agents/, references/ - Skills have SKILL.md (instructions), scripts/ (executable), assets/ (templates) - Release-please handles independent semver per plugin DON'T demo five plugins. One clear problem→solution is worth more. TIME: 3–4 minutes max.

3 · Plugins & Skills

What Should We Build Next?

"What repetitive engineering task do you wish
Claude could handle better?"

The decision tree:

Repetitive task identified │ ┌──────┴──────┐ │ │ Simple? Complex? │ │ ▼ ▼ Prompt or Skill or CLAUDE.md Plugin │ │ │ ┌────┴────┐ │ │ │ │ Reusable Unique │ across to one │ projects project │ │ │ │ ▼ ▼ │ Plugin Project │ skill ▼ Done ✓

Where our plugins came from:

gemma-dbt — "I keep writing the same base model boilerplate"
gemma-dlt — "Setting up a new connector takes 2 hours of scaffolding"
gemma-snowflake — "Keypair rotation is error-prone and manual"
gemma-deployment-security — "We need consistent security audits"
gemma-kimball — "Dimensional modelling follows patterns, let's encode them"

Every plugin started as a repeated prompt,
graduated to a CLAUDE.md note,
and eventually became a skill.

4 · Production Workflows & Lessons Learned

Power-User Workflow

Git repository │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ Worktree A Worktree B Worktree C │ │ │ Claude #1 Claude #2 Claude #3 Feature Refactor Review │ │ │ ▼ ▼ ▼ PR #42 PR #43 PR #44 │ │ │ └──────────────┴──────────────┘ │ merge to main

Git worktrees = multiple working directories from the same repo. Each gets its own Claude session with isolated context.

Setup:

git worktree add ../repo-feat feat-branch
git worktree add ../repo-refactor refactor
git worktree add ../repo-review review

# Each in its own terminal tab:
cd ../repo-feat && claude
cd ../repo-refactor && claude
cd ../repo-review && claude

Why worktrees over branches:

No context switching — each dir is independent
Claude in session A doesn't see session B's changes
Parallel work with zero conflicts until merge
Clean context per task = better output

This is how power users actually work with Claude Code. Instead of one long session that tries to do everything, you run parallel sessions with isolated contexts. Git worktrees give you multiple checked-out copies of the same repo. Each worktree has its own working tree but shares the same .git directory. Practical workflow: - Terminal tab 1: Feature implementation (worktree A + Claude) - Terminal tab 2: Refactoring a different area (worktree B + Claude) - Terminal tab 3: Code review or test writing (worktree C + Claude) Each Claude session only sees its worktree, so context is focused. No cross-contamination between tasks. In our Slack bot (Gemmbot), each thread is already an isolated session with its own workspace directory — same principle, different interface. DEMO: If time permits, show creating a worktree and starting Claude in it. Otherwise, the diagram is self-explanatory.

4 · Production Workflows & Lessons Learned

Case Study: The dbt Refactor

Problem

Large dbt project needs refactoring — model restructuring, naming conventions, documentation, tests. Too big for one session.

Approach

Break into independently verifiable model groups.
Each group: one Claude session → one PR → one validation cycle.

Large refactor │ ┌─────┼─────┬─────┐ ▼ ▼ ▼ ▼ A B C D Model groups │ │ │ │ test test test test dbt build per group │ │ │ │ PR PR PR PR Review each └─────┴─────┴─────┘ │ Integration test dbt build --full-refresh │ Data validation Compare row counts, sums

Division of work:

🤖 Claude

Read existing models
Apply naming conventions
Restructure SQL
Generate schema.yml
Add generic tests
Update refs

👤 Human

Define model groups
Set naming rules
Review business logic
Validate data output
Approve PRs
Run integration tests

Key prompt pattern:

"Refactor only the models in models/staging/
shopify/. Follow naming convention stg_shopify__
{entity}. Update schema.yml. Don't touch
anything outside this directory."

Result: Weeks of refactoring → days. Each group independently validated. No data regression.

This is the main case study — the most concrete example of using Claude Code for real production work. THE STORY: We had a dbt project that had grown organically. Models were inconsistently named, documentation was sparse, tests were missing, and the directory structure didn't reflect the data flow. THE APPROACH: 1. We mapped the dependency graph and identified independent model groups 2. Each group became one Claude session with a tightly scoped prompt 3. Claude did the mechanical work: renaming, restructuring SQL, generating schema.yml, adding tests 4. We reviewed each PR for business logic correctness 5. We ran dbt build on each group to verify 6. After all groups merged, we ran a full integration test WHAT MADE IT WORK: - Bounded scope per session: "only models in this directory" - Claude had our naming conventions in CLAUDE.md - We used gemma-dbt skills for base model generation - Each PR was independently reviewable and revertable WHAT WOULD HAVE BROKEN: - "Refactor the entire dbt project" in one session → context exhaustion, inconsistent changes, unverifiable result - Skipping the integration test → subtle data regressions The human role was critical: defining the groups, reviewing business logic, and validating the data. Claude did the tedious mechanical work.

4 · Production Workflows & Lessons Learned

What Worked / What Didn't

✓ Worked

Small, bounded tasks
"Refactor this directory" not "refactor the project"
Planning before implementation
Explore → plan → align → implement
Good project context (CLAUDE.md)
Claude follows conventions without being told each time
Automated validation
dbt build, pytest, ruff — let CI catch what review misses
Human review of business logic
Claude gets syntax right; humans verify semantics
Interview pattern for requirements
Reduces rework by 80%

✗ Didn't work

Overly broad prompts
"Fix the data pipeline" — which pipeline? what's broken?
Monster sessions
Context degradation → contradictory suggestions
Skipping validation
"Claude wrote tests, so it must be correct" — no.
"Refactor everything at once"
Unreviable PRs, untraceable changes
Excessive permissions
More access ≠ more useful. Often the opposite.
Trusting without verifying
Claude confidently generates plausible-but-wrong SQL

This should be the most honest slide in the deck. WHAT WORKED — the common thread is "bounded scope + human oversight": - Small tasks = better output. Claude can hold the full context of a small task. It can't hold a full project. - Planning first catches wrong assumptions before they become code. - CLAUDE.md means Claude follows conventions automatically. - Automated tests catch mechanical errors; human review catches logic errors. WHAT DIDN'T WORK — the common thread is "too much trust, too little structure": - "Fix the pipeline" is like telling a new hire "fix the system" — unhelpful. - Long sessions degrade. We've seen Claude contradict itself after 30+ exchanges. - "Claude wrote the tests" is circular reasoning. Claude writes tests that test what it implemented, not what you needed. - Big refactors in one session produce big PRs that nobody can review properly. - We had a case where Claude generated SQL that looked correct but had a subtle join condition error. It passed tests because Claude also wrote the tests to match its implementation. Human review caught it. The lesson: Claude is a powerful implementation tool, not a replacement for engineering judgment.

4 · Production Workflows & Lessons Learned

Humans Still Own the Important Decisions

🤖 Claude

🔍 Explore & navigate codebases
⌨️ Implement changes
♻️ Refactor & restructure
🧪 Write & run tests
📝 Explain & document
🔧 Scaffold & boilerplate
🐛 Debug & diagnose

👤 Human

🏗️ Architecture decisions
🔒 Security boundaries
📋 Requirements & priorities
⚖️ Trade-off evaluation
✅ Validation & approval
📊 Data correctness
🎯 Accountability

Claude accelerates engineering work — it does not remove engineering responsibility.

This is the most important conceptual slide. Claude is exceptional at mechanical work: reading code, implementing patterns, refactoring, scaffolding, writing tests. It's fast and tireless. But it has no understanding of: - WHY this architecture was chosen over alternatives - WHAT the security implications of a change are - WHETHER the trade-off is acceptable for this specific context - IF the data is correct (it can verify syntax, not semantics) The danger zone is when you start treating Claude like a senior engineer who "gets it." It doesn't get it. It generates plausible outputs. Your job is to verify that plausible = correct. Analogy: Claude is like a very fast junior developer with perfect syntax and zero business context. You wouldn't let a junior push to production without review. Same principle.

5 · Security & Sensitive Data

Code Access ≠ Data Access

Developer │ ▼ Claude Code │ ├── Source code ✓ ├── Dev environment ✓ ├── dbt compile ✓ ├── dbt run / build ✓ (transforms in warehouse) ├── dbt show ✗ (returns data locally) ├── Test / fixture data ? (must be synthetic) ├── .env / secrets ✗ ├── Client data files ✗ ├── Database queries ✗ (on Anthropic API) └── Database queries ✓ (on AWS Bedrock)

Why two providers?

Anthropic API (default)
Data flows through Anthropic's servers.
→ Code work only. No client data.

AWS Bedrock
All traffic stays within Gemma's AWS account (eu-central-1).
→ Full access including databases and client data.

The rule is simple:

Does the task involve client data?
No → Anthropic API (faster, cheaper)
Yes → AWS Bedrock (data stays in our account)

# Terminal
claude-db          # One-off Bedrock session
bedrock-on         # Toggle for current shell

# Slack bot
provider bedrock   # Switch in current thread

This is the key security concept and worth spending time on. The question isn't "can Claude access the database?" — it's "WHERE does the data flow when it does?" On the Anthropic API: your prompts and responses go through Anthropic's servers. Fine for code. Not fine for client data — contractual and compliance issue. On AWS Bedrock: same Claude models, but the API runs within our AWS account in eu-central-1. Data never leaves our infrastructure. The data protection policy is enforced at the system prompt level: - Blocks database connections on Anthropic API - Blocks reading .env files (even via indirect methods) - Blocks dbt show (returns data) but allows dbt run (transforms in warehouse) - Blocks reading client data files This is enforced via a SessionStart hook in the bot — it injects the data protection policy before any user message is processed. dbt commands are a good example of the nuance: - dbt compile: ✓ (generates SQL, no data) - dbt run: ✓ (executes in warehouse, no data returned) - dbt build: ✓ (run + test in warehouse) - dbt show: ✗ (fetches rows to the terminal)

5 · Security & Sensitive Data

Our Security Architecture

Slack │ ▼ ┌─────────────┐ │ Gemmbot │ Node.js bot wrapper │ (Slack bot) │ Session management └──────┬──────┘ │ ┌────────────┼────────────┐ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ │ Anthropic API │ │ AWS Bedrock │ │ (default) │ │ (eu-central-1) │ │ │ │ │ │ ✓ Code access │ │ ✓ Code access │ │ ✗ Data access │ │ ✓ Data access │ │ ✗ Secrets │ │ ✓ DB queries │ └──────────────────┘ └──────────────────┘ │ │ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ │ Claude Code │ │ Claude Code │ │ --print mode │ │ --print mode │ │ + system prompt │ │ + system prompt │ │ + plugins │ │ + plugins │ └────────┬─────────┘ └────────┬─────────┘ │ │ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ │ Source code │ │ Source code │ │ Git repos │ │ Git repos │ │ Tests, CI/CD │ │ + Snowflake │ │ Documentation │ │ + Client data │ └──────────────────┘ └──────────────────┘

Additional boundaries:

Each session = isolated workspace directory
Secrets injected via env vars, never stored in prompts
GitHub Actions use Bedrock via OIDC (no long-lived keys)
Git: never push to main, always PR

GitHub Actions integration:

@claude mentions → agentic task via Bedrock
PR opened → automated code review (9-category sweep)
Scheduled audits → security reports via plugins
Bot identity: "Gemma Claude Assistant" GitHub App

This is the actual architecture we run. Gemmbot is the Slack bot wrapper — Node.js, Socket Mode. It manages sessions, user auth, and provider switching. Every Claude invocation uses --print mode (non-interactive) with --dangerously-skip-permissions (because there's no TTY for approval prompts). Security is enforced at the system prompt level instead. The system prompt is assembled from templates: - Base template: Slack formatting, working style, constraints - Data protection policy: injected via SessionStart hook - Feature templates: email, VPN, secret management (conditional) - Credential templates: Snowflake, Airflow, GitHub (per-user) Each user has their own Linux user on the server, isolated workspace per thread. Secrets are encrypted at rest (AES-256-GCM) and injected as env vars. GitHub Actions integration: - claude.yml: @claude mention handler (uses Bedrock OIDC, eu-central-1) - claude-review.yml: automated PR reviews (9 categories, inline comments) - claude-audit.yml: scheduled security/dbt audits (opens PR with report) All use a GitHub App for bot identity, not personal tokens.

Closing

Claude Code Playbook

Keep CLAUDE.md short — point to docs, don't duplicate them
Start with minimal permissions — expand only when needed
Separate code access from data access
Plan complex work before implementing
Ask Claude to interview you when requirements are unclear

Treat context as a limited resource — fresh sessions for new tasks
Use skills for repeatable workflows — promote from prompts
Break large work into independently verifiable tasks
Validate with tests, CI, and human review — not just Claude
Keep humans accountable for architecture, security, and data

These aren't Claude-specific principles — they're good engineering practices
applied to a new tool. The tool changes; the discipline doesn't.

Open Exchange

What are you going to try differently tomorrow?

💬

Share your
workflows

❓

Ask
questions

🔌

Propose
new skills

Gemma Agentic Toolkit → github.com/Gemma-Analytics/gemma-agentic-toolkit
Claude Code docs → docs.anthropic.com/en/docs/claude-code

Open the floor for discussion. 5 minutes. Good prompts if the room is quiet: - "What's the most tedious part of your workflow right now?" - "Has anyone tried Claude Code and hit a wall? What happened?" - "What would you want to automate first?" If someone asks about getting started: - Install Claude Code: npm install -g @anthropic-ai/claude-code - Run `claude` in any project directory - Start with /init to generate a CLAUDE.md - Try Plan Mode first (Shift+Tab) before implementing If someone asks about cost: - Claude Code subscription is per-seat - Bedrock is pay-per-token - /cost shows token usage per session - For our Slack bot, cost is tracked per thread and reported in the wrapper Wrap up with: "The best way to learn is to try it on a real task tomorrow. Pick something small and bounded — a refactor, a test, a documentation task. See how it goes, and share what you learn."