بنقرة واحدة
create-goal
Use when setting up a new open-ended goal for autonomy tracking, before starting the first iteration
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Use when setting up a new open-ended goal for autonomy tracking, before starting the first iteration
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | create-goal |
| description | Use when setting up a new open-ended goal for autonomy tracking, before starting the first iteration |
| user-invocable | true |
Set up a new open-ended goal by creating the directory structure, writing the goal definition, and preparing for iteration tracking.
Core principle: One-time setup. Run this once per goal, then use start-iteration for all subsequent work.
Use this skill when:
/create-goal commandDO NOT use for:
| Step | Action | Tool |
|---|---|---|
| 1. Verify no existing goal | Check for autonomy directory | Glob |
| 2. Get goal details | Prompt user for goal statement | User interaction |
| 3. Generate directory name | Convert to kebab-case | Manual |
| 4. Create structure | Make directory | Bash |
| 5. Write goal.md | Document goal definition | Write |
| 6. Announce ready | Tell user to run /start-iteration | Direct output |
Check that no goal already exists:
# Use Glob to check
pattern: "autonomy/*/goal.md"
If goal.md found:
"An autonomy goal already exists: [goal-name]
Use '/start-iteration' to continue working on this goal.
If you want to create a different goal, first archive or remove the existing one."
Stop here - don't create duplicate goals.
If no goal found: Proceed to Step 2.
Prompt user for goal information:
"What open-ended goal would you like to pursue?
This should be a goal that never truly completes - ongoing optimization, continuous improvement, or iterative exploration.
Examples:
- Maximize monthly recurring revenue
- Improve developer productivity
- Reduce customer churn
- Optimize application performance
Your goal:"
User provides goal statement.
Then ask about success criteria:
"What metrics or indicators should we track for this goal?
Since this is open-ended, there's no 'done' state, but we can track progress.
Examples:
- MRR: Starting at $45k/month
- Churn rate: Currently 13%
- Build time: Currently 5 minutes
Your metrics (or 'none' if not applicable):"
User provides metrics or indicates none.
Convert goal statement to kebab-case:
Rules:
Examples:
maximize-monthly-recurring-revenueimprove-developer-productivityreduce-customer-churnCreate the goal directory:
# Use Bash to create directory
mkdir -p autonomy/[goal-name]
Create the goal definition file:
# Goal: [Original goal statement]
## Goal Statement
[Full description from user]
## Success Criteria
[Open-ended - note that this has no completion state]
## Metrics to Track
[If user provided metrics:]
- [Metric 1]: [Starting value]
- [Metric 2]: [Starting value]
[If no metrics:]
- No specific metrics defined
- Progress will be qualitative
## Current Status
Active - Ready for iteration 1
## Started
[Current date: YYYY-MM-DD]
## Notes
[Any additional context from user]
Write this file to: autonomy/[goal-name]/goal.md
Inform user that goal is created:
**Goal created: [goal-name]**
Directory: `autonomy/[goal-name]/`
Goal definition: `autonomy/[goal-name]/goal.md`
---
**Next step:** Run `/start-iteration` to begin the first iteration.
This will:
- Create iteration-0001-[today's date].md
- Set up workspace for working toward the goal
- Track progress in iteration journals
Currently, autonomy supports one goal per project directory:
Keep directory names:
Verify goal is truly open-ended:
Good examples:
Bad examples:
If user suggests closed goal, guide them:
"This goal seems to have a clear completion state. For goals with a definition of 'done',
consider using the [ed3d-plugins](https://github.com/ed3dai/ed3d-plugins) plan-and-execute workflow instead.
Autonomy is designed for never-ending optimization and improvement goals.
Would you like to reframe this as an open-ended goal, or would a different workflow be better?"
Not all open-ended goals have quantifiable metrics:
Accept "none" or "qualitative" as valid answers.
| Mistake | Reality |
|---|---|
| "I'll create goal even though one exists" | NO. One goal per project. Check first. |
| "User goal is closed-ended but I'll create anyway" | NO. Guide to appropriate workflow. |
| "I'll skip metrics prompt to save time" | NO. Always ask - user may have important metrics. |
| "Directory name can have spaces" | NO. Use kebab-case only. |
| "I'll start first iteration automatically" | NO. Let user run /start-iteration when ready. |
Once goal is created:
/start-iteration to begin workUse when working in a project that has a `.agents/` directory or when the user asks about Conway Architecture, the conway-architecture plugin, domain agents, owned_paths enforcement, or how to coordinate a persistent subagent team that shadows the application's architecture
Use when reading or writing OST (Outcome / Strategy / Tactic) graph data in the `agents` TypeDB database - covers the falsifiability rubric, the three-layer discipline, ID conventions, lifecycle transitions, and the structured Task fields that replace generic descriptions
Use when interacting with a TypeDB 3.x database via the typedb MCP tools (typedb-query, typedb-database_schema, etc.) - covers schema-first workflow, transaction types, TypeQL 3.x syntax (which differs materially from 2.x), and the most common failure modes
Use when analyzing another branch's iteration journals to extract findings, decisions, and insights from divergent work
Use when user wants detailed status report for single autonomy branch including iteration timeline and metrics progression
Use when saving current iteration progress mid-conversation, before context compaction, or at interim pause points