AgentSkillsCN

haskell-programming-reviewer

擅长运用现代函数式编程范式对Haskell代码库进行审阅。致力于打造简洁、可组合的代码，确保强类型安全，提供完善的文档说明，并借助HLint、Haddock，以及（在适用情况下）Cabal/Stack等工具，严格遵循最佳实践。当用户寻求“反馈”、进行“审阅”，或希望“检查”其代码变更时使用。

SKILL.md
--- frontmatter
name: haskell-programming-reviewer
description: 'Expertise in reviewing Haskell codebases using modern functional programming idioms. It ensures clean, composable code; strong type safety; proper documentation; and adherence to best practices using tools such as HLint, Haddock, and (when relevant) Cabal/Stack conventions. Use when the user asks for "feedback," a "review," or to "check" their changes.'
applyTo: '**/{*.hs,*.lhs}'

Haskell Programming Reviewer

This skill specialises in reviewing Haskell codebases using modern functional programming idioms. It ensures clean, composable code; strong type safety; proper documentation; and adherence to best practices using tools such as HLint, Haddock, and (when relevant) Cabal/Stack conventions.

This skill enforces:

  • •Pure functional programming
  • •Clear function boundaries
  • •Small, composable definitions
  • •Proper type signatures
  • •Correct, structured documentation
  • •Clean-code principles appropriate for functional languages

Core Principles

Use "General Programming Review" guidelines as a base.

Coding Style

  • •Use 2 spaces for indentation.
  • •Limit lines to 80 characters.
  • •Use camelCase for variable and function names.
  • •Use PascalCase for type and data constructors.
  • •Use single characters for generic type variables (e.g., a, b, m).
  • •Use hlint to enforce style guidelines and suggest improvements.
  • •Use stylish-haskell for consistent formatting.
  • •All generated text output, including markdown content and descriptions, must adhere to an 80-column line limit. This applies to all content generated by the agent, not just code.

Functional Programming (FP) Foundations

  • •Encourage pure, total functions.
  • •Avoid partial functions (head, tail, fromJust, etc.) unless justified.
  • •Promote:
    • •higher-order functions (map, foldr, foldl', traverse, sequence)
    • •applicative/monadic patterns where appropriate
    • •function composition ((.)) and pipelines
    • •point-free style when it improves clarity
  • •Prefer algebraic data types and pattern matching.
  • •Encourage immutability and referential transparency.

Type Safety & Type System Usage

  • •Require explicit type signatures for top-level functions.
  • •Encourage:
    • •newtypes over type synonyms when providing semantic meaning
    • •sum types for branching logic rather than booleans or magic values
    • •record syntax for clarity
    • •deriving strategies (deriving stock, deriving newtype)
  • •Promote strong type design and small domain-specific types.

Clean Code & Architecture

  • •Functions should be small, focused, and composable.
  • •Modules should adhere to Single Responsibility Principle.
  • •Avoid:
    • •deeply nested pattern matches
    • •overly large case expressions
    • •unnecessary monad stacks
    • •mixing pure and effectful logic in the same function
  • •Prefer pure logic at the core and constrained effects at the boundaries.
  • •Suggest decomposition of complex monadic pipelines.

Documentation Standards (Haddock)

Every top-level function and type should include Haddock-style documentation:

  • •Summary description
  • •Parameter explanation via -- ^
  • •Return value description
  • •Example usage via >>>
  • •When applicable, document invariants and laws

Examples:

haskell
-- | Compute the average of a list of numbers.
average :: Fractional a => [a] -> a
average xs = sum xs / fromIntegral (length xs)