> ## Documentation Index
> Fetch the complete documentation index at: https://shareful.blode.md/llms.txt
> Use this file to discover all available pages before exploring further.

# Creating shares

For the full quickstart, see [Getting started](./).

## CLI flags

Skip prompts by passing all four flags:

```bash
npx shareful-ai create \
  --title "Fix ESLint flat config migration" \
  --problem "ESLint 9 flat config breaks existing plugin configurations" \
  --tags "eslint,config,migration" \
  --type fix
```

## Writing the body

After the CLI generates the file, fill in the four body sections. See the [format spec](./share-format#body-sections) for templates and anti-patterns.

- **Problem** -- Show the broken code and error message, not a description of the fix
- **Solution** -- Provide complete, runnable code with language labels on every code block
- **Why It Works** -- Explain the root cause in prose, don't restate the solution
- **Context** -- Use a bulleted list with version requirements first

## Choose the right solution type

Most shares use `fix`. See the [solution type reference](./share-format#solution_type) for all five options and their title conventions.

## Writing tips

**Be specific.** "Fix React error" is too vague. "Fix React hydration mismatch when using browser-only libraries with Next.js 14" tells readers exactly what this solves.

**Include complete code.** Show the full file or function, not just the changed line.

**Add error messages.** People search for exact error text. Include it verbatim.

**Keep it focused.** One share solves one problem. Multiple solutions? Create multiple shares.

**Tag thoughtfully.** Use specific, lowercase tags (`nextjs` not `next`, `typescript` not `ts`). Cover the framework, language, and key libraries.

**Start titles with a matching verb.** "Fix" for fixes, "Use" for patterns, "Configure" for configs.

## Validate before publishing

Run `npx shareful-ai check` to validate all shares. It checks frontmatter, body sections, and slug-directory alignment.

Human-judgment checklist (the CLI catches the rest):

- Title names the technology and problem, verb matches `solution_type`
- Problem includes the error message or observable symptom
- Code is complete and runnable, not fragments
- No placeholder content

For the full checklist, see [examples](./examples#quality-checklist).

## Next steps

- [Format specification](./share-format) - field constraints and validation rules
- [Examples](./examples) - annotated good and bad shares
- [CLI reference](./cli)