Team Workflows

Concrete workflows showing how teams use Spark in practice. Each includes the actual commands your developers will run. The CLI surface is the same as for individual users — what changes for teams is that shares land in your private knowledge layer alongside the public network.

Workflow 1: Error resolution

Scenario: A developer hits an unfamiliar error in legacy code — a cryptic database migration failure that nobody on the current team has seen before.

Without Spark: The developer spends 2-3 hours reading through migration history, searching Stack Overflow, and experimenting with fixes.

With Spark:

# Developer hits the error and queries Spark
spark --pretty query "ActiveRecord::StatementInvalid PG::UndefinedColumn alter_table" \
  --tag framework:rails:7 \
  --tag library:postgresql

Spark returns a recommendation from a teammate who solved this exact issue two weeks ago — the response is JSON by default; --pretty reformats it for terminal reading. After applying the fix, the developer rates the recommendation:

# Confirm the recommendation worked (idx is the recommendation's idx from the query response)
spark feedback <session-id> \
  --feedback "<feedback idx='session-id-0' relevant='true' correct='true'>Exact fix, schema cache was stale</feedback>"

Workflow 2: Senior dev knowledge sharing

Scenario: A senior developer spends an afternoon debugging a tricky Kubernetes deployment issue — pods were failing health checks because of a misconfigured readiness probe timeout interacting with a slow database connection pool warmup.

After solving it, they share the pattern. They didn't start from a spark query, so they use spark share-task (no session ID required):

spark share-task "kubernetes pods restarting CrashLoopBackOff readiness probe HikariCP" \
  --title "K8s readiness probe timeout vs HikariCP pool warmup" \
  --content "When using HikariCP with default pool warmup, the readiness probe must account for connection pool initialization time. Set initialDelaySeconds to 30 and timeoutSeconds to 10. The default 5s initialDelay causes pods to restart before the pool is ready, creating a crash loop. Also set minimumIdle to match the expected baseline load to reduce warmup time." \
  --tag tool:kubernetes \
  --tag library:hikaricp \
  --tag domain:deployment

Now every developer on the team — and their AI agents — can find this solution. The next time anyone encounters pods crash-looping during deployment, a simple query surfaces the fix:

spark --pretty query "kubernetes pods restarting CrashLoopBackOff readiness probe"

💡

The value of this workflow is asymmetric: the senior developer spends 30 seconds sharing, but saves potentially hours of debugging for every teammate who encounters the same class of problem.

Workflow 3: Onboarding new developers

Scenario: A new hire joins the team and starts working on the main application. They're unfamiliar with the team's conventions, infrastructure quirks, and common pitfalls.

Their AI agent queries Spark as it works:

# New dev's agent encounters a test failure pattern
spark --pretty query "factory_bot trait not found for user model" \
  --tag framework:rails:7 \
  --tag tool:rspec

# New dev is setting up their local environment
spark --pretty query "docker compose redis connection refused on macOS" \
  --tag tool:docker \
  --tag library:redis

# New dev hits a deployment question
spark --pretty query "how to deploy feature branch to staging environment" \
  --tag domain:deployment

Instead of interrupting teammates or searching through Confluence pages, the new developer's agent finds team-specific answers immediately. The knowledge layer acts as a living, queryable onboarding document.

Workflow 4: Post-incident knowledge sharing

Scenario: After a production incident — a memory leak caused by an unbounded cache in a background job worker — the team runs a postmortem and documents the root cause.

The on-call engineer shares the incident findings, again with spark share-task (no prior query):

spark share-task "sidekiq worker memory growing unbounded RSS increasing Rails.cache" \
  --title "Memory leak in Sidekiq workers from unbounded Rails.cache" \
  --content "Background jobs using Rails.cache.fetch without an expires_in option caused unbounded memory growth in Sidekiq workers. The default memory store has no eviction policy. Fix: always set expires_in on cache entries in background jobs, or switch to a bounded cache store like LRU. Monitoring: alert on Sidekiq worker RSS exceeding 512MB. Detection: watch for linear memory growth in worker metrics over hours." \
  --tag tool:sidekiq \
  --tag framework:rails:7 \
  --tag domain:deployment

Now the pattern is permanently documented in the knowledge layer. Future queries about similar symptoms surface the fix immediately:

# Six months later, a different developer notices memory growth
spark --pretty query "sidekiq worker memory growing unbounded RSS increasing"

Post-incident shares are some of the highest-value contributions to a team's knowledge base. They capture hard-won operational knowledge that is otherwise lost in postmortem documents that nobody reads twice.

Pattern: integrating Spark into your daily workflow

The highest-value habit is simple: query before you debug, share after you solve.

# Before starting work on an error
spark --pretty query "the error message or problem description" --tag <relevant tags>
 
# After solving — when you started from a query session
spark share <session-id> \
  --title "Short description" \
  --content "What you did and why it worked" \
  --task-index new \
  --tag <relevant tags>
 
# After solving — when you didn't start from a query
spark share-task "what someone would search for" \
  --title "Short description" \
  --content "What you did and why it worked" \
  --tag <relevant tags>

This three-command pattern, adopted across a team, is what produces the compound knowledge returns described in the research.

Privacy & Security Onboarding Guide