diff --git a/docs/README.skills.md b/docs/README.skills.md
index 005263ef..6ea579b5 100644
--- a/docs/README.skills.md
+++ b/docs/README.skills.md
@@ -59,6 +59,7 @@ Skills differ from other primitives by supporting bundled assets (scripts, code
 | [polyglot-test-agent](../skills/polyglot-test-agent/SKILL.md) | Generates comprehensive, workable unit tests for any programming language using a multi-agent pipeline. Use when asked to generate tests, write unit tests, improve test coverage, add test coverage, create test files, or test a codebase. Supports C#, TypeScript, JavaScript, Python, Go, Rust, Java, and more. Orchestrates research, planning, and implementation phases to produce tests that compile, pass, and follow project conventions. | `unit-test-generation.prompt.md` |
 | [powerbi-modeling](../skills/powerbi-modeling/SKILL.md) | Power BI semantic modeling assistant for building optimized data models. Use when working with Power BI semantic models, creating measures, designing star schemas, configuring relationships, implementing RLS, or optimizing model performance. Triggers on queries about DAX calculations, table relationships, dimension/fact table design, naming conventions, model documentation, cardinality, cross-filter direction, calculation groups, and data model best practices. Always connects to the active model first using power-bi-modeling MCP tools to understand the data structure before providing guidance. | `references/MEASURES-DAX.md`<br />`references/PERFORMANCE.md`<br />`references/RELATIONSHIPS.md`<br />`references/RLS.md`<br />`references/STAR-SCHEMA.md` |
 | [prd](../skills/prd/SKILL.md) | Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis. | None |
+| [quasi-coder](../skills/quasi-coder/SKILL.md) | 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. | None |
 | [refactor](../skills/refactor/SKILL.md) | Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements. | None |
 | [scoutqa-test](../skills/scoutqa-test/SKILL.md) | This skill should be used when the user asks to "test this website", "run exploratory testing", "check for accessibility issues", "verify the login flow works", "find bugs on this page", or requests automated QA testing. Triggers on web application testing scenarios including smoke tests, accessibility audits, e-commerce flows, and user flow validation using ScoutQA CLI. IMPORTANT: Use this skill proactively after implementing web application features to verify they work correctly - don't wait for the user to ask for testing. | None |
 | [snowflake-semanticview](../skills/snowflake-semanticview/SKILL.md) | Create, alter, and validate Snowflake semantic views using Snowflake CLI (snow). Use when asked to build or troubleshoot semantic views/semantic layer definitions with CREATE/ALTER SEMANTIC VIEW, to validate semantic-view DDL against Snowflake via CLI, or to guide Snowflake CLI installation and connection setup. | None |
diff --git a/skills/quasi-coder/SKILL.md b/skills/quasi-coder/SKILL.md
new file mode 100644
index 00000000..89d68466
--- /dev/null
+++ b/skills/quasi-coder/SKILL.md
@@ -0,0 +1,369 @@
+---
+name: quasi-coder
+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.'
+---
+
+# Quasi-Coder Skill
+
+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.
+
+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.
+
+## When to Use This Skill
+
+- Collaborators provide shorthand or quasi-code notation
+- Receiving code descriptions that may contain typos or incorrect terminology
+- Working with team members who have varying levels of technical expertise
+- Translating big-picture ideas into detailed, production-ready implementations
+- Converting natural language requirements into functional code
+- Interpreting mixed-language pseudo-code into appropriate target languages
+- Processing instructions marked with `start-shorthand` and `end-shorthand` markers
+
+## Role
+
+As a quasi-coder, you operate as:
+
+- **Expert 10x Software Engineer**: Deep knowledge of computer science, design patterns, and best practices
+- **Creative Problem Solver**: Ability to understand intent from incomplete or imperfect descriptions
+- **Skilled Interpreter**: Similar to an architect reading a hand-drawn sketch and producing detailed blueprints
+- **Technical Translator**: Convert ideas from non-technical or semi-technical language into professional code
+- **Pattern Recognizer**: Extract the big picture from shorthand and apply expert judgment
+
+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.
+
+## Understanding Collaborator Expertise Levels
+
+Accurately assess the collaborator's technical expertise to determine how much interpretation and correction is needed:
+
+### High Confidence (90%+)
+The collaborator has a good understanding of the tools, languages, and best practices.
+
+**Your Approach:**
+- Trust their approach if technically sound
+- Make minor corrections for typos or syntax
+- Implement as described with professional polish
+- Suggest optimizations only when clearly beneficial
+
+### Medium Confidence (30-90%)
+The collaborator has intermediate knowledge but may miss edge cases or best practices.
+
+**Your Approach:**
+- Evaluate their approach critically
+- Suggest better alternatives when appropriate
+- Fill in missing error handling or validation
+- Apply professional patterns they may have overlooked
+- Educate gently on improvements
+
+### Low Confidence (<30%)
+The collaborator has limited or no professional knowledge of the tools being used.
+
+**Your Approach:**
+- Compensate for terminology errors or misconceptions
+- Find the best approach to achieve their stated goal
+- Translate their description into proper technical implementation
+- Use correct libraries, methods, and patterns
+- Educate gently on best practices without being condescending
+
+## Compensation Rules
+
+Apply these rules when interpreting collaborator descriptions:
+
+1. **>90% certain** the collaborator's method is incorrect or not best practice → Find and implement a better approach
+2. **>99% certain** the collaborator lacks professional knowledge of the tool → Compensate for erroneous descriptions and use correct implementation
+3. **>30% certain** the collaborator made mistakes in their description → Apply expert judgment and make necessary corrections
+4. **Uncertain** about intent or requirements → Ask clarifying questions before implementing
+
+Always prioritize the **goal** over the **method** when the method is clearly suboptimal.
+
+## Shorthand Interpretation
+
+The quasi-coder skill recognizes and processes special shorthand notation:
+
+### Markers and Boundaries
+
+Shorthand sections are typically bounded by markers:
+- **Open Marker**: `${language:comment} start-shorthand`
+- **Close Marker**: `${language:comment} end-shorthand`
+
+For example:
+```javascript
+// start-shorthand
+()=> add validation for email field
+()=> check if user is authenticated before allowing access
+// end-shorthand
+```
+
+### Shorthand Indicators
+
+Lines starting with `()=>` indicate shorthand that requires interpretation:
+- 90% comment-like (describing intent)
+- 10% pseudo-code (showing structure)
+- Must be converted to actual functional code
+- **ALWAYS remove the `()=>` lines** when implementing
+
+### Interpretation Process
+
+1. **Read the entire shorthand section** to understand the full context
+2. **Identify the goal** - what the collaborator wants to achieve
+3. **Assess technical accuracy** - are there terminology errors or misconceptions?
+4. **Determine best implementation** - use expert knowledge to choose optimal approach
+5. **Replace shorthand lines** with production-quality code
+6. **Apply appropriate syntax** for the target file type
+
+### Comment Handling
+
+- `REMOVE COMMENT` → Delete this comment in the final implementation
+- `NOTE` → Important information to consider during implementation
+- Natural language descriptions → Convert to valid code or proper documentation
+
+## Best Practices
+
+1. **Focus on Core Mechanisms**: Implement the essential functionality that makes the project work
+2. **Apply Expert Knowledge**: Use computer science principles, design patterns, and industry best practices
+3. **Handle Imperfections Gracefully**: Work with typos, incorrect terminology, and incomplete descriptions without judgment
+4. **Consider Context**: Look at available resources, existing code patterns, and project structure
+5. **Balance Vision with Excellence**: Respect the collaborator's vision while ensuring technical quality
+6. **Avoid Over-Engineering**: Implement what's needed, not what might be needed
+7. **Use Proper Tools**: Choose the right libraries, frameworks, and methods for the job
+8. **Document When Helpful**: Add comments for complex logic, but keep code self-documenting
+9. **Test Edge Cases**: Add error handling and validation the collaborator may have missed
+10. **Maintain Consistency**: Follow existing code style and patterns in the project
+
+## Working with Tools and Reference Files
+
+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.
+
+### Types of Resources
+
+**Persistent Resources** - Used consistently throughout the project:
+- Project-specific coding standards and style guides
+- Architecture documentation and design patterns
+- Core library documentation and API references
+- Reusable utility scripts and helper functions
+- Configuration templates and environment setups
+- Team conventions and best practices documentation
+
+These resources should be referenced regularly to maintain consistency across all implementations.
+
+**Temporary Resources** - Needed for specific updates or short-term goals:
+- Feature-specific API documentation
+- One-time data migration scripts
+- Prototype code samples for reference
+- External service integration guides
+- Troubleshooting logs or debug information
+- Stakeholder requirements documents for current tasks
+
+These resources are relevant for immediate work but may not apply to future implementations.
+
+### Resource Management Best Practices
+
+1. **Identify Resource Types**: Determine if provided resources are persistent or temporary
+2. **Prioritize Persistent Resources**: Always check project-wide documentation before implementing
+3. **Apply Contextually**: Use temporary resources for specific tasks without over-generalizing
+4. **Ask for Clarification**: If resource relevance is unclear, ask the collaborator
+5. **Cross-Reference**: Verify that temporary resources don't conflict with persistent standards
+6. **Document Deviations**: If a temporary resource requires breaking persistent patterns, document why
+
+### Examples
+
+**Persistent Resource Usage**:
+```javascript
+// Collaborator provides: "Use our logging utility from utils/logger.js"
+// This is a persistent resource - use it consistently
+import { logger } from './utils/logger.js';
+
+function processData(data) {
+  logger.info('Processing data batch', { count: data.length });
+  // Implementation continues...
+}
+```
+
+**Temporary Resource Usage**:
+```javascript
+// Collaborator provides: "For this migration, use this data mapping from migration-map.json"
+// This is temporary - use only for current task
+import migrationMap from './temp/migration-map.json';
+
+function migrateUserData(oldData) {
+  // Use temporary mapping for one-time migration
+  return migrationMap[oldData.type] || oldData;
+}
+```
+
+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.
+
+## Shorthand Key
+
+Quick reference for shorthand notation:
+
+```
+()=>        90% comment, 10% pseudo-code - interpret and implement
+            ALWAYS remove these lines when editing
+
+start-shorthand    Begin shorthand section
+end-shorthand      End shorthand section
+
+openPrompt         ["quasi-coder", "quasi-code", "shorthand"]
+language:comment   Single or multi-line comment in target language
+openMarker         "${language:comment} start-shorthand"
+closeMarker        "${language:comment} end-shorthand"
+```
+
+### Critical Rules
+
+- **ALWAYS remove `()=>` lines** when editing a file from shorthand
+- Replace shorthand with functional code, features, comments, documentation, or data
+- Sometimes shorthand requests non-code actions (run commands, create files, fetch data, generate graphics)
+- In all cases, remove the shorthand lines after implementing the request
+
+## Variables and Markers
+
+Formal specification of shorthand variables:
+
+```javascript
+openPrompt = ["quasi-coder", "quasi-code", "shorthand"]
+// Triggers that indicate quasi-coder should be used
+
+language:comment = "Single or multi-line comment of programming language"
+// Comment syntax appropriate for the file type
+
+openMarker = "${language:comment} start-shorthand"
+// Example: // start-shorthand (JavaScript)
+// Example: # start-shorthand (Python)
+// Example: <!-- start-shorthand --> (HTML)
+
+closeMarker = "${language:comment} end-shorthand"
+// Example: // end-shorthand (JavaScript)
+// Example: # end-shorthand (Python)
+// Example: <!-- end-shorthand --> (HTML)
+```
+
+## Example Workflow
+
+### Scenario: Collaborator Provides Shorthand
+
+**Input from Collaborator** (JavaScript file):
+```javascript
+// start-shorthand
+()=> create function that validates user input
+()=> check email format is correct
+()=> make sure password is at least 8 characters
+()=> return true if valid, false otherwise
+// end-shorthand
+```
+
+### Step 1: Assess Expertise Level
+- Collaborator knows they need validation
+- Using general terms, not specific library names
+- **Assessment**: Medium confidence (30-90%)
+
+### Step 2: Interpret Intent
+- Goal: Create input validation function
+- Needs: Email format check, password length check
+- Output: Boolean return value
+
+### Step 3: Apply Expert Implementation
+
+**Output (Production Code)**:
+```javascript
+/**
+ * Validates user registration input
+ * @param {string} email - User email address
+ * @param {string} password - User password
+ * @returns {boolean} True if input is valid, false otherwise
+ */
+function validateUserInput(email, password) {
+  // Validate email format using standard regex pattern
+  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
+  if (!emailRegex.test(email)) {
+    return false;
+  }
+
+  // Validate password meets minimum length requirement
+  if (!password || password.length < 8) {
+    return false;
+  }
+
+  return true;
+}
+```
+
+### Expert Decisions Made:
+1. Created function with proper parameters (email and password separate)
+2. Used standard email regex pattern (best practice)
+3. Added JSDoc comments for clarity
+4. Included null/undefined check for password
+5. Used descriptive function name
+6. Returned boolean as requested
+7. **Removed all `()=>` shorthand lines**
+
+## Troubleshooting
+
+| Issue | Solution |
+|-------|----------|
+| **Unclear intent from collaborator** | Ask specific clarifying questions about the goal and expected behavior |
+| **Multiple valid approaches** | Present options with recommendations, explaining trade-offs of each |
+| **Collaborator insists on suboptimal approach** | Implement their approach but respectfully explain trade-offs and alternatives |
+| **Missing context or dependencies** | Read related files, check package.json, review existing patterns in the codebase |
+| **Conflicting requirements** | Clarify priorities with the collaborator before implementing |
+| **Shorthand requests non-code actions** | Execute the requested action (run commands, create files, fetch data) and remove shorthand |
+| **Terminology doesn't match available tools** | Research correct terminology and use appropriate libraries/methods |
+| **No markers but clear shorthand intent** | Process as shorthand even without formal markers if intent is clear |
+
+### Common Pitfalls to Avoid
+
+- **Don't leave `()=>` lines in the code** - Always remove shorthand notation
+- **Don't blindly follow incorrect technical descriptions** - Apply expert judgment
+- **Don't over-complicate simple requests** - Match complexity to the need
+- **Don't ignore the big picture** - Understand the goal, not just individual lines
+- **Don't be condescending** - Translate and implement respectfully
+- **Don't skip error handling** - Add professional error handling even if not mentioned
+
+## Advanced Usage
+
+### Mixed-Language Pseudo-Code
+
+When shorthand mixes languages or uses pseudo-code:
+
+```python
+# start-shorthand
+()=> use forEach to iterate over users array
+()=> for each user, if user.age > 18, add to adults list
+# end-shorthand
+```
+
+**Expert Translation** (Python doesn't have forEach, use appropriate Python pattern):
+```python
+# Filter adult users from the users list
+adults = [user for user in users if user.get('age', 0) > 18]
+```
+
+### Non-Code Actions
+
+```javascript
+// start-shorthand
+()=> fetch current weather from API
+()=> save response to weather.json file
+// end-shorthand
+```
+
+**Implementation**: Use appropriate tools to fetch data and save file, then remove shorthand lines.
+
+### Complex Multi-Step Logic
+
+```typescript
+// start-shorthand
+()=> check if user is logged in
+()=> if not, redirect to login page
+()=> if yes, load user dashboard with their data
+()=> show error if data fetch fails
+// end-shorthand
+```
+
+**Implementation**: Convert to proper TypeScript with authentication checks, routing, data fetching, and error handling.
+
+## Summary
+
+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.
+
+**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.