Roblox Site Architect

Roblox Site Growth Pipeline

Coordinate research, planning, implementation, validation, and growth work for a Roblox-focused site. This Skill is a workflow orchestrator: it defines stage gates and deliverables, but it does not claim to generate or deploy a complete production site by itself.

Operating model

The pipeline has seven ordered stages. Each stage writes one durable Markdown artifact under <project-root>/pipeline/ using the schema in references/pipeline-contracts.md. Read that contract before starting or resuming work.

Use a named supporting Skill only when it is available in the current environment and relevant to the request. If it is unavailable, either:

1. produce an equivalent artifact using available capabilities such as searching the web, reading files, and running local commands; or
2. mark the artifact partial or blocked, record the missing capability and evidence gap, and stop at the affected gate.

Never state that a Skill, tool, build, deployment, submission, or external action ran unless its actual result is available in the current work record.

Status and progression

• complete: all exit criteria are met with cited evidence.
• partial: useful work exists, but named gaps remain. Proceed only when those gaps cannot invalidate the next decision.
• blocked: a required input, authorization, or capability is absent. Do not advance.

When resuming, inspect existing artifacts in numeric order. Preserve prior evidence, note superseded conclusions, and update timestamps instead of silently rewriting history.

Inputs

Establish these before Stage 01:

• the Roblox game name or canonical game URL;
• the intended audience, locale, and business objective if known;
• <project-root> if a target project already exists;
• the user's requested scope: research only, planning, local implementation, or authorized external release.

Unknown inputs stay explicitly unknown. A game name alone does not authorize building, purchasing, publishing, or outreach.

Initialize pipeline artifacts

Use scripts/init_pipeline.py to prepare the seven contract artifacts from the maintained pipeline templates. The initializer creates only <project-root>/pipeline/ and its seven Markdown files; it does not build a website or access the network.

Run a dry-run first from any working directory. Dry-run is the default and prints a JSON plan without creating files:

python3 /path/to/roblox-site-architect/scripts/init_pipeline.py \
  --project-root /path/to/project \
  --game "Canonical Roblox game name" \
  --scope "Bounded research and delivery scope"

After reviewing the resolved targets, add --apply to create all seven files. The initializer validates every input, template, and target before writing; if any target artifact already exists, it fails without overwriting or creating the other artifacts. There is no force mode.

Initialize a project only once. To resume or repair an existing pipeline, inspect its artifacts in numeric order and continue from their recorded state; never rerun initialization over an existing artifact set.

Seven-stage pipeline

01 Opportunity

Purpose: decide whether the game/site opportunity deserves further research.

Preferred supporting Skill: roblox-hit-evaluator when available.

Entry criteria

• A candidate game can be distinguished from similarly named games.
• The evaluation horizon and decision question are stated.

Work

• Confirm canonical Roblox identity, developer, creation/release context, and observable activity.
• Measure demand, momentum, content supply, and uncertainty from timestamped public evidence.
• Separate breakout potential from SEO-site viability; they are related but not identical.
• Record counter-evidence and missing observations.

Artifact: <project-root>/pipeline/01-opportunity-report.md.

Exit criteria

• The game identity is unambiguous.
• A pursue, hold, or reject decision is stated with evidence and confidence limits.
• Material unknowns and the next validation action are explicit.
• blocked stops the pipeline; reject ends it unless the user changes the objective.

02 Keywords

Purpose: turn the opportunity into a prioritized, non-duplicative search-demand map.

Preferred supporting Skills: site-keyword-research, keyword-competition-analysis, and google-trends-to-pages when available and relevant.

Entry criteria

• Stage 01 is complete, or its remaining gaps do not affect keyword discovery.
• Target locale and game identity are known.

Work

• Collect query evidence from current search results, trends, platform language, and target-site coverage.
• Cluster by intent rather than by superficial wording.
• Map each cluster to a proposed page, existing page, or watchlist item.
• Record demand/competition evidence separately from inferred priority.
• Avoid inventing search volume when no measurement source is available.

Artifact: <project-root>/pipeline/02-keyword-map.md.

Exit criteria

• Each priority cluster has intent, evidence, target route or disposition, and rationale.
• Cannibalization and duplicate-page risks are identified.
• P0/P1 work is small enough to implement and trace back to sources.

03 Evidence

Purpose: assemble a source ledger that can support every factual page claim.

Preferred supporting Skills: roblox-game-data-scraper for supported public Trello collection, youtube-transcribe for supplied or accessible videos, and other relevant evidence Skills when available.

Entry criteria

• Priority page intents from Stage 02 are known.
• Required claim types are listed: codes, mechanics, values, steps, dates, or comparisons.

Work

• Collect primary sources first; use secondary/community sources as attributed signals.
• Store source URL or stable identifier, publisher, captured time, relevant excerpt/field, and claim supported.
• Reconcile conflicts without averaging incompatible facts.
• Mark volatile claims with a freshness expectation.
• Do not infer a game code, numeric value, redemption step, or mechanic from generic genre conventions.

Artifact: <project-root>/pipeline/03-source-ledger.md.

Exit criteria

• Every planned factual section maps to at least one source or is marked unknown.
• Codes, numeric values, and redemption instructions have explicit support and observation time.
• Conflicts, stale sources, and unsupported page ideas are visible to the next stage.

04 Site plan and build

Purpose: convert validated demand and evidence into a scoped information architecture and local implementation.

Preferred supporting Skill: multi-game-codes-hub for its implemented codes-page generator when relevant; otherwise work directly in the target project with its existing framework and conventions.

This orchestrator does not include a complete starter project. Implement inside the confirmed target project, or use a separately available supporting Skill whose starter/output has been validated for that project.

Entry criteria

• Stage 02 identifies target routes and intent.
• Stage 03 supports the facts needed by the initial scope.
• <project-root> and local change scope are confirmed before implementation.

Work

• Define page purpose, primary query cluster, source dependencies, route, internal-link role, and acceptance checks.
• Prefer the smallest coherent launch scope; do not add generic codes, tier, wiki, or calculator pages without demand and evidence.
• Preserve the target project's design system, data architecture, and build conventions.
• Implement only locally authorized work. Generated content remains a draft until evidence and project checks pass.

Artifact: <project-root>/pipeline/04-site-plan.md.

Exit criteria

• Every planned/built route maps to keyword intent and evidence.
• The artifact distinguishes planned, implemented, verified, and deferred routes.
• Local typecheck/build/test outcomes are recorded from real command results.
• Unsupported claims and placeholder content are absent from release candidates.