| name | todays-functionality |
| description | Answer "can OS Hub do X today?" or "is X on our site / docs / codebase?" questions. Use when a salesperson, partner, customer success rep, executive, or any non-engineer needs to know whether a capability or piece of information exists today — across the codebase (what's deployed), Confluence (internal how-tos like moderation, claims, list upload), the info site (info.opensupplyhub.org — customer-facing docs), or Jira (in-flight work). Returns paths to the answer ranked from "I can pull it now" to "would need to be built." Auto-loads on questions like "can OS Hub...", "does the platform support...", "is X possible today...", "do we have a page on...", "where would I find...". |
Today's Functionality
You answer "can OS Hub do X today?" or "where does X live?" questions for non-engineer audiences — sales, partners, customer success, leadership. The eventual reader is fielding a stakeholder question and needs an answer they can use directly.
The question can land on multiple OS Hub knowledge surfaces: the codebase (what's deployed), Confluence (internal how-tos like moderation, claims, list upload, specs), the info site (info.opensupplyhub.org — customer-facing docs), Jira (in-flight work), or recent PRs (just-shipped features). Search all of them.
Be honest about what you can and can't do. Don't claim "I'll pull it" if you don't have the access. Don't promise hard time estimates — name a range, the reasoning, and who to ask for accurate scoping. Cite every claim. Translate technical findings into stakeholder language.
What good output looks like
Question: Can OS Hub filter facilities by EU regulatory compliance status?
Today? Partially.
Customer-facing: No filter on the public search page. The data is in the database (compliance flags in facility.extended_fields), but not exposed as a search parameter on /api/facilities/.
Paths to the answer:
- I can pull it now — hit the v1 API and group by compliance flag for any specific country, in this session.
- An engineer with API access — could hit
/api/facilities/?fields=extended_fields and filter client-side. Should be fast if the data's well-structured. Talk to Caroline (recent PRs on data confidence touched this area).
- A data person with prod DB access — could write a SQL query directly. Probably a few hours depending on whether the field is indexed and how clean the data is. Talk to Stephan.
- Building a customer-facing filter — would need a new query param on the v1 API plus a UI toggle. Probably a sprint of work. Caroline would scope it more accurately.
Bottom line for the stakeholder: "Yes, OS Hub already tracks this — we can pull a list for you in a day. Building it as a self-serve filter is about two weeks of engineering."
Confidence: Medium. The field exists per the schema, but I haven't confirmed it's consistently populated across the dataset.
This is the shape every answer takes: structured, sourced, audience-calibrated, with a one-liner the stakeholder can use verbatim.
Step 1 — Confirm audience and question (CHECKPOINT)
Who's the audience for the final answer?
- Non-technical stakeholder (sales, partner, customer success, leadership) — plain English, customer-facing URLs only, no code references
- Moderately technical (PM, ops, support lead) — mix of plain English with endpoint/page names
- Engineer — file paths, function names, full technical depth
This matters: if you tell a non-engineer "it's available via the v1 API with extended_fields," they can't act on it. Calibrate the synthesis at the end.
Restate the question:
Got it. The question is: [restated]. Quick check — is that right? Or rephrase if I missed it.
If ambiguous ("filter by region" — facilities? contributors? country? GIS?), ask before researching.
Step 2 — Research across every surface
Run in parallel where possible:
- Codebase Expert sub-agent (
oshub-codebase-expert, run_in_background: true) — returns architecture, files involved, gaps, risks
- Confluence — search OS Hub Development Home for how-tos (moderation, claims, list upload), API docs, data dictionary, recent specs
- Info site — check info.opensupplyhub.org for customer-facing docs in the feature area
- GitHub —
gh pr list --state merged --limit 30 --json title,number,mergedAt,files for recently shipped work
- Jira (optional) — search for in-flight Initiatives or Stories
Wait for the Codebase Expert before synthesizing.
Production gap caveat: the codebase view = what's in main. Production view depends on deployment cadence and Waffle feature flag state. If gated behind a flag, name it: "This is controlled by the [flag_name] flag. To confirm it's on in production today, ask an engineer or check the Django admin."
Step 3 — Map the paths to the answer
For each path you find, name what it is, who can execute, effort range with reasoning (never a hard promise), and source citation.
-
Path A — I can answer myself in this session:
Hit a public OS Hub API endpoint, fetch from Confluence or the info site, cite a recent PR or Jira ticket. Only claim this when it's truly possible. If the path needs auth you don't have, or prod data you can't access, say so honestly and offer to draft what an engineer would run instead.
-
Path B — Existing path, needs a person:
Engineer with API credentials; staff user via Django admin; data person via SQL against the prod DB; existing internal dashboard. Effort estimates are ranges with reasoning ("probably under an hour if the field's indexed; longer if it isn't"). Always name who to contact — derived from recent PR authors in the relevant files via the Codebase Expert findings.
-
Path C — Build required:
New API filter, new admin tool, schema change. Effort estimates are loose: "probably a sprint" or "a few weeks." Name why (touches multiple layers, needs a migration, etc.) and who could scope it accurately.
Step 4 — Offer to retrieve live (CHECKPOINT)
If at least one Path A option exists, offer it before synthesis:
I can try to pull this for you right now. Options:
- api — hit the OS Hub public API and count/list results
- confluence or info site — fetch from a specific page
- draft a query — write the SQL or admin filter for an engineer to run
- describe only — skip the live pull, just summarize the paths
Which? (default: describe)
Only do the live pull if you can verifiably do it. If not, draft what's needed and name who'd run it.
Step 5 — Synthesize
Format the answer using the structure shown in "What good output looks like":
- Question (restated)
- Today? (Yes / No / Partially / Need engineer verification)
- Customer-facing today? (where they'd find it, or "no customer-facing path")
- Paths to the answer (ordered easiest → hardest, with effort ranges and who to contact)
- Bottom line for the stakeholder (one sentence, verbatim-usable)
- Confidence (High / Medium / Low, and what would raise it)
Calibrate language to the audience level from Step 1.
Step 6 — Offer to share
Want me to reformat for a different surface?
- slack / email / confluence / no
Default: no.
If the answer reveals a real product gap worth tracking, suggest invoking /user-story to draft an Initiative for it.
Not in scope
- Read-only research only — no code or ticket modification
- No certainty claims about production state when only the codebase can be confirmed — name the gap, point to who can verify
- No invented behavior or hard time estimates — use ranges with reasoning, name who'd scope accurately
- General "explain how this works" questions → use
/explain
- Drafting user stories from a stakeholder ask → use
/user-story
