{"title":"Implement Function from Spec","description":"Generate a single, well-tested function from a precise specification.","tags":["function","implementation","tdd"],"content":"Implement a {{language}} function named `{{name}}` that satisfies this specification:\n\n{{spec}}\n\nRequirements:\n- Handle all edge cases explicitly (empty input, nulls, boundaries, overflow).\n- No external dependencies unless I name them.\n- Add a short docstring describing parameters, return value, and thrown errors.\n- Follow idiomatic style and naming for {{language}}.\n\nAfter the implementation, list the edge cases you handled and any assumptions you made.","variables":[{"name":"language","description":"Programming language","required":true},{"name":"name","description":"Function name","required":true},{"name":"spec","description":"What the function must do","required":true}]}
{"title":"Add Feature to Existing Code","description":"Extend a codebase with a new feature while preserving existing behavior and conventions.","tags":["feature","integration"],"content":"I want to add the following feature: {{feature}}\n\nBefore writing code:\n1. Identify the files and functions that must change, and explain why.\n2. Describe how you'll keep existing behavior intact (and which tests prove it).\n3. Match the project's existing patterns, naming, and error-handling style.\n\nThen implement the change as a minimal, reviewable diff. Call out any place where the existing code made you choose between two reasonable approaches.","variables":[{"name":"feature","description":"The feature to add","required":true}]}
{"title":"Explain This Code","description":"Get a clear, layered explanation of an unfamiliar piece of code.","tags":["explain","onboarding","comprehension"],"content":"Explain the following code:\n\n```\n{{code}}\n```\n\nStructure your answer as:\n1. One sentence: what it does overall.\n2. A step-by-step walk-through of the control flow.\n3. Any non-obvious details — performance characteristics, side effects, edge cases, or subtle bugs.\n4. What a caller needs to know to use it correctly.\n\nAssume I'm a competent engineer new to this specific code.","variables":[{"name":"code","description":"The code to explain","required":true,"multiline":true}]}
{"title":"Convert Pseudocode to Code","description":"Translate an algorithm or pseudocode into working, idiomatic code.","tags":["algorithm","translation"],"content":"Translate the following pseudocode/algorithm into idiomatic {{language}}:\n\n{{pseudocode}}\n\n- Preserve the algorithm's complexity; note the Big-O of the result.\n- Use clear names; don't leave single-letter variables unless conventional.\n- Add input validation where a real caller could pass bad data.\n- Include a couple of usage examples.","variables":[{"name":"language","description":"Target language","required":true},{"name":"pseudocode","description":"The algorithm or pseudocode","required":true,"multiline":true}]}
{"title":"Implement an API Client","description":"Write a typed client for a REST or RPC API from its docs.","tags":["api","http","client"],"content":"Write a {{language}} client for this API:\n\n{{api_description}}\n\nRequirements:\n- Strong types for every request and response shape.\n- Centralized error handling that distinguishes network, 4xx, and 5xx failures.\n- Timeouts and a single, configurable retry policy for idempotent calls.\n- No secrets in code — read credentials from configuration/env.\n- A short usage example for the two most common calls.","variables":[{"name":"language","description":"Language/runtime","required":true},{"name":"api_description","description":"API endpoints and shapes","required":true}]}
{"title":"Add Robust Error Handling","description":"Harden a function or module against failure with deliberate error handling.","tags":["errors","resilience","validation"],"content":"Review the code below and add robust error handling:\n\n```\n{{code}}\n```\n\nFor each failure mode, decide deliberately: validate-and-reject, retry, fall back, or propagate. Then:\n- Validate inputs at the boundary; fail fast with actionable messages.\n- Never swallow errors silently — log or rethrow with context.\n- Distinguish expected failures (return/throw typed errors) from bugs (let them surface).\n- Keep the happy path readable; don't drown it in try/catch.\n\nShow the revised code and a one-line rationale per change.","variables":[{"name":"code","description":"The code to harden","required":true,"multiline":true}]}
{"title":"Write a CLI Command","description":"Build a command-line subcommand with argument parsing and good UX.","tags":["cli","ux","tooling"],"content":"Create a CLI command `{{command}}` in {{language}} that: {{behavior}}\n\nRequirements:\n- Parse flags and positional args with clear `--help` output.\n- Validate arguments and exit with a non-zero code and a useful message on error.\n- Support `--json` for machine-readable output where it makes sense.\n- Be quiet on success by default; add `--verbose` for detail.\n- Handle Ctrl+C cleanly.","variables":[{"name":"command","description":"Command name","required":true},{"name":"language","description":"Language/framework","required":true},{"name":"behavior","description":"What the command does","required":true}]}
{"title":"Concurrency-Safe Implementation","description":"Implement logic that is correct under concurrent access.","tags":["concurrency","threads","async"],"content":"Implement the following with correct behavior under concurrency: {{task}}\n\nIn {{language}}:\n- Identify the shared state and the exact invariants that must hold.\n- Choose the simplest correct synchronization (immutability > message passing > locks).\n- Avoid deadlocks and races; explain why your choice is free of both.\n- Note the performance trade-off you made.\n\nProvide the code plus a short paragraph on how it behaves under contention.","variables":[{"name":"language","description":"Language/runtime","required":true},{"name":"task","description":"The concurrent task","required":true}]}
{"title":"Design a Regular Expression","description":"Build and explain a regex for a specific matching task.","tags":["regex","parsing"],"content":"Write a regular expression that matches: {{requirement}}\n\nProvide the pattern in {{flavor}} syntax, a plain-language breakdown of each part, 3 strings it SHOULD match and 3 it should NOT, and a note on any catastrophic-backtracking risk and how to avoid it. Prefer readability (named groups) over cleverness.","variables":[{"name":"requirement","description":"What the regex must match","required":true},{"name":"flavor","description":"Regex flavor (PCRE, JS, Python)","required":true,"enum":["PCRE","JavaScript","Python","Go","Java",".NET","Rust","RE2"]}]}
{"title":"Choose a Data Structure","description":"Pick the right data structure for an access pattern.","tags":["data-structures","performance"],"content":"I need to store and access data like this: {{access_pattern}}\n\nRecommend the data structure. Compare the 2-3 viable candidates on the operations I care about (insert, lookup, delete, iterate, ordered) with their Big-O. State the memory trade-off and which one wins for MY pattern. Flag the structure people reach for by habit that would be wrong here.","variables":[{"name":"access_pattern","description":"How the data is written and read","required":true}]}
{"title":"Implement a State Machine","description":"Model a process as an explicit finite state machine.","tags":["state-machine","modeling"],"content":"Model this as a state machine: {{process}}\n\nDefine the states, the events/transitions between them, and the actions on each transition. Make illegal transitions impossible to represent. Implement it in {{language}} with a clear transition table or typed states. Call out the states that are easy to forget: error, timeout, cancelled.","variables":[{"name":"process","description":"The process to model","required":true},{"name":"language","description":"Target language","required":true}]}
{"title":"Add a Caching Layer","description":"Introduce caching to a hot path correctly.","tags":["caching","performance"],"content":"I want to cache: {{what}}\n\nDesign the cache: the key, what to store, the eviction policy, and the TTL. Critically, define the INVALIDATION strategy: when does cached data go stale and how is it refreshed? Handle the cache-stampede and stale-read cases. Tell me how I will measure hit rate and whether this cache is even worth it.","variables":[{"name":"what","description":"What you want to cache","required":true}]}
{"title":"Optimize a Hot Path","description":"Make a performance-critical piece of code faster.","tags":["performance","optimization"],"content":"This code is on a hot path and too slow:\n\n{{code}}\n\nProfile it in your head first: what is the dominant cost (allocations, repeated work, I/O, bad complexity)? Propose the change with the highest payoff, not micro-tweaks. Show the optimized version, state the new complexity or the work removed, and confirm behavior is unchanged. Warn me if the speedup trades away readability or correctness, and tell me how to measure that it actually helped.","variables":[{"name":"code","description":"The slow code","required":true,"multiline":true}]}
{"title":"Implement Pagination","description":"Add correct pagination to a list endpoint or query.","tags":["pagination","api"],"content":"I need to paginate: {{what}}\n\nRecommend cursor-based or offset-based for my case and say why. Show the implementation: the page size, how the cursor or offset is encoded, how the client asks for the next page, and how the last page is detected. Handle the edge cases: items inserted or deleted mid-iteration, an invalid cursor, and an empty result. Note the stability and performance trade-off of the choice.","variables":[{"name":"what","description":"What you are paginating","required":true}]}
{"title":"Write a Parser","description":"Parse a structured text format into a usable structure.","tags":["parsing","format"],"content":"Write a parser for this format: {{format}}\n\nDefine the grammar or structure first, then implement it in {{language}}. Decide between a hand-written recursive-descent parser and a regex/split approach, and justify it. Produce clear errors with position info on malformed input rather than silently misparsing. Cover the tricky cases: nesting, escaping, whitespace, and empty input. Include a couple of example inputs and their parsed output.","variables":[{"name":"format","description":"The format to parse","required":true},{"name":"language","description":"Target language","required":true}]}
{"title":"Validate Untrusted Input","description":"Validate and sanitize input at a trust boundary.","tags":["validation","security"],"content":"This input crosses a trust boundary: {{input}}\n\nWrite validation that rejects anything that isn't explicitly allowed (allow-list, not deny-list). Define the shape, types, ranges, and formats that are valid, and the exact error for each violation. Normalize before comparing. Cover the attack-shaped cases: oversized, malformed, injection, and unexpected encodings. Tell me what to do on failure (reject vs coerce) and why reject is usually right here.","variables":[{"name":"input","description":"The untrusted input","required":true}]}