Skip to content
Agentmart
Submit a tool
This entry duplicates planning, which is the one we list in search.

planning

Use when starting a non-trivial feature, refactor, or multi-file change.

Skill by Jason-Clark-FG

IndexedApache-2.0
Write a review

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/jason-clark-fg-planning

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Use when starting a non-trivial feature, refactor, or multi-file change. Forces structured design thinking before writing any code - brainstorm approaches, get approval, then create a step-by-step implementation plan.

Use cases: design, writing

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions: not checked yet.

What's inside

Skill name
planning
Description
Use when starting a non-trivial feature, refactor, or multi-file change. Forces structured design thinking before writing any code - brainstorm approaches, get approval, then create a step-by-step implementation plan.
License
Apache-2.0
Instructions
84 lines in SKILL.md · view on GitHub

Files (1)

  • SKILL.md

SKILL.md (first lines)

# Planning - Design Before Code

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

For Python changes, use the locked Nox sessions through Make from the checkout root:
`make unit_ingestion ARGS="-n 0 tests/unit/PATH"`.
Include lock validation with the pinned `ingestion/.nox/bootstrap/bin/uv lock --check --project ingestion`.
When generation inputs change, include `make generate ARGS=--python-only` and
`python3 scripts/check_generated_models.py --check`. Preserve public aliases and
intentional test exclusions when migrating command callers.

**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.

From Jason-Clark-FG/OpenMetadata-Mirror, Apache-2.0.

Signals

Stars
0
Forks
0
Open issues
0
Last commit (this folder)
Apr 28, 2026 (6 months ago)

From GitHub (fetched Oct 24, 2026).

Details

License
Apache-2.0
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

Same skill elsewhere

Copies of this SKILL.md published by others; search shows only one of them.

Cite this page

planning skill. Agent Mart. https://agentmart.dev/skills/jason-clark-fg-planning (last updated 2026-10-24)