planner

Files (8)

• CLAUDE.md
• INTENT.md
• README.md
• SKILL.md
• CLAUDE.md · resources/
• README.md · resources/
• plan-format.md · resources/
• plan-json-schema.md · resources/

SKILL.md (first lines)

## Activation

When this skill activates, run the step-1 command for the requested mode before exploring,
and follow its output: the script prints each step, so it is the workflow.

| Mode      | Intent                             | Entry point                                 |
| --------- | ---------------------------------- | ------------------------------------------- |
| planning  | "plan", "design", "architect"      | `skills.planner.orchestrator.planner` step 1 |
| execution | "execute", "implement", "run plan" | `skills.planner.orchestrator.executor` step 1 |

Each command is self-contained: run one whole line, since shell state does not persist between invocations. `<scripts>` is a literal absolute path you write in, inside the double quotes the command gives it: `<project>/.claude/skills/scripts` when `test -d "<project>/.claude/skills/scripts"`, run as a command of its own, exits 0, and `<home>/.claude/skills/scripts` otherwise, with `<home>` your home directory written out.

**planning**

```bash
uv run --project "<scripts>" python -m skills.planner.orchestrator.planner --step 1
```

**execution**

```bash
uv run --project "<scripts>" python -m skills.planner.orchestrator.executor --step 1
```

**Run these from inside the project.** Step 1 resolves the project from the git
repository at or above the working directory, and Claude Code keeps that directory inside
the project: a subagent's working directory resets before every call, and the main
session's resets when it leaves the project. Do not `cd`, into the skills directory or
anywhere else: `--project` already locates the scripts, and step 1 needs the project's
own working directory left intact.

`<scripts>` picks the install layout from that same project, so a project-local install wins when it exists. Write the path out rather than computing it in the command: Claude Code asks for approval outside bypass mode when a command argument contains a shell substitution. An environment-variable fallback cannot pick the layout either -- Claude Code does not populate `CLAUDE_PROJECT_DIR` for Bash-tool subprocesses, so unless the user exports it themselves the fallback selects the user-global install. That fails on a project-local-only install and silently runs the global scripts when both exist.

Step 1 is the only step that can see which project the run belongs to. It reads
`$CLAUDE_PROJECT_DIR`, then falls back to the working directory, and records the answer in
the state directory; every later step runs under `uv run --directory <SKILLS_DIR> ...`
and reads it back rather than looking again. That is why these entry points use
`--project` instead of the `<invoke working-dir=...>` form other skills use: `working-dir`
resolves the install layout by `cd`-ing into it, discarding the working directory -- the
one signal Claude Code supplies for these subprocesses. See
`skills/scripts/skills/lib/workflow/prompts/README.md` ("Invocation Forms") and
`skills/planner/INTENT.md` ("State directory location").

From gcharang/claude-config, MIT.

More from gcharang/claude-config