ankhorage-coding-rules

Implements, tests, and delivers Ankhorage repository changes through pull requests.

3|Updated Apr 18, 2026
One-click install
npx skills add https://github.com/ankhorage/zora --skill ankhorage-coding-rules-ankhorage
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ankhorage-coding-rules
Source: https://github.com/ankhorage/zora/tree/main/.agents/skills/ankhorage-coding-rules
Command: npx skills add https://github.com/ankhorage/zora --skill ankhorage-coding-rules-ankhorage

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes in Ankhorage repositories must follow strict canonical policies covering lint compliance, functional programming style, Paradox documentation, behavior-focused testing, and release-quality delivery, and this Skill ensures every task branch and pull request satisfies those rules. ## Core Features & Use Cases - Git and Delivery Workflow: Creates task branches from origin/main, preserves unrelated user work, and delivers changes through well-described pull requests. - Canonical Lint and Documentation Compliance: Enforces the canonical ESLint configuration, functional programming defaults, and Paradox /*** ... */ documentation with supported tags like @usage and @example. - Behavior-Focused Testing and Release Quality: Tests observable behavior at owning boundaries, avoids hardcoded versions, manages changesets, and runs build, lint, typecheck, and packaging checks before handoff. - Use Case: When asked to add a feature to an Ankhorage package, the Skill branches from main, implements the change with Paradox-documented functions, adds tests and a changeset, validates all checks, and opens a release-ready pull request. ## Quick Start Use the ankhorage-coding-rules skill to implement this issue on a fresh task branch and deliver it as a pull request.

Frequently Asked Questions about ankhorage-coding-rules

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement a code change in an Ankhorage repository?▼

Fetch the latest origin/main, create a fresh task branch, and implement the change following the canonical ESLint configuration and functional programming defaults. Deliver the work through a pull request describing the change, validation, and public API impact.

How to document functions with Paradox comments?▼

Give every named production function under src a concise Paradox /*** ... */ comment, using only supported tags: @readme, @config, @example, and @usage. Do not use JSDoc-only tags like @param or @returns as Paradox metadata.

Can I add eslint.local.config.mjs exceptions for new code?▼

No, new and materially changed code must satisfy the canonical ESLint configuration without local exceptions. Existing exceptions are removable migration debt, and suppression comments or unsafe casts to bypass validation are prohibited.

Should tests hardcode package dependency versions?▼

No, tests must not hardcode Renovate-managed literal versions. Assert the required semver range shape or a shared policy value instead, and assert an exact version only when the pin itself is the contract under test.

When should I regenerate the README or Paradox documentation?▼

Ordinary feature pull requests must not regenerate or commit README.md or Paradox output; the managed release workflow runs bun run docs after the version bump. Run docs locally only when the task explicitly changes or validates Paradox generation.

What should I do when E2E tests keep failing?▼

Do not rerun an unchanged E2E or smoke failure without a new hypothesis. After two unsuccessful full reruns without a substantive change, stop cycling, inspect logs and artifacts, and report the blocker explicitly.