Write the GTM task plan from an approved spec with the architect. Use when the spec is approved.
2 stars
0 votes
0 copies
4 views
Added October 26, 2026
ai-agentsgosecurity
Security analysis
A100/100
Scanned November 11, 2026
$npx -y skills add MorganKryze/GentleTeaM --skill plan --agent claude-code
Installs into .claude/skills of the current project.
Sponsors
SSkills DirectorySkills Directory
Know which skills are safe — weekly.
SSkills DirectorySkills Directory
Is that skill safe to install?
Are you the author of Plan?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/morgankryze-plan)
---
name: plan
description: "Write the GTM task plan from an approved spec with the architect. Use when the spec is approved."
argument-hint: "[spec path or slug]"
---
# Plan (no checkpoint)
Ground rules: as in the `gtm` skill §0. The spec's Status must start with `approved`; otherwise
run `/gtm:spec` first.
## 1. Write
An amend (a dig pick from `/gtm:brief-me`): dispatch the architect with the existing plan path
and the picked option, never the shortcut below; it edits that file in place, same path, kept
Decisions, writes the pick into the plan's "Decisions made where the spec is silent" and a ledger
`ruling` line, and the plan is shown to the human before delivery (§3).
The spec's Status ends with `plan kept from the one pass` and the plan exists: dispatch no
architect, go to §2. Otherwise (no one pass, a card answered otherwise, the spec changed),
dispatch `gtm:architect` (plan mode), which writes or rewrites the plan, with: the spec path, the
validated mockup page, the output path `<root>/plans/<YYYY-MM-DD>-<slug>.md`, the ledger path, the
team settings' Gates (replay risky tasks: yes/no; risky paths; `tasks per branch`), and the
mandate the human's request or an answer gave, verbatim with where and when, or the current plan's
`## Mandate` section with its `> Source:` line (none: none). Template:
`${CLAUDE_PLUGIN_ROOT}/templates/plan.md`. When it returns, append its progress line (`plan`) as
`/gtm:deliver` §1 says, and one more after each correction round and each revision (§2); a
phase's lines are summed in the run line.
## 2. Check
- Every task has Files, Interfaces, TDD steps with commands from `verify`, a Verify line and a
commit message.
- `[P]` only on tasks whose files, CHANGELOG included, are disjoint within their parallel wave (two
or more consecutive `[P]` tasks); a lone `[P]` task runs as any other.
- At most the Gates line `tasks per branch` (absent: 8) tasks, a release-only one not counted,
each a vertical slice (a screen, a flow) and one review unit; more: back to the architect
once, then a card (split / accept), with your recommendation.
- Every task names the numbered global constraints it touches.
- Every task has `Tier: guarded | standard`: guarded when one of its Files matches a trigger of a
specialist the team settings' `review cadence` keeps per-task (a role left out, an unknown
value, or a lighter security-reviewer or data-reviewer: per-task; no cadence line: every task
guarded); a security-reviewer or data-reviewer is per-task always, an invalid trigger matches
every file, and a cadence keeping `reviewer` per-task makes every task guarded; a missing or
wrong one goes back.
- Every EARS line of the spec maps to at least one task's test.
- Every row of the spec's Decisions table confirmed by `review:` is named as a requirement in the
task that implements it, so it reaches the brief; a missing one goes back to the architect:
where a final review is skipped, that task's reviewer is the row's only reader. A row naming
`security-reviewer`, `data-reviewer` or `ux-qa` sits on a task with a File matching a trigger of
that specialist, which is on; a row naming `design-critic` or `final-reviewer`, or a match that
fails, goes back too: delivery runs a specialist by its triggers, never by a row.
- Risky tasks dry-run as the architect's Dry-run policy says, with gate counts recorded; a plan
of one task gets no dry run, its TDD steps plant the mutations instead.
- The plan lists the ledger lessons it applied.
- A `## Mandate` section only when the human's request or answer gave one, its lines verbatim under
a `> Source:` line naming where and when; one without a source goes back. A rewrite carries an
existing section over verbatim, its `> Source:` line included.
- The Summary holds the estimate line. Past 1.5× of the spec's (minutes or tokens): a Heads-up
and a decision card (go on / revise the plan), with your recommendation; no numeric estimate
in the spec: no comparison, no card.
One round of corrections with the architect if a check fails.
## 3. Continue
Do not present the plan. Go straight to `/gtm:deliver`, unless the plan deviates from the spec (a
Heads-up and a decision card), its task count passes the cap (§2's split / accept card), its
estimate passes 1.5× of the spec's (§2), or the human asked to see it (`/gtm:brief-me`).
After an amend, show the plan and wait for the human's go before `/gtm:deliver`.