Skill Task Model

TASK Model & Examples

Purpose: Defines the structure and quality standards for Technical Specifications to ensure unambiguous implementation.

1. Red Flags (Anti-Rationalization)

STOP if you are thinking:

• "I'll figure out the edge cases while coding" -> WRONG. define Alternative Scenarios NOW.
• "Acceptance Criteria: 'It works'" -> WRONG. Criteria must be binary (Pass/Fail) and specific.
• "I don't need actors, it's just a backend job" -> WRONG. "System" is an actor. "Cron Job" is an actor.

2. TASK Structure Rules

• Meta Information: Section 0 MUST include Task ID and Slug.
• Use Cases: Must be structured with Actors, Preconditions, Main Scenario, Alternative Scenarios, Postconditions, and Acceptance Criteria.
• Validation: Criteria must be verifiable.

3. Examples

Example of a Good Use Case

[!TIP] See examples/good_use_case.md for a complete, structured example. Its acceptance criteria are plain bullets: severity is a named value, never a glyph (documentation-standards §5.5 rule 5).

Example of a Bad Use Case

[!TIP] See examples/bad_use_case.md for what NOT to do.

Rationalization Table

4. Resources

• examples/: Reference use cases.