Arckit Gov Code Search

If no project exists, that is fine — proceed with the user's query alone. You will need to create a project directory using create-project.sh --json before writing output.

Step 2: Take User's Query

Extract the search query from the user's arguments. The query is what follows the $arckit-gov-code-search command invocation. Preserve the user's intent exactly — do not summarise or rephrase their query at this stage.

Step 3: Read Template

Read .arckit/templates/gov-code-search-template.md for the output structure.

Step 4: Initial Search

Search govreposcrape with the user's original query:

• query: user's query (3-500 characters, descriptive natural language)
• resultMode: "snippets"
• limit: 20

Record all results. Note total number of hits returned.

Step 5: Generate and Execute Query Variations

Generate multiple query variations to maximise coverage:

Broadened queries (remove specific terms to widen results):

• Strip technical specifics from the original query
• Use category-level terms (e.g., "patient record system" instead of "FHIR R4 patient resource API")

Narrowed queries (add specifics to find precise implementations):

• Add technology specifics (language, framework, standard version)
• Add government context (GDS, GOV.UK, NHS, HMRC, MOD, DLUHC)

Rephrased queries (synonyms and alternative technical terms):

• Use synonyms for key concepts
• Use alternative technical terminology (e.g., "session store" instead of "session management")

Good govreposcrape queries are descriptive natural language phrases (not keyword strings). Examples:

• "Redis session management for GOV.UK services"
• "NHS patient appointment scheduling API client"
• "government accessible form components GOV.UK Design System"

Execute 3-5 query variations. Use resultMode: "snippets", limit: 20 for each.

Step 6: Deduplicate Results

Combine all results from Steps 4 and 5. Remove duplicate repositories (same org/repo appearing in multiple searches). Keep track of which queries surfaced each result — a repo appearing in many queries is a stronger signal of relevance.

Step 7: Group Results by Relevance

Classify deduplicated results:

High relevance (directly addresses the query):

• Repository description and README snippets clearly match the user's information need
• The repo appears in multiple query variations
• Active government organisation (alphagov, nhsx, hmrc, dwp, moj, dfe, etc.)

Medium relevance (related or tangential):

• Repository is in the same domain but doesn't directly solve the query
• Older repos that may have relevant historical patterns
• Dependency repos that are used by relevant implementations

Step 8: Deep Dive on High-Relevance Results

For the top 10 high-relevance results, use WebFetch on the GitHub repository page to gather:

• Organisation: Which government department or agency owns it
• Description: What the repo does (from GitHub description and README intro)
• Language and framework: Primary language, key frameworks used
• License: Type of open-source licence
• Last activity: Last commit date, is it actively maintained
• Stars and forks: Popularity and adoption signals
• README excerpt: Key implementation details, usage patterns, dependencies

Construct WebFetch URLs as: https://github.com/{org}/{repo}

For repos with particularly relevant READMEs, also fetch https://raw.githubusercontent.com/{org}/{repo}/main/README.md to get the full README content.

Step 9: Identify Code Patterns

Across all high-relevance results, identify recurring patterns:

• Common approaches: How are teams solving this problem? (e.g., REST API vs event-driven, monolith vs microservices)
• Common frameworks: What technologies appear repeatedly? (e.g., Ruby on Rails, Node.js, Python Flask, Java Spring)
• Common standards: What standards or specifications are referenced? (e.g., FHIR R4, GOV.UK Design System, OAuth 2.0)
• Common infrastructure patterns: Deployment approaches, cloud providers, database choices
• Shared dependencies: Libraries or packages used across multiple repos

Step 10: Compare Implementation Approaches

Where multiple repos solve the same problem differently, compare:

• What trade-offs did each approach make?
• Which approach appears more mature or widely adopted?
• Are there any that stand out as best practice examples?

This comparison is valuable for teams choosing an implementation approach.

Step 10b: Project Relevance Mapping (if project context available)

If project requirements were read in Step 1, create a table mapping the top search results back to specific project requirements:

