@actrun_ai/tastekit-core 0.1.0

package/dist/domains/development-agent/rubric.js

@@ -0,0 +1,451 @@
+/**
+ * Development Agent Domain Rubric (Hybrid)
+ *
+ * Quick tier: Values-First (deep developer identity)
+ * Guided adds: Outcome-Centric (practical, what the agent produces)
+ * Operator adds: Workflow-Centric (deep process dives)
+ *
+ * Combined with 7 universal dimensions, this gives:
+ *   quick=9, guided=20, operator=28
+ */
+export const DevelopmentAgentRubric = {
+    domain_id: 'development-agent',
+    version: '0.5.0',
+    interview_goal: 'Understand the developer\'s engineering philosophy, code quality standards, workflow preferences, and collaboration style to configure an agent that writes code the way they would.',
+    includes_universal: true,
+    dimensions: [
+        // === QUICK TIER: Values-First (5 dimensions) ===
+        {
+            id: 'engineering_identity',
+            name: 'Engineering Identity',
+            description: 'How they see themselves as a developer. Craftsperson, pragmatist, scientist, artist? What kind of engineer are they?',
+            maps_to: ['principles'],
+            depth_tiers: ['quick', 'guided', 'operator'],
+            priority: 'critical',
+            question_budget: { min: 1, max: 2 },
+            exploration_hints: [
+                'Ask how they would describe their engineering style in a sentence',
+                'Probe for role models or engineering philosophies they admire',
+                'Listen for self-identification: are they a systems thinker, product engineer, infrastructure person?',
+                'Understand whether they prioritize shipping or craftsmanship',
+            ],
+            coverage_criteria: [
+                'Engineering identity/archetype captured',
+                'Primary motivation understood (shipping, quality, learning, impact)',
+            ],
+        },
+        {
+            id: 'core_technical_values',
+            name: 'Core Technical Values',
+            description: 'Their 3-5 non-negotiable technical values. Simplicity, correctness, velocity, readability, performance, security — what matters most?',
+            maps_to: ['principles'],
+            depth_tiers: ['quick', 'guided', 'operator'],
+            priority: 'critical',
+            question_budget: { min: 1, max: 2 },
+            exploration_hints: [
+                'Ask what their top 3 non-negotiable values are when writing code',
+                'Challenge with tradeoff scenarios: "if you had to choose between readable and fast?"',
+                'Ask what annoys them most in a codebase',
+                'Listen for implicit values in their complaints and preferences',
+            ],
+            coverage_criteria: [
+                'At least 3 core values identified',
+                'Priority ordering established',
+                'At least one tradeoff position expressed',
+            ],
+        },
+        {
+            id: 'collaboration_style',
+            name: 'Collaboration Style',
+            description: 'How they work with other developers and how the agent should fit into that. Code review expectations, pair programming mindset.',
+            maps_to: ['principles', 'tone'],
+            depth_tiers: ['quick', 'guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask if they think of the agent as a pair programmer, junior dev, or tool',
+                'Probe for code review preferences: what do they look for?',
+                'Understand async vs. sync collaboration preferences',
+                'At operator depth: how should the agent handle disagreements?',
+            ],
+            coverage_criteria: [
+                'Agent relationship model established (peer, assistant, tool)',
+                'Code review expectations expressed',
+            ],
+        },
+        {
+            id: 'learning_philosophy',
+            name: 'Learning & Growth Philosophy',
+            description: 'How they approach new technology, learning from mistakes, and experimentation in codebases.',
+            maps_to: ['tradeoffs', 'principles'],
+            depth_tiers: ['quick', 'guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about their stance on new vs. battle-tested technology',
+                'Probe for how they learn best: docs, examples, trial and error?',
+                'Understand experimentation tolerance in production codebases',
+            ],
+            coverage_criteria: [
+                'Innovation vs. stability position captured',
+                'Learning style understood',
+            ],
+        },
+        {
+            id: 'failure_tolerance',
+            name: 'Failure & Mistake Philosophy',
+            description: 'How they think about bugs, mistakes, and learning from failures. Perfectionist or "fail fast"?',
+            maps_to: ['tradeoffs', 'principles'],
+            depth_tiers: ['quick', 'guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask what they do when they find a bug they introduced',
+                'Probe their stance on "move fast and break things" vs. careful shipping',
+                'Understand how they want the agent to handle its own mistakes',
+            ],
+            coverage_criteria: [
+                'Error tolerance level captured',
+                'Agent mistake handling expectation set',
+            ],
+        },
+        // === GUIDED TIER adds: Outcome-Centric (11 dimensions) ===
+        {
+            id: 'code_quality_bar',
+            name: 'Code Quality Bar',
+            description: 'What "good code" means to them. Readable? Performant? Minimal? Well-tested? DRY? Pragmatic duplication?',
+            maps_to: ['principles'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'critical',
+            question_budget: { min: 1, max: 2 },
+            exploration_hints: [
+                'Ask what they notice first when reading someone else\'s code',
+                'Probe their DRY stance: is duplication sometimes acceptable?',
+                'Ask for their definition of "production-ready" code',
+                'Understand testing expectations as part of quality',
+            ],
+            coverage_criteria: [
+                'Quality definition captured',
+                'Testing expectations as part of quality expressed',
+            ],
+        },
+        {
+            id: 'output_format_preferences',
+            name: 'Output Format Preferences',
+            description: 'How they want the agent to present code. Full files? Diffs? Explanations alongside? Comments in code?',
+            maps_to: ['tone', 'domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask if they prefer full file output or targeted diffs',
+                'Probe for explanation expectations: inline comments? separate section?',
+                'Understand verbosity preference: minimal changes or thorough context?',
+            ],
+            coverage_criteria: [
+                'Output format preference expressed',
+                'Explanation style captured',
+            ],
+        },
+        {
+            id: 'naming_conventions',
+            name: 'Naming Conventions',
+            description: 'Variable, function, file, and module naming philosophy. Case style, descriptiveness, abbreviation tolerance.',
+            maps_to: ['tone', 'domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about naming style: verbose descriptive or terse?',
+                'Probe for abbreviation tolerance',
+                'Ask about file naming: kebab-case? camelCase?',
+                'Understand naming-specific pet peeves',
+            ],
+            coverage_criteria: [
+                'Naming style preference captured',
+                'At least one specific convention mentioned',
+            ],
+        },
+        {
+            id: 'code_structure_preferences',
+            name: 'Code Structure & Organization',
+            description: 'Module organization, file size limits, separation of concerns, directory structure opinions.',
+            maps_to: ['principles', 'domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about preferred file organization patterns',
+                'Probe for file size preferences: when is a file too big?',
+                'Understand separation of concerns philosophy',
+                'Ask about single responsibility at the module level',
+            ],
+            coverage_criteria: [
+                'Organization philosophy captured',
+                'File size/complexity threshold expressed',
+            ],
+        },
+        {
+            id: 'testing_output_expectations',
+            name: 'Testing Philosophy & Output',
+            description: 'Test naming, assertion style, what to test vs. skip, TDD vs. test-after, unit vs. integration focus.',
+            maps_to: ['principles', 'domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'critical',
+            question_budget: { min: 1, max: 2 },
+            exploration_hints: [
+                'Ask about TDD vs. test-after preference',
+                'Probe for unit vs. integration vs. e2e balance',
+                'Ask about test naming conventions',
+                'Understand coverage expectations: percentage or coverage of critical paths?',
+            ],
+            coverage_criteria: [
+                'Testing approach captured (TDD vs. test-after)',
+                'Coverage expectations expressed',
+            ],
+        },
+        {
+            id: 'commit_message_format',
+            name: 'Commit Message Format',
+            description: 'Conventional commits, detail level, scope expectations, squash vs. granular commits.',
+            maps_to: ['tone', 'domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'nice-to-have',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about commit message format (conventional commits, free-form, etc.)',
+                'Probe for commit granularity: atomic or batched?',
+                'Understand squash-on-merge vs. clean history preferences',
+            ],
+            coverage_criteria: [
+                'Commit format preference captured',
+                'Granularity preference expressed',
+            ],
+        },
+        {
+            id: 'pr_description_quality',
+            name: 'PR Description Quality',
+            description: 'What a good PR description includes. Summary style, test plan, screenshots, linked issues.',
+            maps_to: ['tone', 'domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'nice-to-have',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask what they always want to see in a PR description',
+                'Probe for template usage',
+                'Understand review expectations for the agent\'s PRs',
+            ],
+            coverage_criteria: [
+                'PR description expectations captured',
+            ],
+        },
+        {
+            id: 'documentation_voice',
+            name: 'Documentation Voice',
+            description: 'Technical writing style, audience assumptions, when docs are needed, inline vs. external documentation.',
+            maps_to: ['tone', 'domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask when they think documentation is necessary vs. overkill',
+                'Probe for inline comment philosophy: minimal or thorough?',
+                'Understand README expectations',
+            ],
+            coverage_criteria: [
+                'Documentation philosophy captured',
+                'Comment style preference expressed',
+            ],
+        },
+        {
+            id: 'error_message_philosophy',
+            name: 'Error Message Philosophy',
+            description: 'User-facing vs. developer error messages. Actionable errors, error handling patterns.',
+            maps_to: ['principles', 'domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about their error handling philosophy: defensive or fail-fast?',
+                'Probe for error message quality expectations',
+                'Understand logging verbosity preferences',
+            ],
+            coverage_criteria: [
+                'Error handling philosophy captured',
+            ],
+        },
+        {
+            id: 'logging_approach',
+            name: 'Logging & Observability',
+            description: 'What to log, log levels, structured logging opinions, debugging approach.',
+            maps_to: ['domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about logging philosophy: when is a log line warranted?',
+                'Probe for structured logging opinions',
+                'Understand debugging approach: printf, debugger, or both?',
+            ],
+            coverage_criteria: [
+                'Logging philosophy captured',
+            ],
+        },
+        {
+            id: 'type_safety_stance',
+            name: 'Type Safety Stance',
+            description: 'Strict typing preferences, use of any/unknown, generics philosophy, type inference reliance.',
+            maps_to: ['principles', 'domain_specific'],
+            depth_tiers: ['guided', 'operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about strict mode, any vs. unknown, generics usage',
+                'Probe for type inference tolerance vs. explicit annotations',
+                'Understand opinions on type-driven development',
+            ],
+            coverage_criteria: [
+                'Type safety preference captured',
+            ],
+        },
+        // === OPERATOR TIER adds: Workflow-Centric (8 dimensions) ===
+        {
+            id: 'ci_cd_philosophy',
+            name: 'CI/CD Philosophy',
+            description: 'Pipeline expectations, deployment safety, rollback approach, branch protection opinions.',
+            maps_to: ['domain_specific', 'tradeoffs'],
+            depth_tiers: ['operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about deployment frequency and safety nets',
+                'Probe for rollback strategy',
+                'Understand branch protection and merge requirements',
+            ],
+            coverage_criteria: [
+                'Deployment philosophy captured',
+                'Safety requirements expressed',
+            ],
+        },
+        {
+            id: 'incident_response',
+            name: 'Incident Response',
+            description: 'How the agent should behave during outages or critical bugs. Urgency, communication, rollback authority.',
+            maps_to: ['taboos', 'domain_specific'],
+            depth_tiers: ['operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask how the agent should handle production issues',
+                'Probe for escalation procedures',
+                'Understand hotfix vs. proper-fix tradeoff tolerance',
+            ],
+            coverage_criteria: [
+                'Incident handling expectations set',
+            ],
+        },
+        {
+            id: 'api_design_principles',
+            name: 'API Design Principles',
+            description: 'REST vs. GraphQL, versioning, error format, endpoint naming, backward compatibility opinions.',
+            maps_to: ['principles', 'domain_specific'],
+            depth_tiers: ['operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about API design opinions',
+                'Probe for backward compatibility stance',
+                'Understand error response format preferences',
+            ],
+            coverage_criteria: [
+                'API design preferences captured',
+            ],
+        },
+        {
+            id: 'technical_debt_management',
+            name: 'Technical Debt Management',
+            description: 'When to take on debt, when to pay it down, tracking approach, refactoring cadence.',
+            maps_to: ['tradeoffs', 'principles'],
+            depth_tiers: ['operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about their relationship with technical debt',
+                'Probe for refactoring triggers and boundaries',
+                'Understand boy scout rule adherence',
+            ],
+            coverage_criteria: [
+                'Tech debt philosophy captured',
+            ],
+        },
+        {
+            id: 'legacy_code_approach',
+            name: 'Legacy Code Approach',
+            description: 'How to handle legacy code. Migration strategies, strangler fig, big-bang rewrite opinions.',
+            maps_to: ['principles', 'domain_specific'],
+            depth_tiers: ['operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about their approach to working with legacy codebases',
+                'Probe for migration strategy preferences',
+                'Understand tolerance for "leave it as-is" vs. "improve as you go"',
+            ],
+            coverage_criteria: [
+                'Legacy code approach captured',
+            ],
+        },
+        {
+            id: 'mentoring_voice',
+            name: 'Mentoring & Teaching Voice',
+            description: 'If the agent is helping less experienced developers, what teaching style to use. Patient, Socratic, direct?',
+            maps_to: ['tone', 'principles'],
+            depth_tiers: ['operator'],
+            priority: 'nice-to-have',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask how they mentor junior developers',
+                'Probe for teaching philosophy: explain why or just show how?',
+                'Understand when the agent should be pedagogical vs. efficient',
+            ],
+            coverage_criteria: [
+                'Teaching/mentoring style captured',
+            ],
+        },
+        {
+            id: 'open_source_etiquette',
+            name: 'Open Source Etiquette',
+            description: 'Contributing to open source, license awareness, community interaction style.',
+            maps_to: ['principles', 'domain_specific'],
+            depth_tiers: ['operator'],
+            priority: 'nice-to-have',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about open source contribution experience',
+                'Probe for license awareness and preference',
+                'Understand community engagement expectations',
+            ],
+            coverage_criteria: [
+                'Open source stance captured',
+            ],
+        },
+        {
+            id: 'tech_stack_opinions',
+            name: 'Tech Stack Opinions',
+            description: 'Strong opinions about frameworks, libraries, patterns. What they love, hate, and refuse to use.',
+            maps_to: ['domain_specific', 'principles'],
+            depth_tiers: ['operator'],
+            priority: 'important',
+            question_budget: { min: 0, max: 1 },
+            exploration_hints: [
+                'Ask about frameworks and libraries they love and hate',
+                'Probe for design pattern opinions',
+                'Understand "never use" list for technologies',
+            ],
+            coverage_criteria: [
+                'Key tech stack opinions captured',
+            ],
+        },
+    ],
+};
+//# sourceMappingURL=rubric.js.map

