Six Real‑World Skill Templates Unveiled: Full Code, Structure, and Design Rationale

After the Harness pilot recap, the team received requests for de‑identified Skill examples. This post releases six representative Skills that span framework conventions, common business capabilities, engineering workflows, interface contracts, testing/review processes, and a frontend D2C scenario. For each Skill the article shows the repository layout, the full SKILL.md content, and the design rationale that prevents AI‑generated code from drifting away from verified project practices.

Part 01 – Framework Standards

Skill name: server-common-go-standard Problem: without a Skill, AI relies on a developer’s reminder to follow project conventions. This Skill encodes the "how to write" rules so AI can recognise and obey them automatically.

server-common-go-standard/
├── SKILL.md
├── agents/
│   └── openai.yaml
└── references/
    ├── api-gateway-protobuf.md
    ├── bus-cron-workers.md
    ├── ci-deploy.md
    ├── config-observability.md
    ├── data-cache-clients.md
    ├── project-shape.md
    ├── runtime-registration.md
    └── verification.md

Key workflow steps include locating the project root via go.mod, main.go, etc., reading AGENTS.md if present, and applying rules only after confirming the current repository still matches the reference files. The common rules enforce a unified Go module layout, module path pattern, Go version 1.23.0, and a set of mandatory dependencies and configuration files. The design note stresses a "fact boundary": only rules verified across multiple projects are recorded, and any conflict between the Skill and the live code is resolved in favour of the live code.

Part 02 – Common Business Capability

Skill name: integrate-rank-service Purpose: guide backend engineers to reuse the internal public ranking service instead of re‑implementing ranking logic.

integrate-rank-service/
├── SKILL.md
├── agents/
└── references/
    ├── requirement-intake.md
    ├── service-boundary.md
    ├── config-model.md
    ├── integration-playbook.md
    ├── expression-and-extension.md
    ├── troubleshooting.md
    └── cases/
        └── directional-pair-rank.md

The Skill defines when to use the service (new or activity rankings, direction‑pair rankings, etc.) and when not to (pure frontend styling, one‑off SQL ranking, or a requirement for an isolated system). The workflow checks the user’s input, asks for missing business information, determines supportability, and then outputs a checklist covering missing inputs, reuse feasibility, dimension support, configuration order, code entry points, verification steps, and troubleshooting priorities.

Part 03 – Engineering Workflow

Skill name: archery-ddl-workflow Goal: produce MySQL DDL that can be submitted directly to the Archery audit system, avoiding the typical "write‑then‑reject‑then‑fix" cycle.

archery-ddl-workflow/
├── SKILL.md
├── agents/
│   └── openai.yaml
└── references/
    ├── archery-rules.md
    ├── activity-rank-journal-example.md
    ├── common-fixes.md
    └── example-prompts.md

The Skill lists required inputs (new table vs. alter, business key, retry fields, status column, etc.) and a five‑step workflow: start from business contract, design the minimal column set, translate to Archery‑friendly SQL (explicit comments, defaults, collations, index naming), run a self‑check against common rejection reasons, and add rollback or risk notes if the DDL may affect online writes. Mandatory rules forbid IF EXISTS / IF NOT EXISTS, enforce a single‑column id primary key unless an exception is approved, and prescribe index naming conventions.

Part 04 – Interface Contract

Skill name: interface-contract-docs Purpose: generate, complete, or audit front‑back contract documentation so frontend developers receive a ready‑to‑use Markdown file.

interface-contract-docs/
├── SKILL.md
├── agents/
│   └── openai.yaml
└── references/
    └── contract-doc-pattern.md

The Skill forces the output file to reside under <project_root>/docs/delivery/, using a canonical naming scheme. It collects interface facts (requirements, proto files, Apifox specs, code snippets), distinguishes factual fields from inferred ones, and then produces a contract that describes call entry, parameter sources, minimal consumption fields, ignored fields, error handling, and integration checks. The process includes a self‑check to ensure the document is usable by both frontend and backend teams.

Part 05 – Test / Review

Skill name: review-skills (contains two sub‑skills: doc-driven-code-review and iterative-change-review)

These Skills split the "how to write" and "how to verify" concerns. They encode rules for evidence collection, exclusion criteria, review modes, high‑risk keyword triggers, and output requirements. The directory layout is shown below; the full SKILL.md content is omitted because it is lengthy.

review-skills/
├── doc-driven-code-review/
│   ├── SKILL.md
│   ├── agents/
│   └── references/…
└── iterative-change-review/
    ├── SKILL.md
    ├── agents/
    └── references/…

Part 06 – Frontend / D2C

Skill name: frontend-d2c-vue-activity-standard Focus: prevent layout drift when converting design drafts to code.

frontend-d2c-vue-activity-standard/
├── SKILL.md
└── references/
    ├── layout-generation-rules.md
    ├── component-and-asset-standard.md
    └── acceptance-checklist.md

The Skill mandates an anchor‑audit before extracting components (recording container size, child element coordinates, equal‑width/spacing checks) and requires explicit verification of CSS units (searching for rem or vw in the component directory). It warns that AI tends to over‑optimise layouts into uniform flex distributions, which can mis‑align with the original design; only when true equal‑width/spacing is confirmed may flex be used.

All seven Skills share a common theme: they define clear boundaries—when AI should follow strict rules, when it must pause for clarification, and when it should avoid making autonomous decisions—thereby reducing over‑confidence and keeping generated code aligned with verified project standards.