
pydev-feature
by luvisaisa
comprehensive claude workflow + commands for your software development needs :) easy install
SKILL.md
name: pydev-feature description: 6-step feature implementation workflow for building specific features, components, or modules. use when implementing features from todo lists, user requests feature work, or invoked by pydev-workflow step 07. handles task analysis, design, implementation, testing, integration, and cleanup. allowed-tools: Read, Glob, Grep, Write, Edit, Bash(git:), Bash(pytest:), Bash(mypy:), Bash(ruff:), Bash(npm:*)
pydev-feature: Feature Implementation Workflow
execute 6-step structured feature development process.
when to apply this skill
- user says "implement [feature]", "build [component]", "add [functionality]"
- invoked by pydev-workflow during step 07 (implementation)
- user provides a todo list with major/mid-level/minor tasks
- user says "run pydev-feature for this todo"
- user mentions specific pydev-feature steps (task analysis, design, implementation, testing, integration, cleanup)
- user asks to add tests, integrate code, or cleanup implementation
workflow entry points
can start at different steps based on context:
| entry point | trigger phrases | context signals |
|---|---|---|
| step 01 (task analysis) | "implement [feature]", "build [component]" | new feature, unclear scope |
| step 02 (design) | "design this", "plan implementation" | scope clear, need implementation approach |
| step 03 (implementation) | "code this", "write the code", design provided | ready to write code |
| step 04 (testing) | "add tests for", "test this code" | code exists, needs tests |
| step 05 (integration) | "connect this", "integrate [feature]" | tested code needs wiring |
| step 06 (cleanup) | "clean up", "document this" | working feature needs polish |
core principles
always read CLAUDE.md first
check project root for CLAUDE.md - contains project-specific best practices and patterns.
80% certainty rule
- above 80% certain: execute autonomously, document decisions
- below 80% certain: stop, explain uncertainty, ask specific questions
git requirements
- email: isa.lucia.sch@gmail.com
- user: luvisaisa
- branch: main
- commit triggers:
- mid-level task completion: commit implementation
- major task completion: push to remote
- test completion: commit tests
- integration complete: commit integration
- cleanup complete: commit docs
code conventions
- comments always lowercase, no emojis
- type hints always required (python)
- follow existing patterns in codebase
- one concept per file (~300 lines max)
documentation practices
- update existing files, do not create new ones without asking
- timestamp documentation updates
- maintain DEV_LOG.md with feature summaries
- update ARCHITECTURE.md if architecture changes
- update IMPLEMENTATION_PLAN.md progress if part of pydev-workflow
todo list format
hierarchical structure with 3 levels:
## TODO: [Feature/Component Name]
Refs: IMPLEMENTATION_PLAN.md Section [X.X]
* Major Task: [High-level goal]
* Mid-level Task: [Concrete deliverable]
* Minor task: [Specific action]
* Minor task: [Specific action]
* Mid-level Task: [Concrete deliverable]
* Minor task: [Specific action]
| level | scope | commit trigger |
|---|---|---|
| major task | feature or component | commit after all mid-level tasks complete |
| mid-level task | concrete deliverable | commit after completion |
| minor task | specific action | part of mid-level commit |
6-step workflow
step 01: task analysis
id: 01-task-analysis
output: task analysis (inline or document for complex features)
checkpoint: only if below 80% certainty
commit: docs: task analysis for [feature] (if document created)
understand scope, map dependencies, identify risks.
actions:
- read CLAUDE.md for project patterns
- read ARCHITECTURE.md to understand system
- read IMPLEMENTATION_PLAN.md if part of pydev-workflow
- parse todo into discrete work units
- identify files to create/modify
- map dependencies on existing components
- identify risks and edge cases
- verify alignment with existing architecture
80% certainty check:
- do i understand what needs to be built?
- do i know where it fits in the codebase?
- are dependencies clear?
- are edge cases identified?
if any answer uncertain, ask before proceeding.
output format (inline for simple, document for complex):
[STEP 1/6] TASK ANALYSIS
scope: [what needs to be built]
files affected:
| file | action | reason |
|------|--------|--------|
| [path] | CREATE/MODIFY | [why] |
dependencies:
| dependency | status | notes |
|------------|--------|-------|
| [component] | exists/needs creation | [notes] |
risks/edge cases:
| risk | impact | mitigation |
|------|--------|------------|
| [description] | high/med/low | [how to handle] |
implementation sequence:
1. [first thing to build]
2. [second thing]
3. [third thing]
use slash commands:
/find-usagesto find usage of related code/explainto understand existing components/traceto trace execution paths
step 02: feature design
id: 02-design
output: design notes (inline or document for complex features)
checkpoint: only if below 80% certainty or complex design
commit: docs: feature design for [feature] (if document created)
plan implementation approach before writing code.
actions:
- review task analysis
- design component structure
- define function/class signatures
- plan error handling approach
- identify test scenarios
- verify consistency with existing patterns (check CLAUDE.md)
- create design with interfaces and data flow
80% certainty check:
- is design consistent with existing architecture?
- are interfaces clear and complete?
- is error handling comprehensive?
output format:
[STEP 2/6] FEATURE DESIGN
approach: [high-level implementation strategy]
components:
| component | purpose | location | dependencies |
|-----------|---------|----------|--------------|
| [name] | [what it does] | [file path] | [what it needs] |
interfaces:
```python
def function_name(param: Type) -> ReturnType:
"""brief description."""
data flow:
flowchart LR
A[Input] --> B[Validate]
B --> C[Process]
C --> D[Output]
test scenarios:
| scenario | input | expected output |
|---|---|---|
| happy path | [input] | [output] |
| edge case | [input] | [output] |
| error case | [input] | [error] |
**use slash commands**:
- `/explain` to understand patterns to follow
- `/refactor-plan` if refactoring is needed
### step 03: implementation
**id**: `03-implementation`
**output**: source files
**commit**: after each mid-level task completion
**push**: after major task completion
write the code following the design.
**actions**:
1. implement each work unit in sequence per todo
2. follow existing code patterns from codebase
3. add docstrings and comments (lowercase, no emojis)
4. verify types with mypy after each file
5. format with ruff after changes
6. commit after each mid-level task completion
7. push after major task completion
**progress format**:
[STEP 3/6] IMPLEMENTATION
[IMPL] path/to/file.py action: CREATE status: COMPLETE summary: implemented [what was done]
[IMPL] path/to/other.py action: MODIFY status: COMPLETE summary: added [what was added]
mid-level task complete: [task name] ✓ committed: feat: [component] - [what was implemented]
**comment style** (always lowercase, no emojis):
```python
# validate input before processing
def process_data(input: DataType) -> Result:
"""
process the input data and return result.
args:
input: the data to process
returns:
processed result
"""
# check for empty input
if not input:
return None
# transform and return
return transform(input)
commit after each mid-level task:
git add [files]
git commit -m "feat: [component] - [what was implemented]"
push after major task:
git push origin main
use slash commands:
/new-modelfor creating sqlalchemy models/new-endpointfor creating api endpoints/new-servicefor creating service modules/new-adapterfor creating data adapters/new-componentfor creating react components/fix-typesto fix type errors/fix-lintto fix linting issues/fix-importsto organize imports
step 04: testing
id: 04-testing
output: test files, passing tests
commit: test: [component] - [what was tested]
push: after test commit
write and run tests for the implementation.
actions:
- write tests for each component (follow TEST_STRATEGY.md if exists)
- include happy path, edge cases, error handling
- run tests with coverage
- fix failures (up to 3 auto-retry attempts)
- verify coverage is acceptable
- commit tests
- push to remote
test output format:
[STEP 4/6] TESTING
[TEST] [component]
test_happy_path ........................ PASS
test_edge_case ......................... PASS
test_error_handling .................... PASS
test_integration ....................... PASS
----------------------------------------
SUMMARY: 4 passed / 0 failed / 0 skipped
----------------------------------------
coverage: [X]% lines, [Y]% branches
if failures occur:
test_edge_case ......................... FAIL
expected: [expected value]
actual: [actual value]
[FIX ATTEMPT 1/3]
analysis: [what went wrong]
fix: [what was changed]
[RETRY] test_edge_case ................. PASS
if failures persist after 3 attempts: stop, report issue, ask for guidance.
commit:
git add tests/
git commit -m "test: [component] - [what was tested]"
git push origin main
use slash commands:
/test-generateto generate comprehensive test suites/test-edge-casesto generate edge case tests/testto run tests with coverage/verifyto run full verification suite
step 05: integration
id: 05-integration
output: integrated feature
commit: feat: integrate [feature] with [system component]
push: after integration commit
connect new code to existing system.
actions:
- update imports and module wiring
- connect to existing components per ARCHITECTURE.md
- update registries or factories if needed
- run broader test suite for regression check
- verify feature works in full system context
- fix any integration issues
- commit integration
- push to remote
output format:
[STEP 5/6] INTEGRATION
connections made:
| from | to | how |
|------|-----|-----|
| [new component] | [existing component] | [import/call/event] |
updated files:
| file | change |
|------|--------|
| [path] | [what was updated] |
regression check:
running full test suite...
----------------------------------------
SUMMARY: [X] passed / [Y] failed / [Z] skipped
----------------------------------------
[if failures, list and explain]
commit:
git add .
git commit -m "feat: integrate [feature] with [system component]"
git push origin main
use slash commands:
/testto run integration tests/verifyto run full verification suite/debugif integration issues occur/find-usagesto verify all connections
step 06: cleanup and documentation
id: 06-cleanup
output: clean, documented code
commit: docs: [feature] implementation complete - dev log updated
push: after cleanup commit
polish code and update documentation.
actions:
- review code for clarity (small refactoring only)
- ensure all docstrings complete (lowercase comments)
- update ARCHITECTURE.md if new components added (timestamped)
- add entry to DEV_LOG.md with implementation summary
- update IMPLEMENTATION_PLAN.md progress if part of pydev-workflow
- final lint/format pass
- commit documentation
- push to remote
do not create new documentation files - update existing ones.
update ARCHITECTURE.md (if architecture changed):
## [Relevant Section]
> Last updated: [YYYY-MM-DD]
[add new component/flow documentation with mermaid diagrams]
add DEV_LOG.md entry:
### [YYYY-MM-DD] [Feature Name] Implemented {#feature-id}
**summary**: [what was accomplished]
**changes**:
| component | change |
|-----------|--------|
| [component] | [what changed] |
**files added/modified**:
| file | action | purpose |
|------|--------|---------|
| [path] | CREATE/MODIFY | [why] |
**decisions made**:
| decision | rationale |
|----------|-----------|
| [decision] | [why] |
**test coverage**: [X]% lines
**next steps**:
- [follow-up tasks if any]
---
final output:
[STEP 6/6] CLEANUP AND DOCUMENTATION
refactoring: [changes made or "none needed"]
documentation updated:
| document | section | change |
|----------|---------|--------|
| ARCHITECTURE.md | [section] | [what was added] |
| DEV_LOG.md | entries | added implementation summary |
| IMPLEMENTATION_PLAN.md | [unit] | marked complete |
lint/format: PASS
✅ feature complete: [feature name]
final commit:
git add .
git commit -m "docs: [feature] implementation complete - dev log updated"
git push origin main
use slash commands:
/documentto generate or update documentation/architecture-syncto sync architecture with codebase/fix-lint,/fix-types,/fix-importsfor final cleanup/verifyfor final verification
context-aware execution
analyze user messages for workflow adjustments:
| user input | skill action |
|---|---|
| "skip the design" | jump directly to step 03 (implementation) |
| "just write tests" | jump to step 04 (testing) |
| "analyze this first" | execute step 01 only, wait for approval |
| "implement this todo" | start at step 01, proceed through step 06 |
| "continue" | resume from last completed step |
| "go back to [step]" | return to specified step |
| "pause" | stop and checkpoint current progress |
progress tracking
[pydev-feature PROGRESS]
feature: [feature name]
refs: IMPLEMENTATION_PLAN.md Section [X.X]
✅ 01: task analysis - scope and dependencies mapped
✅ 02: feature design - components and interfaces defined
✅ 03: implementation - code complete
🔄 04: testing - 3/5 test scenarios complete
⏸️ 05: integration - pending
⏸️ 06: cleanup - pending
commits:
- feat: [component] - [description]
- feat: [component] - [description]
- test: [component] - [description]
integration with pydev-workflow
when invoked by pydev-workflow during step 07:
- receive unit todo from IMPLEMENTATION_PLAN.md
- execute steps 01-06 for the unit
- update IMPLEMENTATION_PLAN.md progress
- return control to pydev-workflow
- pydev-workflow proceeds to next unit or step
file operations guidance
prefer existing files:
- always edit existing code files when possible
- create new files only when:
- implementing new components/modules
- adding tests for new code
- scaffolding requires new structure
avoid:
- creating new documentation files without asking
- duplicating existing functionality
- over-engineering simple features
automatic command usage
during implementation, automatically use relevant commands:
| task type | auto-use command |
|---|---|
| creating sqlalchemy model | /new-model |
| creating api endpoint | /new-endpoint |
| creating service module | /new-service |
| creating data adapter | /new-adapter |
| creating react component | /new-component |
| generating tests | /test-generate |
| analyzing bugs | /debug |
| finding code usages | /find-usages |
| before committing | /verify |
quick reference
git config
git config user.email "isa.lucia.sch@gmail.com"
git config user.name "luvisaisa"
commit types
feat:- new feature implementationfix:- bug fixtest:- test changesrefactor:- code refactoringdocs:- documentation changes
comment rules
- always lowercase
- never use emojis
- be concise and clear
80% rule
- above 80% certain: execute, document decisions
- below 80% certain: stop, ask specific questions
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon