Skip to content
Back to skills

Plan Triage

ASecurity

Triage plan review findings — categorize issues, fix actionable ones, report

  • 23 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added May 28, 2026
documentationgobash

Security analysis

A100/100

Scanned May 28, 2026

npx -y skills add tta-lab/ttal-cli --skill plan-triage --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Plan Triage?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Plan Triage
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/tta-lab-plan-triage/badge)](https://www.skillsdirectory.com/skills/tta-lab-plan-triage)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: plan-triage
description: "Triage plan review findings — categorize issues, fix actionable ones, report"
argument-hint: ""
claude-code:
  allowed-tools:
    - Bash
    - Read
    - Glob
    - Grep
---

# Plan Triage

Triage plan review findings: categorize each issue, fix what's actionable, then report.

You already have the plan and its review issues in context. No need to search or re-read — just categorize, fix, and report.

## Usage

```
/plan-triage
```

Run this after `ttal go <uuid>` has identified issues. The plans and issues are already in your conversation context.

## Phase 1: Categorize

For each issue from the plan review, categorize it:

**Actionable (fix now)**
- Gaps that would block a worker
- Wrong assumptions verified against the codebase
- Missing error handling or edge cases that matter
- Under-engineered: shortcuts that will create tech debt
- Ambiguities that can be clarified from the codebase

Format: `[FIX] <summary> — <why it matters>`

**False Positive (push back)**
- Assumption that's actually correct (verified)
- Edge case that can't happen in this context
- "Over-engineered" flag on complexity that's genuinely needed

Format: `[FALSE POSITIVE] <summary> — <why it's wrong>`

**Deferrable (follow-up)**
- Nice-to-have improvements, not blockers
- Style preferences in the plan structure
- Over-engineered parts that work fine, just aren't minimal

Format: `[DEFER] <summary> — <why it can wait>`

**Needs Neil (can't resolve without human input)**
- Business requirements or product decisions
- Priority tradeoffs
- Integration points the reviewer can't verify

Format: `[ASK] <summary> — <question for Neil>`

## Phase 2: Fix

Address all `[FIX]` items directly in the plan using flicknote:

```
# Update a section
echo "updated content" | flicknote modify <id> --section <section-id>

# Append missing steps
echo "new content" | flicknote append <id>

# Insert before/after a section
echo "content" | flicknote insert <id> --after <section-id>
```

For each fix:
- Make the change in the flicknote plan
- Keep fixes minimal — address the issue, don't redesign the plan
- If a fix requires significant rewriting, recategorize it as `[ASK]` instead

## Phase 3: Report

```markdown
# Plan Triage: <plan title>

## Fixed
- [x] <issue> — <what was changed>

## False Positive
- [FALSE POSITIVE] <issue> — <why>

## Deferred
- [DEFER] <issue> — <why>

## Needs Neil
- [ASK] <issue> — <question>

## Verdict
**Ready / Needs Revision / Needs Rethink**
```

**Verdict rules:**
- **Ready** — all actionable items fixed, no `[ASK]` items remaining
- **Needs Revision** — has `[ASK]` items that need Neil's input before proceeding
- **Needs Rethink** — fundamental problems that small fixes can't address

### Post the Report

Post the triage report via `ttal comment add` so the plan-reviewer can see it and trigger re-review:

```
ttal comment add "<triage report markdown>"
```

Or via heredoc for multiline:

```
cat <<'TRIAGE' | ttal comment add
## Plan Triage: <plan title>
...
TRIAGE
```

This is required — don't just output the report inline. The comment system is how the review loop communicates.

## Turns

Triage is iterative. After Neil answers `[ASK]` items or a designer revises:

```
plan-review → plan-triage (round 1) → fix + ask
  → Neil answers / designer revises
plan-review → plan-triage (round 2) → fix
  → all clear
plan-triage (round 3) → ready
```

Include the **round number** in the header. Track how the verdict changed:
- **Ready** (was Needs Revision) — issues addressed
- **Needs Revision** (still) — issues weren't addressed
- **Needs Rethink** (was Needs Revision) — revision revealed deeper problems

If a plan is stuck for 2+ rounds, escalate to Neil rather than routing back again.

## Guidelines

- Fix what you can, ask about what you can't — don't block on things you can resolve yourself
- Keep fixes minimal — address the issue, don't redesign the plan
- Be objective — don't approve plans just because you fixed a few things
- Evaluate by impact, not by count — one critical gap beats five minor style issues

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.