1c-feature-dev

/1c-feature-dev — Full cycle of 1C development

Full cycle of 1C customization development using specifications, an adaptive approach, and integration with tools (RLM, BSL LSP, MCP).

OPERATING PRINCIPLES

• Adaptivity: The number of agents depends on complexity (1-4+)
• Early validation: Plan review BEFORE implementation
• Requirements clarification: All ambiguities are resolved BEFORE design
• Atomic stages: With acceptance criteria and checks
• Progress tracking: Each phase is marked as completed

WORKFLOW (9 PHASES)

Phase 0: Complexity assessment

Goal: Understand the scope of the task and choose a strategy

Initial request: $ARGUMENTS

Actions:

1. Create a task list with all phases
2. Create the structure: openspec/changes/[feature-name]/
3. Assess complexity:
   • Simple: A small change, obvious implementation
   • Medium: Several modules, requires understanding of the architecture
   • Complex: A large customization, several subsystems
   • Critical: Architectural changes, high risks
4. Choose a strategy (number of agents)
5. Save: openspec/changes/[feature-name]/phase0-complexity.md

Phase 1: Discovery

Goal: Understand what needs to be built

Actions:

1. If the customization is unclear — ask questions (AskUserQuestion)
2. Summarize the understanding
3. Get user confirmation
4. Save: openspec/changes/[feature-name]/phase1-requirements.md

Phase 2: Codebase research

Goal: Understand the existing code and patterns

Adaptive approach:

• Simple: Grep/Glob direct search
• Medium: Task(subagent_type="Explore") for in-depth analysis
• Complex: Several parallel Task(subagent_type="Explore")

Actions:

1. Use MCP codemetadata/metadatasearch to search the codebase
2. Use Grep/Glob to search for patterns
3. For complex tasks — launch Task agents in parallel
4. Save: openspec/changes/[feature-name]/phase2-exploration.md

Phase 3: Clarifying questions

Goal: Fill in the gaps BEFORE design

Actions:

1. Review findings and requirements
2. Identify ambiguities (edge cases, error handling, integration)
3. Present ALL questions to the user via AskUserQuestion
4. Wait for answers before Phase 4
5. Save: openspec/changes/[feature-name]/phase3-clarifications.md

Phase 4: Architecture design

Goal: Design the implementation architecture

Actions:

1. Design based on phase1-3 artifacts
2. For complex tasks — propose several approaches
3. Create a plan with atomic stages and acceptance criteria
4. Save: openspec/changes/[feature-name]/phase4-architecture.md

Phase 5: Plan review

Goal: Validate the plan BEFORE implementation

Actions:

1. Check the completeness, correctness, and feasibility of the plan
2. If there are problems — update plan and repeat
3. Present the plan to the user
4. Ask: "The plan is ready for implementation, can we start?"
5. DO NOT PROCEED TO PHASE 6 WITHOUT APPROVAL!
6. Save: openspec/changes/[feature-name]/phase5-plan-review.md

Phase 6: Implementation by stages

Goal: Build the enhancement in atomic steps

DO NOT START WITHOUT USER APPROVAL!

For each stage:

1. Determine the task type and select a skill:
   • Form creation → /form-compile, /form-edit
   • Print form → /mxl-compile
   • Setting up rights → /role-compile
   • Metadata object → /meta-compile, /meta-edit
   • Processing/report → /epf-init, /erf-init
   • Extension → /cfe-init, /cfe-borrow
   • BSP integration → /epf-bsp-init
   • DCS → /skd-compile, /skd-edit
   • Loading into the database → /db-load-xml, /db-update
   • General task → write code manually
2. Execute stage
3. Validate result (corresponding /...-validate)
4. Mark stage as completed in phase4-architecture.md

Phase 7: Code review

Goal: Ensure quality

Actions:

1. Check code for compliance with the plan
2. Check quality (standards, readability, security)
3. Save: openspec/changes/[feature-name]/phase7-code-review.md
4. If problems are found — fix and repeat

Phase 8: Summary

Actions:

1. Mark all tasks as completed
2. Create summary: openspec/changes/[feature-name]/phase8-summary.md
3. Save to RLM (if available):
   • rlm_add_hierarchical_fact — what was built
   • rlm_record_causal_decision — key decisions
   • rlm_sync_state

ARTIFACTS

All artifacts in openspec/changes/[feature-name]/:

phase0-complexity.md      # Оценка сложности
phase1-requirements.md    # Требования
phase2-exploration.md     # Исследование кода
phase3-clarifications.md  # Уточнения
phase4-architecture.md    # План (с этапами)
phase5-plan-review.md     # Ревью плана
phase7-code-review.md     # Ревью кода
phase8-summary.md         # Итоги

CRITICAL RULES

1. Phase 0 is mandatory — assessment determines strategy
2. Phase 3 is mandatory — clarifications BEFORE design
3. Phase 5 is mandatory — plan review BEFORE implementation
4. User approval — before Phase 6
5. Atomic stages — each with acceptance criteria
6. Use existing skills — do not write by hand what is automated
7. Saving to RLM — Phase 8 is mandatory