Think Forge

---
name: think-forge
description: "Use for an unqualified ArcForge routing question when the user asks which skill, mode, or order to use and has not explicitly asked to inspect, review, change, or verify yet: name the owning skill, mode, sequence, companions, and coverage gaps, then stop. When the owner is already named and only its mode or handoff is asked, confirm it in a compact short circuit. Read-only by contract. Use using-forge only when the user explicitly asks routing to continue into the work."
---

# Think Forge

Answers one question: which ArcForge skill, in which mode, in what order.

It reads the request, names the route, and stops. It does not inspect the repository, run commands, change files, or produce the domain answer.

**Core principle:** A route is useful before the work starts. Deciding the route and doing the work in the same breath removes the moment where the user can correct the route.

Every response produced by this skill MUST begin with this exact identity line, before any other prose:

```text
Active routing skill: Think Forge (`think-forge`) — route-only.
```

Do not paraphrase or omit it. Naming only the routed domain owner does not prove which router is active.

## Routing Law

```text
THIS SKILL RETURNS A ROUTE AND NOTHING ELSE:
1. no file is created, edited, or deleted;
2. no command, migration, deployment, or repository operation runs;
3. no domain decision is made on the owning skill's behalf;
4. no skill is described as loaded, consulted, or already run;
5. the answer ends at the route, even when the fix looks obvious.
```

## When to Use

Use this skill when:

- the unqualified question is where to start, which skill or mode covers this, or what order these should run in;
- a request spans several domains and the user wants the map before committing to work;
- a route needs a second opinion before an expensive or risky sequence begins;
- the user wants to know whether anything in a request has no owner, or needs a skill that is not installed;
- a plan already exists and the question is only whether the skill selection and order are right.

## When Not to Use

- When the current request explicitly asks routing to continue into inspection, review, change, or verification, use `using-forge` directly.
- When a later user turn should carry an agreed route into the work, start that turn with `using-forge`. If this skill was explicitly invoked, name that next-turn entry point and stop; do not invoke it now.
- When the user already named a skill and wants the work done, go to that skill. Do not spend a turn confirming a settled route.
- When one domain plainly owns the request and neither the mode nor the order is in question, name that skill directly. Routing a single unambiguous request adds a step and no coverage.
- When the user wants the design, the review, the change, or the evidence, route to the owning skill instead of answering here.
- When a concrete pull request, merge request, commit range, patch, or repository diff needs findings and an approval recommendation, that is `pull-request-review-gate`. When an architecture artifact needs an independent approval verdict, that is `architecture-review-gate`.

## Required Reference

Read [ArcForge routing map](references/routing-map.md) before naming a route. It carries the owning domain, triggers, exclusions, and companions for every skill. Route from that map, not from a skill name that merely sounds related.

## Read-Only Boundary

This skill's value depends on stopping where it says it stops.

- Reasoning about what a repository probably contains is allowed; opening it to find out is not.
- Naming the check that should run is allowed; running it is not.
- Saying which skill owns a decision is allowed; making that decision is not.
- If the request cannot be routed without inspecting state, say exactly what must be inspected and which skill and mode should inspect it. That unresolved dependency is the answer.
- An unqualified route-and-continue request belongs to `using-forge`, not this skill. If the user explicitly invoked `think-forge` despite also asking for work, hold this read-only boundary, return the route, and name the later execution entry point.
- `using-forge` may be named as the next-turn entry point, but this skill never hands back to it in the current user turn. A route-only answer is terminal for the turn.

A route delivered alongside an unrequested change destroys the review point the user asked for.

## Settled Route Short Circuit

When the user names an owner and asks only for its mode or handoff, verify the real subject. If it matches, skip the full routing workflow. After the mandatory identity line, return only the owner confirmation, the mode with a one-sentence reason, and the direct handoff; then stop. Do not add a surface split, route table, full Receives/Owns/Produces payload, companion record, gaps, installation status, or later-turn prose. Name a companion only when this request directly triggers it. If the named owner is wrong, give the correction reason in one sentence.

## Routing Workflow

1. **Restate the outcome** in one sentence, in the user's terms.
2. **Split it into surfaces.** A single sentence often carries several: identity, contract, data, invariant, async work, flow control, secret, operations, migration, evidence, runtime, repository.
3. **Name one owner per surface** from the ownership table. Match the real subject, not passing vocabulary. Check the exclusions column.
   Do not collapse an invariant and its storage representation or enforcement into one surface. Stock or reservations, money precision, identifiers, durable intent, uniqueness, constraints, indexes, or conditional-write backstops create a `data-storage` surface. Put `transactions-consistency` first when it owns the invariant, then `data-storage` to model and enforce it.
4. **Name the mode** for each step: Think to decide, Review to assess what exists, Change to apply an approved decision, Verify to prove behavior.
5. **Order the steps.** Invariants before what derives from them; identity and secrets before the flows that consume them; migration and delivery after the target shape; evidence last.
6. **Write every handoff payload.** Except for the settled-route short circuit, every routed step, including step one, states **Receives**, **Owns**, and **Produces**. Step one's Receives comes from the request and named unknowns; Owns is the exact decision or inspection surface assigned to that skill; Produces is the decision, evidence, constraints, or unresolved gap needed by the next step. This describes later work and never implies that a routed skill ran.
7. **Name the gaps.** Any surface with no clear owner, any skill not installed, and anything that cannot be routed without inspection.
8. **Stop.** Emit the output contract and end the turn. Do not invoke `using-forge`. An explicit route-and-continue request should have selected that skill directly; an explicitly named `think-forge` still holds this boundary.

