Arness Standard

Implement medium-complexity features and enhancements through a mid-ceremony, pattern-aware workflow: spec-lite generation, structured plan, task-tracked execution, verification, review-lite, and unified change record -- all in a single session. Every standard implementation produces three artifacts in <plans-dir>/STANDARD_<name>/: a plan (STANDARD_<name>.md), a report (STANDARD_REPORT.json), and a change record (CHANGE_RECORD.json), giving robust auditability with less overhead than the full thorough pipeline.

This skill follows the same execution model as arn-code-swift's moderate path but adds a Spec-Lite front-end (lightweight architectural specification) and a unified CHANGE_RECORD.json envelope for downstream consumption.

This is an execution skill. It runs in normal conversation (NOT plan mode).

Step 0: Ensure Configuration

Read ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-ensure-config/references/step-0-fast-path.md and follow its instructions. This guarantees a user profile exists and ## Arness is configured with Arness Code fields before proceeding.

Pipeline Position

              arn-code-standard (this skill)
              ============================
              For medium-complexity changes
              routed here by the scope router

Entry:  arn-planning (scope router) --> standard tier
          |
          v
        arn-implementing --> arn-code-standard
          |
          v
        Spec-Lite --> Plan --> Execute --> Report --> Review-Lite --> Change Record --> Ship
          |
          v
        <plans-dir>/STANDARD_<name>/
        +-- STANDARD_<name>.md      (plan with spec-lite)
        +-- STANDARD_REPORT.json    (execution report)
        +-- CHANGE_RECORD.json      (unified envelope)

Workflow

Step 1: Capture and Load Context

1. Accept the user's description. This can be anything from a sentence ("add rate limiting to /api/users") to detailed requirements. If the user already provided the description in their trigger message, use that directly without asking again.

2. Confirm understanding with a brief restatement (1-2 sentences).

3. Read the project's CLAUDE.md and extract the ## Arness section to find:

   • Code patterns path
   • Plans directory
   • Template path
   • Template version and Template updates preference (if present)

4. Load pattern documentation from the code patterns directory:

   • code-patterns.md (required)
   • testing-patterns.md (required)
   • architecture.md (required)
   • ui-patterns.md (if it exists)
   • security-patterns.md (if it exists)

5. If pattern documentation files are missing (no code-patterns.md, testing-patterns.md, or architecture.md in the Code patterns directory):

   Inform the user: "This is the first time pattern documentation is being generated for this project. Analyzing your codebase to understand its patterns, conventions, and architecture. This is a one-time operation — future invocations will use the cached results."

   Then invoke the arn-code-codebase-analyzer agent (existing codebase) or arn-code-pattern-architect (greenfield) to generate fresh analysis. Write the results to the Code patterns directory.

Hold this context for use throughout the workflow.

Step 2: Spec-Lite Generation

2a. Pre-check specialist relevance

Before invoking any agents, read ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-ensure-config/references/specialist-pre-check.md and apply the pre-check logic using the pattern documentation loaded in Step 1 and the user's feature description. This produces two boolean flags:

• ui_involved: true if ANY of: (1) ui-patterns.md exists AND contains a ## Sketch Strategy section, (2) the feature description contains UI terms (component, page, form, button, layout, dashboard, UI, UX, screen, view, modal, dialog, command, terminal, output, widget, window, panel, console, display, prompt, menu, toolbar, status bar, progress, table, tree -- case-insensitive), (3) architecture.md contains a frontend, CLI, TUI, desktop, or mobile framework in its Technology Stack section
• security_relevant: true if BOTH: (1) security-patterns.md exists, AND (2) the feature description contains security terms (auth, login, password, token, payment, upload, API key, PII, encrypt, permission, session, cookie, CORS, CSRF, rate limit, secret, credential -- case-insensitive)

2b. Parallel agent dispatch

Dispatch the following agents in parallel based on the pre-check results:

• Always: arn-code-architect
• If ui_involved: also arn-code-ux-specialist (requires ui-patterns.md to exist)
• If security_relevant: also arn-code-security-specialist (requires security-patterns.md to exist)

All dispatched agents run in parallel (independent analyses, no cross-agent dependencies).

For arn-code-architect, provide:

User expertise context:

--- BEGIN USER EXPERTISE ---
[Read from ~/.arness/user-profile.yaml or .claude/arness-profile.local.md (project override takes precedence)]
Role: [role]
Experience: [development_experience]
Technology preferences: [technology_preferences]
Expertise-aware: [expertise_aware]
--- END USER EXPERTISE ---

--- BEGIN PROJECT PREFERENCES ---
[Read from .arness/preferences.yaml if it exists, otherwise omit this section]
--- END PROJECT PREFERENCES ---

When presenting technology recommendations, apply the advisory pattern: present the technically optimal recommendation first, then present any preference-aligned alternative with honest pros/cons. Let the user decide.

Feature idea: The user's description from Step 1.

Codebase context: The full content of the pattern documentation loaded in Step 1 (code-patterns.md, testing-patterns.md, architecture.md, and ui-patterns.md if present).

Specific question: "Standard-tier assessment for this change: (1) Problem statement -- what problem does this solve in 1-2 sentences? (2) Key requirements -- what are the 3-7 concrete, verifiable requirements? (3) Which files need modification and why? (4) Which codebase patterns apply? (5) Architectural notes -- how does this change fit the existing architecture? What modules, integration points, and constraints are involved? (6) Are there architectural risks or concerns? (7) Does this change need UI work? (8) Are there security implications?"

For arn-code-ux-specialist (when dispatched), provide: The same feature description and ui-patterns.md. Specific question: "Quick UI assessment: which components are affected? Any accessibility considerations?"

For arn-code-security-specialist (when dispatched), provide: A brief security assessment request with the feature description and security-patterns.md.

2c. False-negative follow-up

After all parallel agents complete, check the architect's assessment for signals that a missed specialist should have been included:

• If ui_involved was false AND the architect's output mentions UI concerns, component design, user interaction, or interface layout: dispatch arn-code-ux-specialist sequentially with the architect's assessment as additional context.
• If security_relevant was false AND the architect's output mentions security concerns, authentication, authorization, data protection, or vulnerability: dispatch arn-code-security-specialist sequentially with the architect's assessment as additional context.

The follow-up dispatch is silent -- no user notification or status message. The user sees the combined Spec-Lite from all agents (parallel + sequential) as a single result.

2d. Present the Spec-Lite

Present the Spec-Lite to the user, structured as:

1. Problem Statement (1-2 sentences)
2. Key Requirements (3-7 bullet points)
3. Architectural Notes (2-5 sentences on how this fits the codebase)
4. Files to modify (with paths and rationale)
5. Applicable patterns from code-patterns.md
6. Risks or concerns (if any)
7. **UI a