agentleFS
Vinix24Vinix24/vnx-orchestration/skills/planner/SKILL.md

planner

Skill63 starsChanged 8 days agoMITView on GitHub

Planning specialist that breaks a VNX feature or track into small, independently-shippable PRs with dependencies and per-PR task-class routing. USE THIS when the user wants to break a feature down into PRs, sequence the work, or turn a plan into a PR queue. Delegated to by @horizon (formerly @pm — @pm still resolves via alias). Works from Horizon's tracks DB (`vnx horizon`, alias `vnx objective`); the repo FEATURE_PLAN.md is a generated generic example, not the source.

32 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use executor, review-plan and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MooseDesign1Skill

    executor

    Main executor agent. Triggered by /executor, or natural language such as: "build this feature", "execute the feature", "start building", "map the codebase", "scan the code", "resume building", "continue the build", "dev status", "where are we on development", "what's built". Do NOT trigger for /planner, /plan:project, /plan:feature, /plan:status, /product-designer, /pd:*, /ds-designer, /ds-*.

    Also in 3 projects that use this

  • JetBrainsSkill

    review-plan

    Manually re-run the autonomous plan review (Phase 2 — consistency + structural). The same review runs automatically as the first phase of /execute-tracks; this command is for re-runs after inline replanning or whenever the plan needs explicit re-validation. TRIGGER when: user asks to re-validate the plan after inline replanning; user requests explicit plan review outside /execute-tracks. SKIP: /execute-tracks already running State 0 in this session (autonomous Phase 2 path will fire) — do not double-run.

    Also in 3 projects that use this

  • tesla0225Skill

    orchestrator

    Issue/要件を受けたら分解→担当割当→実装→検証→統合を回す手順。未整備なら /repo-init でbootstrap。

    Also in 4 projects that use this

  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 3 projects that use this

  • SentrySkill

    skill-creator

    Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, writing, registration, and verification.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 5 are distinctive, and 10 are very specific to this project.

  • 0

    Common

    Most of the 27 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 10

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Ensure acyclic dependency graphs

    line 22
  2. Distinctive:

    Size Validation: Verify all PRs within 150-300 line constraint

    line 30
  3. Very specific:

    Rule of thumb: If a failing item should block the PR, make sure its wording triggers blocker classification.

    line 62
  4. Very specific:

    Every FEATURE_PLAN.md MUST follow this structure:

    line 66
  5. Very specific:

    PR headers: Must be ## PR-X: Title (exactly this format)

    line 104
  6. Very specific:

    Metadata fields: Use Field: Value format (bold markdown)

    line 105
  7. Very specific:

    Dependencies: Use [PR-1, PR-2] array format, [] for none

    line 106
  8. Very specific:

    Quality Gate section: Must be ### Quality Gate followed by backtick gate name

    line 107
  9. Very specific:

    Checklist items: Must use - [ ] format (markdown checkboxes)

    line 108
  10. Very specific:

    PR separator: Use --- between PRs

    line 109
  11. Very specific:

    Gate name: Use backtick format gate_prX_descriptive_name

    line 110
  12. Distinctive:

    Add 10% buffer for edge cases

    line 125
  13. Distinctive:

    Quality Gates as Deliverables: Every checklist item becomes a tracked open item

    line 153
  14. Very specific:

    Use scripts/intelligence.sh for accessing VNX intelligence patterns and solutions.

    line 160
  15. Distinctive:

    No exceptions. This must appear before any other content.

    line 172

“Common” is measured: kept by at least 6 in 10 of the 27 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Planning Specialist

Generate structured FEATURE_PLAN.md documents with PR-based breakdown for T0 orchestration.

Core Responsibilities

  • Break features into reviewable PRs (150-300 lines each)
  • Define clear PR dependencies and execution order
  • Map skills to specific PRs
  • Validate PR size constraints
  • Ensure acyclic dependency graphs
  • Write quality gates that become trackable deliverables (see Governance Model)

Planning Process

  1. Analyze Requirements: Break down into testable requirements
  2. PR Decomposition: Split into 150-300 line PRs with clear scope
  3. Skill Assignment: Map appropriate @skill to each PR
  4. Dependency Mapping: Define PR execution order (must be acyclic)
  5. Size Validation: Verify all PRs within 150-300 line constraint
  6. Quality Gates: Define verification criteria per PR using checklist format