package/dist/domains/development-agent/rubric.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"rubric.js","sourceRoot":"","sources":["../../../domains/development-agent/rubric.ts"],"names":[],"mappings":"AAEA;;;;;;;;;GASG;AACH,MAAM,CAAC,MAAM,sBAAsB,GAAiB;IAClD,SAAS,EAAE,mBAAmB;IAC9B,OAAO,EAAE,OAAO;IAChB,cAAc,EAAE,sLAAsL;IACtM,kBAAkB,EAAE,IAAI;IAExB,UAAU,EAAE;QACV,kDAAkD;QAClD;YACE,EAAE,EAAE,sBAAsB;YAC1B,IAAI,EAAE,sBAAsB;YAC5B,WAAW,EAAE,sHAAsH;YACnI,OAAO,EAAE,CAAC,YAAY,CAAC;YACvB,WAAW,EAAE,CAAC,OAAO,EAAE,QAAQ,EAAE,UAAU,CAAC;YAC5C,QAAQ,EAAE,UAAU;YACpB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,mEAAmE;gBACnE,+DAA+D;gBAC/D,sGAAsG;gBACtG,8DAA8D;aAC/D;YACD,iBAAiB,EAAE;gBACjB,yCAAyC;gBACzC,qEAAqE;aACtE;SACF;QACD;YACE,EAAE,EAAE,uBAAuB;YAC3B,IAAI,EAAE,uBAAuB;YAC7B,WAAW,EAAE,uIAAuI;YACpJ,OAAO,EAAE,CAAC,YAAY,CAAC;YACvB,WAAW,EAAE,CAAC,OAAO,EAAE,QAAQ,EAAE,UAAU,CAAC;YAC5C,QAAQ,EAAE,UAAU;YACpB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,kEAAkE;gBAClE,sFAAsF;gBACtF,yCAAyC;gBACzC,gEAAgE;aACjE;YACD,iBAAiB,EAAE;gBACjB,mCAAmC;gBACnC,+BAA+B;gBAC/B,0CAA0C;aAC3C;SACF;QACD;YACE,EAAE,EAAE,qBAAqB;YACzB,IAAI,EAAE,qBAAqB;YAC3B,WAAW,EAAE,iIAAiI;YAC9I,OAAO,EAAE,CAAC,YAAY,EAAE,MAAM,CAAC;YAC/B,WAAW,EAAE,CAAC,OAAO,EAAE,QAAQ,EAAE,UAAU,CAAC;YAC5C,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,0EAA0E;gBAC1E,2DAA2D;gBAC3D,qDAAqD;gBACrD,+DAA+D;aAChE;YACD,iBAAiB,EAAE;gBACjB,8DAA8D;gBAC9D,oCAAoC;aACrC;SACF;QACD;YACE,EAAE,EAAE,qBAAqB;YACzB,IAAI,EAAE,8BAA8B;YACpC,WAAW,EAAE,6FAA6F;YAC1G,OAAO,EAAE,CAAC,WAAW,EAAE,YAAY,CAAC;YACpC,WAAW,EAAE,CAAC,OAAO,EAAE,QAAQ,EAAE,UAAU,CAAC;YAC5C,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,4DAA4D;gBAC5D,iEAAiE;gBACjE,8DAA8D;aAC/D;YACD,iBAAiB,EAAE;gBACjB,4CAA4C;gBAC5C,2BAA2B;aAC5B;SACF;QACD;YACE,EAAE,EAAE,mBAAmB;YACvB,IAAI,EAAE,8BAA8B;YACpC,WAAW,EAAE,gGAAgG;YAC7G,OAAO,EAAE,CAAC,WAAW,EAAE,YAAY,CAAC;YACpC,WAAW,EAAE,CAAC,OAAO,EAAE,QAAQ,EAAE,UAAU,CAAC;YAC5C,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,uDAAuD;gBACvD,yEAAyE;gBACzE,+DAA+D;aAChE;YACD,iBAAiB,EAAE;gBACjB,gCAAgC;gBAChC,wCAAwC;aACzC;SACF;QAED,4DAA4D;QAC5D;YACE,EAAE,EAAE,kBAAkB;YACtB,IAAI,EAAE,kBAAkB;YACxB,WAAW,EAAE,yGAAyG;YACtH,OAAO,EAAE,CAAC,YAAY,CAAC;YACvB,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,UAAU;YACpB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,8DAA8D;gBAC9D,8DAA8D;gBAC9D,qDAAqD;gBACrD,oDAAoD;aACrD;YACD,iBAAiB,EAAE;gBACjB,6BAA6B;gBAC7B,mDAAmD;aACpD;SACF;QACD;YACE,EAAE,EAAE,2BAA2B;YAC/B,IAAI,EAAE,2BAA2B;YACjC,WAAW,EAAE,uGAAuG;YACpH,OAAO,EAAE,CAAC,MAAM,EAAE,iBAAiB,CAAC;YACpC,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,uDAAuD;gBACvD,wEAAwE;gBACxE,uEAAuE;aACxE;YACD,iBAAiB,EAAE;gBACjB,oCAAoC;gBACpC,4BAA4B;aAC7B;SACF;QACD;YACE,EAAE,EAAE,oBAAoB;YACxB,IAAI,EAAE,oBAAoB;YAC1B,WAAW,EAAE,8GAA8G;YAC3H,OAAO,EAAE,CAAC,MAAM,EAAE,iBAAiB,CAAC;YACpC,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,uDAAuD;gBACvD,kCAAkC;gBAClC,+CAA+C;gBAC/C,uCAAuC;aACxC;YACD,iBAAiB,EAAE;gBACjB,kCAAkC;gBAClC,4CAA4C;aAC7C;SACF;QACD;YACE,EAAE,EAAE,4BAA4B;YAChC,IAAI,EAAE,+BAA+B;YACrC,WAAW,EAAE,8FAA8F;YAC3G,OAAO,EAAE,CAAC,YAAY,EAAE,iBAAiB,CAAC;YAC1C,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,gDAAgD;gBAChD,0DAA0D;gBAC1D,8CAA8C;gBAC9C,qDAAqD;aACtD;YACD,iBAAiB,EAAE;gBACjB,kCAAkC;gBAClC,0CAA0C;aAC3C;SACF;QACD;YACE,EAAE,EAAE,6BAA6B;YACjC,IAAI,EAAE,6BAA6B;YACnC,WAAW,EAAE,sGAAsG;YACnH,OAAO,EAAE,CAAC,YAAY,EAAE,iBAAiB,CAAC;YAC1C,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,UAAU;YACpB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,yCAAyC;gBACzC,gDAAgD;gBAChD,mCAAmC;gBACnC,6EAA6E;aAC9E;YACD,iBAAiB,EAAE;gBACjB,gDAAgD;gBAChD,iCAAiC;aAClC;SACF;QACD;YACE,EAAE,EAAE,uBAAuB;YAC3B,IAAI,EAAE,uBAAuB;YAC7B,WAAW,EAAE,sFAAsF;YACnG,OAAO,EAAE,CAAC,MAAM,EAAE,iBAAiB,CAAC;YACpC,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,cAAc;YACxB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,yEAAyE;gBACzE,kDAAkD;gBAClD,0DAA0D;aAC3D;YACD,iBAAiB,EAAE;gBACjB,mCAAmC;gBACnC,kCAAkC;aACnC;SACF;QACD;YACE,EAAE,EAAE,wBAAwB;YAC5B,IAAI,EAAE,wBAAwB;YAC9B,WAAW,EAAE,4FAA4F;YACzG,OAAO,EAAE,CAAC,MAAM,EAAE,iBAAiB,CAAC;YACpC,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,cAAc;YACxB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,sDAAsD;gBACtD,0BAA0B;gBAC1B,qDAAqD;aACtD;YACD,iBAAiB,EAAE;gBACjB,sCAAsC;aACvC;SACF;QACD;YACE,EAAE,EAAE,qBAAqB;YACzB,IAAI,EAAE,qBAAqB;YAC3B,WAAW,EAAE,yGAAyG;YACtH,OAAO,EAAE,CAAC,MAAM,EAAE,iBAAiB,CAAC;YACpC,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,6DAA6D;gBAC7D,2DAA2D;gBAC3D,gCAAgC;aACjC;YACD,iBAAiB,EAAE;gBACjB,mCAAmC;gBACnC,oCAAoC;aACrC;SACF;QACD;YACE,EAAE,EAAE,0BAA0B;YAC9B,IAAI,EAAE,0BAA0B;YAChC,WAAW,EAAE,uFAAuF;YACpG,OAAO,EAAE,CAAC,YAAY,EAAE,iBAAiB,CAAC;YAC1C,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,oEAAoE;gBACpE,8CAA8C;gBAC9C,0CAA0C;aAC3C;YACD,iBAAiB,EAAE;gBACjB,oCAAoC;aACrC;SACF;QACD;YACE,EAAE,EAAE,kBAAkB;YACtB,IAAI,EAAE,yBAAyB;YAC/B,WAAW,EAAE,2EAA2E;YACxF,OAAO,EAAE,CAAC,iBAAiB,CAAC;YAC5B,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,6DAA6D;gBAC7D,uCAAuC;gBACvC,2DAA2D;aAC5D;YACD,iBAAiB,EAAE;gBACjB,6BAA6B;aAC9B;SACF;QACD;YACE,EAAE,EAAE,oBAAoB;YACxB,IAAI,EAAE,oBAAoB;YAC1B,WAAW,EAAE,8FAA8F;YAC3G,OAAO,EAAE,CAAC,YAAY,EAAE,iBAAiB,CAAC;YAC1C,WAAW,EAAE,CAAC,QAAQ,EAAE,UAAU,CAAC;YACnC,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,wDAAwD;gBACxD,6DAA6D;gBAC7D,gDAAgD;aACjD;YACD,iBAAiB,EAAE;gBACjB,iCAAiC;aAClC;SACF;QAED,8DAA8D;QAC9D;YACE,EAAE,EAAE,kBAAkB;YACtB,IAAI,EAAE,kBAAkB;YACxB,WAAW,EAAE,0FAA0F;YACvG,OAAO,EAAE,CAAC,iBAAiB,EAAE,WAAW,CAAC;YACzC,WAAW,EAAE,CAAC,UAAU,CAAC;YACzB,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,gDAAgD;gBAChD,6BAA6B;gBAC7B,qDAAqD;aACtD;YACD,iBAAiB,EAAE;gBACjB,gCAAgC;gBAChC,+BAA+B;aAChC;SACF;QACD;YACE,EAAE,EAAE,mBAAmB;YACvB,IAAI,EAAE,mBAAmB;YACzB,WAAW,EAAE,0GAA0G;YACvH,OAAO,EAAE,CAAC,QAAQ,EAAE,iBAAiB,CAAC;YACtC,WAAW,EAAE,CAAC,UAAU,CAAC;YACzB,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,mDAAmD;gBACnD,iCAAiC;gBACjC,qDAAqD;aACtD;YACD,iBAAiB,EAAE;gBACjB,oCAAoC;aACrC;SACF;QACD;YACE,EAAE,EAAE,uBAAuB;YAC3B,IAAI,EAAE,uBAAuB;YAC7B,WAAW,EAAE,+FAA+F;YAC5G,OAAO,EAAE,CAAC,YAAY,EAAE,iBAAiB,CAAC;YAC1C,WAAW,EAAE,CAAC,UAAU,CAAC;YACzB,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,+BAA+B;gBAC/B,yCAAyC;gBACzC,8CAA8C;aAC/C;YACD,iBAAiB,EAAE;gBACjB,iCAAiC;aAClC;SACF;QACD;YACE,EAAE,EAAE,2BAA2B;YAC/B,IAAI,EAAE,2BAA2B;YACjC,WAAW,EAAE,oFAAoF;YACjG,OAAO,EAAE,CAAC,WAAW,EAAE,YAAY,CAAC;YACpC,WAAW,EAAE,CAAC,UAAU,CAAC;YACzB,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,kDAAkD;gBAClD,+CAA+C;gBAC/C,qCAAqC;aACtC;YACD,iBAAiB,EAAE;gBACjB,+BAA+B;aAChC;SACF;QACD;YACE,EAAE,EAAE,sBAAsB;YAC1B,IAAI,EAAE,sBAAsB;YAC5B,WAAW,EAAE,4FAA4F;YACzG,OAAO,EAAE,CAAC,YAAY,EAAE,iBAAiB,CAAC;YAC1C,WAAW,EAAE,CAAC,UAAU,CAAC;YACzB,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,2DAA2D;gBAC3D,0CAA0C;gBAC1C,mEAAmE;aACpE;YACD,iBAAiB,EAAE;gBACjB,+BAA+B;aAChC;SACF;QACD;YACE,EAAE,EAAE,iBAAiB;YACrB,IAAI,EAAE,4BAA4B;YAClC,WAAW,EAAE,6GAA6G;YAC1H,OAAO,EAAE,CAAC,MAAM,EAAE,YAAY,CAAC;YAC/B,WAAW,EAAE,CAAC,UAAU,CAAC;YACzB,QAAQ,EAAE,cAAc;YACxB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,uCAAuC;gBACvC,8DAA8D;gBAC9D,+DAA+D;aAChE;YACD,iBAAiB,EAAE;gBACjB,mCAAmC;aACpC;SACF;QACD;YACE,EAAE,EAAE,uBAAuB;YAC3B,IAAI,EAAE,uBAAuB;YAC7B,WAAW,EAAE,8EAA8E;YAC3F,OAAO,EAAE,CAAC,YAAY,EAAE,iBAAiB,CAAC;YAC1C,WAAW,EAAE,CAAC,UAAU,CAAC;YACzB,QAAQ,EAAE,cAAc;YACxB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,+CAA+C;gBAC/C,4CAA4C;gBAC5C,8CAA8C;aAC/C;YACD,iBAAiB,EAAE;gBACjB,6BAA6B;aAC9B;SACF;QACD;YACE,EAAE,EAAE,qBAAqB;YACzB,IAAI,EAAE,qBAAqB;YAC3B,WAAW,EAAE,iGAAiG;YAC9G,OAAO,EAAE,CAAC,iBAAiB,EAAE,YAAY,CAAC;YAC1C,WAAW,EAAE,CAAC,UAAU,CAAC;YACzB,QAAQ,EAAE,WAAW;YACrB,eAAe,EAAE,EAAE,GAAG,EAAE,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE;YACnC,iBAAiB,EAAE;gBACjB,uDAAuD;gBACvD,mCAAmC;gBACnC,8CAA8C;aAC/C;YACD,iBAAiB,EAAE;gBACjB,kCAAkC;aACnC;SACF;KACF;CACF,CAAC"}

