zicato-dev-guide

Guides safe changes to zicato source code, tests, contracts, and workflows.

4|2|Updated May 14, 2026
One-click install
npx skills add https://github.com/pedapudi/zicato --skill zicato-dev-guide
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: zicato-dev-guide
Source: https://github.com/pedapudi/zicato/tree/main/skills/zicato-dev-guide
Command: npx skills add https://github.com/pedapudi/zicato --skill zicato-dev-guide

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps developers modify zicato safely without overlooking its architecture, contracts, testing requirements, or hard-won engineering invariants.

Core Features & Use Cases

  • Surface Routing: Directs changes to the correct chapter of the 14-chapter development guide.
  • Invariant Protection: Provides the 10 Golden Rules, shipped-bug warnings, visibility constraints, epoch requirements, and worker-boundary rules.
  • Verification Workflow: Defines the pre-commit ladder covering tests, formatting, typing, import contracts, parity gates, JavaScript checks, oracle tests, and vendor scanning.
  • Use Case: When adding a scoring knob or changing tournament code, use this Skill to identify the governing invariants, read the relevant development recipe, and run the required validation steps.

Quick Start

Use the zicato development guide to safely review and implement the requested source or test change.

Frequently Asked Questions about zicato-dev-guide

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

FAQPage Schema
How do I safely modify software architecture and preserve invariants during code modification?

To safely modify software architecture and preserve invariants, consult a code-grounded development guide that outlines Golden Rules, visibility constraints, and worker-boundary rules before changing source code. This ensures architectural integrity and invariant protection throughout your development workflow.

What pre-commit verification steps are required for testing and formatting source code changes?

Required pre-commit verification steps for testing and formatting include running a validation ladder covering tests, formatting checks, typing, import contracts, parity gates, JavaScript checks, oracle tests, and vendor scanning. These steps ensure source code changes meet all engineering invariants before committing.

When do I need to check development guide chapters before changing tournament or scoring code?

You need to check development guide chapters when changing tournament or scoring code to identify governing invariants, read relevant development recipes, and run required validation steps. This surface routing directs changes to the correct chapter across 14 development guide sections.

Does this code-grounded guidance cover orchestrator, runtime, and storage development workflows?

Yes, this code-grounded guidance covers orchestrator, runtime, and storage development workflows, applying also to proposer, tournament, selection, scoring, supervisor, dashboard, builder, CLI, and harness-adapter work. It ensures safe changes across all listed architectural components.

What are the Golden Rules and shipped-bug warnings I must follow when modifying contracts?

The Golden Rules and shipped-bug warnings are invariant protection mechanisms that define visibility constraints, epoch requirements, and worker-boundary rules you must follow when modifying contracts. They prevent regressions and preserve hard-won engineering invariants during code modification.