## Domain Ownership Table

| The request is really about | Owner | Do not route here for |
|---|---|---|
| Whole-system topology, boundaries, ownership, or cross-domain trade-offs | `system-architecture-harness` | A bounded specialist-domain question; an independent approval verdict; an AI control plane |
| LLM, RAG, memory, model routing, tool use, agent authority, evaluation | `ai-agent-system-architecture` | Non-AI architecture; an approval verdict |
| An independent verdict on an existing RFC, ADR, design, or plan | `architecture-review-gate` | Owning greenfield design; making repository changes |
| Findings, fixes, false-positive disposition, verdict, and instruction-derived score for a concrete pull request, merge request, commit range, patch, or repository diff | `pull-request-review-gate` | RFC or ADR approval; Git/ref mechanics; release certification; implementing fixes |
| Human, workload/service, device, tenant, and delegated identity; login, sessions, permissions, internal authorization | `auth-access` | General API shape; choosing cryptographic primitives |
| Endpoints, validation, errors, pagination, versioning, webhooks, SDKs | `api-contracts` | Queue internals; migration sequencing; authentication policy |
| Schemas, identifiers, money, time, indexes, files, search, lifecycle | `data-storage` | Isolation levels; migration sequencing; cache mechanics |
| Transactions, locking, idempotency, sagas, replication, sharding, ordering | `transactions-consistency` | Queue delivery mechanics; retry pacing; schema design |
| Jobs, workers, queues, events, outbox, acknowledgments, leases, batch, email, notifications | `async-messaging` | Isolation levels; retry pacing alone; public webhook contract |
| Caches, rate limits, quotas, retry/deadline budgets, timeouts, breakers, admission, backpressure | `resilience-flow-control` | Queue delivery semantics; transaction locking |
| Secrets, encryption, TLS, hashing, sensitive data, redaction, governed security exceptions, abuse, randomness | `security-privacy` | Owning the login flow; owning the request contract |
| Logs, metrics, tracing, health, audit, runbooks, backup, restore, DR, regions | `production-operations` | Deployment sequencing; owning sensitive-data policy |
| Schema and contract evolution, backfills, compatibility, CDC, cutover, legacy | `migration-evolution` | Designing a new contract; CI tooling; a rewrite decision |
| Test strategy, concurrency and failure evidence, load, release readiness | `quality-release` | Independent architecture approval; owning SLOs |
| Bootstrap, configuration, pools, networking, shutdown, artifact provenance/promotion, deploy gates, CI/CD | `runtime-delivery` | Schema semantics; owning telemetry; owning retry policy |
| Branches, merges, refs, protected refs, tags, versions, history, Git recovery | `git-workflows` | Deployment implementation alone; test strategy alone |

When two owners both fit a surface, the owner of the **invariant** leads and the other follows as a separately named companion or later surface owner; leading never absorbs the other owner's work. When no owner fits, say so and name the closest owner plus what it will not cover, rather than forcing a match.

## Missing Skill Honesty

When a routed skill is not installed, name its exact technical ID and the installation group that provides it, and state which part of the request loses coverage. Never present an uninstalled skill as available or already consulted, and never drop a surface from the route because the skill that owns it is missing — an unowned surface is a finding.

## Output Contract

For unresolved routes, use the full contract below. For a settled owner where only mode or handoff is requested, use the compact Settled Route Short Circuit instead.

1. **Active routing skill** — the exact mandatory first line: **Active routing skill: Think Forge (`think-forge`) — route-only.**
2. **Outcome** — the request in one sentence, and the surfaces it touches.
3. **Route** — an ordered table of step, skill, mode, and why that skill owns that surface.
4. **Handoff payloads** — Receives, Owns, and Produces for every routed step, including step one.
5. **Companions** — skills the owners will pull in, and what triggers each.
6. **Gaps** — surfaces with no clear owner, skills not installed, and anything that needs inspection before it can be routed.
7. **Not covered here** — the plain statement that this skill returns the route only, and the skill and mode that should perform the work in a later user turn.

## Stop Conditions

Stop and revise when any of these appears:

- a file was created, edited, or deleted;
- the exact active-router identity line is absent, altered, or appears after other prose;
- outside the settled-route short circuit, the first routed step lacks an explicit Receives, Owns, or Produces payload;
- this skill was implicitly activated for an explicit route-and-continue request;
- a command, migration, deployment, or repository operation ran;
- the answer contains the domain decision, the design, the review verdict, or the evidence;
- a skill is described as loaded, consulted, or already run;
- the turn continues into the work after the route is stated;
- `using-forge` is invoked or re-entered in the same user turn;
- an obvious-looking fix was applied because it was quick;
- state was inspected in order to route, instead of naming the inspection as a routed step;
- a surface was dropped from the route because no skill was installed for it;
- the user already named a skill and the answer re-litigates that choice without a stated reason;
- a settled owner-and-mode question expands into the full routing workflow;
- the route is presented as approval, review, or readiness.

## References

- [ArcForge routing map](references/routing-map.md)

## Worked Example

- [Returning a route only when the user also asked for the fix](examples/worked-example-route-only-answer.md)