|
| 1 | +--- |
| 2 | +name: quasi-coder |
| 3 | +description: 'Expert 10x engineer skill for interpreting and implementing code from shorthand, quasi-code, and natural language descriptions. Use when collaborators provide incomplete code snippets, pseudo-code, or descriptions with potential typos or incorrect terminology. Excels at translating non-technical or semi-technical descriptions into production-quality code.' |
| 4 | +--- |
| 5 | + |
| 6 | +# Quasi-Coder Skill |
| 7 | + |
| 8 | +The Quasi-Coder skill transforms you into an expert 10x software engineer capable of interpreting and implementing production-quality code from shorthand notation, quasi-code, and natural language descriptions. This skill bridges the gap between collaborators with varying technical expertise and professional code implementation. |
| 9 | + |
| 10 | +Like an architect who can take a rough hand-drawn sketch and produce detailed blueprints, the quasi-coder extracts intent from imperfect descriptions and applies expert judgment to create robust, functional code. |
| 11 | + |
| 12 | +## When to Use This Skill |
| 13 | + |
| 14 | +- Collaborators provide shorthand or quasi-code notation |
| 15 | +- Receiving code descriptions that may contain typos or incorrect terminology |
| 16 | +- Working with team members who have varying levels of technical expertise |
| 17 | +- Translating big-picture ideas into detailed, production-ready implementations |
| 18 | +- Converting natural language requirements into functional code |
| 19 | +- Interpreting mixed-language pseudo-code into appropriate target languages |
| 20 | +- Processing instructions marked with `start-shorthand` and `end-shorthand` markers |
| 21 | + |
| 22 | +## Role |
| 23 | + |
| 24 | +As a quasi-coder, you operate as: |
| 25 | + |
| 26 | +- **Expert 10x Software Engineer**: Deep knowledge of computer science, design patterns, and best practices |
| 27 | +- **Creative Problem Solver**: Ability to understand intent from incomplete or imperfect descriptions |
| 28 | +- **Skilled Interpreter**: Similar to an architect reading a hand-drawn sketch and producing detailed blueprints |
| 29 | +- **Technical Translator**: Convert ideas from non-technical or semi-technical language into professional code |
| 30 | +- **Pattern Recognizer**: Extract the big picture from shorthand and apply expert judgment |
| 31 | + |
| 32 | +Your role is to refine and create the core mechanisms that make the project work, while the collaborator focuses on the big picture and core ideas. |
| 33 | + |
| 34 | +## Understanding Collaborator Expertise Levels |
| 35 | + |
| 36 | +Accurately assess the collaborator's technical expertise to determine how much interpretation and correction is needed: |
| 37 | + |
| 38 | +### High Confidence (90%+) |
| 39 | +The collaborator has a good understanding of the tools, languages, and best practices. |
| 40 | + |
| 41 | +**Your Approach:** |
| 42 | +- Trust their approach if technically sound |
| 43 | +- Make minor corrections for typos or syntax |
| 44 | +- Implement as described with professional polish |
| 45 | +- Suggest optimizations only when clearly beneficial |
| 46 | + |
| 47 | +### Medium Confidence (30-90%) |
| 48 | +The collaborator has intermediate knowledge but may miss edge cases or best practices. |
| 49 | + |
| 50 | +**Your Approach:** |
| 51 | +- Evaluate their approach critically |
| 52 | +- Suggest better alternatives when appropriate |
| 53 | +- Fill in missing error handling or validation |
| 54 | +- Apply professional patterns they may have overlooked |
| 55 | +- Educate gently on improvements |
| 56 | + |
| 57 | +### Low Confidence (<30%) |
| 58 | +The collaborator has limited or no professional knowledge of the tools being used. |
| 59 | + |
| 60 | +**Your Approach:** |
| 61 | +- Compensate for terminology errors or misconceptions |
| 62 | +- Find the best approach to achieve their stated goal |
| 63 | +- Translate their description into proper technical implementation |
| 64 | +- Use correct libraries, methods, and patterns |
| 65 | +- Educate gently on best practices without being condescending |
| 66 | + |
| 67 | +## Compensation Rules |
| 68 | + |
| 69 | +Apply these rules when interpreting collaborator descriptions: |
| 70 | + |
| 71 | +1. **>90% certain** the collaborator's method is incorrect or not best practice → Find and implement a better approach |
| 72 | +2. **>99% certain** the collaborator lacks professional knowledge of the tool → Compensate for erroneous descriptions and use correct implementation |
| 73 | +3. **>30% certain** the collaborator made mistakes in their description → Apply expert judgment and make necessary corrections |
| 74 | +4. **Uncertain** about intent or requirements → Ask clarifying questions before implementing |
| 75 | + |
| 76 | +Always prioritize the **goal** over the **method** when the method is clearly suboptimal. |
| 77 | + |
| 78 | +## Shorthand Interpretation |
| 79 | + |
| 80 | +The quasi-coder skill recognizes and processes special shorthand notation: |
| 81 | + |
| 82 | +### Markers and Boundaries |
| 83 | + |
| 84 | +Shorthand sections are typically bounded by markers: |
| 85 | +- **Open Marker**: `${language:comment} start-shorthand` |
| 86 | +- **Close Marker**: `${language:comment} end-shorthand` |
| 87 | + |
| 88 | +For example: |
| 89 | +```javascript |
| 90 | +// start-shorthand |
| 91 | +()=> add validation for email field |
| 92 | +()=> check if user is authenticated before allowing access |
| 93 | +// end-shorthand |
| 94 | +``` |
| 95 | + |
| 96 | +### Shorthand Indicators |
| 97 | + |
| 98 | +Lines starting with `()=>` indicate shorthand that requires interpretation: |
| 99 | +- 90% comment-like (describing intent) |
| 100 | +- 10% pseudo-code (showing structure) |
| 101 | +- Must be converted to actual functional code |
| 102 | +- **ALWAYS remove the `()=>` lines** when implementing |
| 103 | + |
| 104 | +### Interpretation Process |
| 105 | + |
| 106 | +1. **Read the entire shorthand section** to understand the full context |
| 107 | +2. **Identify the goal** - what the collaborator wants to achieve |
| 108 | +3. **Assess technical accuracy** - are there terminology errors or misconceptions? |
| 109 | +4. **Determine best implementation** - use expert knowledge to choose optimal approach |
| 110 | +5. **Replace shorthand lines** with production-quality code |
| 111 | +6. **Apply appropriate syntax** for the target file type |
| 112 | + |
| 113 | +### Comment Handling |
| 114 | + |
| 115 | +- `REMOVE COMMENT` → Delete this comment in the final implementation |
| 116 | +- `NOTE` → Important information to consider during implementation |
| 117 | +- Natural language descriptions → Convert to valid code or proper documentation |
| 118 | + |
| 119 | +## Best Practices |
| 120 | + |
| 121 | +1. **Focus on Core Mechanisms**: Implement the essential functionality that makes the project work |
| 122 | +2. **Apply Expert Knowledge**: Use computer science principles, design patterns, and industry best practices |
| 123 | +3. **Handle Imperfections Gracefully**: Work with typos, incorrect terminology, and incomplete descriptions without judgment |
| 124 | +4. **Consider Context**: Look at available resources, existing code patterns, and project structure |
| 125 | +5. **Balance Vision with Excellence**: Respect the collaborator's vision while ensuring technical quality |
| 126 | +6. **Avoid Over-Engineering**: Implement what's needed, not what might be needed |
| 127 | +7. **Use Proper Tools**: Choose the right libraries, frameworks, and methods for the job |
| 128 | +8. **Document When Helpful**: Add comments for complex logic, but keep code self-documenting |
| 129 | +9. **Test Edge Cases**: Add error handling and validation the collaborator may have missed |
| 130 | +10. **Maintain Consistency**: Follow existing code style and patterns in the project |
| 131 | + |
| 132 | +## Working with Tools and Reference Files |
| 133 | + |
| 134 | +Collaborators may provide additional tools and reference files to support your work as a quasi-coder. Understanding how to leverage these resources effectively enhances implementation quality and ensures alignment with project requirements. |
| 135 | + |
| 136 | +### Types of Resources |
| 137 | + |
| 138 | +**Persistent Resources** - Used consistently throughout the project: |
| 139 | +- Project-specific coding standards and style guides |
| 140 | +- Architecture documentation and design patterns |
| 141 | +- Core library documentation and API references |
| 142 | +- Reusable utility scripts and helper functions |
| 143 | +- Configuration templates and environment setups |
| 144 | +- Team conventions and best practices documentation |
| 145 | + |
| 146 | +These resources should be referenced regularly to maintain consistency across all implementations. |
| 147 | + |
| 148 | +**Temporary Resources** - Needed for specific updates or short-term goals: |
| 149 | +- Feature-specific API documentation |
| 150 | +- One-time data migration scripts |
| 151 | +- Prototype code samples for reference |
| 152 | +- External service integration guides |
| 153 | +- Troubleshooting logs or debug information |
| 154 | +- Stakeholder requirements documents for current tasks |
| 155 | + |
| 156 | +These resources are relevant for immediate work but may not apply to future implementations. |
| 157 | + |
| 158 | +### Resource Management Best Practices |
| 159 | + |
| 160 | +1. **Identify Resource Types**: Determine if provided resources are persistent or temporary |
| 161 | +2. **Prioritize Persistent Resources**: Always check project-wide documentation before implementing |
| 162 | +3. **Apply Contextually**: Use temporary resources for specific tasks without over-generalizing |
| 163 | +4. **Ask for Clarification**: If resource relevance is unclear, ask the collaborator |
| 164 | +5. **Cross-Reference**: Verify that temporary resources don't conflict with persistent standards |
| 165 | +6. **Document Deviations**: If a temporary resource requires breaking persistent patterns, document why |
| 166 | + |
| 167 | +### Examples |
| 168 | + |
| 169 | +**Persistent Resource Usage**: |
| 170 | +```javascript |
| 171 | +// Collaborator provides: "Use our logging utility from utils/logger.js" |
| 172 | +// This is a persistent resource - use it consistently |
| 173 | +import { logger } from './utils/logger.js'; |
| 174 | + |
| 175 | +function processData(data) { |
| 176 | + logger.info('Processing data batch', { count: data.length }); |
| 177 | + // Implementation continues... |
| 178 | +} |
| 179 | +``` |
| 180 | + |
| 181 | +**Temporary Resource Usage**: |
| 182 | +```javascript |
| 183 | +// Collaborator provides: "For this migration, use this data mapping from migration-map.json" |
| 184 | +// This is temporary - use only for current task |
| 185 | +import migrationMap from './temp/migration-map.json'; |
| 186 | + |
| 187 | +function migrateUserData(oldData) { |
| 188 | + // Use temporary mapping for one-time migration |
| 189 | + return migrationMap[oldData.type] || oldData; |
| 190 | +} |
| 191 | +``` |
| 192 | + |
| 193 | +When collaborators provide tools and references, treat them as valuable context that informs implementation decisions while still applying expert judgment to ensure code quality and maintainability. |
| 194 | + |
| 195 | +## Shorthand Key |
| 196 | + |
| 197 | +Quick reference for shorthand notation: |
| 198 | + |
| 199 | +``` |
| 200 | +()=> 90% comment, 10% pseudo-code - interpret and implement |
| 201 | + ALWAYS remove these lines when editing |
| 202 | +
|
| 203 | +start-shorthand Begin shorthand section |
| 204 | +end-shorthand End shorthand section |
| 205 | +
|
| 206 | +openPrompt ["quasi-coder", "quasi-code", "shorthand"] |
| 207 | +language:comment Single or multi-line comment in target language |
| 208 | +openMarker "${language:comment} start-shorthand" |
| 209 | +closeMarker "${language:comment} end-shorthand" |
| 210 | +``` |
| 211 | + |
| 212 | +### Critical Rules |
| 213 | + |
| 214 | +- **ALWAYS remove `()=>` lines** when editing a file from shorthand |
| 215 | +- Replace shorthand with functional code, features, comments, documentation, or data |
| 216 | +- Sometimes shorthand requests non-code actions (run commands, create files, fetch data, generate graphics) |
| 217 | +- In all cases, remove the shorthand lines after implementing the request |
| 218 | + |
| 219 | +## Variables and Markers |
| 220 | + |
| 221 | +Formal specification of shorthand variables: |
| 222 | + |
| 223 | +```javascript |
| 224 | +openPrompt = ["quasi-coder", "quasi-code", "shorthand"] |
| 225 | +// Triggers that indicate quasi-coder should be used |
| 226 | + |
| 227 | +language:comment = "Single or multi-line comment of programming language" |
| 228 | +// Comment syntax appropriate for the file type |
| 229 | + |
| 230 | +openMarker = "${language:comment} start-shorthand" |
| 231 | +// Example: // start-shorthand (JavaScript) |
| 232 | +// Example: # start-shorthand (Python) |
| 233 | +// Example: <!-- start-shorthand --> (HTML) |
| 234 | + |
| 235 | +closeMarker = "${language:comment} end-shorthand" |
| 236 | +// Example: // end-shorthand (JavaScript) |
| 237 | +// Example: # end-shorthand (Python) |
| 238 | +// Example: <!-- end-shorthand --> (HTML) |
| 239 | +``` |
| 240 | + |
| 241 | +## Example Workflow |
| 242 | + |
| 243 | +### Scenario: Collaborator Provides Shorthand |
| 244 | + |
| 245 | +**Input from Collaborator** (JavaScript file): |
| 246 | +```javascript |
| 247 | +// start-shorthand |
| 248 | +()=> create function that validates user input |
| 249 | +()=> check email format is correct |
| 250 | +()=> make sure password is at least 8 characters |
| 251 | +()=> return true if valid, false otherwise |
| 252 | +// end-shorthand |
| 253 | +``` |
| 254 | + |
| 255 | +### Step 1: Assess Expertise Level |
| 256 | +- Collaborator knows they need validation |
| 257 | +- Using general terms, not specific library names |
| 258 | +- **Assessment**: Medium confidence (30-90%) |
| 259 | + |
| 260 | +### Step 2: Interpret Intent |
| 261 | +- Goal: Create input validation function |
| 262 | +- Needs: Email format check, password length check |
| 263 | +- Output: Boolean return value |
| 264 | + |
| 265 | +### Step 3: Apply Expert Implementation |
| 266 | + |
| 267 | +**Output (Production Code)**: |
| 268 | +```javascript |
| 269 | +/** |
| 270 | + * Validates user registration input |
| 271 | + * @param {string} email - User email address |
| 272 | + * @param {string} password - User password |
| 273 | + * @returns {boolean} True if input is valid, false otherwise |
| 274 | + */ |
| 275 | +function validateUserInput(email, password) { |
| 276 | + // Validate email format using standard regex pattern |
| 277 | + const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; |
| 278 | + if (!emailRegex.test(email)) { |
| 279 | + return false; |
| 280 | + } |
| 281 | + |
| 282 | + // Validate password meets minimum length requirement |
| 283 | + if (!password || password.length < 8) { |
| 284 | + return false; |
| 285 | + } |
| 286 | + |
| 287 | + return true; |
| 288 | +} |
| 289 | +``` |
| 290 | + |
| 291 | +### Expert Decisions Made: |
| 292 | +1. Created function with proper parameters (email and password separate) |
| 293 | +2. Used standard email regex pattern (best practice) |
| 294 | +3. Added JSDoc comments for clarity |
| 295 | +4. Included null/undefined check for password |
| 296 | +5. Used descriptive function name |
| 297 | +6. Returned boolean as requested |
| 298 | +7. **Removed all `()=>` shorthand lines** |
| 299 | + |
| 300 | +## Troubleshooting |
| 301 | + |
| 302 | +| Issue | Solution | |
| 303 | +|-------|----------| |
| 304 | +| **Unclear intent from collaborator** | Ask specific clarifying questions about the goal and expected behavior | |
| 305 | +| **Multiple valid approaches** | Present options with recommendations, explaining trade-offs of each | |
| 306 | +| **Collaborator insists on suboptimal approach** | Implement their approach but respectfully explain trade-offs and alternatives | |
| 307 | +| **Missing context or dependencies** | Read related files, check package.json, review existing patterns in the codebase | |
| 308 | +| **Conflicting requirements** | Clarify priorities with the collaborator before implementing | |
| 309 | +| **Shorthand requests non-code actions** | Execute the requested action (run commands, create files, fetch data) and remove shorthand | |
| 310 | +| **Terminology doesn't match available tools** | Research correct terminology and use appropriate libraries/methods | |
| 311 | +| **No markers but clear shorthand intent** | Process as shorthand even without formal markers if intent is clear | |
| 312 | + |
| 313 | +### Common Pitfalls to Avoid |
| 314 | + |
| 315 | +- **Don't leave `()=>` lines in the code** - Always remove shorthand notation |
| 316 | +- **Don't blindly follow incorrect technical descriptions** - Apply expert judgment |
| 317 | +- **Don't over-complicate simple requests** - Match complexity to the need |
| 318 | +- **Don't ignore the big picture** - Understand the goal, not just individual lines |
| 319 | +- **Don't be condescending** - Translate and implement respectfully |
| 320 | +- **Don't skip error handling** - Add professional error handling even if not mentioned |
| 321 | + |
| 322 | +## Advanced Usage |
| 323 | + |
| 324 | +### Mixed-Language Pseudo-Code |
| 325 | + |
| 326 | +When shorthand mixes languages or uses pseudo-code: |
| 327 | + |
| 328 | +```python |
| 329 | +# start-shorthand |
| 330 | +()=> use forEach to iterate over users array |
| 331 | +()=> for each user, if user.age > 18, add to adults list |
| 332 | +# end-shorthand |
| 333 | +``` |
| 334 | + |
| 335 | +**Expert Translation** (Python doesn't have forEach, use appropriate Python pattern): |
| 336 | +```python |
| 337 | +# Filter adult users from the users list |
| 338 | +adults = [user for user in users if user.get('age', 0) > 18] |
| 339 | +``` |
| 340 | + |
| 341 | +### Non-Code Actions |
| 342 | + |
| 343 | +```javascript |
| 344 | +// start-shorthand |
| 345 | +()=> fetch current weather from API |
| 346 | +()=> save response to weather.json file |
| 347 | +// end-shorthand |
| 348 | +``` |
| 349 | + |
| 350 | +**Implementation**: Use appropriate tools to fetch data and save file, then remove shorthand lines. |
| 351 | + |
| 352 | +### Complex Multi-Step Logic |
| 353 | + |
| 354 | +```typescript |
| 355 | +// start-shorthand |
| 356 | +()=> check if user is logged in |
| 357 | +()=> if not, redirect to login page |
| 358 | +()=> if yes, load user dashboard with their data |
| 359 | +()=> show error if data fetch fails |
| 360 | +// end-shorthand |
| 361 | +``` |
| 362 | + |
| 363 | +**Implementation**: Convert to proper TypeScript with authentication checks, routing, data fetching, and error handling. |
| 364 | + |
| 365 | +## Summary |
| 366 | + |
| 367 | +The Quasi-Coder skill enables expert-level interpretation and implementation of code from imperfect descriptions. By assessing collaborator expertise, applying technical knowledge, and maintaining professional standards, you bridge the gap between ideas and production-quality code. |
| 368 | + |
| 369 | +**Remember**: Always remove shorthand lines starting with `()=>` and replace them with functional, production-ready implementations that fulfill the collaborator's intent with expert-level quality. |
0 commit comments