VinaywhoandClaude Opus 4.7
4f66eb9c08
Qoder ships an Agent Skills system at .qoder/skills/{name}/SKILL.md with
slash-command invocation, mapping cleanly onto the existing transformer
pipeline. Adds Qoder as a 13th first-class harness:
- PROVIDER_PLACEHOLDERS entry in scripts/lib/utils.js (model, config_file,
ask_instruction, command_prefix) mirroring the Pi/Rovo Dev shape.
- PROVIDERS entry in scripts/lib/transformers/providers.js with
configDir=.qoder and the OpenCode/Claude Code frontmatter field set
(user-invocable, argument-hint, license, compatibility, metadata,
allowed-tools), since Qoder docs explicitly support those.
- transformQoder named export in scripts/lib/transformers/index.js for
test-spy parity (kept per CLAUDE.md guidance, even though build.js uses
PROVIDERS directly).
- .qoder added to PROVIDER_DIRS in bin/commands/skills.mjs so the CLI
detects existing Qoder installs.
- HARNESSES.md updated: official docs row, frontmatter support column,
directory structure row, and "Last verified" date bumped.
- DEVELOP.md reference link added.
- .github/ISSUE_TEMPLATE/feature_request.md and PULL_REQUEST_TEMPLATE.md
extended with Qoder in the provider checklists.
- Built .qoder/skills/impeccable/ tree committed (per CLAUDE.md harness
output dirs are tracked so npx skills can read them at install time).
The dynamic providers.test.js loop picks up Qoder automatically; all
non-prefix Qoder cases pass. The pre-existing Windows-only prefix-test
flake affects every provider equally and is out of scope for this PR.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.4 KiB
Extract Flow
Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
Step 1: Discover the Design System
Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
CRITICAL: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
Step 2: Identify Patterns
Look for extraction opportunities in the target area:
- Repeated components: Similar UI patterns used 3+ times (buttons, cards, inputs)
- Hard-coded values: Colors, spacing, typography, shadows that should be tokens
- Inconsistent variations: Multiple implementations of the same concept
- Composition patterns: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
- Type styles: Repeated font-size + weight + line-height combinations
- Animation patterns: Repeated easing, duration, or keyframe combinations
Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
Step 3: Plan Extraction
Create a systematic plan:
- Components to extract: Which UI elements become reusable components?
- Tokens to create: Which hard-coded values become design tokens?
- Variants to support: What variations does each component need?
- Naming conventions: Component names, token names, prop names that match existing patterns
- Migration path: How to refactor existing uses to consume the new shared versions
IMPORTANT: Design systems grow incrementally. Extract what is clearly reusable now, not everything that might someday be reusable.
Step 4: Extract & Enrich
Build improved, reusable versions:
- Components: Clear props API with sensible defaults, proper variants for different use cases, accessibility built in (ARIA, keyboard navigation, focus management), documentation and usage examples
- Design tokens: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
- Patterns: When to use this pattern, code examples, variations and combinations
Step 5: Migrate
Replace existing uses with the new shared versions:
- Find all instances: Search for the patterns you extracted
- Replace systematically: Update each use to consume the shared version
- Test thoroughly: Ensure visual and functional parity
- Delete dead code: Remove the old implementations
Step 6: Document
Update design system documentation:
- Add new components to the component library
- Document token usage and values
- Add examples and guidelines
- Update any Storybook or component catalog
NEVER:
- Extract one-off, context-specific implementations without generalization
- Create components so generic they are useless
- Extract without considering existing design system conventions
- Skip proper TypeScript types or prop documentation
- Create tokens for every single value (tokens should have semantic meaning)
- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.