# Arckit Gcloud Search

> Find G-Cloud services on UK Digital Marketplace with live search and comparison

- Skill: `tractorjuice/arckit-gcloud-search` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tractorjuice/arckit-gcloud-search`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tractorjuice/arckit-gcloud-search/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: tractorjuice (https://skillmd.com/u/tractorjuice)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tractorjuice/arckit-gcloud-search

---


You are helping an enterprise architect find and compare G-Cloud services on the UK Digital Marketplace.

## User Input

```text
$ARGUMENTS
```

## Context

**G-Cloud** is the UK Digital Marketplace framework for procuring off-the-shelf cloud services:

- Cloud hosting, IaaS, PaaS
- SaaS platforms and tools
- Cloud support services
- No custom development - just service procurement

This command:

1. Analyzes your project requirements to identify cloud service needs
2. Generates G-Cloud procurement requirements
3. **Searches the Digital Marketplace for matching services** (live search)
4. Compares services and provides recommendations

## Instructions

### 1. Prerequisites Check

**IMPORTANT**: Check prerequisites before proceeding:

a. **Project with Requirements** (MUST exist):

- Check if user specified a project name/number
- Look for `projects/[project]/ARC-*-REQ-v*.md`
- If NOT found: ERROR "Run $arckit-requirements first to define project needs"

b. **Architecture Principles** (RECOMMENDED):

- Check if `projects/000-global/ARC-000-PRIN-*.md` exists
- If exists: Read it for cloud strategy, security requirements
- If NOT found: WARN "Consider running $arckit-principles to define cloud governance"

### 2. Load Project Context

> **Note**: Before generating, scan `projects/` for existing project directories. For each project, list all `ARC-*.md` artifacts, check `external/` for reference documents, and check `000-global/` for cross-project policies. If no external docs exist but they would improve output, ask the user.

1. Read the **REQ** (Requirements) artifact for the target project
2. Read the **PRIN** (Architecture Principles, in 000-global) if available
3. Parse user input for specific service types needed

### 3. Analyze Cloud Service Needs

**Scan requirements** to identify what cloud services are needed:

**Look for**:

- INT-xxx mentioning: "cloud hosting", "SaaS", "IaaS", "PaaS", "monitoring", "email service"
- NFR-xxx mentioning: "uptime", "availability", "disaster recovery", "cloud infrastructure"
- FR-xxx mentioning: "platform", "service", "hosting", "managed service"

**Service categories to identify**:

- **Cloud Hosting**: IaaS, VMs, containers, Kubernetes
- **Cloud Software**: SaaS platforms, tools, applications
- **Cloud Support**: Managed services, monitoring, backup
- **Specialized Services**: Email, CDN, databases, analytics

**Determine**:

- Primary service category needed
- Must-have requirements (from MUST priority)
- Desirable requirements (from SHOULD priority)
- Compliance needs (security certifications, data residency)

---

**CRITICAL - Auto-Populate Document Control Fields**:

Before completing the document, populate ALL document control fields in the header:

**Construct Document ID**:

- **Document ID**: `ARC-{PROJECT_ID}-GCLD-v{VERSION}` (e.g., `ARC-001-GCLD-v1.0`)

**Populate Required Fields**:

*Auto-populated fields* (populate these automatically):

- `[PROJECT_ID]` → Extract from project path (e.g., "001" from "projects/001-project-name")
- `[VERSION]` → "1.0" (or increment if previous version exists)
- `[DATE]` / `[YYYY-MM-DD]` → Current date in YYYY-MM-DD format
- `[DOCUMENT_TYPE_NAME]` → "G-Cloud Service Requirements"
- `ARC-[PROJECT_ID]-GCLD-v[VERSION]` → Construct using format above
- `[COMMAND]` → "arckit.gcloud-search"

*User-provided fields* (extract from project metadata or user input):

- `[PROJECT_NAME]` → Full project name from project metadata or user input
- `[OWNER_NAME_AND_ROLE]` → Document owner (prompt user if not in metadata)
- **Classification** → comes from the resolved Document Control header, not from a placeholder. `_partials/RENDERING.md` fixes the ladder from the artefact's own regime; `${default_classification}` applies only where that regime falls through to user config.

*Calculated fields*:

- `[YYYY-MM-DD]` for Next Review Date → Current date + 30 days

*Pending fields* (leave as [PENDING] until manually updated):

- `[REVIEWER_NAME]` → [PENDING]
- `[APPROVER_NAME]` → [PENDING]
- `[DISTRIBUTION_LIST]` → Default to "Project Team, Architecture Team" or [PENDING]

**Populate Revision History**:

```markdown
| 1.0 | {DATE} | ArcKit AI | Initial creation from `$arckit-gcloud-search` command | [PENDING] | [PENDING] |
```

**Populate Generation Metadata Footer**:

The footer should be populated with:

```markdown
**Generated by**: ArcKit `$arckit-gcloud-search` command
**Generated on**: {DATE} {TIME} GMT
**ArcKit Version**: {ARCKIT_VERSION}
**Project**: {PROJECT_NAME} (Project {PROJECT_ID})
**AI Model**: [Use actual model name, e.g., "Claude Sonnet 5 (session default)"]
**Generation Context**: [Brief note about source documents used]
```

---

### 4. Read the Template

**Read the template** (user override takes precedence):

- **First**, check `.arckit/templates-custom/gcloud-requirements-template.md`
- **Then**, `.arckit/templates-custom/gcloud-requirements-template.md`
- **Fallback**, `.arckit/templates/gcloud-requirements-template.md`
- **Then read** `.arckit/templates/_partials/RENDERING.md` and resolve the `<!-- DOC-CONTROL-HEADER -->` marker in the template before writing. Do not hand-write the Document Control table: the partial `RENDERING.md` selects is the only source of the 14 standard fields and of the classification ladder.

The template owns the document structure. Populate it — do not invent a parallel one.

Create directory: `projects/[project]/procurement/`

Fill **Sections 1-5** from the analysis in Step 3:

- **1. Service Overview** — what is needed and why, from the BR-xxx requirements; strategic alignment against `ARC-000-PRIN-*.md` where it exists; integration context from the INT-xxx requirements.
- **2. Must-Have Requirements** — the functional, performance, security, compliance and integration requirements a service MUST satisfy, each traced to its source requirement ID.
- **3. Desirable Requirements** — the nice-to-haves, with the weighting they carry in Section 5.
- **4. Success Criteria** — how the buying team will know the chosen service worked.
- **5. Evaluation Criteria** — the weighted model. The template ships 50/25/15/10; adjust the weights to the project and say why if you do.

Sections 6-9 are filled in Steps 5-7 below, once the search has run.

### 5. Search Digital Marketplace (WebSearch)

**IMPORTANT**: Now perform **live marketplace search** to find actual services.

For each service category identified:

#### 5.1 Build Search Query

Create search query:

```text
site:digitalmarketplace.service.gov.uk g-cloud [service category] [key requirements]
```

**Examples**:

- `site:digitalmarketplace.service.gov.uk g-cloud cloud hosting kubernetes`
- `site:digitalmarketplace.service.gov.uk g-cloud monitoring prometheus grafana`
- `site:digitalmarketplace.service.gov.uk g-cloud email delivery service`

**Include in query**:

- Service category name
- Key technical requirements (from MUST requirements)
- Important features (top 2-3 from requirements)

#### 5.2 Execute WebSearch

Use WebSearch tool to search Digital Marketplace.

**For each major service type needed** (up to 3 service types):

1. Execute WebSearch with built query
2. Parse results to extract:
   - Service names
   - Supplier names
   - Service descriptions
   - Links to service pages
   - Pricing information (if mentioned)
   - Key features mentioned

#### 5.3 Parse and Filter Results

For each service found:

- **Check MUST requirements**: Does service mention capabilities for MUST requirements?
- **Score SHOULD requirements**: How many desirable features are mentioned?
- **Check compliance**: Are required certifications mentioned?
- **Extract pricing**: If mentioned in search results
- **Capture link**: Direct URL to service page

#### 5.4 Populate the Search Results Sections

Fill **Sections 6-8** of the template from what the search returned:

- **6. Service Search Results** — record the search strategy first (queries run, date, filters applied), then one "Service N" block per shortlisted service using the template's block structure: supplier, G-Cloud service ID, service URL, category, pricing model, must-have and desirable match counts, key features, compliance mentions, gaps identified, and a risk level. Keep 3-5 services; the template ships three blocks and says to repeat the structure.
- **7. Service Comparison Matrix** — score every shortlisted service against the weighted criteria. Then complete **Unmet Must-Have Requirements**: any MUST from Section 2 that no shortlisted service clearly meets. Write "No unmet must-have requirements." rather than dropping the section when there are none — an empty heading and a missing heading say different things to whoever reviews the procurement.
- **8. Recommendation** — the primary recommendation with its justification, plus at least one alternative. Say what would change the recommendation.

Search-result evidence is external content, so follow the citation instructions in `.arckit/references/citation-instructions.md`: place inline citation markers next to claims drawn from a supplier's service page and register each source in the template's **External References** section.

### 6. Handle Search Scenarios

**If WebSearch finds 5+ good matches**:

- Show top 5 services in comparison table
- Provide recommendation with clear rationale

**If WebSearch finds 3-4 matches**:

- Show all matches in comparison table
- Highlight which best meets requirements
- May suggest alternative search terms

**If WebSearch finds 1-2 matches**:

- Show what was found
- Suggest broader search terms
- Recommend manual marketplace search with guidance

**If WebSearch finds 0 matches**:

- Explain no results found for this query
- Suggest alternative search terms (broader)
- Provide manual search guidance: go to https://www.digitalmarketplace.service.gov.uk/
- List specific search terms to try manually
- Note: Service may exist but not indexed well - encourage direct marketplace search

### 7. Complete the Closing Sections

Fill the rest of the template, then write the file:

- **9. Next Steps** — immediate actions, supplier engagement, evaluation and contract award. Give each a named owner and a date rather than leaving the template's placeholders in place.
- **10. Resources and References** — the template ships the Digital Marketplace guidance links, the G-Cloud framework notes and the related ArcKit commands. Add the project's own documents; keep the framework notes.
- **Appendix A: Search Methodology** — the queries, filters and exclusions actually used, so the search is reproducible.
- **Appendix B: Glossary** — expand any G-Cloud or framework term the buying team will not already know.
- **External References** — the document register, citations and unreferenced documents, per the citation instructions.

**CRITICAL**: Use the **Write tool** to save the completed document to
`projects/[project]/procurement/ARC-{PROJECT_ID}-GCLD-v1.0.md`. Writing it inline
risks the 32K output-token limit; the Write tool also creates parent directories.

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

### 8. Quality Validation

Before finalizing, validate output:

- ✅ All requirements from ARC-*-REQ-*.md are included
- ✅ Architecture principles referenced (if available)
- ✅ WebSearch was executed for each major service type
- ✅ At least 3 services found and compared (or explanation if fewer)
- ✅ Comparison table is complete
- ✅ Recommendation has clear rationale
- ✅ All service links are included
- ✅ Must-have requirements are checked against each service
- ✅ Gaps are identified if services don't meet all requirements
- ✅ Next steps are actionable

### 9. Report Completion

Output to user:

```text
✅ Generated G-Cloud service search for [PROJECT_NAME]

