@bfirestone45/opencode-arc 0.3.1

package/commands/arc-which.md

@@ -0,0 +1,13 @@
+---
+description: Show which project is active and how it was resolved
+---
+
+Run `arc which` to display the currently active project and its resolution source.
+
+Shows:
+- The active project ID and name
+- Where the project was resolved from (command line flag, local config, or server path match)
+- The project config file path
+- Any warnings about the configuration
+
+Useful for debugging project resolution issues when commands target the wrong project.

package/index.js

@@ -0,0 +1,153 @@
+import fs from "node:fs";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+
+const pluginRoot = path.dirname(fileURLToPath(import.meta.url));
+
+function readMarkdownAsset(assetPath) {
+  const content = fs.readFileSync(assetPath, "utf8");
+  const match = content.match(/^---\n([\s\S]*?)\n---\n?([\s\S]*)$/);
+  if (!match) {
+    return { frontmatter: {}, body: content.trim() };
+  }
+  return {
+    frontmatter: parseFrontmatter(match[1]),
+    body: match[2].trim(),
+  };
+}
+
+function parseFrontmatter(source) {
+  const result = {};
+  let currentObject;
+
+  for (const line of source.split("\n")) {
+    if (line.trim() === "") {
+      continue;
+    }
+
+    const nested = line.match(/^\s+([^:]+):\s*(.*)$/);
+    if (nested && currentObject) {
+      currentObject[nested[1].trim()] = parseScalar(nested[2]);
+      continue;
+    }
+
+    const entry = line.match(/^([^:]+):\s*(.*)$/);
+    if (!entry) {
+      continue;
+    }
+
+    const key = entry[1].trim();
+    const value = entry[2];
+    if (value === "") {
+      result[key] = {};
+      currentObject = result[key];
+      continue;
+    }
+
+    result[key] = parseScalar(value);
+    currentObject = undefined;
+  }
+
+  return result;
+}
+
+function parseScalar(value) {
+  const trimmed = value.trim();
+  if (trimmed === "true") {
+    return true;
+  }
+  if (trimmed === "false") {
+    return false;
+  }
+  return trimmed;
+}
+
+function listMarkdownFiles(directory) {
+  return fs
+    .readdirSync(directory, { withFileTypes: true })
+    .filter((entry) => entry.isFile() && entry.name.endsWith(".md"))
+    .map((entry) => path.join(directory, entry.name))
+    .sort();
+}
+
+function loadCommands() {
+  const commands = {};
+  const commandsDir = path.join(pluginRoot, "commands");
+
+  for (const filePath of listMarkdownFiles(commandsDir)) {
+    const { frontmatter, body } = readMarkdownAsset(filePath);
+    commands[path.basename(filePath, ".md")] = {
+      ...frontmatter,
+      template: body,
+    };
+  }
+
+  return commands;
+}
+
+function loadAgents() {
+  const agents = {};
+  const agentsDir = path.join(pluginRoot, "agents");
+
+  for (const filePath of listMarkdownFiles(agentsDir)) {
+    const { frontmatter, body } = readMarkdownAsset(filePath);
+    const permission = permissionsFromTools(frontmatter.tools);
+    agents[path.basename(filePath, ".md")] = {
+      ...frontmatter,
+      ...(Object.keys(permission).length > 0 ? { permission } : {}),
+      prompt: body,
+    };
+  }
+
+  return agents;
+}
+
+function permissionsFromTools(tools = {}) {
+  const supportedPermissions = new Set(["bash", "edit", "webfetch", "doom_loop", "external_directory"]);
+  const permission = {};
+
+  for (const [toolName, enabled] of Object.entries(tools)) {
+    if (supportedPermissions.has(toolName)) {
+      permission[toolName] = enabled ? "allow" : "deny";
+    }
+  }
+
+  return permission;
+}
+
+function addDefaults(target, defaults) {
+  for (const [key, value] of Object.entries(defaults)) {
+    if (target[key] === undefined) {
+      target[key] = value;
+    }
+  }
+}
+
+export const ArcPlugin = async ({ $ }) => ({
+  config: async (config) => {
+    config.command ??= {};
+    config.agent ??= {};
+    config.skills ??= {};
+    config.skills.paths ??= [];
+
+    addDefaults(config.command, loadCommands());
+    addDefaults(config.agent, loadAgents());
+
+    const skillsPath = path.join(pluginRoot, "skills");
+    if (!config.skills.paths.includes(skillsPath)) {
+      config.skills.paths.push(skillsPath);
+    }
+  },
+  event: async ({ event }) => {
+    if (event.type !== "session.created" && event.type !== "session.compacted") {
+      return;
+    }
+    try {
+      await $`arc prime`;
+    } catch {
+      // Fail open so missing or unhealthy arc never blocks OpenCode.
+    }
+  },
+});
+
+export default ArcPlugin;

