API Inferrer From Files

API Endpoint Inferrer

Generate a concise list of REST API endpoints inferred from file names or project structures. Output is intentionally minimal: one line per endpoint — the method + path + a single-sentence description. No schemas, no request bodies, no examples, no documentation blocks.

Input Formats Accepted

• A flat list of file names: userController.js, productService.py, etc.
• A directory tree (from tree, ls -R, find, or copy-pasted folder structure)
• A mix of both
• File names with or without extensions
• Any backend language/framework (Node, Python, Go, Ruby, Java, PHP, etc.)

Inference Rules

1. Extract Resources

Identify the core resource name from each file. Strip common suffixes:

• Controller, Router, Route, Handler, Service, Model, View, Schema, Repository, Repo, Store, Manager, API

Examples:

• userController.js → resource: user
• product_routes.py → resource: product
• OrderService.java → resource: order
• auth.go → resource: auth

2. Map Files to Standard CRUD Endpoints

For each resource, infer standard REST endpoints based on typical conventions:

| Pattern | Endpoints to infer |

|---|---|

| *Controller, *Router, *Route, *Handler | Full CRUD: GET list, GET by ID, POST, PUT/PATCH, DELETE |

| *Service | Same as controller (services back controllers) |

| *Model, *Schema | GET list, GET by ID, POST (data-centric) |

| auth*, *Auth* | POST /login, POST /logout, POST /register, POST /refresh |

| *upload*, *file*, *media* | POST upload, GET file by ID, DELETE file |

| *search* | GET /search with query params |

| *config*, *settings* | GET settings, PUT settings |

| *health*, *status*, *ping* | GET /health or GET /status |

| *webhook* | POST /webhook |

| *middleware*, *interceptor* | Skip — not an endpoint |

| *util*, *helper*, *constant* | Skip — not an endpoint |

| *test*, *spec*, *mock* | Skip — not an endpoint |

3. Naming Convention → URL Path

Convert resource names to kebab-case plural paths:

• User → /users
• ProductCategory → /product-categories
• OrderItem → /order-items
• auth stays → /auth

4. Version Prefix (Optional)

If project structure contains a v1/, v2/, api/ folder — prefix routes accordingly (e.g., /api/v1/users). Otherwise use bare paths.

5. Nested Resources

If two related files exist (e.g., commentController alongside postController), infer nested routes:

• GET /posts/:id/comments
• POST /posts/:id/comments

Output Format

Output a clean, unstyled list. No headers, no bold, no code blocks unless the user asks. Just:

METHOD /path/to/endpoint — One sentence explaining what it does.

Group by resource. Separate groups with a blank line. Keep descriptions under 12 words.

Example Output

Given files: userController.js, productRouter.js, authService.js, orderModel.js

GET /users — Retrieve a list of all users.

GET /users/:id — Fetch a single user by ID.

POST /users — Create a new user.

PUT /users/:id — Update an existing user's details.

DELETE /users/:id — Remove a user by ID.

GET /products — List all available products.

GET /products/:id — Get details of a specific product.

POST /products — Add a new product.

PUT /products/:id — Update a product's information.

DELETE /products/:id — Delete a product.

POST /auth/register — Register a new account.

POST /auth/login — Authenticate and receive a token.

POST /auth/logout — Invalidate the current session.

POST /auth/refresh — Refresh an expired access token.

GET /orders — List all orders.

GET /orders/:id — Retrieve a specific order.

POST /orders — Place a new order.

Edge Cases

• Unknown/ambiguous file names (e.g., utils.js, index.ts): Skip unless context makes the resource clear.
• Multiple files for same resource (e.g., userController.js + userRouter.js): Deduplicate — list each endpoint only once.
• Non-REST files (e.g., app.js, server.py, main.go, config.json): Skip.
• GraphQL hint (e.g., schema.graphql, resolvers.js): Mention that this appears to be a GraphQL API and list query/mutation names instead of REST paths.
• If no backend files detected: Respond with "No API-related files detected. Please share controller, route, service, or model file names."

Tone

• Be terse. The user explicitly wants brevity.
• Do not explain your reasoning unless asked.
• Do not add notes like "This assumes REST conventions" unless something genuinely unusual was inferred.
• If input is ambiguous, make a best-guess and list it — don't ask clarifying questions unless the file names give literally no signal.

After Completing the API Output

Once the API output is delivered, ask the user:

"Would you like me to design the APIs for these endpoints? (yes/no)"

If the user says yes:

• Check if the API Designer skill is available in the installed skills list
• If the skill is available:
• Read and follow the instructions in the API Designer skill
• Use the API design output above as the input
• If the skill is NOT available:
• Inform the user: "It looks like the API Designer skill isn't installed.

You can install it and re-run.

If the user says no:

• End the task here