fp-add

Add a new feature or suite to the E2E spec and generate corresponding tests

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "fp-add" with this command: npx skills add endorhq/flightplanner/endorhq-flightplanner-fp-add

Add E2E Test

Context-aware command that adds a new feature or suite to the E2E spec and generates corresponding tests. Automatically detects whether to add to an existing suite or create a new one.

Additional instructions from the user: "$ARGUMENTS". Ignore if empty.

Phase 1: Discover Context

  1. Find all E2E_TESTS.md files in the project.
  2. Read them to understand existing suites and features.
  3. Find existing E2E test files and read them to understand patterns.
  4. Analyze the user's request ($ARGUMENTS) to determine:
    • Is this a new suite or an addition to an existing suite?
    • What category does this feature belong to? (core/edge/error/side-effect/idempotency)
    • What preconditions are needed?
    • What assertions should be verified?

Phase 2: Determine Scope

If adding to an existing suite:

  1. Identify the target suite from the user's description.
  2. Check for conflicts with existing features (no duplicate names).
  3. Draft the new feature entry in the spec format.

If creating a new suite:

  1. Analyze the relevant source code to understand:
    • What the feature does
    • What external dependencies it has
    • What states and error conditions exist
  2. Draft a complete suite with these sections, using heading levels appropriate to their nesting depth (e.g., if the suite is an H2, then these sections are H3; if the suite is an H3, they are H4; and so on):
    • Preconditions (heading with bullet list)
    • Features (heading) containing individual features as flat peer subheadings one level deeper (do NOT create intermediate category headings — categories are specified only via <!-- category: ... --> HTML comments), across multiple categories (at minimum: core + error)
    • Postconditions (heading with bullet list)
  3. Determine which E2E_TESTS.md file to add it to (or create a new one).

Phase 3: Update Spec

  1. Present the draft spec entry to the user for review.
  2. Ask the user if they want to adjust anything.
  3. Add the approved entry to the appropriate E2E_TESTS.md file:
    • For existing suites: add under the ### Features section
    • For new suites: add as a new ## section and add a link to the new suite in the Index section at the top of the file

Phase 4: Generate Tests

  1. If adding to an existing suite:

    • Read the existing test file
    • Add new test cases for the new features (e.g., it() blocks in vitest/jest)
    • Follow the existing patterns in that file exactly
  2. If creating a new suite:

    • Create a new test file following the project's conventions
    • Include autogenerated header/footer
    • Implement all features from the spec
  3. Run the tests to verify they pass.

  4. Run the project's formatter on modified/created files.

  5. Present a summary of changes made.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

fp-init

No summary provided by upstream source.

Repository SourceNeeds Review
General

fp-fix

No summary provided by upstream source.

Repository SourceNeeds Review
General

fp-update

No summary provided by upstream source.

Repository SourceNeeds Review
General

fp-smoke-test

No summary provided by upstream source.

Repository SourceNeeds Review