planning-software — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited planning-software (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Produce a self-contained orchestration plan from an approved enriched roadmap. The plan is the orchestrator's execution contract — it records the workflow tier, tracks chunk progress, and contains the full per-chunk protocol so any orchestrator session (including a fresh one) can resume work without reading conversation history.
The plan describes process (agent sequence, review perspectives, gates). The roadmap describes content (what to build in each chunk). These are separate documents with separate owners. Never duplicate roadmap content into the plan.
This skill covers:
This skill does NOT cover:
Before producing the plan, confirm you have:
If any input is missing, request it before proceeding.
Both files live in the project root alongside PRD.md, ARCHITECTURE.md, and ROADMAP.md.
Read ROADMAP.md completely. Note:
Apply the scale rules:
| Tier | Plan depth |
|---|---|
| Quick | Short — no phases section, flat chunk list, no whole-project review step |
| Standard | Full — sequential chunks, complete per-chunk protocol, whole-project review at end |
| Thorough | Full with phases — phase groupings, parallel dispatch annotations, whole-project review at end |
Use the Template section below. Populate each section with the data from Steps 1-2:
[ ] not started, [~] in-progress, [x] complete.Create an empty ORCHESTRATION-LOG.md file with a header comment only. The format for log entries is defined in orchestrating-software-dev — do not define it here.
# Orchestration Log
<!-- Append-only. Do not edit previous entries. -->Use this template to produce ORCHESTRATION-PLAN.md. Adapt to the workflow tier (see annotations).
Note: The per-chunk protocol below intentionally summarises content from orchestrating-software-dev so the plan is self-contained for cross-session resumption. If the protocol changes in orchestrating-software-dev, update this template to match.
# Orchestration Plan — [Project Name]
**Tier:** [Quick / Standard / Thorough]
**Created:** [YYYY-MM-DD]
**Roadmap:** ROADMAP.md
**PRD:** PRD.md
**Architecture:** ARCHITECTURE.md
---
## Upstream Steps
- [x] PRD — PRD.md
- [x] Architecture — ARCHITECTURE.md
[Standard/Thorough add:]
- [x] Interface Design — .interface-design/system.md (if project has UI)
- [x] Decomposition — ROADMAP.md (structure)
- [x] Enrichment — ROADMAP.md (executable)
---
## Build Progress
<!-- Update status markers as work proceeds: [ ] not started, [~] in-progress, [x] complete -->
- [ ] chunk-001: [name]
- [ ] chunk-002: [name]
[... repeat for all chunks ...]
[Standard/Thorough add:]
- [ ] Whole-project review
---
## Per-Chunk Execution Protocol
### 1. Assign the chunk
Read the next uncomplete chunk from ROADMAP.md. Provide developer-agent with:
- Chunk section from ROADMAP.md (acceptance criteria, file set)
- Relevant ARCHITECTURE.md section(s)
- For Standard/Thorough: pointer to patterns from earlier chunks if relevant
### 2. Worktree setup
Orchestrator creates an isolated worktree for this chunk using the using-worktrees skill, then points developer-agent to the worktree path.
### 3. Developer executes
Developer-agent: TDD (red-green-refactor) → verify → report status code.
| Status code | Orchestrator action |
|------------|---------------------|
| DONE | Send to reviewer-agent |
| DONE_WITH_CONCERNS | Review concerns, then send to reviewer-agent |
| NEEDS_CONTEXT | Provide missing context, developer continues |
| BLOCKED | Escalate — is this an architecture gap or scope issue? |
### 4. Review loop
Invoke reviewer-agent with the appropriate perspectives:
[Quick:]
- spec-compliance
[Standard:]
- spec-compliance → code-quality → design-compliance (if system.md exists and chunk touches UI)
[Thorough:]
- spec-compliance → code-quality → design-compliance (if system.md exists and chunk touches UI) → security (if chunk handles user input or sensitive data)
**Decision:**
- Accept → merge worktree, proceed to Step 5
- Revise → return to developer-agent with specific findings
- After 3 iterations without acceptance → escalate (signals a brief or architecture gap)
### 5. After each chunk
1. Update chunk status in Build Progress above
2. Append step to ORCHESTRATION-LOG.md
3. Update LEARNINGS.md only if something noteworthy happened
---
## Completion
[Quick: omit this section]
[Standard/Thorough:]
After all chunks are marked complete:
1. Invoke reviewer-agent with whole-project perspective against PRD.md
2. If accepted: mark plan complete
3. If revise: address findings and re-run whole-project review
---
## Resumption Note
New session? Read this file. Find the first `[~]` or `[ ]` chunk in Build Progress. Resume from there using the Per-Chunk Execution Protocol above.Resuming mid-chunk: If a chunk is marked [~] (in-progress), check ORCHESTRATION-LOG.md for the last completed step. Re-read the relevant chunk from ROADMAP.md and resume from where the developer-agent left off.
Tier change after plan creation: Do not modify an existing plan's tier mid-project. If scope expands significantly, note it in ORCHESTRATION-LOG.md and create a revised plan.
Parallel chunks (Thorough only): If ROADMAP.md annotates chunks as parallelisable, note this in the Build Progress list (e.g., - [ ] chunk-003: [name] [parallel with chunk-004]). The orchestrator dispatches these concurrently when file sets do not conflict.
Quick tier with security concern: Override the default spec-compliance-only perspective. Load security perspective for any chunk handling authentication, user input, or sensitive data.
Input: Approved ROADMAP.md with 2 flat chunks for a bug fix. Tier: Quick.
Expected output: Short ORCHESTRATION-PLAN.md — upstream steps show PRD and architecture update only; Build Progress lists 2 chunks with no whole-project review; protocol section shows spec-compliance only; no phases. Whole file under 60 lines.
Input: Approved enriched ROADMAP.md with 5 sequential vertical-slice chunks for a new feature. Tier: Standard.
Expected Build Progress section:
## Build Progress
- [ ] chunk-001: Walking Skeleton
- [ ] chunk-002: User Service
- [ ] chunk-003: Recipe Service
- [ ] chunk-004: Shopping Service
- [ ] chunk-005: Frontend Pages
- [ ] Whole-project reviewProtocol shows spec-compliance → code-quality perspectives. Completion section includes whole-project review step. Resumption note present.
Input: Approved enriched ROADMAP.md with 9 chunks in 3 phases, some marked parallelisable. Tier: Thorough.
Expected output: Full ORCHESTRATION-PLAN.md with phase groupings in Build Progress; parallel annotations noted; protocol shows spec-compliance → code-quality → security; completion section includes whole-project review. Plan is complete enough that a fresh orchestrator session reading it cold can identify the current phase, the next chunk, and which perspectives to load.
Input: An existing ORCHESTRATION-PLAN.md with chunk-001 marked [x], chunk-002 marked [~], remaining chunks [ ].
Expected behaviour: Orchestrator reads plan, identifies chunk-002 as in-progress, checks ORCHESTRATION-LOG.md for last completed step, resumes chunk-002 from that point without asking the user for context.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.