Operating principles
- Adaptability: the number of agents and the depth of analysis depend on the complexity of the task
- Early validation: review the plan before implementation, not after
- Requirements clarification: identify all ambiguities before design through questions to the user
- Atomic steps: implementation stages with acceptance criteria and checks
- Progress tracking: after completing each phase, mark it as completed in the task list
Phase 0: Initialization and complexity assessment
Goal: understand the scope of the task and create a structure for the work
Initial request: $ARGUMENTS
Actions:
- Create a task list with all phases
- Create the directory
.tasks/task-[feature-name]/for storing artifacts - Assess the complexity of the task (simple/medium/complex/critical):
- Simple: a small change, obvious implementation
- Medium: affects several modules, requires understanding of the architecture
- Complex: a large enhancement, several subsystems, non-obvious solutions
- Critical: architectural changes, impact on the entire system, high risks
- Record the complexity assessment in the file
.tasks/task-[feature-name]/phase0-complexity.md
Phase 1: Discovery
Goal: understand what needs to be built
Actions:
- If the enhancement is unclear, ask the user:
- What problem are they solving?
- What should the enhancement do?
- Are there any constraints or requirements?
- Summarize your understanding and get confirmation from the user
- Save the confirmed understanding to the file
.tasks/task-[feature-name]/phase1-requirements.md:- The original request from $ARGUMENTS
- Clarifying questions and answers (if any)
- Summary of task understanding
- Key requirements and constraints
- User confirmation
Phase 2: Exploration of the 1C codebase
Goal: understand the existing code and patterns
PRINCIPLES OF ADAPTIVE EXPLORATION:
YOU DECIDE on the exploration strategy based on:
- The complexity assessment from Phase 0
- The nature of the task (new enhancement vs extension of an existing one)
- How well-understood the codebase area is
Key principle: depth is more important than breadth - it is better to launch agents sequentially to deepen than in parallel on the same thing.
Your decisions:
-
How many agents
1c-code-explorerto launch? (1-4+)- For simple tasks, one may be enough
- For complex ones, several with deepening may be needed
-
In parallel or sequentially?
- In parallel - if different independent areas need to be studied
- Sequentially - if deepening is needed: the first agent finds, the second digs deeper
-
Which aspects to focus on?
- Similar enhancements and patterns
- Architecture and abstraction layers
- Integrations and dependencies
- Critical components found by previous agents
-
Iterative deepening
- You can launch an agent, look at the results, decide whether more deepening is needed
- Each subsequent agent can focus on the findings of the previous ones
Actions:
- Make a decision on the exploration strategy (justify briefly)
- Launch agents
1c-code-exploreraccording to your strategy:- Pass the path to the requirements:
phase1-requirements.md - Specify the exploration focus for each agent (patterns, architecture, similar enhancements, etc.)
- Pass the path to the requirements:
- Each agent must return a list of several key files to read
- Read all the specified files for deep understanding
- Assess: is the understanding sufficient? Is further deepening needed? If yes - launch more agents
- Present a complete summary of the discovered patterns
- Save the summary to the file
.tasks/task-[feature-name]/phase2-exploration.md:- Discovered patterns and conventions
- Similar enhancements with links to files
- Key components and their purpose
- Architectural insights
- List of all key files read
Phase 3: Clarifying questions
Goal: fill in the gaps and resolve all ambiguities BEFORE designing
Actions:
- Review the findings from the codebase and the original enhancement request
- Identify underspecified aspects: edge cases, error handling, integration points, scope boundaries, design preferences, backward compatibility, performance needs
- Present all questions to the user in a clear, organized list
- Wait for answers before designing the architecture
- Save the questions and answers to the file
.tasks/task-[feature-name]/phase3-clarifications.md:- List of questions with context
- User answers to each question
- Decisions made and recommendations
If the user says "do what you think is best", provide your recommendation and obtain explicit confirmation.
Phase 4: Architecture design
Goal: design the implementation architecture
ADAPTIVE APPROACH - the number of agents depends on complexity:
Simple task (1 agent):
- Launch 1 agent
1c-code-architect - Create a single practical implementation plan
Medium task (1 agent + optional multisampling):
- By default: 1 agent with a practical plan
- Optionally: if the solution is not obvious, you can launch 2 agents with different approaches and choose the best one
Complex/critical task (2-3 agents, multisampling):
- Launch 2-3 agents
1c-code-architectin parallel with different focus:- Minimal changes (smallest change, maximum reuse)
- Clean architecture (maintainability, elegant abstractions)
- Pragmatic balance (speed + quality)
- Form an opinion about the best approach
- Present all approaches to the user with your recommendation
- Ask the user which approach they prefer
Actions:
- Launch agents
1c-code-architectaccording to the task complexity:- Pass the paths to the artifacts:
phase1-requirements.md,phase2-exploration.md,phase3-clarifications.md - For each agent, specify the architectural approach (minimal changes / clean architecture / balance)
- Pass the paths to the artifacts:
- After choosing the approach, create the file
.tasks/task-[feature-name]/phase4-architecture.mdс:- Task statement
- Complexity assessment from Phase 0
- Chosen architectural approach with justification
- Found patterns and conventions from Phase 2
- Answers to clarifying questions from Phase 3
- IMPLEMENTATION STAGES - break the implementation into logical stages (checklist in markdown):
- Granularity: simple task = 1 stage, medium = 2-4, complex = 4-8, critical = 5-10+ (base it on atomicity)
- Atomicity: a stage is completed in 1 agent session, has a verifiable result, does not block itself
- Format:
- [ ] **Этап N**: описание + файлы + критерии приемки + зависимости (если есть)
- Mermaid diagrams (architecture, data flows)
- The plan must be self-sufficient for understanding without the conversation context
Phase 5: Plan review
Goal: validate the plan BEFORE implementation — mistakes in the plan are costly, all the code will have to be rewritten.
Actions:
- Launch the agent
1c-code-architectto review the plan:- Pass the artifact paths:
phase1-requirements.md,phase2-exploration.md,phase3-clarifications.md,phase4-architecture.md - Review focus:
- Completeness: are all aspects of the task covered?
- Correctness: do the solutions match the patterns found in Phase 2?
- Realism: can the plan be implemented as described?
- Compliance with requirements: does the plan cover all requirements from Phase 1 and the answers from Phase 3?
- Stage acceptance criteria: are they clear and verifiable enough?
- Dependencies: is the sequence of stages arranged correctly?
- Technical debt: are there known issues that the plan will worsen?
- Pass the artifact paths:
- If the agent finds issues:
- Update the plan in
.tasks/task-[feature-name]/phase4-architecture.md - Repeat Phase 5 (review of the updated plan)
- Update the plan in
- When the plan is approved by the agent, save the review results in
.tasks/task-[feature-name]/phase5-plan-review.md:- What was checked (completeness, correctness, realism, etc.)
- What issues were found and fixed (if any)
- Final conclusion: the plan is ready for implementation
- Present the plan to the user:
- Brief summary of the plan
- Implementation stages with acceptance criteria
- Ask explicitly: "The plan is ready for implementation, can we start?"
DO NOT PROCEED TO PHASE 6 WITHOUT EXPLICIT USER APPROVAL
Phase 6: Implementation by stages
Goal: build the enhancement in atomic steps with acceptance checks
DO NOT START WITHOUT USER APPROVAL
Actions:
- Read the plan file
.tasks/task-[feature-name]/phase4-architecture.md - For each implementation stage sequentially:
a. Mark the stage in the plan as started (change
- [ ]to- [🔄]in the plan file) b. Launch the agent1c-code-writerto implement the stage:- Pass the path to the plan
- Specify the specific stage to implement
- Remind me about the acceptance criteria c. Check the acceptance criteria of the stage:
- Have all files been created/changed as described?
- Are the acceptance criteria met?
- Does the code comply with the rules from
1c-rules.md? d. If the criteria are not met: - Launch the agent
1c-code-writerto fix:- Pass the path to the plan and specify the stage
- Describe the problems found and what needs to be fixed
- Repeat the criteria check
- Repeat the fix cycle until the acceptance criteria are met
e. Mark the stage in the plan as completed (change
- [🔄]to- [x]in the plan file)
Phase 7: Code review
Goal: make sure the code is correct, elegant, and complies with the plan
Actions:
- Launch reviewers according to the task size:
- Simple:
1c-code-reviewer- Pass the path to the plan:
phase4-architecture.md - Focus: basic correctness + a quick check of compliance with the plan
- Pass the path to the plan:
- Medium/complex:
1c-code-architectto check compliance with the plan:- Pass the paths to the artifacts:
phase1-requirements.md,phase4-architecture.md,phase5-plan-review.md - Focus: compliance with the plan, architectural decisions, stage acceptance criteria
- Pass the paths to the artifacts:
1c-code-reviewerto check code quality:- Specify the path to the rules:
~/.claude/rules/1c-rules.md - Focus: bugs, readability, rules, DRY, elegance
- Specify the path to the rules:
- Very large: divide the code into logical modules/subsystems, and for each module launch a pair of agents (architect + reviewer) with the same instructions
- Simple:
- Consolidate their responses and identify problems requiring fixes
- Save the review results in
.tasks/task-[feature-name]/phase7-code-review.md:- What was checked (compliance with the plan, quality, bugs, etc.)
- Problems found with severity and recommendations
- Overall assessment of code readiness
- Present the identified problems to the user and ask what they want to do:
- Fix now
- Fix later (add to TODO/technical debt)
- Continue as is
- If "fix now":
- Add the issues to the plan in the "Fixes after review" section
- Run the agent
1c-code-writerto fix:- Pass the path to the plan:
phase4-architecture.md - Describe the issues from the review and what needs to be fixed
- Pass the path to the plan:
- Return to the beginning of Phase 7 (re-review)
- Repeat iterations until the reviewers stop finding critical issues
- If "fix later":
- Add the issues to the plan in the "Technical debt" section
- Mark them in the plan as deferred
Phase 8: Summary
Goal: document what was done
Actions:
- Mark all tasks as completed
- Save the summary to the file
.tasks/task-[feature-name]/phase8-summary.md:- What was built (links to implementation phases)
- Key decisions made (link to the plan)
- Changed files (git diff --stat)
- Remaining technical debt (if any)
- Proposed next steps
- Present the summary to the user