Add phases to the sprint

Register in config

Add your phase to the project config with its position in the pipeline:

// .nanostack/config.json
{
  "phases": {
    "custom": [
      {
        "name": "deploy",
        "after": "ship",
        "skill": "deploy",
        "parallel": false
      }
    ]
  }
}

The after field sets where the phase runs in the pipeline. The skill field references the skill directory name (from ~/.nanostack/custom/deploy/ or .nanostack/custom/deploy/).

Setting parallel to true lets the phase run alongside review, qa, and security. Set it to false for phases that must run sequentially.

What registration enables

Once a custom phase is registered, it gets everything the core phases have:

Artifact saving — sprint.sh complete deploy saves the artifact to .nanostack/deploy/artifact.json.
Artifact reading — find-artifact.sh deploy locates and verifies the deploy artifact.
Sprint status — sprint.sh status shows the deploy phase with its state (pending, claimed, complete, failed).
Analytics — bin/analytics.sh includes the custom phase in timing, finding counts, and sprint summaries.
Journal entry— the sprint journal logs the custom phase alongside all other phases.
Conductor support — /conductor manages the custom phase like any other. It can be claimed, locked, and batch-assigned.

Example: adding /deploy after /ship

Here is a complete example. First, create the skill:

# ~/.nanostack/custom/deploy/SKILL.md
---
name: deploy
description: Deploy to staging and verify
phase: deploy
trigger: /deploy
---

# /deploy

1. Read the ship artifact for the commit SHA.
2. Run: git push origin HEAD:staging
3. Wait 30 seconds for the deploy to propagate.
4. Curl the health check endpoint.
5. Save the result as a deploy artifact.

## Artifact format
{
  "phase": "deploy",
  "url": "https://staging.example.com",
  "health_check": "pass" | "fail",
  "deploy_sha": "<commit>",
  "duration_seconds": <number>
}

Then register it:

// .nanostack/config.json
{
  "phases": {
    "custom": [
      {
        "name": "deploy",
        "after": "ship",
        "skill": "deploy",
        "parallel": false
      }
    ]
  }
}

Now the sprint pipeline is: think, plan, build, review + qa + security (parallel), ship, deploy.

Ordering rules

after must reference a core phase (think, plan, build, review, qa, security, ship) or another custom phase that is already registered.
Circular dependencies are rejected at registration time.
Multiple custom phases can have the same after value. If they are both parallel: true, they run concurrently. If both are parallel: false, they run in registration order.

Removing a custom phase

Delete the entry from config.json. The skill directory can stay in place; it just will not be part of the sprint pipeline anymore. You can still invoke it manually with its trigger command.