Planning - Design Before Code

SkillFiles & storage

The planning skill is a structured workflow that makes an AI agent design a coding task before writing any code. It is meant for non-trivial features, refactors, and multi-file changes, and it walks the agent through understanding the problem, proposing approaches, building an ordered implementation plan, and then executing it task by task. The agent must get your approval before any code is written.

Then ask your AI: use the Planning - Design Before Code skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Have a non-trivial feature, refactor, or multi-file change you want planned before code is written.

What your AI can do with it

  • Reads relevant code, schemas, and tests before proposing any change
  • Presents two or three approaches with pros, cons, files affected, and risk
  • Builds an ordered implementation plan with exact file paths and verification commands
  • Orders tasks by dependency, with schema changes before model generation
  • Stops to discuss blockers instead of deviating from the approved plan
  • Runs a final verification task over all relevant tests

Getting started

  1. Have a non-trivial feature, refactor, or multi-file change you want planned before code is written.
  2. Invoke the skill with a description of the feature or task as its argument.
  3. Answer the clarifying questions the agent asks, one at a time.
  4. Review the proposed approaches and approve one before the agent proceeds.
  5. Work through the ordered plan task by task and run the final verification.

What this skill tells your AI

The instructions your AI receives, as published by open-metadata/openmetadata in skills/planning/SKILL.md and read by Ahel’s review.

Structured workflow for planning implementation before writing code. Prevents wasted effort from diving in without a clear direction.

When to Use

  • New features spanning multiple files or modules
  • Refactors touching backend, frontend, or ingestion layers
  • Bug fixes where the root cause is unclear
  • Any task where the approach isn't immediately obvious

Workflow

Phase 1: Understand the Problem

  1. Read before suggesting. Explore the relevant code, schemas, and tests. Do not propose changes to code you haven't read.
  2. Ask clarifying questions one at a time. Don't dump a list of 10 questions.
  3. Identify constraints:
    • Which layers are affected? (Java backend, React frontend, Python ingestion, JSON schemas)
    • Are there existing patterns to follow? (Check similar implementations)
    • Database migration needed? (Flyway in bootstrap/sql/migrations/)
    • Schema changes needed? (openmetadata-spec/ JSON schemas)

Phase 2: Propose Approaches

Present 2-3 approaches with trade-offs:

## Approach A: [Name]
- How it works: [1-2 sentences]
- Pros: [bullet list]
- Cons: [bullet list]
- Files affected: [list]
- Risk: [low/medium/high]

## Approach B: [Name]
...

## Recommendation: [A or B] because [reason]

Wait for user approval before proceeding.

Phase 3: Create Implementation Plan

Once an approach is approved, break it into ordered tasks:

  1. Each task should be completable in a single focused step
  2. Each task must specify:
    • Exact file paths to create or modify
    • What changes to make (not vague descriptions)
    • Verification command (test to run, build to check)
  3. Order tasks by dependency — schema changes before model generation, backend before frontend
  4. Include a final verification task that runs all relevant tests

OpenMetadata task ordering pattern:

1. JSON Schema changes (openmetadata-spec/)
2. Run: make generate (regenerate Pydantic models)
3. Java backend changes (openmetadata-service/)
4. Run: mvn spotless:apply && mvn test-compile
5. Python ingestion changes (ingestion/)
6. Run: cd ingestion && make py_format && make py_format_check && make unit_ingestion_dev_env
7. Frontend changes (openmetadata-ui/.../ui/)
8. Run: yarn lint && yarn test
9. Database migrations if needed (bootstrap/sql/)
10. Full verification: mvn test or relevant integration tests

Phase 4: Execute

  • Work through the plan task by task
  • Mark each task complete as you finish it
  • If you hit a blocker, stop and discuss — don't silently deviate from the plan
  • After all tasks complete, run the final verification

Rules

  • Never skip Phase 2. Even if the approach seems obvious, stating it gets alignment.
  • No placeholder code. Every step in the plan must describe real, complete changes.
  • Schema-first. If the feature touches data models, start with JSON Schema changes in openmetadata-spec/.
  • User approves before code. Don't write code until the plan is approved.

Signals

GitHub stars
15k
Forks
2k
Last commit
Oct 2026

Questions

Does it write code before I approve the approach?
No. It waits for your approval of one of the proposed approaches before creating the implementation plan, and no code is written until then.
What happens if the agent hits a blocker mid-plan?
It stops and discusses the blocker with you rather than silently deviating from the approved plan.
Advanced
Item type
skill
Key
planning-open-metadata
Source
github.com/open-metadata/openmetadata