Sley Documentation

What Sley is for

Sley is a compiler-oriented language surface for people and AI operators who need fast edits with strong evidence. Use it when your workflow values reproducibility, scope control, and explicit planning over ad-hoc text patching.

• Language-level boundaries for authority and side-effects
• Deterministic planning and edit receipts for machine handoff
• Token-aware workflows where context stays scoped and reviewable

Quick start

Use this shortest path for a first successful loop with low context overhead.

# 1) Sanity-check the language surface
sley doctor --json .

# 2) Inspect structure and graph intent
sley ast --json main.sley
sley graph --json --slice <node-id> main.sley

Starter page: Sley tutorial

Public command surface

The public API is oriented around checks, graph views, and verified edit planning. Use JSON outputs by default so tools can compare receipts across hands.

• sley ast
• sley graph
• sley query
• sley lint
• sley plan
• sley verify
• sley doctor

Language-first workflow

Sley prefers explicit task declarations, typed task calls, schema-linked JSON reports, and deterministic plan outputs. This keeps token pressure low by preserving edit structure instead of re-explaining intent on every cycle.

• Scope every operation to the smallest valid edit slice
• Read diagnostics before mutation
• Use `--dry-run` mode for repair previews

Hands-on walkthrough

From a fresh checkout, begin with release-boundary checks, then run readiness commands in this sequence. Each stage emits JSON artifacts intended for deterministic comparison across handoffs.

# Step 1: baseline health
sley doctor

# Step 2: inspect structure
sley ast --json .

# Step 3: inspect planned edits
sley plan --json --graft-templates .

# Step 4: lock behavior with verification
sley verify --json .

Evidence and safety boundaries

Every public-facing route points to bounded claims and open references only. Internal runtime specifics remain intentionally omitted from the public mirror until release posture and doctrine allow a wider public reveal.

• Source and docs links are canonical: GitHub, OpenForge, and sleylang.org
• Protected implementation details stay off the public brief
• Verification artifacts stay the compatibility boundary for external review

Operational references

Public release posture, benchmark posture, and release notes are surfaced through Greyforge OpenForge and Greyforge Chronicles. Those are the stable sources for claims and public links.

• Read `/chronicles/sley-zjx-agent-native-stack` on greyforge.tech
• Track OpenForge repo posture from the same source chain
• Use llms.txt for crawler-facing summary and links

Public claim summary

• First AI-native language claim: structured edits over unbounded prompts.
• Token-efficiency claim: reduce churn through explicit intent boundaries.
• Safety claim: review-oriented execution at the public edge.

Walkthrough map

1. Read this brief and the walkthrough before any edits.
2. Verify baseline posture: sley doctor --json .
3. Inspect structure and graph slices before planning: sley ast --json . and sley graph --json --slice <node-id> .
4. Produce structured plans and only then promote: sley plan --json --graft-templates .
5. Validate again with sley verify --json . and move forward only if checks pass.

Release-friendly onboarding

The easiest onboarding path is intentionally conservative: confirm baseline checks, generate structured reports, and only then promote deeper edits after lint and verify pass.