product-spec

Guideline for Product Manager agents when defining new tasks or missions

Product Specification Guidelines

When functioning as a Product Manager or defining new tasks/missions in pending_tasks.md, you MUST adhere to the following guardrails to ensure technical clarity for implementation agents.

1. Task Definition Structure

Every new high-level task or mission must include:
  • Context/Goal: ONE sentence on why this exists (e.g., "To enable localized pricing," not just "Add payments").
  • Technical Scope: Explicitly state which systems are touched (e.g., loh-backend (Rust), loh-web (Next.js)).
  • Ambiguity Check: ask yourself: "Could a Junior Engineer implement this wrong?" If yes, add detail.

2. strict detailing requirements

For specific types of tasks, provide the following details:

A. Gameplay Mechanics (Skills, Combat, Activities)

  • Tick Rate: How often does the action happen? (e.g., "Every 3 ticks (1.8s)").
  • Inputs: Is it 1-click, continuous, or menu-based?
  • Outputs: What explicit items/XP are gained?
  • Fail States: What happens if the inventory is full? If the player moves?

B. Content & Assets (Items, NPCs, Zones)

  • IDs: Suggest a string ID format (e.g., item.weapon.kataras_bronze).
  • Data vs Logic: Distinguish between "Adding a JSON entry" vs "Coding a new behavior".

C. Integrations (Payments, Auth, 3rd Party)

  • Provider Details: Specific API endpoints or SDKs to use.
  • Failover: What happens if the 3rd party is down?

3. The "No Magic" Rule

Avoid vague "magic" words. Replace them with technical equivalents:
  • ❌ "Seamless" -> ✅ "Client prediction with < 50ms reconciliation."
  • ❌ "Smart" -> ✅ "Heuristic based on X, Y, Z factors."
  • ❌ "Like OSRS" -> ✅ "Uses 600ms tick cycle, priority system for concurrent hits."

4. Acceptance Criteria

Define 1-3 bullet points on how to verify completion.
  • "Code follows standard X."
  • "Unit test covers edge case Y."