goddard-app-feature-planner

Plan Goddard app features grounded in spec and architecture.

Updated Mar 2, 2026
One-click install
npx skills add https://github.com/goddard-ai/goddard --skill goddard-app-feature-planner
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: goddard-app-feature-planner
Source: https://github.com/goddard-ai/goddard/tree/main/app/.agents/skills/goddard-app-feature-planner
Command: npx skills add https://github.com/goddard-ai/goddard --skill goddard-app-feature-planner

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Teams planning Goddard app features often drift from the current spec and architecture, leading to inconsistent plans and missed dependencies. This Skill enforces plan creation that stays aligned with the spec, glossary, and planning docs, and clearly marks MVP, deferred work, and blockers.

Core Features & Use Cases

  • Plan new features by grounding them in the current app spec and architecture.
  • Reconcile proposed changes with existing state modules, components, and constraints.
  • Identify required plan files, MVP scope, and follow-on work.

Quick Start

Plan a new feature by drafting a plan that references the latest spec and glossary and notes MVP and blockers.

Frequently Asked Questions about goddard-app-feature-planner

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I plan app features grounded in existing spec and architecture?

Feature planning prevents drift from current architecture by enforcing alignment with spec, glossary, and planning docs. It reconciles proposed changes against state modules and dependencies, clearly marking MVP, deferred, or blocked work to avoid missed dependencies.

How do I map dependencies across spec, glossary, and planning docs?

To mark MVP and deferred work in feature plans, apply the proposed feature to app constraints and MVP scope. The plan must explicitly categorize work items as MVP, deferred, or blocked while cross-referencing the relevant state modules and components.

What is the best way to reconcile new features with existing state modules and components?

Feature planning requires a current app spec, architecture, and glossary to ground the proposed changes. Without these foundational planning docs, the process cannot accurately map dependencies or reconcile constraints against the existing state modules.

Why does feature planning drift from the current spec and architecture?

When feature planning misses dependencies, it typically means the plan was not applied to the current app constraints and dependency mapping across spec, glossary, and planning docs. Ensuring explicit references to state modules and components resolves this.