Menu
Create and structure a new autonomous project — "/new-project <what project does>"
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | new-project |
| version | 0.2.0 |
| description | Create and structure a new autonomous project — "/new-project <what project does>" |
| activation | {"keywords":["project","create project","new project","set up project","autonomous workspace","campaign","department","company project"],"patterns":["create a (new )?project","set up.*project","organize.*into.*project","new.project","/new.project"],"tags":["project-management","organization","goals"],"max_context_tokens":2000} |
Create an autonomous project workspace using memory_write and mission_create.
Given the user's description of what the project does, derive a short slug (lowercase, hyphens, e.g. ai-research). Then execute these steps sequentially (one tool call at a time — do NOT batch calls that depend on each other):
memory_write(target: "projects/{slug}/AGENTS.md", content: "# {Project Name}\n\n{What the agent should know about this project: domain, stakeholders, priorities, constraints, tools/APIs to use.}")
This file is loaded into the system prompt for every mission in this project. Make it specific and actionable.
memory_write(target: "projects/{slug}/context.md", content: "# {Project Name} — Context\n\n## Overview\n{What the project is and why it exists.}\n\n## Current State\n{What is known so far.}")
memory_write(target: "projects/{slug}/goals.md", content: "# Goals\n\n- Goal 1\n- Goal 2\n...")
Include measurable targets when possible. If the project would benefit from tracked metrics, add a metrics section:
## Metrics
| Metric | Unit | Target | How to measure |
|--------|------|--------|----------------|
| {name} | {unit} | {target} | {evaluation instruction — tell the agent HOW to check this: API call, file to read, command to run} |
Create recurring missions scoped to the project. Use the project name or slug as project_id (the engine resolves it to the correct project):
mission_create(name: "...", goal: "...", cadence: "daily", project_id: "{Project Name}")
Choose appropriate cadences: hourly, daily, weekly, monthly, or cron expressions like 0 9 * * 1-5.
projects/
{slug}/
AGENTS.md # Agent instructions (loaded into system prompt)
context.md # Background knowledge, current state
goals.md # Goal breakdown with optional metrics
research/ # Research and analysis outputs
reports/ # Generated reports
project_id when creating missions. Without it, missions land in the Default project.Use when adding or reviewing tests for Reborn behavior — choosing a test tier, covering a bug fix, testing model/tool-choice behavior, touching tests/integration or tests/fixtures/llm_traces, or when a test needs Postgres, Docker, or a live LLM.
Navigate building a user-facing feature in the Reborn stack (a capability that crosses product_workflow → composition → webui_v2 → runtime/serve → frontend). Use when planning or implementing any new Reborn settings page, endpoint, facade method, or runtime-backed capability — especially before writing code, to avoid rebuilding what already exists and to wire it in one pass instead of layer-by-layer.
Use when asked to "review the open PRs", review a batch or stack of pull requests, or run a recurring PR-review pass on a repo — especially with many PRs, stacked branches, conflicts, or security-sensitive changes. Covers grouping, fan-out to review subagents, verdict synthesis, and posting.
Generate or update the IronClaw architecture overview video using Remotion. Use when asked to update, regenerate, or modify the architecture video, add/remove scenes, or reflect codebase changes in the video.
Use when writing or reviewing a change in crates/ that adds a trait, a crate, a dependency edge, a re-export, or code in ironclaw_reborn_composition — or when deciding whether an abstraction, layer, or crate boundary is justified in the IronClaw Reborn stack.
Use when starting work in the IronClaw repo, deciding where a feature/fix/prompt/doc belongs, tracing how a request flows, looking up which crate owns a subsystem, or when repo docs, the knowledge graph, or component names seem stale, missing, or contradictory.