Governance Model: Quality Gates as Deliverables

Quality gate items become open items once the track is imported. Each checklist item is tracked individually with a severity level. T0 (the orchestrator) is the sole authority for declaring work done — the performing terminal never auto-completes its own PR.

Flow:

FEATURE_PLAN.md quality gates
    → the open-items import carries the checklist items
    → creates open items (OI-PRx-001, OI-PRx-002, ...)
    → terminal executes work, receipt records evidence
    → T0 reviews evidence, closes satisfied items
    → all blockers/warns closed → PR complete

This means every quality gate item you write will be individually tracked. Write them to be:

  • Specific: "All 405 tests pass" not "Tests pass"
  • Measurable: Include numbers, thresholds, or binary criteria
  • Verifiable: T0 must be able to evaluate evidence against the criterion

Quality Gate Severity Classification

Items are classified by keywords:

SeverityKeywordsExample
blocker"all tests pass", "E2E", "100%", "test suite passes"- [ ] All tests pass
warn"memory", "zombie", "regression", ">=", "shutdown", "speed"- [ ] Memory profiling: no regression
infoDefault (anything else)- [ ] Dashboard shows accurate data

Rule of thumb: If a failing item should block the PR, make sure its wording triggers blocker classification.

FEATURE_PLAN.md Format (Required)

Every FEATURE_PLAN.md MUST follow this structure:

# Feature: [Feature Name]

## PR-1: [PR Title]
**Track**: A
**Priority**: P1
**Complexity**: Medium
**Risk**: Low
**Skill**: @backend-developer
**Estimated Time**: 2-3 hours
**Dependencies**: []

### Description
[What this PR does]

### Scope
- File changes listed here

### Success Criteria
- Criterion 1
- Criterion 2

### Quality Gate
`gate_pr1_descriptive_name`:
- [ ] All tests pass
- [ ] Specific measurable criterion
- [ ] Another verifiable criterion

---

## PR-2: [Next PR Title]
**Dependencies**: [PR-1]
...

Critical Format Rules

  1. PR headers: Must be ## PR-X: Title (exactly this format)
  2. Metadata fields: Use **Field**: Value format (bold markdown)
  3. Dependencies: Use [PR-1, PR-2] array format, [] for none
  4. Quality Gate section: Must be ### Quality Gate followed by backtick gate name
  5. Checklist items: Must use - [ ] format (markdown checkboxes)
  6. PR separator: Use --- between PRs
  7. Gate name: Use backtick format `gate_prX_descriptive_name`

Examples

  • /planner Create authentication system plan
  • "Use planner skill to break down the refactoring"
  • "Generate FEATURE_PLAN for the API redesign"

PR Size Guidelines

Target Range: 150-300 lines per PR

How to estimate:

  • Count modified/created files
  • Estimate lines per file (implementation + tests)
  • Include documentation updates
  • Add 10% buffer for edge cases

If PR exceeds 300 lines: Split into smaller, logical PRs If PR below 150 lines: Combine with related work

Skill Assignment

Available skills (use with @ prefix in FEATURE_PLAN, without @ in dispatches):

  • @backend-developer - Python/API implementation
  • @api-developer - REST API endpoints
  • @frontend-developer - UI components
  • @test-engineer - Testing infrastructure
  • @quality-engineer - Quality assurance and validation
  • @debugger - Issue investigation
  • @reviewer - Code review
  • @architect - System design
  • @security-engineer - Security hardening
  • @performance-profiler - Performance analysis
  • @python-optimizer - Code optimization
  • @supabase-expert - Database optimization
  • @data-analyst - Data analysis
  • @monitoring-specialist - Monitoring setup

Key Principles

  1. Small PRs: 150-300 lines for fast review cycles
  2. Clear Dependencies: Explicit prerequisite mapping (acyclic)
  3. Skill Alignment: Right expertise for each PR
  4. Size Validation: Estimate and verify line counts
  5. Quality Gates as Deliverables: Every checklist item becomes a tracked open item
  6. Specific & Measurable: Quality criteria must be evaluable by T0

Output Instructions

See template.md for report format and output location.

Intelligence Access

Use scripts/intelligence.sh for accessing VNX intelligence patterns and solutions.


Skill Activation Announcement

MANDATORY — first line of every response after skill load:

🔧 Skill actief: planner

No exceptions. This must appear before any other content.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.