using-arc

What this skill does

<SUBAGENT-STOP>
If you were dispatched as a subagent to execute a specific task, skip this skill.
</SUBAGENT-STOP>

<arc_runtime>
Arc-owned files live at the Arc plugin root for full-runtime installs.

Skills and agents reference Arc-owned files using bare relative paths from the plugin root: `agents/`, `references/`, `disciplines/`, `templates/`, `scripts/`, `rules/`, and `skills/<name>/`. Resolve the plugin root by walking up from a SKILL.md or agent file's location (it's the directory containing `agents/` and `skills/`).

Project-local files stay relative to the user's repository (`.ruler/`, `docs/`, `src/`, etc.).
</arc_runtime>

# Using Arc

Arc's canonical product definition, domain language, and operating boundary live in
`CONTEXT.md` at the Arc repository root. This skill applies that context at session
startup.

Arc has a broad workflow surface. Use this skill as the small control plane that decides
how to route work without loading every workflow into context at once.

Arc is self-contained and lifecycle-focused. Its job is to move software work from idea
to shipped code through Arc-owned workflows, not to act as a general registry for
external personal skills. When a specialist practice is useful, absorb it into the
relevant Arc workflow in Arc's own language.

## Instruction Priority

When instructions conflict, use this order:

1. User instructions in the conversation
2. Project instructions (`AGENTS.md`, `CLAUDE.md`, repo docs)
3. Arc skills
4. Default system behavior

The user stays in control. Arc provides process, not authority over explicit user intent.

## The Rule

Before substantial work, decide whether an Arc skill clearly applies.

- If the user names an Arc skill, use it.
- If the task clearly matches an Arc workflow, use that skill before acting.
- If the task is small, direct, or outside Arc's workflows, respond normally.

Arc should improve routing, not create ceremony for every trivial request.

Do not route users to external skill collections as part of Arc's normal operation.
External skills can inspire Arc workflow design, but Arc workflows must remain usable on
their own.

## Platform Adaptation

<required_reading>
Arc skills may mention Claude Code tool names. For platform mappings and equivalents, read:

`references/platform-tools.md`
</required_reading>

When a skill says `AskUserQuestion`, preserve the behavior rather than the literal tool name.
In Codex, ask one concise plain-text question at a time unless a structured question tool is actually available in the current mode.
Do not narrate tool fallbacks or tell the user that a question tool is unavailable.

## Arc Runtime

Arc supports two install classes:

- **Full-runtime installs**: Claude plugin and Codex installer. These include Arc-owned `agents/`, `references/`, `disciplines/`, `templates/`, and `scripts/`.
- **Prompt-only installs**: `skills.sh` and similar prompt distributors. These copy `SKILL.md` files only.

When a workflow needs Arc-owned files, resolve the Arc plugin root by walking up from the loaded skill's filesystem location (it's the directory containing `agents/` and `skills/`). Skills reference Arc-owned files using bare relative paths from that root: `agents/...`, `references/...`, `disciplines/...`, `templates/...`, `scripts/...`, `rules/...`, `skills/<name>/...`. Project-local paths such as `.ruler/`, `docs/`, `src/`, or the user's own `rules/` stay scoped to the user's repository.

If the requested workflow depends on Arc-owned files and the environment only has prompt-only skills, stop early and tell the user to upgrade to the full Claude plugin or Codex installer.

For UI work, keep these roles separate:

- WireText -> low-fidelity wireframes and layout exploration
- Chrome MCP -> preferred rendered-page verification in Claude Code
- `agent-browser` -> preferred browser automation fallback outside Claude Code
- Playwright -> scripted browser fallback when needed
- Figma MCP -> implementation from real design files

## Progressive Disclosure

Do not preload large Arc workflows.

- Start with the smallest relevant skill
- Load reference files only when the active task actually needs them
- Prefer targeted rules and references over broad up-front reading

## Workflow Routing

Use these defaults:

- New feature or product thinking -> `ideate`
- Plan execution -> `implement`
- Small scoped change -> `implement`
- Architecture or quality review -> `review` or `audit`
- Testing work -> `testing`
- Go-live/shareability readiness -> `launch`
- Unsure what to do -> ask one focused question, then route to the smallest matching workflow

When a task needs a specialist lens, keep the routing Arc-native:

- Ambiguous product intent -> `vision`, `ideate`, or `review` with one focused clarifying question
- Reuse or duplicated UI patterns -> `implement`, `review`, or `audit`
- Public API documentation -> package-focused `implement` or external documentation skills
- Architecture boundaries or oversized modules -> `review`, `audit`, or `implement`
- Rendered UX, browser behavior, and responsive issues -> `implement` when tied to Arc UI work, otherwise external rendered-app QA skills

## Artifact Locations

Arc-owned artifacts live under:

- `docs/arc/specs/`
- `docs/arc/plans/`
- `docs/arc/archive/`

If a workflow references legacy `docs/plans/`, treat it as a compatibility fallback while the repo migrates.