| name | craft-authoring |
| description | Required when running /craft. Provides Workflow / Skill / Prompt scaffolds and quality guardrails using judgment-driven criteria. |
Craft Authoring - Scaffolds and Self-Check
This skill carries the execution detail of /craft.
/craft defines direction; this file defines landing. Direction without landing becomes rhetoric. Landing without direction becomes mechanical output.
Global Authoring Protocol
- Keep language precise and intentional.
- Let narration add force, not noise.
- Prefer judgment signals over decorative phrasing.
- Ensure every major section answers: what / why / how to validate.
- Build meaning first, then rules, then verification.
Judgment bar:
- A good document makes execution clearer, steadier, and reproducible.
- A weak document sounds energetic but depends on improvisation.
Split from output-contract: This file covers scaffolds for workflows/skills/prompts only. Shared on-disk spec, parent/child delegation, and single-writer rules live in .agents/skills/output-contract/SKILL.md.
CLI install manifest: what copies on anws init, registry + BUNDLE_POLICY boundaries—read references/BUNDLE_POLICY.md.
Workflow Skeleton (minimal)
---
description: [one-line purpose]
---
# /name
<phase_context>
You are **[role]**.
**Mission**: …
**Capabilities**: …
**Constraints**: …
**Relationship to user**: …
**Output Goal**: `path`
</phase_context>
---
## CRITICAL Writing Constraints
> [!IMPORTANT]
> Writing constraints are defined in `/craft` and should not be duplicated here.
---
## Step 1: [Title]
### What
...
### Why
...
### How to Validate
- ...
- ...
---
<completion_criteria>
- [observable done condition]
</completion_criteria>
Skill Skeleton (description is the trigger)
---
name: kebab-name
description: When [concrete trigger scenario], load this skill. [Capability summary]
---
# Title
## What
...
## Why
...
## How to Validate
- Input contract: ...
- Output contract: ...
Bad description: capability slogan.
Good description: precise trigger boundary.
Judgment bar:
A strong description behaves like a gate, not a banner.
It defines both when to activate and when not to activate.
Prompt Skeleton
# Title
## What
...
## Why
...
## How to Validate
- Constraints: ...
- Output format: ...
Guardrail Cheat Sheet
| Mechanism | Use |
|---|
[!IMPORTANT] | non-skippable node |
## CRITICAL | loud boundary |
you **must** | hard action |
<completion_criteria> | definition of done |
Strong constraints explain at least: what, why, and drift signal.
Filling Pass (equivalent to old Step 5)
Use sequential-thinking for 3-5 thoughts to cover goals, risks, I/O, and where research lands.
Quick checks:
- Is each section actionable?
- Is each critical rule justified?
- Is completion externally verifiable?
Judgment bar:
If a paragraph cannot tell the executor what to do, it is noise.
If it cannot tell why, it is command theater.
If it cannot tell how to verify, it is wishful writing.
Validation (before ship)
Structure:
- frontmatter
phase_context (workflow use)- CRITICAL block
<completion_criteria>
Content:
- correct path and naming
- clear trigger boundaries
- complete input/output contracts
- externally observable failure signals
Scoring Gate (before release)
Before shipping, run static scoring:
- read
references/PROMPT_QUALITY_RUBRIC.md
- produce a scorecard using
references/SCORECARD_TEMPLATE.md
- report Tier (T0/T1/T2/T3) and weighted seven-dimension score
Hard rules:
- if Hard Fail Gate is triggered, final verdict must be
Infeasible
- if no Hard Fail and weighted score < 4.0, run one repair iteration and re-score
Self-Critique (last gate)
Use sequential-thinking for 3-5 thoughts:
- where users might stall
- where the model might skip
- which section still mixes too many concerns
- what to revise before shipping
Final question:
If this document is executed repeatedly, are you willing to own its consequences?
