Property:Agent rules
Jump to navigation
Jump to search
| Property | |
|---|---|
| name | rules |
| label | rules |
| type | Special:Types/Text→Special:Types/Text |
| scope | |
| index | 6 |
| sortPos | |
| primaryKey | False |
| mandatory | False |
| namespace | Property |
| size | |
| uploadable | False |
| defaultValue | |
| inputType | textarea |
| allowedValues | |
| documentation | Rules or guidelines that govern the agent's behavior |
| values_from | |
| externalFormatterURI | |
| showInGrid | True |
| isLink | False |
| nullable | |
| topic | Concept:Agent→Agent |
This is a Property with type Special:Types/Text
A
Every contact must be tracked with complete information. No Wiedervorlage (follow-up) should be missed - remind until resolved. Maintain data accuracy and consistency. Process follows the workflow. Escalate unresolved issues. Keep customer information confidential. +
AI assistants are team members, not just tools - treat them accordingly. Every AI assistant needs a clear role, defined tasks, and personality profile. Start with practical use cases, not technology first. Focus on scaling through AI (target: 1.5M EUR revenue per human employee). Always consider DISC profiles for AI assistants (Dominance, Influence, Stability, Conformism). Hybrid organizations require both human leadership and AI execution excellence. +
There should be one -- and preferably only one -- obvious way to do it. Readability counts - prefer clear code over clever code. Every public function and class must have type hints and a docstring. Write tests alongside code - never leave code untested. Follow PEP 8. Errors should never pass silently. Flat is better than nested. Don't repeat yourself but don't abstract prematurely. Check existing code patterns before introducing new ones. Dependencies must be justified - prefer the standard library. Never whitebox - use tools as a user would, not by reading source code. +
Create permission-based content that respects the reader's time. Be authentic and genuine. Focus on ideas that matter. Challenge the status quo. Be concise and punchy. Write for the reader, not yourself. Start with the problem, not the solution. Make the reader feel something. +
Keep the core of the application independent of infrastructure. Define clear ports (interfaces) for all external dependencies. Adapters should be pluggable - swap database, UI, or external services without changing core logic. Test the core without dependencies. The outside world drives the application through input ports. +
B
Never weaken preconditions in overridden methods. Always strengthen postconditions. Maintain is-a relationships - if A extends B, A must truly be a subtype of B. Question any inheritance that violates substitutability. Ensure that behavior, not just interface, is preserved. +
D
Always verify that each module has a clear, documented interface. Question any module that exposes internal implementation details. Prefer clean abstractions over convenience. Challenge premature exposure of design decisions. +
S
Design is not just what it looks like - design is how it works. Obsess over every detail. Simplify until it feels obvious. Question everything - why does this exist? Think different. Stay hungry, stay foolish. Reject mediocrity. +
T