howells/go

<tool_restrictions>

MANDATORY Tool Restrictions

REQUIRED TOOLS — use these when indicated:

• AskUserQuestion — Preserve the one-question-at-a-time interaction pattern. In Claude Code, use the tool. 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 missing tools or fallbacks to the user. </tool_restrictions>

/arc:go

The front door to Arc. Understands context, asks what you want to do, routes to the right workflow.

Process

Step 1: Gather Context (in parallel)

Explore the codebase:

Task Explore model: haiku: "Quick overview of this codebase:
- What is this project? (framework, language, purpose)
- Key directories and their purposes
- Any obvious patterns or conventions
- Is this an empty/minimal project with no framework set up?
  (e.g. just a package.json with no src/, no app framework, no pages)

Keep it brief — 5-10 bullet points max."

Check for existing Arc artifacts:

ls docs/vision.md docs/arc/specs/*.md docs/arc/plans/*.md docs/plans/*.md 2>/dev/null | head -10

Check Linear (if MCP available): If mcp__linear__* tools exist, check for active issues.

Read progress journal for recent work:

head -50 docs/arc/progress.md 2>/dev/null

Check repo staleness:

# Last commit date (ISO format)
git log -1 --format=%ci 2>/dev/null
# Stale branches (merged or no commits in 30+ days)
git branch --list --format='%(refname:short) %(committerdate:relative)' | head -10

A repo is considered stale if the last commit was more than 2 weeks ago.

Step 2: Present Context

Briefly share what you found:

• Project type and key patterns
• Any existing plans or tasks
• Recent work from progress journal (if found)

Step 3: Ask What They Want to Do

Present options based on context using AskUserQuestion. Evaluate conditions in order — use the first that matches.

If repo is stale (last commit > 2 weeks ago):

AskUserQuestion:
  question: "This repo hasn't been touched in a while (last commit: [date]). What would you like to do?"
  header: "Returning to [project name]"
  options:
    - label: "Run a health check"
      description: "Check if it builds, review outdated deps, and surface what needs attention"
    - label: "I know what I want to work on"
      description: "Skip the checkup and jump straight in"
    - label: "See suggestions"
      description: "Run /arc:suggest for ideas on what to work on"

If Linear has active issues:

AskUserQuestion:
  question: "You have [N] active issues in Linear. What would you like to do?"
  header: "Active Issues Found"
  options:
    - label: "Work on an issue"
      description: "Pick one of the active Linear issues to work on"
    - label: "Start something new"
      description: "Ignore existing issues and start fresh"
    - label: "See suggestions"
      description: "Run /arc:suggest for ideas on what to work on"

If recent plans exist:

AskUserQuestion:
  question: "I found a plan for [topic]. What would you like to do?"
  header: "Existing Plan Found"
  options:
    - label: "Continue that work"
      description: "Pick up where you left off on [topic]"
    - label: "Start something different"
      description: "Set the existing plan aside and work on something new"

If empty/minimal codebase (no framework detected):

AskUserQuestion:
  question: "This project doesn't have a framework set up yet. What would you like to do?"
  header: "Empty Project"
  options:
    - label: "Set up a new project"
      description: "Scaffold a framework (Next.js, etc.) and get started"
    - label: "Define a vision first"
      description: "Run /arc:vision to clarify project goals before building"
    - label: "I know what I want to build"
      description: "Describe the feature and jump straight in"

If fresh codebase (has framework but no Arc artifacts):

AskUserQuestion:
  question: "What would you like to work on?"
  header: "Ready to Go"
  options:
    - label: "Build a feature"
      description: "Describe a feature or change you want to make"
    - label: "Fix a bug"
      description: "Describe the bug you want to fix"
    - label: "Explore what needs work"
      description: "Run /arc:suggest to discover what could be improved"

Step 3.5: Scope Posture (feature work only)

Skip this step if the user's intent is a quick fix, continuing an existing plan, running tests, shipping, or reviewing code. Only ask when routing to /arc:ideate or /arc:implement for a new feature.

Ask one question:

AskUserQuestion:
  question: "How should I approach this?"
  header: "Scope Posture"
  options:
    - label: "Expand"
      description: "Find the bigger product hiding inside this. Push the ambition up."
    - label: "Reduce"
      description: "Find the minimum viable version. Strip everything else."
    - label: "Just build what I described"
      description: "Take the request as-is, no scope change. (Default if you skip this.)"

Pass the chosen posture as context when invoking the downstream skill:

Skill arc:[chosen]: "[user's description] [Posture: expand|reduce|as-described]"

Rules:

• If the user doesn't engage with the question or says something like "just do it", default to as-described and move on. Don't slow them down.
• Never ask this for small changes, bug fixes, or continuation of existing work.

Step 4: Route to Workflow

Based on their answer:

| Intent | Route to | |--------|----------| | "Run a health check" | Health check flow (see below) | | "Set up a new project" | /arc:implement with scaffolding context | | "I want to build [feature]" | /arc:ideate (with posture from Step 3.5) | | "Quick fix/small change" | /arc:implement | | "Continue [existing plan]" | /arc:implement | | "Not sure what to work on" | /arc:suggest | | "Review/improve existing code" | /arc:audit or /arc:review | | "Make it responsive/fix mobile" | /arc:responsive | | "Ship to production" | /arc:letsgo | | "Run tests" | /arc:testing |

Invoke the skill:

Skill arc:[chosen]: "[user's description]"

Health Check Flow

When the user picks "Run a health check", run these sequentially — stop and report if anything critical fails:

1. Run mechanical checks — Skill arc:audit: "quick"

   • Does it build? Typecheck? Lint? Tests pass?
   • If critical failures, report them and ask if the user wants to fix before continuing.

2. Check dependencies — Skill arc:deps

   • Outdated packages, known CVEs, major version bumps available.
   • Present the deps report but don't auto-apply upgrades.

3. Surface what needs attention — Skill arc:suggest

   • TODOs, technical debt, stale plans, vision gaps.
   • Gives the user a prioritized list of what to tackle.

After all three, summarize:

## Health Check Summary

**Build:** [passing / failing — brief detail if failing]
**Dependencies:** [N outdated, N with CVEs — or "all current"]
**What needs attention:** [top 2-3 items from suggest]

Then ask:

AskUserQuestion:
  question: "What would you like to tackle?"
  header: "Health Check Complete"
  options:
    - label: "[Top suggestion from results]"
      description: "[Brief rationale]"
    - label: "[Second suggestion]"
      description: "[Brief rationale]"
    - label: "Something else"
      description: "Tell me what you want to work on"

What /arc:go is NOT

• Not a replacement for specific commands — it routes TO them
• Not for when you already know what command to use

Interop

• Routes to all other /arc:* commands
• Reads Linear issues (if MCP available), /arc:vision, progress for context
• Uses /arc:suggest when user is unsure
• Chains /arc:audit quick → /arc:deps → /arc:suggest for stale repo health checks