Implement github feature

Skill AgnosticUI/agnosticui/.claude/skills/implement-github-feature

AgnosticUI Local (v2) is a CLI-based UI component library that copies components directly into your project. Works with AI tools, agent-driven UIs, and prompt-ready workflows.

Install

npx -y skills add AgnosticUI/agnosticui --skill implement-github-feature

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Design and implement a new feature or component from a GitHub issue. Use for net-new functionality, not bug fixes.

SKILL.md

6.4 KB, as published. Nobody here has run it

Usage: /implement-github-feature ISSUE_NUMBER

Example: /implement-github-feature 281

Implement GitHub feature request $ARGUMENTS following AgnosticUI conventions, accessibility standards, and CSS-first principles.

Setup

Read project context
- Read .claude/PROJECT_CONTEXT.md
- Understand:
  - Repository structure
  - Design principles
  - Accessibility requirements
  - Branch conventions
  - Component workflows

Phase 0: Safety Checks (Required)

Verify clean starting state
- Run git status
- Confirm:
  - Working directory is clean
  - Current branch is master
- If either condition fails:
  - STOP
  - Ask the user to resolve before continuing

Phase 1: Branching

Propose feature branch
- Follow convention: issue-$ARGUMENTS/short-descriptive-name
- Example: issue-281/selection-card-group
- Run:
```
git checkout -b issue-$ARGUMENTS/short-description
```
- WAIT FOR USER APPROVAL of branch name before proceeding

Phase 2: Issue Analysis & Intent Extraction (No Code)

Analyze the GitHub issue
- Fetch full details:
```
gh issue view $ARGUMENTS
```
- Extract and summarize:
  - Feature goals
  - Non-goals / constraints
  - API expectations
  - Accessibility requirements
  - Styling and theming expectations
  - Framework implications (Lit / React / Vue)
Study existing related components
- Identify components this feature will compose or resemble
- Read their implementations in v2/lib/src/components/
- Note patterns for:
  - Props and attributes
  - Slot usage
  - CSS custom properties
  - ::part exposure
  - Event dispatching
  - Accessibility implementation
- This ensures consistency with established AgnosticUI conventions
Confirm feature classification
- This is a:
  - Net-new component OR
  - Major enhancement (not a bug fix)
- If scope appears ambiguous:
  - Ask the user before proceeding

Phase 3: Design Proposal (Hard Stop Before Code)

Propose high-level design
- Identify:
  - New components to be created
  - Public vs internal APIs
  - Required props vs optional props
  - Slot usage and responsibilities
  - Accessibility model (labels, roles, keyboard behavior)
  - Shadow DOM strategy (::part, ::slotted)
- Explicitly call out:
  - Web Component constraints
  - CSS-first decisions
  - What is intentionally not supported
Propose file & directory layout
- Core components:
  - v2/lib/src/components/...
- Documentation:
  - v2/site/docs/components/...
- Storybook playgrounds:
  - Lit
  - React
  - Vue
- Examples:
  - Lit / React / Vue test examples
WAIT FOR USER APPROVAL

Do not create files
Do not write code
Proceed only after explicit approval of:
- API shape
- Accessibility approach
- Styling strategy

Phase 4: Scaffolding (Minimal, Intentional)

Create initial scaffolding
- Create component directories
- Add placeholder files where appropriate
- Add minimal README or doc stubs if needed
- No implementation logic yet
Show scaffolding diff
- Use git diff
- Explain what was created and why
- WAIT FOR USER APPROVAL

Phase 5: Core Implementation (Lit Web Components First)

Implement core component(s)
- Work only in:
  - v2/lib/src/components/
- Follow:
  - CSS-first approach
  - Design token usage
  - Accessibility requirements
- Ensure:
  - Keyboard interaction works
  - Labels and semantics are correct
  - Shadow DOM parts are intentional and minimal
Verify build
- Run npm run build in v2/lib/
- Fix any compilation errors
- Run npm run lint if available
Pause for review
- Explain:
  - DOM structure
  - Slot behavior
  - ::part surface
  - Accessibility decisions
- WAIT FOR USER APPROVAL before proceeding

Phase 6: Framework Integrations

Integrate with frameworks
- React playground
- Vue playground
- Lit playground
- APIs should feel idiomatic but map 1:1 conceptually
Add Storybook stories
- Demonstrate:
  - Core use cases
  - Variants
  - Accessibility states
- Ensure consistency across frameworks

Phase 7: Documentation & Examples

Write documentation
- Add VitePress docs:
  - API
  - Slots vs props
  - Styling guidance
  - Accessibility notes
- Update or add playbooks if applicable
Update examples
- Verify examples compile and behave correctly
- Keep examples minimal and educational

Phase 8: Final Review & Commit

Final verification
- Review:
  - git diff
  - Accessibility behavior
  - Styling hooks
  - API consistency
- Ensure no accidental breaking changes
Prepare commit
- Stage changes:
```
git add .
```
- Commit message format:
```
Add #$ARGUMENTS: [concise feature description]
```
- Show commit contents
- WAIT FOR USER APPROVAL before committing

Phase 9: Handoff

Explain next steps

User is on branch: issue-$ARGUMENTS/...
Review with:
```
git diff master
```

Push when ready:

git push -u origin issue-$ARGUMENTS/...

Create PR:

gh pr create --base master --head issue-$ARGUMENTS/...

Important Rules

NEVER work directly on master
NEVER push without explicit user permission
ALWAYS stop at design gates
ALWAYS prioritize accessibility over convenience
Prefer slots for layout, props for semantics
CSS custom properties > ::part > ::slotted
Do not assume intent — if unclear, ask