82 lines
5.9 KiB
Markdown
82 lines
5.9 KiB
Markdown
# Agent Test Spec: community-manager
|
|
|
|
## Agent Summary
|
|
- **Domain**: Player-facing communications — patch notes text (player-friendly), social media post drafts, community update announcements, crisis communication response plans, bug triage and routing from player reports (not fixing)
|
|
- **Does NOT own**: Technical patch content (devops-engineer), QA verification and test execution (qa-lead), bug fixes (programmers), brand strategy direction (creative-director)
|
|
- **Model tier**: Sonnet
|
|
- **Gate IDs**: None; escalates brand voice conflicts to creative-director
|
|
|
|
---
|
|
|
|
## Static Assertions (Structural)
|
|
|
|
- [ ] `description:` field is present and domain-specific (references player communication, patch notes, community management)
|
|
- [ ] `allowed-tools:` list matches the agent's role (Read/Write for production/releases/patch-notes/ and communication drafts; no code or build tools)
|
|
- [ ] Model tier is Sonnet (default for operations specialists)
|
|
- [ ] Agent definition does not claim authority over technical content, QA strategy, or bug fixing
|
|
|
|
---
|
|
|
|
## Test Cases
|
|
|
|
### Case 1: In-domain request — patch notes for a bug fix
|
|
**Input**: "Write player-facing patch notes for this fix: 'JIRA-4821: Fixed NullReferenceException in InventoryManager.LoadSave() when save file was created on a previous version without the new equipment slot field.'"
|
|
**Expected behavior**:
|
|
- Produces a player-friendly patch note — no internal ticket IDs (JIRA-4821 is removed), no class names (InventoryManager.LoadSave()), no technical stack trace language
|
|
- Uses clear player-facing language: e.g., "Fixed a crash that could occur when loading save files created before the last update."
|
|
- Conveys the user impact (game crashed on load) without exposing internal implementation details
|
|
- Output is formatted for the project's patch notes style (bullet, or numbered, depending on established format)
|
|
|
|
### Case 2: Out-of-domain request — fixing a reported bug
|
|
**Input**: "A player reported that their save file is corrupted. Can you fix the save system?"
|
|
**Expected behavior**:
|
|
- Does not produce any code or attempt to diagnose the save system implementation
|
|
- Triages the report: acknowledges it as a potential bug affecting player data (high severity)
|
|
- Routes it: "This requires investigation by the appropriate programmer; I'm routing this to [gameplay-programmer or lead-programmer] for technical triage"
|
|
- Optionally drafts a player-facing acknowledgment post ("We're aware of reports of save corruption and are investigating") if requested
|
|
|
|
### Case 3: Community crisis — backlash over a game change
|
|
**Input**: "Players are angry about our latest patch. We nerfed a popular character's damage by 40% and the community is calling for a rollback. Forum posts, tweets, and Discord are all very negative."
|
|
**Expected behavior**:
|
|
- Produces a crisis communication response plan (not just a single tweet)
|
|
- Plan includes: (1) immediate acknowledgment post — acknowledge the feedback without being defensive; (2) timeline for developer response — commit to a specific timeframe for a design team statement; (3) developer statement template — explain the reasoning behind the nerf without dismissing player concerns; (4) follow-up structure — if rollback or adjustment is planned, communicate it with a timeline
|
|
- Does NOT commit to a rollback on behalf of the design team — flags this as a creative-director decision
|
|
- Tone is empathetic but not apologetic for intentional design decisions
|
|
|
|
### Case 4: Brand voice conflict in patch notes
|
|
**Input**: "Here is our patch note draft: 'We have annihilated the egregious framerate catastrophe that plagued the loading screen.' Our brand voice guide specifies: clear, warm, slightly humorous — not dramatic or hyperbolic."
|
|
**Expected behavior**:
|
|
- Identifies the conflict: "annihilated," "egregious," and "catastrophe" are dramatic/hyperbolic — inconsistent with the specified brand voice
|
|
- Does NOT approve the draft as-is
|
|
- Produces a revised version: e.g., "Fixed a performance issue that was causing the loading screen to run slowly — things should feel snappier now."
|
|
- Flags the inconsistency explicitly rather than silently rewriting without noting the problem
|
|
|
|
### Case 5: Context pass — using a brand voice document
|
|
**Input context**: Brand voice guide specifies: direct language, second-person ("you"), light humor is encouraged, avoid corporate jargon, game-specific slang from the in-world glossary is appropriate.
|
|
**Input**: "Write a social media post announcing a new hero character named Velk, a shadow assassin."
|
|
**Expected behavior**:
|
|
- Uses second-person address ("Meet your next favorite assassin")
|
|
- Incorporates light humor if it fits naturally
|
|
- Avoids corporate language ("We are pleased to announce" → "Meet Velk")
|
|
- Uses in-world language if the context includes a glossary (e.g., if assassins are called "Shadowwalkers" in-world, uses that term)
|
|
- Output matches the specified tone — not a generic press-release announcement
|
|
|
|
---
|
|
|
|
## Protocol Compliance
|
|
|
|
- [ ] Stays within declared domain (player-facing communication, patch note text, crisis response, bug routing)
|
|
- [ ] Strips internal IDs, class names, and technical jargon from all player-facing output
|
|
- [ ] Redirects bug fix requests to appropriate programmers rather than attempting technical solutions
|
|
- [ ] Does NOT commit to design rollbacks without creative-director authority
|
|
- [ ] Applies brand voice specifications from context; flags violations rather than silently accepting them
|
|
|
|
---
|
|
|
|
## Coverage Notes
|
|
- Case 1 (patch note sanitization) is the most frequently used behavior — test on every new patch cycle
|
|
- Case 3 (crisis communication) is a brand-safety test — verify the agent de-escalates rather than inflames
|
|
- Case 4 requires a brand voice document to be in context; test is incomplete without it
|
|
- Case 5 is the most important context-awareness test for tone consistency
|
|
- No automated runner; review manually or via `/skill-test`
|