package/package.json

@@ -0,0 +1,43 @@
+{
+  "name": "@bfirestone45/opencode-arc",
+  "version": "0.3.1",
+  "description": "Official OpenCode plugin package for arc workflow integration.",
+  "type": "module",
+  "main": "./index.js",
+  "module": "./index.js",
+  "exports": {
+    ".": "./index.js"
+  },
+  "files": [
+    "index.js",
+    "commands",
+    "agents",
+    "skills",
+    "README.md",
+    "CHANGELOG.md",
+    "version.txt"
+  ],
+  "scripts": {
+    "test": "node --test index.test.mjs",
+    "pack:dry-run": "npm pack --dry-run",
+    "prepublishOnly": "npm test && npm run pack:dry-run"
+  },
+  "keywords": [
+    "opencode",
+    "opencode-plugin",
+    "arc",
+    "agent-workflow"
+  ],
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/bfirestone/agent-marketplace",
+    "directory": "opencode-marketplace/plugins/arc"
+  },
+  "peerDependencies": {
+    "@opencode-ai/plugin": "*"
+  },
+  "publishConfig": {
+    "access": "public"
+  }
+}

package/skills/arc/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: arc
+description: General arc CLI reference and workflow context. Use when the user asks about arc commands, issue tracking workflows, when to use arc vs TodoWrite, or needs help with arc configuration.
+---
+
+# Arc Issue Tracker
+
+Track complex, multi-session work with a central issue tracking system.
+
+## Setup
+
+Install the OpenCode arc plugin from `opencode-marketplace/plugins/arc/`.
+
+After installation, run `arc onboard` in any project. It will:
+- Resolve project from server-side path registration (primary mechanism)
+- Or detect from local project config (`~/.arc/projects/`)
+- Or prompt you to run `arc init` for new projects
+
+If you are using the CLI without the plugin:
+```bash
+arc init                    # Initialize project
+```
+
+The plugin is the single source of truth for agent-runtime integration. It provides:
+- **SessionStart/PreCompact hooks** - runs `arc prime` automatically
+- **Starter prompts and docs** - includes install metadata and command docs that point users to `arc onboard`
+- **Skills and resources** - detailed guides and reference
+- **Agents** - for bulk operations
+
+## When to Use Arc vs TodoWrite
+
+| Use Arc | Use TodoWrite |
+|---------|---------------|
+| Multi-session work | Single-session tasks |
+| Complex dependencies | Linear task lists |
+| Discovered work patterns | Simple checklists |
+| Work needing audit trail | Quick, disposable lists |
+
+**Rule of thumb**: When in doubt, prefer arc—persistence you don't need beats lost context.
+
+**Deep dive**: Run `arc docs boundaries` for detailed decision criteria.
+
+## Workflow Skills
+
+Arc includes workflow skills that guide you through the development lifecycle with built-in process discipline.
+
+| Skill | Purpose | Invoke when |
+|-------|---------|-------------|
+| `arc-brainstorm` | Design discovery through Socratic dialogue | Starting new features or significant work |
+| `arc-plan` | Break design into implementation tasks | After `arc-brainstorm` approves a design |
+| `arc-implement` | TDD execution via fresh subagents per task | Ready to implement planned tasks |
+| `arc-debug` | 4-phase root cause investigation | Encountering bugs or test failures |
+| `arc-verify` | Evidence-based completion gates | Before claiming any work is done |
+| `arc-review` | Code review dispatch and triage | After implementing a task |
+| `arc-finish` | Session completion protocol | Ending a work session |
+
+### Pipeline
+
+```
+arc-brainstorm → arc-plan → arc-implement (per task) → arc-review → arc-finish
+                                ↕              ↕
+                             arc-debug      arc-verify
+```
+
+### Execution Paths
+
+After `arc-plan`, choose:
+- **Single-agent + subagents**: Invoke `arc-implement`. Main agent orchestrates, subagents do TDD. Best for sequential tasks.
+- **Agentic team (Claude Code today)**: This OpenCode port defers that execution path. Use the single-agent + subagent flow here, and only use the team-deploy surface in runtimes that explicitly support it.
+
+## Quick Start
+
+Run `arc onboard` at session start to get project context and available issues.
+
+**Project Recovery**: If local project config is missing, `arc onboard` resolves the project via server-side path registration. The server is the source of truth for project-to-directory mappings.
+
+## CLI Reference
+
+Run `arc prime` for full workflow context, or `arc <command> --help` for specific commands.
+
+**Essential commands:**
+- `arc ready` - Find unblocked work
+- `arc create` - Create issues
+- `arc update` - Update status/fields
+- `arc close` - Complete work
+- `arc show` - View details
+- `arc dep` - Manage dependencies
+- `arc plan` - Manage plans (create, show, approve, reject, comments)
+- `arc which` - Show active project and resolution source
+- `arc paths` - Manage workspace path registrations
+- `arc project` - Manage projects (list, create, delete, rename, merge)
+- `arc self update` - Update arc CLI to latest version
+- `arc db backup` - Create database backup
+
+## Deep Dive Documentation
+
+**Two-step workflow:**
+1. **Search** to find which topic has the info: `arc docs search "query"`
+2. **Read** the full topic for details: `arc docs <topic>`
+
+```bash
+# Search returns [topic] in brackets - tells you where to look
+arc docs search "create issue"
+# Results show: [workflows] Discovery and Issue Creation...
+
+# Then read that topic for full content
+arc docs workflows
+```
+
+Fuzzy matching handles typos - "dependncy" finds "dependency" docs.
+
+**Available topics** with `arc docs <topic>`:
+
+| Command | Purpose |
+|---------|---------|
+| `arc docs boundaries` | When to use arc vs TodoWrite - decision matrix, integration patterns, common mistakes |
+| `arc docs workflows` | Step-by-step checklists for session start, epic planning, side quests, handoff |
+| `arc docs dependencies` | Dependency types (blocks, related, parent-child, discovered-from) and when to use each |
+| `arc docs resumability` | Writing notes that survive compaction - templates and anti-patterns |
+| `arc docs plans` | Plan patterns (inline, parent-epic, shared) with examples |
+| `arc docs plugin` | OpenCode plugin installation and workflow contract |
+
+Run `arc docs` without a topic to see an overview.
+
+## Agent Mode
+
+For bulk operations (creating epics with tasks, batch updates), use the **arc-issue-tracker** agent as a subagent. This keeps arc command execution in a dedicated workflow without consuming main conversation context.
+
+## Dependency Types
+
+Arc supports four dependency types:
+
+| Type | Purpose | Affects Ready? |
+|------|---------|----------------|
+| **blocks** | Hard blocker - B can't start until A complete | Yes |
+| **related** | Soft link - informational only | No |
+| **parent-child** | Epic/subtask hierarchy | Yes |
+| **discovered-from** | Track provenance of discovered work | No |
+
+**Deep dive**: Run `arc docs dependencies` for examples and patterns.
+
+## Plans
+
+Plans are ephemeral review artifacts backed by filesystem markdown files in `docs/plans/`. They support a review workflow with approval, rejection, and comments.
+
+**CLI commands:**
+
+| Command | Purpose |
+|---------|---------|
+| `arc plan create <file-path>` | Register an ephemeral plan, returns plan ID |
+| `arc plan show <plan-id>` | Show plan content, status, and comments |
+| `arc plan approve <plan-id>` | Approve the plan |
+| `arc plan reject <plan-id>` | Reject the plan |
+| `arc plan comments <plan-id>` | List review comments |
+
+Plans go through a review cycle: create, review (with comments), then approve or reject. Approved design content is written into the epic's description field when creating implementation tasks. Run `arc docs plans` for full details.
+
+## Labels
+
+Labels are global (shared across all projects) and support colors and descriptions. Use labels for cross-cutting categorization like `security`, `performance`, `tech-debt`.
+
+## Session Protocol
+
+**At session start:**
+```bash
+arc onboard  # Get context, recover project if needed
+```
+
+**Before ending any session:**
+Invoke the `arc-finish` skill — it handles capturing remaining work, quality gates, arc updates, commit, and push. Work is NOT done until `git push` succeeds.
+
+**Writing notes for resumability:**
+```bash
+arc update <id> --stdin <<'EOF'
+COMPLETED: X. IN PROGRESS: Y. NEXT: Z
+EOF
+```
+
+**Deep dive**: Run `arc docs resumability` for templates.
+
+## Common Workflows
+
+### Starting Work
+```bash
+arc onboard                         # Get context (recovers project if needed)
+arc ready                           # Find available work
+arc show <id>                       # View details
+arc update <id> --take                  # Claim work (sets session ID + in_progress)
+```
+
+### Creating Issues
+```bash
+arc create "Title" -t task          # Create task
+arc create "Epic title" -t epic     # Create epic
+arc create "Subtask" --parent <epic-id>  # Create child issue
+arc dep add child-id parent-id --type parent-child  # Or link existing issue to epic
+
+# With multi-line description (use --stdin flag):
+arc create "Title" -t task --stdin <<'EOF'
+Description with context, acceptance criteria, etc.
+EOF
+```
+
+### Completing Work
+```bash
+arc close <id> --reason "done"      # Complete issue
+arc ready                           # See what unblocked
+```
+
+**Deep dive**: Run `arc docs workflows` for complete checklists.

package/skills/arc/_formatting.md

@@ -0,0 +1,26 @@
+# Content Formatting Guide
+
+The arc frontend renders GitHub Flavored Markdown with syntax highlighting. Follow these rules when writing issue descriptions, plans, comments, and notes.
+
+## Use
+- **Fenced code blocks** with language tags: ` ```go `, ` ```bash `, ` ```json `, ` ```typescript `, ` ```sql `, ` ```yaml `, ` ```python `, ` ```html `, ` ```css `
+- **Headings** (`##` and `###`) for section structure
+- **Bullet lists** (`-`) for unordered items and file lists
+- **Numbered lists** (`1.`) for sequential steps
+- **Task lists** (`- [ ]` and `- [x]`) for checklists
+- **Tables** (`| col | col |`) for structured comparisons
+- **Inline code** (backticks) for file paths, function names, variable names, and CLI commands
+- **Bold** (`**text**`) for emphasis on key terms
+- **Blockquotes** (`>`) for important callouts or notes
+- **Links** (`[text](url)`) for references
+
+## Avoid
+- Raw HTML tags — DOMPurify strips most tags
+- Code fences without language tags — always specify the language for syntax highlighting
+- UPPERCASE section headers (use `##` Markdown headings instead)
+- Very long single-line paragraphs — use line breaks for readability
+
+## Code Block Languages
+Supported with syntax highlighting: go, typescript, javascript, json, bash, shell, sql, yaml, markdown, html, css, python, text
+
+For unsupported languages, use `text` as the language tag.

package/skills/arc-brainstorm/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: arc-brainstorm
+description: Use when starting Arc-tracked design exploration, feature discovery, architecture decisions, or trade-off analysis before implementation. Prefer this over generic brainstorming when the project uses Arc plans and issue tracking.
+---
+
+# Arc Brainstorm
+
+Turn an idea into an approved design artifact, register it with the Arc planner, and hand it off to `arc-plan`.
+
+<HARD-GATE>
+Do NOT write implementation code, scaffold files beyond the design document, invoke `arc-implement`, or begin execution during brainstorming. This skill ends with either an approved design in the planner and a handoff to `arc-plan`, or a saved design that is deferred for later.
+</HARD-GATE>
+
+## Ordered Checklist
+
+Follow these items in order.
+
+1. **Explore current project context**
+   - Check the relevant files, docs, recent changes, and existing Arc issue or plan context before proposing changes.
+   - Understand what already exists, what constraints are already fixed, and which project patterns should be preserved.
+2. **Run a one-question design loop**
+   - Ask one clarifying question at a time.
+   - Prefer native OpenCode multiple-choice questions when practical.
+   - Use open-ended questions only when bounded options would hide an important unknown.
+   - Do not dump a batch of questions in one message.
+3. **Propose bounded approaches**
+   - Present 2-3 realistic approaches with trade-offs, expected complexity, and a recommendation.
+   - Ask the user to approve the recommendation or choose another approach before continuing.
+4. **Present the design in approved sections**
+   - Build the design in clear sections such as goal, scope boundaries, chosen approach, interfaces or contracts, dependency ordering, testing expectations, and risks.
+   - Present one section at a time when the design is non-trivial.
+   - Ask for approval at each major design checkpoint before moving forward.
+   - If the user requests changes, revise that section and ask again.
+5. **Prepare the approved design artifact**
+   - Once the design is approved in-session, write it to `docs/plans/YYYY-MM-DD-<topic>.md`.
+   - Keep the document concise, decision-oriented, and ready for planner review.
+   - Include the approved goal, in-scope work, out-of-scope work, chosen approach, shared contracts, dependency notes, testing expectations, and major risks.
+6. **Register the design with Arc planner**
+    - Run `arc plan create <path>` using the design file path.
+    - Capture the returned plan ID and planner URL from the command output when available.
+    - If the command output does not print the planner URL directly, derive it in this order: `ARC_SERVER` from the environment, then the Arc server URL from local config.
+    - If no authoritative server URL is available, do not invent one; surface the `plan-id` explicitly and tell the user the planner URL could not be derived automatically.
+    - Surface both the `plan-id` and planner URL explicitly whenever the URL is available so the user can open or resume the review state directly.
+7. **Run the planner review loop with a native OpenCode question**
+   - Ask a native OpenCode question with only these outcomes:
+     - `approve the design`
+     - `feedback submitted in planner`
+     - `save for later`
+   - Do not render a plain-text approval menu.
+   - Include the planner URL directly in the prompt text.
+8. **Handle planner feedback truthfully**
+   - If the user selects `feedback submitted in planner`, run `arc plan comments <plan-id>` and `arc plan show <plan-id>`.
+   - Read the planner feedback, revise the same design file, and repeat the same planner review loop.
+   - Continue until the design is approved or deferred.
+9. **Approve and hand off**
+   - If the user selects `approve the design`, run `arc plan approve <plan-id>`.
+   - Always hand off to `arc-plan` after approval.
+   - Never offer direct `arc-implement` routing from `arc-brainstorm`, even for tiny tasks.
+10. **Defer cleanly when needed**
+   - If the user selects `save for later`, stop after confirming the design file path, `plan-id`, and planner URL.
+   - Do not begin planning or implementation.
+
+## Interaction Rules
+
+- Ask one question at a time.
+- Prefer native OpenCode multiple-choice questions when practical.
+- Present 2-3 approaches before locking the design.
+- Ask for approval at each major design checkpoint.
+- Avoid bulk question dumps.
+- Avoid plain-text approval menus.
+- Do not begin implementation.
+
+## Design Artifact Requirements
+
+The approved design artifact should be ready for `arc-plan` without re-inventing the design.
+
+- Include the approved goal and success criteria.
+- Include scope boundaries and explicit non-goals.
+- Include the chosen approach and why it won.
+- Include shared contracts or interfaces when later tasks depend on them.
+- Include dependency ordering or foundation-first sequencing when needed.
+- Include testing expectations and major risks.
+- Keep the design truthful and bounded to what the user actually approved.
+
+## Planner Review Loop
+
+Follow the review loop already defined in the ordered checklist.
+
+- Surface both the `plan-id` and planner URL as the review state.
+- If the planner URL cannot be derived from command output, `ARC_SERVER`, or local Arc config, say so explicitly instead of fabricating a link.
+- Reuse the same native OpenCode question until the design is approved or deferred.
+- On approval, run `arc plan approve <plan-id>` and route to `arc-plan`.
+
+## Completion Condition
+
+This skill is complete when:
+
+- the design has been explored and approved in sections,
+- the approved design has been written to `docs/plans/`,
+- the design has been registered with `arc plan create`,
+- the `plan-id` and planner URL have been surfaced explicitly,
+- the planner review loop has ended in approval or deferral, and
+- approved work is handed off to `arc-plan`, while deferred work stops cleanly without planning or implementation.

package/skills/arc-debug/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: arc-debug
+description: Use when debugging an arc-tracked task in OpenCode, especially for bugs, failing tests, unexpected behavior, stack traces, or requests to investigate root cause before changing code.
+---
+
+# Arc Debug
+
+Debug by proving what is happening before proposing a fix.
+
+## Core Rule
+
+**No fixes without root cause investigation first.**
+
+If the problem is not reproduced and supported by evidence, do not guess.
+
+## Process
+
+### 1. Reproduce the issue
+
+- Capture the exact failing command, input, or user flow.
+- Re-run it until the failure is reproducible, or record that it is intermittent.
+- If it does not reproduce yet, keep gathering data instead of proposing changes.
+
+### 2. Gather evidence
+
+- Read the full error output, stack trace, logs, and test failure text.
+- Check recent relevant changes and the specific code path involved.
+- In multi-step flows, trace the data or state across each boundary until it stops matching expectations.
+- Write down the observed facts separately from assumptions.
+
+### 3. Identify root cause
+
+- Form one concrete hypothesis that explains the evidence.
+- Test that hypothesis with the smallest possible confirming check.
+- If the check fails, discard the hypothesis and continue investigating.
+- Do not recommend a fix until the root cause is identified in substance.
+
+### 4. Ask focused follow-up questions only when needed
+
+- Ask one focused question only if a missing fact blocks reproduction or root-cause analysis.
+- Prefer questions that unlock a specific check, such as environment, inputs, or expected behavior.
+- Do not ask broad exploratory questions when the answer can be gathered from the repo or command output.
+
+### 5. Then fix and verify
+
+- Change the smallest thing that addresses the root cause.
+- Re-run the reproduction step and any relevant tests.
+- If the fix does not hold up under verification, return to investigation.
+
+## Red Flags
+
+- Proposing code changes before reproducing the issue
+- Treating symptoms as the root cause
+- Bundling multiple speculative fixes together
+- Saying something "should work" without evidence
+- Asking unfocused questions instead of collecting the next missing fact
+
+## Arc Notes
+
+- Keep arc issue state truthful while investigating.
+- If debugging reveals separate follow-up work, capture it in arc instead of hiding it inside the current task.
+- Format any arc notes per `skills/arc/_formatting.md`.

package/skills/arc-finish/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: arc-finish
+description: Use when wrapping up arc-tracked work in OpenCode, especially at session end or when deciding whether to close, defer, commit, push, or hand off work while keeping issue and branch state accurate.
+---
+
+# Arc Finish
+
+Close out work by checking what remains, making one decision at a time, and leaving arc and git in a truthful state.
+
+## Core Rule
+
+**Do not perform close-out actions by habit. Verify the current state first, then ask for the next decision when needed.**
+
+## Close-Out Protocol
+
+### 1. Verify remaining work
+
+- Review the task goal, current implementation state, and latest verification evidence.
+- Confirm what is done, what is still open, and what follow-up work should be captured separately.
+- If completion is not yet proven, do not present the work as ready to close.
+
+### 2. Keep arc state truthful
+
+- Close the issue only when the task is actually complete.
+- Leave it open or move it to the truthful status when work remains.
+- Record concise factual notes about what changed, what is verified, and what is still pending.
+
+### 3. Keep branch state truthful
+
+- Distinguish between uncommitted changes, local commits, and pushed commits.
+- Do not imply work is landed if it only exists in the working tree or on the local branch.
+- If the branch still needs a user decision, say so plainly.
+
+### 4. Ask one native question at a time for close-out decisions
+
+- Ask one question when a real decision is needed, such as whether to close now, create follow-up issues, commit, push, or hand off.
+- Keep it native to the current state of the work, not a canned checklist.
+- Do not bundle several decisions into one question.
+
+### 5. Execute only the chosen next step
+
+- After the user answers, perform that step and then reassess.
+- If another decision remains, ask the next one question after updating the state.
+
+## Red Flags
+
+- Blind always-push behavior
+- Closing issues without verified completion
+- Saying a branch is clean or landed when it is only local
+- Asking multiple close-out decisions at once
+- Summarizing remaining work without checking it first
+
+## Arc Notes
+
+- This skill is a truthful close-out decision protocol, not an unconditional push script.
+- Use `arc-verify` before any final completion claim.
+- Format any arc notes per `skills/arc/_formatting.md`.