implementation
starsforks
How to install implementation?
omnigentx/jarvis/implementation
$npx -y skills add omnigentx/jarvis --skill implementationGuidelines for implementing features and fixes. Covers code quality, file organization, and the implementation workflow within the team context.
SKILL.md
| 1 | # Implementation Guide (DEV) |
| 2 | |
| 3 | Structured approach to implementing features and bug fixes within a multi-agent team. |
| 4 | |
| 5 | ## Implementation Workflow |
| 6 | |
| 7 | ### 1. Understand the Task |
| 8 | - Read the requirements from PM's instructions or meeting context |
| 9 | - Check existing code in the workspace |
| 10 | - Identify affected files and components |
| 11 | |
| 12 | ### 2. Plan Before Coding |
| 13 | - Break down the task into small, verifiable steps |
| 14 | - Identify dependencies and potential conflicts |
| 15 | - Determine the simplest approach that meets requirements |
| 16 | |
| 17 | ### 3. Implement |
| 18 | - Write clean, self-documenting code |
| 19 | - Follow existing project conventions and patterns |
| 20 | - Keep changes focused — one concern per commit |
| 21 | - Add error handling from the start |
| 22 | |
| 23 | ### 4. Verify Your Work |
| 24 | - Run existing tests to check for regressions |
| 25 | - Test your changes manually if applicable |
| 26 | - Ensure code is syntactically correct (no import errors, no typos) |
| 27 | |
| 28 | ### 5. Report |
| 29 | - Summarize what you changed and why |
| 30 | - List files modified |
| 31 | - Note any concerns or trade-offs |
| 32 | |
| 33 | ## Code Quality Standards |
| 34 | |
| 35 | - **Early returns** over nested conditions |
| 36 | - **Descriptive names** — avoid `utils`, `helpers`, `misc` |
| 37 | - **Small functions** — under 50 lines when possible |
| 38 | - **Small files** — under 200 lines when possible |
| 39 | - **DRY** — extract common logic into reusable functions |
| 40 | - **Error handling** — validate inputs, handle edge cases |
| 41 | - **Comments** — explain "why", not "what" |
| 42 | |
| 43 | ## In Meeting Context |
| 44 | |
| 45 | When working in a meeting: |
| 46 | - Use `filesystem` tools to read/write code during your turns |
| 47 | - Show concrete changes in your `speak()` responses |
| 48 | - If QE gives a FAIL verdict, fix the issues immediately using your tools |
| 49 | - Don't just describe what you'll do — actually do it during the meeting |
People who liked this also viewed
6 picksType
- hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026
- request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026
- explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026
- ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
