write-intent
Announce intent before writing files — one sentence stating what, where, and why, with an idempotence check that skips the Write entirely when state is already correct.
$ npx -y skills add nyldn/claude-octopus --agent claude-codeHow it fires
How this agent gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
Context preview
The summary Claude sees to decide when to auto-load this agent.
Announce intent before writing files — one sentence stating what, where, and why, with an idempotence check that skips the Write entirely when state is already correct.
Agent definition
write-intent.mdname: write-intent-principle
domain: general
description: Announce intent before writing files — one sentence stating what, where, and why, with an idempotence check that skips the Write entirely when state is already correct.
Write-Intent Principle
Before creating, overwriting, or rewriting any file as part of a command, skill, or agent workflow, you MUST:
1. Check for idempotence first
If the desired state already matches the current state, **do not call Write at all.** Confirm the state to the user and exit. The most common bug this prevents is writing config for a mode / setting / flag the user is already in — that's noise, not value.
Examples of state to check before writing:
- Target mode matches current mode → skip
- Target frontmatter field matches current field → skip
- Generated file is byte-identical to what you'd write → skip
2. Announce intent in one sentence
When a Write **is** needed, say what you're about to do **before** calling the tool. Format:
> Writing `<path>` (create | update | overwrite) — `<field/change>` — because `<why>`.
Example:
> Updating `.claude/claude-octopus.local.md` — setting `knowledge_mode: false` (was `true`) — because the user requested `/octo:dev`.
3. Never write "empty" config
Do not create a config file populated with defaults just to "mark" a state. Absent config is a legitimate state — it means "use defaults". Creating a file to restate defaults adds noise, makes diffs confusing, and implies the user opted into something they didn't.
4. Respect scope
Before writing to `.claude/`, `~/.claude-octopus/`, `~/.claude/`, or any user-owned directory from a command/skill, consider whether the file should live in:
- The plugin (committed, shipped to all users)
- The user's home (`~/.claude/`) — persists across projects
- The project workspace (`.claude/`) — per-project
- `~/.claude/scratchpad/<session-id>/` — ephemeral working files
A user-facing command that writes to an unexpected scope (e.g. a "mode switch" that writes to project `.claude/`) needs to say *which* scope in its intent sentence.
Anti-Patterns (reject in review)
- ❌ `/octo:dev` writes `.claude/claude-octopus.local.md` when the file didn't exist and the user was already in default Dev Work Mode.
- ❌ A "setup" wizard silently creates configuration for every possible option even when not selected.
- ❌ An idempotent-looking operation overwrites a file with identical content, bumping its mtime and confusing build systems.
- ❌ A skill announces "I'll update your config" and then writes without showing the diff or field being changed.
Correct Patterns
- ✅ Check current state → already matches target → confirm to user → exit without Write.
- ✅ "Switching Knowledge Work → Dev Work — updating `.claude/claude-octopus.local.md` (`knowledge_mode: true` → `false`)." followed by the Write.
- ✅ "No `.claude/claude-octopus.local.md` exists — you're in default Dev Work Mode. Nothing to change." followed by no Write.
Scope
This principle applies to **all** Write operations initiated by skills, commands, and agents in this plugin. Tests in `tests/unit/test-write-intent.sh` enforce that user-facing mode-switch commands carry the idempotence check in their implementation instructions.
Read more
name: write-intent-principle domain: general description: Announce intent before writing files — one sentence stating what, where, and why, with an idempotence check that skips the Write entirely when state is already correct.
Write-Intent Principle
Before creating, overwriting, or rewriting any file as part of a command, skill, or agent workflow, you MUST:
1. Check for idempotence first
If the desired state already matches the current state, **do not call Write at all.** Confirm the state to the user and exit. The most common bug this prevents is writing config for a mode / setting / flag the user is already in — that's noise, not value.
Examples of state to check before writing:
- Target mode matches current mode → skip
- Target frontmatter field matches current field → skip
- Generated file is byte-identical to what you'd write → skip
2. Announce intent in one sentence
When a Write **is** needed, say what you're about to do **before** calling the tool. Format:
> Writing `<path>` (create | update | overwrite) — `<field/change>` — because `<why>`.
Example:
> Updating `.claude/claude-octopus.local.md` — setting `knowledge_mode: false` (was `true`) — because the user requested `/octo:dev`.
3. Never write "empty" config
Do not create a config file populated with defaults just to "mark" a state. Absent config is a legitimate state — it means "use defaults". Creating a file to restate defaults adds noise, makes diffs confusing, and implies the user opted into something they didn't.
4. Respect scope
Before writing to `.claude/`, `~/.claude-octopus/`, `~/.claude/`, or any user-owned directory from a command/skill, consider whether the file should live in:
- The plugin (committed, shipped to all users)
- The user's home (`~/.claude/`) — persists across projects
- The project workspace (`.claude/`) — per-project
- `~/.claude/scratchpad/<session-id>/` — ephemeral working files
A user-facing command that writes to an unexpected scope (e.g. a "mode switch" that writes to project `.claude/`) needs to say *which* scope in its intent sentence.
Anti-Patterns (reject in review)
- ❌ `/octo:dev` writes `.claude/claude-octopus.local.md` when the file didn't exist and the user was already in default Dev Work Mode.
- ❌ A "setup" wizard silently creates configuration for every possible option even when not selected.
- ❌ An idempotent-looking operation overwrites a file with identical content, bumping its mtime and confusing build systems.
- ❌ A skill announces "I'll update your config" and then writes without showing the diff or field being changed.
Correct Patterns
- ✅ Check current state → already matches target → confirm to user → exit without Write.
- ✅ "Switching Knowledge Work → Dev Work — updating `.claude/claude-octopus.local.md` (`knowledge_mode: true` → `false`)." followed by the Write.
- ✅ "No `.claude/claude-octopus.local.md` exists — you're in default Dev Work Mode. Nothing to change." followed by no Write.
Scope
This principle applies to **all** Write operations initiated by skills, commands, and agents in this plugin. Tests in `tests/unit/test-write-intent.sh` enforce that user-facing mode-switch commands carry the idempotence check in their implementation instructions.
Every AI model has blind spots. Claude Octopus supports ten external provider integrations — Codex, Gemini, Antigravity CLI, Copilot, Qwen, Ollama, Perplexity, OpenRouter, OpenCode, and Grok — alongside the built-in Claude Code host, with consensus gates that
Repo: nyldn/claude-octopus
Other agents on octo.
- backend-architect
Expert backend architect for scalable API design, microservices, and distributed systems. Masters REST/GraphQL/gRPC, event-driven patterns, service mesh, and resilience. Use PROACTIVELY for new backend services or APIs.
Open agent - cloud-architect
Expert cloud architect for AWS/Azure/GCP multi-cloud design, IaC (Terraform/CDK), FinOps, serverless, security, and compliance. Use PROACTIVELY for cloud architecture, cost optimization, or migration planning.
Open agent - code-reviewer
Elite code reviewer for AI-powered analysis, security vulnerabilities, performance, and production reliability. Masters static analysis, security scanning, and 2025/2026 best practices. Use PROACTIVELY for code quality.
Open agent - database-architect
Expert database architect for data layer design, technology selection, schema modeling, and scalable architectures. Masters SQL/NoSQL/TimeSeries, normalization, migration planning. Use PROACTIVELY for database architecture or data modeling.
Open agent - debugger
Debugging specialist for errors, test failures, and unexpected behavior. Use proactively when encountering any issues.
Open agent - docs-architect
Creates comprehensive technical documentation from existing codebases. Analyzes architecture, design patterns, and implementation details to produce long-form technical manuals and ebooks. Use PROACTIVELY for system documentation, architecture guides, or technical deep-dives.
Open agent

