
pydev-workflow
by luvisaisa
comprehensive claude workflow + commands for your software development needs :) easy install
SKILL.md
name: pydev-workflow description: comprehensive 12-step project development workflow from initialization through deployment. use when starting a new project, continuing project development, or user mentions project steps, architecture planning, implementation planning, or references pydev-workflow steps 01-12. allowed-tools: Read, Glob, Grep, Write, Edit, Bash(git:), Bash(pytest:), Bash(alembic:), Bash(npm:)
pydev-workflow: Project-Level Development Workflow
execute 12-step structured development process for complete project implementation.
when to apply this skill
- user says "initialize pydev-workflow" or "start pydev-workflow"
- user says "continue pydev-workflow" or "resume project"
- user asks about project status, current step, or workflow progress
- user mentions specific step numbers (01-12) or step names (project-init, system-architecture, etc.)
- user requests architecture design, implementation planning, or deployment prep
- project has PROJECT_FOUNDATION.md, ARCHITECTURE.md, or IMPLEMENTATION_PLAN.md files
workflow entry points
can start at any step based on context:
| entry point | trigger phrases | context signals |
|---|---|---|
| step 01 | "initialize project", "start new project" | no PROJECT_FOUNDATION.md exists |
| step 02 | "design architecture", "define components" | PROJECT_FOUNDATION.md exists |
| step 03 | "define data models", "design schema" | ARCHITECTURE.md exists but no data models section |
| step 06 | "create implementation plan" | ARCHITECTURE.md complete |
| step 07 | "start implementation", "begin coding" | IMPLEMENTATION_PLAN.md exists |
| step 11 | "finalize docs", "write documentation" | implementation complete |
| any step | "continue workflow", "resume" | check existing docs for current step |
core principles
always read CLAUDE.md first
check project root for CLAUDE.md - contains project-specific best practices, patterns, and context.
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 frequently: after meaningful changes per commit triggers table
documentation practices
- update existing files, do not create new ones without evaluation
- timestamp all documentation updates:
> Last updated: [YYYY-MM-DD] - use mermaid.js for all diagrams
- maintain DEV_LOG.md with implementation summaries
- comments always lowercase, no emojis
12-step workflow
step 01: project initialization
id: 01-project-init
output: PROJECT_FOUNDATION.md
checkpoint: approve foundation before design
commit: docs: PROJECT_FOUNDATION.md - initial project definition
establish goals, scope, constraints, high-level architecture.
actions:
- read CLAUDE.md if exists
- gather project requirements from user
- define scope and constraints
- create PROJECT_FOUNDATION.md with:
- project overview
- goals and objectives
- scope boundaries
- constraints and assumptions
- high-level architecture vision
- checkpoint with user for approval
- commit foundation document
- update DEV_LOG.md
step 02: system architecture
id: 02-system-architecture
input: PROJECT_FOUNDATION.md
output: ARCHITECTURE.md
checkpoint: approve component structure
commit: docs: ARCHITECTURE.md - system architecture defined
define components, boundaries, communication patterns.
actions:
- read PROJECT_FOUNDATION.md
- design component structure
- define component responsibilities and boundaries
- map communication patterns (sync/async, protocols)
- identify shared infrastructure (logging, config, errors)
- create architecture diagrams using mermaid.js
- create ARCHITECTURE.md with component map section
- checkpoint if uncertain (below 80%)
- commit architecture document
- update DEV_LOG.md
use slash command: /architecture-sync when updating existing ARCHITECTURE.md
step 03: data models
id: 03-data-models
input: PROJECT_FOUNDATION.md, ARCHITECTURE.md
output: update ARCHITECTURE.md with data models section
checkpoint: approve data structures
commit: docs: ARCHITECTURE.md - data models added
define entities, relationships, storage strategy.
actions:
- read ARCHITECTURE.md
- identify all entities from architecture
- define entity attributes and types
- map relationships (1:1, 1:N, N:M)
- choose storage approach per entity
- design indexes and query patterns
- add data models section to ARCHITECTURE.md with:
- entity relationship diagram (mermaid erDiagram)
- entity definitions table
- indexes and query patterns
- checkpoint if uncertain
- commit update
- update DEV_LOG.md
use slash command: /architecture-sync after updating
step 04: core logic design
id: 04-core-logic
input: PROJECT_FOUNDATION.md, ARCHITECTURE.md
output: update ARCHITECTURE.md with core logic section
checkpoint: approve logic approach
commit: docs: ARCHITECTURE.md - core logic added
define algorithms, business rules, processing flows.
actions:
- read ARCHITECTURE.md
- identify core algorithms needed
- define business rules and validation logic
- design processing flows and state machines
- create type system if applicable
- define computed properties and derived data
- add core logic section to ARCHITECTURE.md with:
- processing flows (mermaid flowchart)
- business rules table
- algorithms with complexity
- state machines if applicable (mermaid stateDiagram)
- checkpoint if uncertain
- commit update
- update DEV_LOG.md
use slash command: /architecture-sync after updating
step 05: interface design
id: 05-interfaces
input: all previous ARCHITECTURE.md sections
output: update ARCHITECTURE.md with interfaces section
checkpoint: approve public interfaces
commit: docs: ARCHITECTURE.md - interfaces added
define apis, contracts, input/output shapes.
actions:
- read ARCHITECTURE.md
- define all public interfaces (apis, clis, events)
- specify request/response shapes
- define error responses and codes
- document authentication/authorization
- add interfaces section to ARCHITECTURE.md with:
- api overview
- endpoint definitions
- request/response flow (mermaid sequenceDiagram)
- event contracts if applicable
- cli interface if applicable
- checkpoint if uncertain
- commit update
- update DEV_LOG.md
use slash commands:
/api-docsto generate api documentation/architecture-syncafter updating
step 06: implementation plan
id: 06-impl-plan
input: all previous documents
output: IMPLEMENTATION_PLAN.md
checkpoint: approve build sequence
commit: plan: IMPLEMENTATION_PLAN.md - implementation plan complete
break designs into buildable units with sequence.
actions:
- read all design documents
- break system into implementation units
- define dependencies between units
- sequence units respecting dependencies
- estimate complexity per unit (low/medium/high)
- identify parallelizable work
- create todo lists per unit using hierarchical format:
- major task (feature/component level)
- mid-level task (concrete deliverable)
- minor task (specific action)
- create IMPLEMENTATION_PLAN.md with:
- overview (total units, estimated complexity, critical path)
- implementation sequence
- unit definitions with todos and acceptance criteria
- risk register
- checkpoint for approval
- commit plan
- update DEV_LOG.md
step 07: implementation
id: 07-implementation
input: IMPLEMENTATION_PLAN.md, all design docs
output: source code
triggers: pydev-feature skill for each unit
checkpoint: review at unit completion
commit: per mid-level task completion
build the system following the plan.
actions:
- read IMPLEMENTATION_PLAN.md
- for each unit in sequence:
- invoke pydev-feature skill with unit todo
- track progress against plan
- commit after each mid-level task
- push after each major task
- update IMPLEMENTATION_PLAN.md progress
- flag deviations from plan
- update DEV_LOG.md after each unit
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/next.js components/testto run tests for implemented units/verifyto run full verification suite/checkpointwhen pausing for review
step 08: test strategy
id: 08-test-strategy
input: all design docs, implementation
output: TEST_STRATEGY.md
checkpoint: approve test approach
commit: docs: TEST_STRATEGY.md - test strategy defined
define testing approach and coverage targets.
actions:
- read implementation and design docs
- define test categories (unit, integration, e2e)
- set coverage targets
- identify critical paths requiring thorough testing
- plan test data strategy
- define test environments
- create TEST_STRATEGY.md with:
- coverage targets table
- test categories (unit, integration, e2e)
- test data strategy
- ci integration approach
- checkpoint if uncertain
- commit strategy
- update DEV_LOG.md
step 09: test implementation
id: 09-test-impl
input: TEST_STRATEGY.md, source code
output: test files
triggers: pydev-feature skill for test implementation
checkpoint: review coverage
commit: test: [component] - [what was tested]
write tests following strategy.
actions:
- read TEST_STRATEGY.md
- create test structure
- write unit tests for critical paths first
- write integration tests
- run full suite, report coverage
- fill coverage gaps
- track progress with coverage reports
- commit after test completion
- update DEV_LOG.md
use slash commands:
/test-generateto generate comprehensive test suites/test-edge-casesto analyze and generate edge case tests/testto run tests with coverage/verifyto run full verification suite
step 10: integration and refinement
id: 10-integration
input: all implementation and tests
output: integrated system
checkpoint: approve integration
commit: refactor: integration cleanup and verification
connect components, verify system works end-to-end.
actions:
- verify all components connect properly
- run integration test suite
- identify and fix integration gaps
- performance check on critical paths
- refactor for consistency
- run full verification
- commit cleanup
- update DEV_LOG.md
use slash commands:
/testfor integration tests/verifyfor full verification suite/refactor-planif major refactoring needed/extractto extract reusable code/fix-lint,/fix-types,/fix-importsfor cleanup
step 11: documentation
id: 11-documentation
input: all previous outputs
output: updated README.md, consolidated docs
checkpoint: review docs
commit: docs: README.md - documentation finalized
finalize user and developer documentation.
actions:
- write/update README.md with quick start
- ensure ARCHITECTURE.md is complete and current
- verify all mermaid diagrams render correctly
- add inline code comments where helpful (lowercase, no emojis)
- evaluate if additional docs needed (ask before creating)
- create/update README.md with:
- project description
- quick start
- architecture overview with mermaid diagram
- development setup
- testing instructions
- documentation index
- update DEV_LOG.md
- commit documentation
use slash commands:
/documentto generate or update documentation/api-docsto generate api documentation/architecture-syncto sync architecture.md with codebase
step 12: deployment prep
id: 12-deployment
input: complete system
output: deployment config, ci/cd
checkpoint: approve deployment strategy
commit: config: deployment configuration
prepare for deployment.
actions:
- create/update dockerfile if applicable
- define environment variables
- set up ci/cd pipeline
- create deployment documentation
- define rollback procedure
- commit deployment config
- update DEV_LOG.md
- final project summary
resuming workflow
when user says "continue workflow" or "resume":
-
check for existing documentation:
ls -la PROJECT_FOUNDATION.md ARCHITECTURE.md IMPLEMENTATION_PLAN.md TEST_STRATEGY.md DEV_LOG.md -
determine current step based on what exists:
- PROJECT_FOUNDATION.md only → at step 02
- ARCHITECTURE.md exists → check completeness (sections), proceed to next incomplete
- IMPLEMENTATION_PLAN.md exists → at step 07 (implementation)
- implementation complete but no TEST_STRATEGY.md → at step 08
- TEST_STRATEGY.md exists → at step 09 or 10
-
read CLAUDE.md for current status if exists
-
read DEV_LOG.md for recent activity
-
report current status:
[pydev-workflow STATUS] current step: [step number and name] completed: [list of completed steps] in progress: [current work] next: [what comes next] -
ask user to confirm or adjust direction
context-aware execution
analyze user messages for context clues:
| user input | skill action |
|---|---|
| "design the api" | jump to step 05 (interface design) |
| "create implementation plan" | jump to step 06 |
| "start coding" | jump to step 07, invoke pydev-feature |
| "write tests" | jump to step 09 |
| "let's document this" | jump to step 11 |
| "continue where we left off" | resume from current step |
| "skip to [step name]" | jump to requested step |
| "go back to [step name]" | return to previous step |
progress tracking format
[pydev-workflow PROGRESS]
✅ 01: project initialization - PROJECT_FOUNDATION.md created
✅ 02: system architecture - ARCHITECTURE.md with components
✅ 03: data models - added to ARCHITECTURE.md
✅ 04: core logic - added to ARCHITECTURE.md
🔄 05: interface design - in progress
⏸️ 06: implementation plan - pending
⏸️ 07: implementation - pending
⏸️ 08: test strategy - pending
⏸️ 09: test implementation - pending
⏸️ 10: integration - pending
⏸️ 11: documentation - pending
⏸️ 12: deployment - pending
integration with pydev-feature
during step 07 (implementation), invoke pydev-feature skill for each implementation unit:
[invoking pydev-feature for unit: [unit name]]
unit todo:
* major task: [goal]
* mid-level task: [deliverable]
* minor task: [action]
[pydev-feature will handle task-analysis through cleanup]
[returns when unit complete]
[updating IMPLEMENTATION_PLAN.md progress]
file structure maintained
project/
├── CLAUDE.md # best practices (read first)
├── DEV_LOG.md # timestamped development log
├── PROJECT_FOUNDATION.md # project definition
├── ARCHITECTURE.md # system design with mermaid
├── IMPLEMENTATION_PLAN.md # build sequence and todos
├── TEST_STRATEGY.md # testing approach
├── README.md # user-facing docs
├── src/ # source code
└── tests/ # test files
quick reference
git config
git config user.email "isa.lucia.sch@gmail.com"
git config user.name "luvisaisa"
commit types
docs:- documentation changesplan:- planning documentsfeat:- new feature implementationfix:- bug fixtest:- test changesrefactor:- code refactoringconfig:- configuration changes
available slash commands
- core:
/verify,/checkpoint,/compact - scaffolding:
/new-model,/new-endpoint,/new-service,/new-adapter,/new-component - database:
/migration,/migrate-check,/seed - testing:
/test,/test-generate,/test-edge-cases - debug:
/debug,/explain,/find-usages,/trace - refactoring:
/extract,/rename-safe,/refactor-plan - documentation:
/document,/api-docs,/architecture-sync - git:
/commit,/changelog,/pr-prep - quick-fixes:
/fix-lint,/fix-imports,/fix-types
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon