Loading...

Skip to main content

Find and Contribute Solution Blocks from Your Coding Assistant

· 8 min read
Gábor Volczér
Gábor Volczér
AI Engineer at Aliz

The Solution Block Hub only pays off if people actually reach for it — before they rebuild something we already have, and after they build something worth sharing. The problem is that "go search the Hub" is a context switch, and context switches don't happen mid-flow.

So now the Hub comes to you. Two skills put it directly inside your coding assistant, working across Claude Code, Codex CLI, and GitHub Copilot CLI: sb-hub-search (before you build — "do we already have a block for this?") and sb-hub-contribute (after you build — "is any of this worth turning into a block?"). Together they close the loop: reuse first, contribute back.

Why it is useful​

  • Stop rebuilding what exists. Most "new" work overlaps something a colleague already solved. Searching the Hub in seconds is cheaper than rediscovering it in days.
  • Grounded, not guessed. The search ranks against the Hub's real summaries, and it tells you honestly when nothing fits instead of inventing a weak match.
  • Contribution without ceremony. The contribute skill finds the genuinely reusable, not-yet-covered parts of what you just built and preps the block for you.
  • In your terminal, in every assistant. No MCP, no service to stand up — just a skill and your existing gh login.

What you need (once)​

  • Python 3.9+
  • The gh CLI, authenticated: gh auth login, with read access to the private aliz-ai/aliz-solution-block-hub repo.
note

The skills shell out to gh for Hub reads, so there are no tokens, env vars, or MCP setup to manage. If a search fails with a gh-not-found or auth error, this is the cause.

Get the skills​

Both skills live in the aliz-ai plugin of the Aliz AI Framework. Install that plugin in your assistant (Claude Code, Codex, or Copilot) by following the framework's plugin install guide. One install gives you both sb-hub-search and sb-hub-contribute; they need nothing beyond the prerequisites above.

Part 1 — Find a block before you build (sb-hub-search)​

When it fires​

Ask your assistant any of these, and the skill activates:

  • "Do we have a solution block for X?"
  • "Is there an SB ready to ship for Y?"
  • "Check the SB hub for the use case in this ARB document."

You can also call it directly: /aliz-ai-sb-hub-search <use case>.

It extracts the use case for you​

You do not need to prep the input. Point the skill at a document (an ARB Review Request, a SoW, a project brief, a README) and it pulls out the real use case before searching, ignoring template boilerplate that would otherwise pollute the match (words like "ARB", "validation", "architect", stakeholders, dates). For an ARB Review Request, for example, it focuses on the Project/Task Brief and Planned Solution Description and skips the rest of the template.

Worked example​

Just describe the problem to Claude Code (or Codex / Copilot) in plain language:

You: Do we have a solution block for a customer-support agent on Gemini Enterprise that answers from our Confluence and Jira via Vertex AI Search, deployed with Terraform?

The skill searches every indexed block and returns the ranked matches with their relevance scores. Real output (the corpus changes over time, so exact scores drift):

Assistant: Searched 197 solution blocks. Top matches:

  1. jira-project-privatizer — score 0.118, production-ready, last updated 2025-11-21, repo aliz-ai/jira-project-privatizer. A scheduled automation that enforces privacy on Jira projects. Ranks up here on the "Jira/Confluence" wording, but it is not really your use case.
  2. ge-custom-agent — score 0.106, experimental, last updated 2026-03-10, repo aliz-ai/ge-custom-agent. A scaffold for a Gemini Enterprise custom agent. Structure only, no implementation yet.
  3. spacewell-support-agent — score 0.102, beta, last updated 2024-12-02, repo aliz-ai/spacewell-support-agent. A Dialogflow CX support agent on GCP that answers from a Confluence knowledge base via Discovery Engine. This is the closest real fit for what you described.

Scores are low across the board, so there is no turnkey block, but spacewell-support-agent is the one worth studying as a reference. Want its full summary?

Every hit comes back with its name, repo, maturity, last-updated date, a relevance score, and a one-line summary, and the assistant reads those to tell you which result actually fits (here, the third by score, not the first). Ask for the full summary of any block worth a closer look and the skill pulls it up.

Pointing it at a document works the same way: say "Check the SB hub for the use case in this ARB doc" and it extracts the use case before searching.

Also handy​

Ask it to show the full summary of a specific block, or to refresh its view of the Hub if you think the cached summaries are stale. Both are just things you say to the assistant.

tip

An honest "nothing fits" is a feature. The ranker has a relevance floor; when nothing clears it, the skill says so plainly rather than dressing up low-score noise as a match. So you can trust a green light.

Part 2 — Contribute a block after you build (sb-hub-contribute)​

The inverse skill. You just shipped a solution; which parts are reusable enough, and not already covered, to become a new block?

When it fires​

  • "Should this be a solution block?"
  • "What in this repo isn't covered by an SB?"
  • "Extract a solution block from this repo."

Or directly: /aliz-ai-sb-hub-contribute [repo path or URL].

How it works​

The skill does the judgement with the LLM and uses a bundled script for the deterministic parts:

  1. Identify candidate reusable units. It reads the repo and pulls out the bounded, repeatable capabilities (for example "BigQuery table-change monitoring"), ignoring client-specific wiring and one-off glue.
  2. Check coverage. Each unit is checked against the existing corpus, returning a verdict: covered (a block already does this, so contribute improvements there instead), partial (related blocks exist, judge whether it stands alone), or gap (nothing close, a strong candidate).
  3. Screen the gaps against the SB review criteria. The non-negotiables: focused scope (one bounded problem, not a whole project), client independence (no client names or identifiers), and formal-requirements feasibility (can it realistically get an sb- repo, the solution-block topic, CODEOWNERS, a track, docs, and a maturity).
  4. Propose the worthwhile blocks. For each survivor it drafts a name (sb-<slug>), owning track, one-sentence scope, negative triggers, and a summary skeleton ready for the Hub's summarizer, plus the create steps.

Worked example​

You: I built a Dockerfile security linter in this repo that fails CI on violations. Is any of it worth turning into a solution block?

Assistant: The reusable unit here is Dockerfile security linting with a CI gate. I ran a coverage check against the Hub: the closest existing block scores only 0.076 (barely above the 0.07 noise floor) and is not actually related, so nothing in the Hub covers this. It passes the review criteria (focused, client-independent, feasible). Proposed block:

  • Name: sb-dockerfile-security-lint (track: Infra / AppDev)
  • Scope: lint Dockerfiles for security best practices and fail CI on violations
  • Create steps: new sb- repo + the solution-block topic + CODEOWNERS + a README stating track, usage, and maturity

The client-specific CI wiring around it is not worth extracting.

The skill recommends and preps; it does not create the repo. Once you create the sb- repo with the solution-block topic, the Hub's collector and summarizer ingest it automatically, and it becomes searchable via Part 1.

note

If nothing in the repo is both uncovered and block-worthy, the skill says so ("already covered" or "nothing here is reusable enough for an SB"). It will not invent candidates.

Further Reading​