SuperAPI AI Directory

1c-feature-dev

General & other

View repository

Updated 10-15 18:37

About this skill

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:

  1. Create a task list with all phases
  2. Create the directory .tasks/task-[feature-name]/ for storing artifacts
  3. 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
  4. 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:

  1. If the enhancement is unclear, ask the user:
    • What problem are they solving?
    • What should the enhancement do?
    • Are there any constraints or requirements?
  2. Summarize your understanding and get confirmation from the user
  3. 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:

  1. How many agents 1c-code-explorer to launch? (1-4+)

    • For simple tasks, one may be enough
    • For complex ones, several with deepening may be needed
  2. 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
  3. Which aspects to focus on?

    • Similar enhancements and patterns
    • Architecture and abstraction layers
    • Integrations and dependencies
    • Critical components found by previous agents
  4. 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:

  1. Make a decision on the exploration strategy (justify briefly)
  2. Launch agents 1c-code-explorer according to your strategy:
    • Pass the path to the requirements: phase1-requirements.md
    • Specify the exploration focus for each agent (patterns, architecture, similar enhancements, etc.)
  3. Each agent must return a list of several key files to read
  4. Read all the specified files for deep understanding
  5. Assess: is the understanding sufficient? Is further deepening needed? If yes - launch more agents
  6. Present a complete summary of the discovered patterns
  7. 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:

  1. Review the findings from the codebase and the original enhancement request
  2. Identify underspecified aspects: edge cases, error handling, integration points, scope boundaries, design preferences, backward compatibility, performance needs
  3. Present all questions to the user in a clear, organized list
  4. Wait for answers before designing the architecture
  5. 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-architect in 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:

  1. Launch agents 1c-code-architect according 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)
  2. 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:

  1. Launch the agent 1c-code-architect to 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?
  2. If the agent finds issues:
    • Update the plan in .tasks/task-[feature-name]/phase4-architecture.md
    • Repeat Phase 5 (review of the updated plan)
  3. 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
  4. 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:

  1. Read the plan file .tasks/task-[feature-name]/phase4-architecture.md
  2. For each implementation stage sequentially: a. Mark the stage in the plan as started (change - [ ] to - [🔄] in the plan file) b. Launch the agent 1c-code-writer to 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-writer to 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:

  1. 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
    • Medium/complex:
      • 1c-code-architect to 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
      • 1c-code-reviewer to check code quality:
        • Specify the path to the rules: ~/.claude/rules/1c-rules.md
        • Focus: bugs, readability, rules, DRY, elegance
    • Very large: divide the code into logical modules/subsystems, and for each module launch a pair of agents (architect + reviewer) with the same instructions
  2. Consolidate their responses and identify problems requiring fixes
  3. 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
  4. 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
  5. If "fix now":
    • Add the issues to the plan in the "Fixes after review" section
    • Run the agent 1c-code-writer to fix:
      • Pass the path to the plan: phase4-architecture.md
      • Describe the issues from the review and what needs to be fixed
    • Return to the beginning of Phase 7 (re-review)
    • Repeat iterations until the reviewers stop finding critical issues
  6. 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:

  1. Mark all tasks as completed
  2. 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
  3. Present the summary to the user