Get the FREE Ultimate OpenClaw Setup Guide →

implement

Scanned
npx machina-cli add skill rana/yogananda-skills/implement --openclaw
Files (1)
SKILL.md
4.7 KB

Read all project markdown documents referenced by the target. Follow CLAUDE.md § Arc-gated reading to load only what the target requires.

Implementation Specification

Target: $ARGUMENTS

Phase 1: Gather Requirements

  1. Identify the target — Parse the argument. If it's a deliverable number (e.g., "1a.2"), find it in ROADMAP.md. If it's a DES/ADR identifier, locate it in the appropriate file. If it's free-text, find the closest matching specification.
  2. Follow all references — Read every ADR, DES section, and cross-reference the target depends on. Build the complete requirements picture.
  3. Extract constraints — From PRINCIPLES.md and CLAUDE.md, identify which principles constrain this implementation (verbatim fidelity, DELTA compliance, performance budgets, accessibility, multilingual, etc.).
  4. Check prerequisites — What must already exist for this implementation to proceed? Database tables, API routes, services, config values, credentials. Flag anything missing.

Phase 2: Map to Code

  1. File inventory — List every file that will be created or modified, with full paths per the project's code layout:

    • /lib/services/ — Business logic (framework-agnostic TypeScript)
    • /lib/config.ts — Named constants (ADR-123)
    • /app/api/v1/ — API routes
    • /app/ — Pages and components
    • /migrations/ — SQL migrations (dbmate)
    • /terraform/ — Infrastructure changes
    • /messages/ — Locale strings

  2. Function signatures — For each service function, specify:

    • Name, parameters, return type
    • Which ADR/DES governs its behavior
    • Error cases

  3. SQL migrations — For any database changes:

    • Full CREATE TABLE / ALTER TABLE statements
    • Indexes (specify type: btree, GIN, HNSW)
    • Constraints and defaults
    • UUIDv7 primary keys per project convention

  4. Config constants — Any tunable parameters per ADR-123:

    • Constant name, type, default value
    • Which DES/ADR specifies the value
    • Where in /lib/config.ts it belongs

  5. API routes — For any new endpoints per DES-019:

    • HTTP method and path
    • Request/response shapes (following ADR-110 conventions)
    • Pagination strategy (cursor-based for lists)
    • Language parameter handling

Phase 3: Specify Tests

  1. Test specifications — For each file/function:
    • Unit tests (what to test, edge cases)
    • Integration tests (API route testing)
    • Which testing layer per ADR-094

Phase 4: Flag Ambiguities

  1. Ambiguities — Questions that must be answered before implementation:

    • Design decisions not yet made
    • Unclear specifications
    • Missing information
    • Choices that need human judgment

  2. Implementation order — Sequence the work:

    • What to build first (dependencies)
    • What can be parallelized
    • Natural commit boundaries

Output Format

## Implementation Spec: [target]

### Prerequisites
[What must exist before starting]

### Files
| File | Action | Purpose | Governing Ref |
|------|--------|---------|---------------|
| /lib/services/foo.ts | Create | ... | DES-NNN |

### SQL Migrations
[Full SQL with comments]

### Config Constants
| Constant | Type | Default | Source |
|----------|------|---------|--------|
| FOO_LIMIT | number | 100 | DES-NNN |

### API Routes
[Method, path, request/response shapes]

### Function Signatures
[TypeScript signatures with JSDoc]

### Test Specifications
[What to test per file]

### Ambiguities
[Questions requiring human input]

### Implementation Order
[Sequenced steps with commit boundaries]

Output Management

Hard constraints:

  • Segment output into groups: Prerequisites + Files first, then SQL + Config, then API + Functions, then Tests + Ambiguities + Order.
  • Write each segment incrementally. Do not accumulate a single large response.
  • After completing each segment, continue immediately to the next. Do not wait for user input.
  • Continue until the full specification is delivered.
  • If the target is too large for one session, state what was covered and what remains.

Document reading strategy:

  • Follow CLAUDE.md § Arc-gated reading. Only load documents the target references.
  • Read DES/ADR sections fully. Read DESIGN.md selectively based on cross-references.

What questions would I benefit from asking?

What am I not asking?

You have complete design autonomy.

Source

git clone https://github.com/rana/yogananda-skills/blob/main/skills/implement/SKILL.mdView on GitHub

Overview

This skill translates architectural deliverables (deliverables, DES sections, or ADRs) into a concrete, executable implementation plan. It aggregates requirements, maps them to code structures, SQL migrations, configs, API routes, and tests, and highlights ambiguities and ordering to ensure a smooth bridge from design to working code.

How This Skill Works

Phase 1 gathers requirements by locating the target in ROADMAP.md, DES, or ADRs, then reads all references and extracts constraints from PRINCIPLES.md and CLAUDE.md. Phase 2 maps requirements to code by generating a full file inventory, defining function signatures with governing ADR/DES, outlining SQL migrations, config constants, and API routes. Phase 3 specifies tests (unit and integration) per file/function, and Phase 4 surfaces ambiguities and establishes a sequenced implementation order.

When to Use It

  • You need a concrete implementation plan from an architectural/design spec.
  • You're converting ADR/DES references into code structure, migrations, and tests.
  • You must enumerate required files, function signatures, and config constants before coding.
  • You require explicit API route definitions and testing scope tied to ADR- or DES-guided rules.
  • You want a clear implementation order with commit boundaries and dependency mapping.

Quick Start

  1. Step 1: Provide the target (deliverable number, DES/ADR ID, or free-text feature).
  2. Step 2: Run Phase 1–Phase 3 to generate the file inventory, signatures, migrations, and tests.
  3. Step 3: Review Ambiguities and finalize the Implementation Order with commit boundaries.

Best Practices

  • Start by identifying the exact target (deliverable number, DES/ADR, or free-text feature).
  • Read every ADR, DES section, and cross-referenced dependency to build a complete requirements picture.
  • Document the exact file layout and which ADR/DES governs each behavior.
  • Specify SQL migrations with full CREATE/ALTER statements, indexes, constraints, and UUIDv7 keys.
  • Define test specifications for each file/function, including unit and integration tests per ADR-094.

Example Use Cases

  • Generate an implementation spec for a user authentication feature including file paths, function signatures, migrations, and tests.
  • Create SQL migrations and config constants for a product catalog refresh guided by ADR-123.
  • Define API routes and request/response shapes for a checkout service per DES-019 conventions.
  • Map a payment gateway integration to code with endpoint definitions and integration test plans.
  • Outline implementation order and commit boundaries for a new notification service across /lib, /app, and /migrations.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers ↗