Documentation
How To Write A Good /goal
A task contract turns one coding request into an auditable result. Name the current files and evidence, keep boundaries explicit, and replace sample commands with the repository's real checks.
Start with seven fields
- GOAL: one concrete outcome.
- CONTEXT: files, issues and logs to inspect first.
- CONSTRAINTS: scope, behavior and safety boundaries.
- DONE WHEN: measurable completion conditions.
- VERIFY: fresh commands or artifacts that prove those conditions.
- OUTPUT: changes, evidence and remaining risks.
- STOP RULES: when missing access or decisions require a pause.
Choose a pattern for your task
- Vague request: inspect context, then draft a goal.
- Tests, lint and typecheck: a mechanical completion loop.
- Blocked work: report an escape hatch instead of claiming completion.
- Design before execution: plan, then run a stable goal.
Is /goal a native command in every agent?
The catalog provides task text. It does not install a command or establish support in every agent. Check your agent's current interface; if needed, paste the contract as ordinary instructions.
How is this different from GitHub Spec Kit?
This catalog helps you select and adapt a bounded task contract. Spec Kit is an installable toolkit with structured specification, bug-fix and assessment workflows. Choose it when you need that workflow and its artifacts; reading this catalog does not install it.
Does source-backed mean ready to run?
It identifies public provenance, not verification in your repository. Seed patterns are separately authored starting points. For both, bind the files, checks and completion conditions to your actual task.
Read the complete English guide or 中文指南. With JavaScript enabled, the full selected-language guide loads here.