Framework: G-Cloud
Document: projects/[project]/procurement/ARC-{PROJECT_ID}-GCLD-v1.0.md

Requirements Summary:
- ✅ Requirements extracted from ARC-*-REQ-*.md
- [✅/⚠️] Architecture principles referenced
- ✅ Service category identified: [Category]

Marketplace Search Results:
- ✅ Executed WebSearch for: [search query 1]
- [✅] Executed WebSearch for: [search query 2] (if multiple)
- ✅ Found [X] matching services
- ✅ Shortlisted top [X] services for comparison

Recommended Service:
🏆 [Service Name] by [Supplier Name]
   - Match Score: [X/Y] MUST + [X/Y] SHOULD requirements
   - Link: [URL]

Alternative Services:
2. [Service Name] by [Supplier] - [URL]
3. [Service Name] by [Supplier] - [URL]

Next Steps:
1. Review document: projects/[project]/procurement/ARC-{PROJECT_ID}-GCLD-v1.0.md
2. Visit recommended service page: [Link]
3. Contact supplier for detailed information
4. Validate integration requirements (INT-xxx)
5. Complete due diligence checklist (Section 9.2)
6. Award contract via Digital Marketplace

Important: All shortlisted services should be validated against MUST requirements before selection.
```

## Key Principles

1. **Live Search**: Always use WebSearch to find actual services - don't just generate requirements
2. **Requirements-Driven**: Build search queries from actual project requirements
3. **Comparison Focus**: Provide side-by-side comparison with clear recommendation
4. **Practical Links**: Include direct links to every service mentioned
5. **Gap Identification**: Clearly identify if services don't meet MUST requirements
6. **Actionable Output**: Next steps should be concrete and immediately actionable
7. **Traceability**: Maintain requirement IDs throughout evaluation

## Search Query Examples

**For Cloud Hosting**:

- `site:digitalmarketplace.service.gov.uk g-cloud cloud hosting kubernetes docker`
- `site:digitalmarketplace.service.gov.uk g-cloud iaas virtual machines linux`
- `site:digitalmarketplace.service.gov.uk g-cloud paas cloud platform managed`

**For SaaS Platforms**:

- `site:digitalmarketplace.service.gov.uk g-cloud monitoring observability prometheus`
- `site:digitalmarketplace.service.gov.uk g-cloud email delivery service smtp`
- `site:digitalmarketplace.service.gov.uk g-cloud ci cd pipeline automation`
- `site:digitalmarketplace.service.gov.uk g-cloud analytics data warehouse`

**For Specialized Services**:

- `site:digitalmarketplace.service.gov.uk g-cloud cdn content delivery network`
- `site:digitalmarketplace.service.gov.uk g-cloud backup disaster recovery`
- `site:digitalmarketplace.service.gov.uk g-cloud security scanning vulnerability`

## Error Handling

- **No requirements**: ERROR "Run $arckit-requirements first - need to define service needs"
- **Custom development detected**: ERROR "This is for custom development - use $arckit-dos instead"
- **No service needs found**: WARN "No cloud service requirements found - are you sure this is G-Cloud procurement?"
- **No search results**: Suggest broader search terms, provide manual search guidance
- **Few search results (1-2)**: Show what was found, suggest alternative searches

## G-Cloud vs DOS Guidance

If requirements suggest custom development rather than cloud services:

```text
⚠️ FRAMEWORK MISMATCH DETECTED

Your requirements suggest custom development (FR-xxx functional requirements for building features).

G-Cloud is for buying off-the-shelf cloud services, not custom development.

✅ Use $arckit-dos instead - Digital Outcomes and Specialists

DOS is the correct framework for:
- Custom software development
- Building new systems
- Hiring developers/specialists
- Project outcomes that require custom implementation

Only use $arckit-gcloud-search if you need:
- Cloud hosting or infrastructure (IaaS/PaaS)
- Off-the-shelf SaaS platforms
- Managed cloud services
```

## 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