package/dist/domains/development-agent/skills/code-review.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Code Review Skill
+ *
+ * Analyze code against user's engineering principles and standards.
+ */
+export declare const CodeReviewSkill: {
+    skill_id: string;
+    name: string;
+    description: string;
+    tags: string[];
+    risk_level: "low";
+    required_tools: string[];
+    compatible_runtimes: string[];
+    feeds_into: string[];
+    pipeline_phase: string;
+    context_model: "inherit";
+    skill_md_content: string;
+    bundled_files: {
+        path: string;
+        description: string;
+        load_when: string;
+        content: string;
+    }[];
+};
+//# sourceMappingURL=code-review.d.ts.map

package/dist/domains/development-agent/skills/code-review.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"code-review.d.ts","sourceRoot":"","sources":["../../../../domains/development-agent/skills/code-review.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,eAAO,MAAM,eAAe;;;;;;;;;;;;;;;;;;CA8I3B,CAAC"}

package/dist/domains/development-agent/skills/code-review.js

@@ -0,0 +1,146 @@
+/**
+ * Code Review Skill
+ *
+ * Analyze code against user's engineering principles and standards.
+ */
+export const CodeReviewSkill = {
+    skill_id: 'code-review',
+    name: 'Code Review',
+    description: 'Reviews code for quality, standards compliance, and alignment with engineering principles. Use when reviewing pull requests, auditing code changes, doing pre-commit review, or when the user asks to check or review code.',
+    tags: ['development', 'code-review', 'quality'],
+    risk_level: 'low',
+    required_tools: ['file-system'],
+    compatible_runtimes: ['claude-code', 'openclaw', 'manus'],
+    feeds_into: ['refactor-plan'],
+    pipeline_phase: 'verify',
+    context_model: 'inherit',
+    skill_md_content: `# Code Review
+
+## Purpose
+
+Review code changes for quality, standards compliance, and alignment with the user's engineering principles. Produce actionable feedback.
+
+## When to use
+
+- Reviewing pull requests or code changes
+- Auditing code quality against team standards
+- Pre-commit review of own changes
+- Onboarding review of unfamiliar codebases
+
+## When NOT to use
+
+- For automated linting (use linter tools directly)
+- For performance benchmarking (use profiling tools)
+- When the user wants code written, not reviewed (use refactor-plan instead)
+
+## Inputs
+
+- **target**: File paths, diff, or PR reference to review
+- **focus**: Review focus areas (optional: security, performance, readability, architecture)
+- **depth**: Review depth (quick, standard, thorough)
+
+## Outputs
+
+- **findings**: Structured review findings with:
+  - **summary**: Overall assessment
+  - **issues**: List of issues found, with severity (critical, warning, suggestion)
+  - **principle_alignment**: How the code aligns with user's engineering principles
+  - **positive_notes**: Things done well (important for balanced feedback)
+
+## Procedure
+
+### Step 1: Understand context
+
+- Read the code changes and surrounding context
+- Identify the purpose of the changes
+- Check which engineering principles are most relevant
+
+### Step 2: Review against principles
+
+For each user principle that applies:
+- Check if the code follows the principle
+- Note violations with specific line references
+- Note positive alignment
+
+### Step 3: Check for common issues
+
+- Security vulnerabilities (injection, auth, data exposure)
+- Error handling gaps
+- Edge cases not covered
+- Naming and readability
+- Test coverage gaps
+
+### Step 4: Assess architecture
+
+- Does the change fit the existing architecture?
+- Are there unnecessary dependencies introduced?
+- Is the abstraction level appropriate?
+
+### Step 5: Format feedback
+
+Structure findings by severity. Lead with the most important issues. Include positive notes.
+
+## Quality checks
+
+- [ ] All changed files reviewed
+- [ ] Feedback references specific lines/sections
+- [ ] Issues categorized by severity
+- [ ] Positive aspects noted alongside issues
+- [ ] Feedback aligns with user's engineering principles
+- [ ] Suggestions are actionable
+
+## Guardrail notes
+
+Low risk — read-only analysis. No approval needed.
+
+`,
+    bundled_files: [
+        {
+            path: 'references/REFERENCE.md',
+            description: 'Security checklist, architecture patterns, and severity classification guide',
+            load_when: 'Reviewing for security, assessing architecture, or classifying issue severity',
+            content: `# Code Review Reference
+
+## Security Vulnerability Checklist
+
+Check for these categories in order of severity:
+
+### Critical
+- **Injection**: SQL injection, command injection, XSS, template injection
+- **Authentication bypass**: Missing auth checks, broken session management
+- **Data exposure**: Secrets in code, PII in logs, unencrypted sensitive data
+- **Privilege escalation**: Missing authorization checks on sensitive operations
+
+### High
+- **CSRF**: Missing CSRF tokens on state-changing endpoints
+- **Path traversal**: Unsanitized file paths from user input
+- **Insecure deserialization**: Parsing untrusted data without validation
+- **Race conditions**: TOCTOU bugs, non-atomic check-then-act patterns
+
+### Medium
+- **Information disclosure**: Verbose error messages, stack traces in production
+- **Missing rate limiting**: Endpoints vulnerable to brute force
+- **Weak cryptography**: MD5/SHA1 for security, hardcoded keys
+
+## Severity Classification Guide
+
+| Severity | Criteria | Action |
+|----------|----------|--------|
+| **Critical** | Security vulnerability, data loss, crash in production | Must fix before merge |
+| **Warning** | Logic error, missing edge case, performance issue | Should fix, can negotiate |
+| **Suggestion** | Style, readability, alternative approach | Nice to have, author decides |
+
+## Architecture Assessment
+
+When reviewing architectural changes, check:
+
+1. **Dependency direction**: Do dependencies point inward (clean architecture)?
+2. **Abstraction level**: Is the new code at the right level of abstraction?
+3. **Single responsibility**: Does each module/class have one reason to change?
+4. **Interface boundaries**: Are public APIs minimal and well-defined?
+5. **Testability**: Can the new code be tested in isolation?
+`,
+        },
+    ],
+};
+//# sourceMappingURL=code-review.js.map

