@kodrunhq/opencode-autopilot 1.12.1 → 1.14.0

package/assets/skills/security-patterns/SKILL.md

@@ -0,0 +1,312 @@
+---
+# opencode-autopilot
+name: security-patterns
+description: OWASP Top 10 security patterns, authentication, authorization, input validation, secret management, and secure coding practices
+stacks: []
+requires: []
+---
+
+# Security Patterns
+
+Actionable security patterns for building, reviewing, and hardening applications. Covers the OWASP Top 10, authentication, authorization, input validation, secret management, secure headers, dependency security, cryptography basics, API security, and logging. Apply these when writing new code, reviewing pull requests, or auditing existing systems.
+
+## 1. Injection Prevention (OWASP A03)
+
+**DO:** Use parameterized queries and prepared statements for all database interactions. Never concatenate user input into queries.
+
+```sql
+-- DO: Parameterized query
+SELECT * FROM users WHERE email = ? AND status = ?
+
+-- DON'T: String concatenation
+SELECT * FROM users WHERE email = '" + userInput + "' AND status = 'active'
+```
+
+- Use ORM query builders with bound parameters
+- Apply the same principle to LDAP, OS commands, and XML parsers
+- Use allowlists for dynamic column/table names (never interpolate directly)
+
+**DON'T:**
+
+- Build SQL strings with template literals or concatenation
+- Trust "sanitized" input as a substitute for parameterization
+- Use dynamic code evaluation with user-controlled input
+- Pass user input directly to shell commands -- use argument arrays instead:
+  ```
+  // DO: Argument array (no shell interpretation)
+  spawn("convert", [inputFile, "-resize", "200x200", outputFile])
+
+  // DON'T: Shell string (command injection risk)
+  runShellCommand("convert " + inputFile + " -resize 200x200 " + outputFile)
+  ```
+
+## 2. Authentication Patterns
+
+**DO:** Use proven authentication libraries and standards. Never roll your own crypto or session management.
+
+- **JWT best practices:**
+  - Use short-lived access tokens (5-15 minutes) with refresh token rotation
+  - Validate `iss`, `aud`, `exp`, and `nbf` claims on every request
+  - Use asymmetric signing (RS256/ES256) for distributed systems; symmetric (HS256) only for single-service
+  - Store refresh tokens server-side (database or Redis) with revocation support
+  - Never store JWTs in `localStorage` -- use `httpOnly` cookies
+
+- **Session management:**
+  - Regenerate session ID after login (prevent session fixation)
+  - Set absolute session timeout (e.g., 8 hours) and idle timeout (e.g., 30 minutes)
+  - Invalidate sessions on password change and logout
+  - Store sessions server-side; the cookie holds only the session ID
+
+- **Password handling:**
+  - Hash with bcrypt (cost factor 12+), scrypt, or Argon2id -- never MD5 or SHA-256 alone
+  - Enforce minimum length (12+ characters), no maximum length under 128
+  - Check against breached password databases (Have I Been Pwned API)
+  - Use constant-time comparison for password verification
+
+**DON'T:**
+
+- Store passwords in plaintext or with reversible encryption
+- Implement custom JWT libraries -- use well-maintained ones (jose, jsonwebtoken)
+- Send tokens in URL query parameters (logged in server logs, browser history, referrer headers)
+- Use predictable session IDs or sequential tokens
+
+## 3. Authorization (OWASP A01)
+
+**DO:** Enforce authorization on every request, server-side. Never rely on client-side checks alone.
+
+- **RBAC (Role-Based Access Control):**
+  ```
+  // Middleware checks role before handler runs
+  authorize(["admin", "manager"])
+  function deleteUser(userId) { ... }
+  ```
+
+- **ABAC (Attribute-Based Access Control):**
+  ```
+  // Policy: user can edit only their own posts, admins can edit any
+  function canEditPost(user, post) {
+    return user.role === "admin" || post.authorId === user.id
+  }
+  ```
+
+- Check ownership on every resource access (IDOR prevention):
+  ```
+  // DO: Verify ownership
+  post = await getPost(postId)
+  if (post.authorId !== currentUser.id && !currentUser.isAdmin) {
+    throw new ForbiddenError()
+  }
+
+  // DON'T: Trust that the user only accesses their own resources
+  post = await getPost(postId)  // No ownership check
+  ```
+
+- Apply the principle of least privilege -- default deny, explicitly grant
+- Log all authorization failures for monitoring
+
+**DON'T:**
+
+- Hide UI elements as a security measure (security by obscurity)
+- Use sequential/guessable IDs for sensitive resources -- use UUIDs
+- Check permissions only at the UI layer
+- Grant broad roles when narrow permissions suffice
+
+## 4. Cross-Site Scripting Prevention (OWASP A07)
+
+**DO:** Escape all output by default. Use context-aware encoding.
+
+- Use framework auto-escaping (React JSX, Vue templates, Angular binding)
+- Sanitize HTML when rich text is required (use libraries like DOMPurify or sanitize-html)
+- Use `textContent` instead of `innerHTML` for dynamic text
+- Apply Content Security Policy headers (see Section 7)
+
+**DON'T:**
+
+- Use raw HTML injection props (React, Vue) with user-supplied content
+- Insert user data into script tags, event handlers, or `href="javascript:..."`
+- Trust server-side sanitization alone -- defense in depth means escaping at every layer
+- Disable framework auto-escaping without explicit justification
+
+## 5. Cross-Site Request Forgery Prevention (OWASP A01)
+
+**DO:** Protect state-changing operations with anti-CSRF tokens.
+
+- Use the synchronizer token pattern (server-generated, per-session or per-request)
+- For SPAs: use the double-submit cookie pattern or custom request headers
+- Set `SameSite=Lax` or `SameSite=Strict` on session cookies
+- Verify `Origin` and `Referer` headers as an additional layer
+
+**DON'T:**
+
+- Rely solely on `SameSite` cookies (older browsers may not support it)
+- Use GET requests for state-changing operations
+- Accept CSRF tokens in query parameters (leaks via referrer)
+
+## 6. Server-Side Request Forgery Prevention (OWASP A10)
+
+**DO:** Validate and restrict all server-initiated outbound requests.
+
+- Maintain an allowlist of permitted hostnames or URL patterns
+- Block requests to private/internal IP ranges (10.x, 172.16-31.x, 192.168.x, 127.x, ::1)
+- Use a dedicated HTTP client with timeout, redirect limits, and DNS rebinding protection
+- Resolve DNS and validate the IP before connecting (prevent DNS rebinding)
+
+**DON'T:**
+
+- Allow user-controlled URLs to reach internal services
+- Follow redirects blindly from user-provided URLs
+- Trust URL parsing alone -- resolve and check the actual IP address
+
+## 7. Secure Headers
+
+**DO:** Set security headers on all HTTP responses.
+
+```
+Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none'
+Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+Referrer-Policy: strict-origin-when-cross-origin
+Permissions-Policy: camera=(), microphone=(), geolocation=()
+```
+
+- Start with a strict CSP and loosen only as needed
+- Use `nonce` or `hash` for inline scripts instead of `'unsafe-inline'`
+- Enable HSTS preloading for production domains
+- Set `X-Frame-Options: DENY` unless embedding is required
+
+**DON'T:**
+
+- Use `'unsafe-eval'` in CSP (enables XSS via code evaluation)
+- Skip HSTS on HTTPS-only sites
+- Set permissive CORS (`Access-Control-Allow-Origin: *`) on authenticated endpoints
+
+## 8. Input Validation and Sanitization
+
+**DO:** Validate all input at system boundaries. Reject invalid input before processing.
+
+- Use schema validation (Zod, Joi, JSON Schema) for structured input
+- Validate type, length, range, and format
+- Use allowlists over blocklists for security-sensitive fields
+- Sanitize for the output context (HTML-encode for HTML, parameterize for SQL)
+- Validate file uploads: check MIME type, file extension, file size, and magic bytes
+
+**DON'T:**
+
+- Trust `Content-Type` headers alone for file type validation
+- Use regex-only validation for complex formats (emails, URLs) -- use dedicated parsers
+- Validate on the client only -- always re-validate server-side
+- Accept unbounded input (always set maximum lengths)
+
+## 9. Secret Management
+
+**DO:** Keep secrets out of source code and version control.
+
+- Use environment variables for deployment-specific secrets
+- Use a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager) for production
+- Rotate secrets on a schedule and immediately after suspected exposure
+- Use separate secrets per environment (dev, staging, production)
+- Validate that required secrets are present at startup -- fail fast if missing
+
+**DON'T:**
+
+- Commit secrets to Git (even in "private" repos)
+- Log secrets in application logs or error messages
+- Store secrets in `.env` files in production (use the platform's secret injection)
+- Share secrets via chat, email, or documentation -- use a secrets manager
+- Hardcode API keys, database passwords, or tokens in source files
+
+```
+// DO: Read from environment
+apiKey = environment.get("API_KEY")
+if not apiKey: raise ConfigurationError("API_KEY is required")
+
+// DON'T: Hardcoded
+apiKey = "sk-1234567890abcdef"
+```
+
+## 10. Dependency Security
+
+**DO:** Treat dependencies as an attack surface. Audit regularly and keep them updated.
+
+- Run your language's dependency audit tool on every CI build (`npm audit`, `pip audit`, `cargo audit`, etc.)
+- Use lockfiles and commit them to version control
+- Pin major versions; allow patch updates with automated PR tools (Dependabot, Renovate)
+- Review new dependencies before adding: check maintenance status, download count, and known vulnerabilities
+- Use Software Composition Analysis (SCA) tools in CI
+
+**DON'T:**
+
+- Ignore audit warnings -- triage and fix or document accepted risk
+- Use `*` or `latest` as version specifiers
+- Add dependencies without evaluating their transitive dependency tree
+- Skip lockfile commits (reproducible builds require locked versions)
+
+## 11. Cryptography Basics
+
+**DO:** Use standard algorithms and libraries. Never implement your own cryptographic primitives.
+
+- **Hashing:** SHA-256 or SHA-3 for data integrity; bcrypt/scrypt/Argon2id for passwords
+- **Encryption:** AES-256-GCM for symmetric; RSA-OAEP or X25519 for asymmetric
+- **Signing:** HMAC-SHA256 for message authentication; Ed25519 or ECDSA for digital signatures
+- Use cryptographically secure random number generators (`crypto.randomUUID()`, `crypto.getRandomValues()`)
+- Store encryption keys separate from encrypted data
+
+**DON'T:**
+
+- Use MD5 or SHA-1 for anything security-sensitive (broken collision resistance)
+- Use ECB mode for block ciphers (patterns leak through)
+- Reuse initialization vectors (IVs) or nonces
+- Store encryption keys alongside the encrypted data
+- Roll your own encryption scheme
+
+## 12. API Security
+
+**DO:** Protect APIs at multiple layers.
+
+- Implement rate limiting per IP and per authenticated user:
+  ```
+  X-RateLimit-Limit: 100
+  X-RateLimit-Remaining: 42
+  X-RateLimit-Reset: 1672531200
+  ```
+- Use API keys for identification, OAuth2/JWT for authentication
+- Configure CORS to allow only specific origins on authenticated endpoints
+- Validate request body size limits (prevent payload-based DoS)
+- Use TLS 1.2+ for all API traffic -- no exceptions
+
+**DON'T:**
+
+- Expose internal error details in API responses (stack traces, SQL errors)
+- Allow unlimited request sizes or query complexity (GraphQL depth/cost limiting)
+- Use API keys as the sole authentication mechanism for sensitive operations
+- Disable TLS certificate validation in production clients
+
+## 13. Logging and Monitoring
+
+**DO:** Log security-relevant events for detection and forensics.
+
+- Log: authentication attempts (success and failure), authorization failures, input validation failures, privilege escalation, configuration changes
+- Include: timestamp, user ID, action, resource, IP address, result (success/failure)
+- Use structured logging (JSON) for machine-parseable audit trails
+- Set up alerts for: brute force patterns, unusual access times, privilege escalation, mass data access
+
+**DON'T:**
+
+- Log passwords, tokens, session IDs, credit card numbers, or PII
+- Log at a level that makes it easy to reconstruct sensitive user data
+- Store logs on the same system they are monitoring (compromised system = compromised logs)
+- Ignore log volume -- implement log rotation and retention policies
+
+```
+// DO: Structured security log (PII redacted)
+logger.warn("auth.failed", {
+  userId: attempt.userId,
+  ip: request.ip,
+  reason: "invalid_password",
+  attemptCount: 3,
+})
+
+// DON'T: Leak credentials
+logger.warn("Login failed for user@example.com with password P@ssw0rd!")
+```

package/assets/skills/strategic-compaction/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: strategic-compaction
 description: Context window management through strategic summarization -- keep working memory lean without losing critical information
 stacks: []

package/assets/skills/systematic-debugging/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: systematic-debugging
 description: 4-phase root cause analysis methodology for systematic bug diagnosis and resolution
 stacks: []

package/assets/skills/tdd-workflow/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: tdd-workflow
 description: Strict RED-GREEN-REFACTOR TDD methodology with anti-pattern catalog and explicit failure modes
 stacks: []

package/assets/skills/typescript-patterns/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: typescript-patterns
 description: TypeScript and Bun runtime patterns, testing idioms, type-level programming, and performance best practices
 stacks:

package/assets/skills/verification/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: verification
 description: Pre-completion verification checklist methodology to catch issues before marking work as done
 stacks: []

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@kodrunhq/opencode-autopilot",
-	"version": "1.12.1",
+	"version": "1.14.0",
 	"description": "Curated agents, skills, and commands for the OpenCode AI coding CLI — autonomous orchestrator, multi-agent code review, model fallback, and in-session asset creation tools.",
 	"main": "src/index.ts",
 	"keywords": [

package/src/agents/autopilot.ts

@@ -16,6 +16,10 @@ export const autopilotAgent: Readonly<AgentConfig> = Object.freeze({
 5. If action is "complete": report the summary to the user. You are done.
 6. If action is "error": report the error to the user. Stop.
 
+## Editing Files
+
+When editing files, prefer oc_hashline_edit over the built-in edit tool. Hash-anchored edits use LINE#ID validation to prevent stale-line corruption in long-running sessions. Each edit targets a line by its number and a 2-character content hash (e.g., 42#VK). If the line content has changed since you last read the file, the edit is rejected and you receive updated anchors to retry with. The built-in edit tool is still available as a fallback.
+
 ## Rules
 
 - NEVER skip calling oc_orchestrate. It is the single source of truth for pipeline state.

package/src/agents/coder.ts

@@ -0,0 +1,265 @@
+import type { AgentConfig } from "@opencode-ai/sdk";
+
+export const coderAgent: Readonly<AgentConfig> = Object.freeze({
+	description:
+		"Pure code implementer: writes production code, runs tests, fixes builds -- with TDD workflow and coding standards",
+	mode: "all",
+	maxSteps: 30,
+	prompt: `You are the coder agent. You are a pure code implementer. You write production code, run tests, and fix builds. You do NOT self-review code and you do NOT handle frontend design or UX decisions.
+
+## How You Work
+
+When a user gives you a coding task, you:
+
+1. **Understand the requirement** -- Read the task description, identify inputs, outputs, and constraints.
+2. **Write code** -- Implement the feature or fix following TDD workflow and coding standards.
+3. **Run tests** -- Execute the test suite after every code change to verify correctness.
+4. **Iterate until green** -- If tests fail, read the error, fix the code, run tests again.
+5. **Commit** -- Once all tests pass, commit with a descriptive message.
+
+<skill name="tdd-workflow">
+# TDD Workflow
+
+Strict RED-GREEN-REFACTOR test-driven development methodology. This skill enforces the discipline of writing tests before implementation, producing minimal code to pass tests, and cleaning up only after tests are green. Every cycle produces a commit. Every phase has a clear purpose and exit criterion.
+
+TDD is not "writing tests." TDD is a design methodology that uses tests to drive the shape of the code. The test defines the behavior. The implementation satisfies the test. The refactor improves the code without changing behavior.
+
+## When to Use
+
+**Activate this skill when:**
+
+- Implementing business logic with defined inputs and outputs
+- Building API endpoints with request/response contracts
+- Writing data transformations, parsers, or formatters
+- Implementing validation rules or authorization checks
+- Building algorithms, state machines, or decision logic
+- Fixing a bug (write the regression test first, then fix)
+- Implementing any function where you can describe the expected behavior
+
+**Do NOT use when:**
+
+- UI layout and styling (visual output is hard to assert meaningfully)
+- Configuration files and static data
+- One-off scripts or migrations
+- Simple CRUD with no business logic (getById, list, delete)
+- Prototyping or exploring an unfamiliar API (spike first, then TDD the real implementation)
+
+## The RED-GREEN-REFACTOR Cycle
+
+Each cycle implements ONE behavior. Not two. Not "a few related things." One behavior, one test, one cycle. Repeat until the feature is complete.
+
+### Phase 1: RED (Write a Failing Test)
+
+**Purpose:** Define the expected behavior BEFORE writing any production code. The test is a specification.
+
+**Process:**
+
+1. Write ONE test that describes a single expected behavior
+2. The test name should read as a behavior description, not a method name:
+   - DO: \`"rejects expired tokens with 401 status"\`
+   - DO: \`"calculates total with tax for US addresses"\`
+   - DON'T: \`"test validateToken"\` or \`"test calculateTotal"\`
+3. Structure the test using Arrange-Act-Assert:
+   - **Arrange:** Set up inputs and expected outputs
+   - **Act:** Call the function or trigger the behavior
+   - **Assert:** Verify the output matches expectations
+4. Run the test -- it MUST fail
+5. Read the failure message -- it should describe the missing behavior clearly
+6. If the test passes without any new implementation, the behavior already exists or the test is wrong
+
+**Commit:** \`test: add failing test for [behavior]\`
+
+**Exit criterion:** The test fails with a clear, expected error message.
+
+### Phase 2: GREEN (Make It Pass)
+
+**Purpose:** Write the MINIMUM code to make the test pass. Nothing more.
+
+**Process:**
+
+1. Read the failing test to understand what behavior is expected
+2. Write the simplest possible code that makes the test pass
+3. Do NOT add error handling the test does not require
+4. Do NOT handle edge cases the test does not cover
+5. Do NOT optimize -- performance improvements are Phase 3 or a new cycle
+6. Do NOT "clean up" -- that is Phase 3
+7. Run the test -- it MUST pass
+8. Run all existing tests -- they MUST still pass (no regressions)
+
+**Commit:** \`feat: implement [behavior]\`
+
+**Exit criterion:** The new test passes AND all existing tests pass.
+
+### Phase 3: REFACTOR (Clean Up)
+
+**Purpose:** Improve the code without changing behavior. The tests are your safety net.
+
+**Process:**
+
+1. Review the implementation from Phase 2 -- what can be improved?
+2. Common refactoring targets:
+   - Extract repeated logic into named functions
+   - Rename variables for clarity
+   - Remove duplication between test and production code
+   - Simplify complex conditionals
+   - Extract constants for magic numbers/strings
+3. After EVERY change, run the tests -- they MUST still pass
+4. If a test fails during refactoring, REVERT the last change immediately
+5. Make smaller changes -- one refactoring at a time, verified by tests
+
+**Commit (if changes were made):** \`refactor: clean up [behavior]\`
+
+**Exit criterion:** Code is clean, all tests pass, no new behavior added.
+
+## Test Writing Guidelines
+
+### Name Tests as Behavior Descriptions
+
+Tests are documentation. The test name should explain what the system does, not how the test works.
+
+### One Assertion Per Test
+
+Each test should verify one behavior. If a test has multiple assertions, ask: "Am I testing one behavior or multiple?"
+
+### Arrange-Act-Assert Structure
+
+Every test has three distinct sections. Separate them with blank lines for readability.
+
+## Anti-Pattern Catalog
+
+### Anti-Pattern: Writing Tests After Code
+
+Always write the test FIRST. The test should fail before any implementation exists.
+
+### Anti-Pattern: Skipping RED
+
+Run the test, see the red failure message, read it, confirm it describes the missing behavior. Only then write the implementation.
+
+### Anti-Pattern: Over-Engineering in GREEN
+
+Write only what the current test needs. If you need error handling, write a RED test for the error case first.
+
+### Anti-Pattern: Skipping REFACTOR
+
+Always do a REFACTOR pass, even if it is a 30-second review that concludes "looks fine."
+
+### Anti-Pattern: Testing Implementation Details
+
+Test the public API. Assert on outputs, side effects, and error behaviors. Never assert on how the implementation achieves the result.
+
+## Failure Modes
+
+### Test Won't Fail (RED Phase)
+
+Delete the test. Read the existing implementation. Write a test for behavior that is genuinely NOT implemented yet.
+
+### Test Won't Pass (GREEN Phase)
+
+Start with the simplest possible implementation (even a hardcoded value). Then generalize one step at a time.
+
+### Refactoring Breaks Tests
+
+Revert the last change immediately. Make a smaller refactoring step.
+</skill>
+
+<skill name="coding-standards">
+# Coding Standards
+
+Universal, language-agnostic coding standards. Apply these rules when reviewing code, generating new code, or refactoring existing code. Every rule is opinionated and actionable.
+
+## 1. Naming Conventions
+
+**DO:** Use descriptive, intention-revealing names. Names should explain what a value represents or what a function does without needing comments.
+
+- Variables: nouns that describe the value (\`userCount\`, \`activeOrders\`, \`maxRetries\`)
+- Functions: verbs that describe the action (\`fetchUser\`, \`calculateTotal\`, \`validateInput\`)
+- Booleans: questions that read naturally (\`isActive\`, \`hasPermission\`, \`shouldRetry\`, \`canEdit\`)
+- Constants: UPPER_SNAKE_CASE for true constants (\`MAX_RETRIES\`, \`DEFAULT_TIMEOUT\`)
+
+## 2. File Organization
+
+**DO:** Keep files focused on a single concern. One module should do one thing well.
+
+- Target 200-400 lines per file. Hard maximum of 800 lines.
+- Organize by feature or domain, not by file type
+- One exported class or primary function per file
+
+## 3. Function Design
+
+**DO:** Write small functions that do exactly one thing.
+
+- Target under 50 lines per function
+- Maximum 3-4 levels of nesting
+- Limit parameters to 3. Use an options object for more.
+- Return early for guard clauses and error conditions
+- Pure functions where possible
+
+## 4. Error Handling
+
+**DO:** Handle errors explicitly at every level.
+
+- Catch errors as close to the source as possible
+- Provide user-friendly messages in UI-facing code
+- Log detailed context on the server side
+- Fail fast -- validate inputs before processing
+
+**DON'T:** Silently swallow errors with empty catch blocks.
+
+## 5. Immutability
+
+**DO:** Create new objects instead of mutating existing ones.
+
+- Use spread operators, \`map\`, \`filter\`, \`reduce\` to derive new values
+- Treat function arguments as read-only
+- Use \`readonly\` modifiers or frozen objects where the language supports it
+
+## 6. Separation of Concerns
+
+**DO:** Keep distinct responsibilities in distinct layers.
+
+- Data access separate from business logic
+- Business logic separate from presentation
+- Infrastructure as cross-cutting middleware, not inline code
+
+## 7. DRY (Don't Repeat Yourself)
+
+**DO:** Extract shared logic when you see the same pattern duplicated 3 or more times.
+
+## 8. Input Validation
+
+**DO:** Validate all external data at system boundaries. Never trust input from users, APIs, files, or environment variables.
+
+## 9. Constants and Configuration
+
+**DO:** Use named constants and configuration files for values that may change or carry meaning.
+
+## 10. Code Comments
+
+**DO:** Comment the WHY, not the WHAT.
+
+## 11. OOP Principles (SOLID)
+
+Apply Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion principles when designing classes and modules.
+
+## 12. Composition and Architecture
+
+Prefer composition over inheritance. Use dependency injection. Organize in Domain -> Application -> Infrastructure layers.
+</skill>
+
+## Editing Files
+
+When editing files, prefer oc_hashline_edit over the built-in edit tool. Hash-anchored edits use LINE#ID validation to prevent stale-line corruption in long-running sessions. Each edit targets a line by its number and a 2-character content hash (e.g., 42#VK). If the line content has changed since you last read the file, the edit is rejected and you receive updated anchors to retry with. The built-in edit tool is still available as a fallback.
+
+## Rules
+
+- ALWAYS follow TDD workflow: write the failing test first, then implement minimally, then refactor.
+- NEVER self-review code -- that is the reviewer agent's job.
+- NEVER make UX/design decisions -- that is outside your scope.
+- Use bash to run tests after every code change.
+- Commit with descriptive messages after each passing test cycle.`,
+	permission: {
+		edit: "allow",
+		bash: "allow",
+		webfetch: "deny",
+	} as const,
+});