This connects abstract search results to concrete project needs and gives developers an immediate next action. Include the exact install command (npm install, pip install, git clone) for each repo where applicable.

If no project context exists, skip this step.

Step 11: Search Effectiveness Assessment

Evaluate the search results honestly:

• Coverage: What percentage of the query's intent was addressed by the results? Were central government repos (alphagov, NHSDigital, govuk-one-login) found, or only local council repos?
• Gaps: What specific topics returned no relevant results? For each gap, provide an alternative search strategy: direct GitHub org URL, official API documentation URL, or specific WebSearch query the user can try
• Index limitations: If govreposcrape results are dominated by a narrow set of orgs or technologies, note this explicitly so the user understands the result bias

This section prevents users from drawing false conclusions (e.g., "no government team has built this") when the reality is the index simply doesn't cover it.

Step 12: Detect Version and Determine Increment

Use Glob to find existing projects/{project-dir}/research/ARC-{PROJECT_ID}-GCSR-*-v*.md files. Read the highest version number from filenames.

If no existing file: Use VERSION="1.0"

If existing file found:

1. Read the existing document to understand its scope (queries searched, repos found)
2. Compare against current query and findings
3. Determine version increment:
   • Minor increment (e.g., 1.0 → 1.1): Same query scope — refreshed results, updated repo details, minor additions
   • Major increment (e.g., 1.0 → 2.0): Substantially different query, new capability areas, significantly different results landscape

Step 13: Quality Check

Before writing, read .arckit/references/quality-checklist.md and verify all Common Checks plus the GCSR per-type checks pass. Fix any failures before proceeding.

Step 14: Write Output

Use the Write tool to save the complete document to projects/{project-dir}/research/ARC-{PROJECT_ID}-GCSR-v${VERSION}.md following the template structure.

Auto-populate fields:

• [PROJECT_ID] from project path
• [VERSION] = determined version from Step 11
• [DATE] = current date (YYYY-MM-DD)
• [STATUS] = "DRAFT"
• [CLASSIFICATION] = "OFFICIAL" (UK Gov) or "PUBLIC"

Include the generation metadata footer:

**Generated by**: ArcKit `$arckit-gov-code-search` agent
**Generated on**: {DATE}
**ArcKit Version**: {ArcKit version from context}
**Project**: {PROJECT_NAME} (Project {PROJECT_ID})
**AI Model**: {Actual model name}

DO NOT output the full document. Write it to file only.

Step 15: Return Summary

Return ONLY a concise summary including:

• Query searched (original and variations)
• Total results found (before deduplication) and unique repos assessed
• Top 5 repositories (org/repo, language, last activity, relevance, GitHub URL)
• Key patterns identified (2-3 bullet points)
• Dominant technologies across results
• Next steps ($arckit-gov-reuse, $arckit-research)

Quality Standards

• govreposcrape as Primary Source: All results must come from govreposcrape searches — do not invent or recall repositories from training data
• WebFetch for Detail: Always verify repo details via WebFetch before including them in the report
• GitHub URLs: Include the full GitHub URL for every repo mentioned in the document
• Descriptive Queries: Use descriptive natural language queries (per govreposcrape docs) — not keyword strings or boolean operators

Edge Cases

• No project context: Still works — create a project directory first using create-project.sh --json before writing output. Use the query as the project name if needed
• No results after all query variations: Suggest refining the query with more government-specific terms, broader domain terms, or alternative technical terminology. Include the attempted queries in the report
• govreposcrape unavailable: Report the unavailability and suggest manual search at https://github.com/search?q=org:alphagov+{query} and other government GitHub organisations

Important Notes

• Markdown escaping: When writing less-than or greater-than comparisons, always include a space after < or > (e.g., < 3 seconds, > 99.9% uptime) to prevent markdown renderers from interpreting them as HTML tags or emoji

User Request

$ARGUMENTS

Suggested Next Steps

After completing this command, consider running:

• $arckit-gov-reuse -- Deep reuse assessment of interesting finds
• $arckit-research -- Broader market research
• $arckit-adr -- Record pattern decisions