package/dist/domains/development-agent/skills/code-review.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"code-review.js","sourceRoot":"","sources":["../../../../domains/development-agent/skills/code-review.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,MAAM,CAAC,MAAM,eAAe,GAAG;IAC7B,QAAQ,EAAE,aAAa;IACvB,IAAI,EAAE,aAAa;IACnB,WAAW,EAAE,6NAA6N;IAC1O,IAAI,EAAE,CAAC,aAAa,EAAE,aAAa,EAAE,SAAS,CAAC;IAC/C,UAAU,EAAE,KAAc;IAC1B,cAAc,EAAE,CAAC,aAAa,CAAC;IAC/B,mBAAmB,EAAE,CAAC,aAAa,EAAE,UAAU,EAAE,OAAO,CAAC;IACzD,UAAU,EAAE,CAAC,eAAe,CAAC;IAC7B,cAAc,EAAE,QAAQ;IACxB,aAAa,EAAE,SAAkB;IAEjC,gBAAgB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+EnB;IAGC,aAAa,EAAE;QACb;YACE,IAAI,EAAE,yBAAyB;YAC/B,WAAW,EAAE,8EAA8E;YAC3F,SAAS,EAAE,+EAA+E;YAC1F,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwCd;SACI;KACF;CACF,CAAC"}

package/dist/domains/development-agent/skills/debugging-issues.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Debugging Issues Skill
+ *
+ * Systematic debugging with root cause investigation.
+ */
+export declare const DebuggingIssuesSkill: {
+    skill_id: string;
+    name: string;
+    description: string;
+    tags: string[];
+    risk_level: "low";
+    required_tools: string[];
+    compatible_runtimes: string[];
+    feeds_into: string[];
+    pipeline_phase: string;
+    context_model: "inherit";
+    skill_md_content: string;
+    bundled_files: {
+        path: string;
+        description: string;
+        load_when: string;
+        content: string;
+    }[];
+};
+//# sourceMappingURL=debugging-issues.d.ts.map