Claude Skill

feature-dev

Structured feature development workflow with codebase exploration, architecture tradeoffs, implementation gating, and review

LLM Mart · 0 points · 0 views 1 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download axisrow-tg_content_factory-.codex-staging_feature-dev-9584862.zip · 3 KB
Part of axisrow/tg_content_factory — 2 skills

Install

skills CLI npx skills add https://github.com/axisrow/tg_content_factory/tree/main/.codex-staging/feature-dev
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install axisrow-tg-content-factory@llmmart
Git git clone https://github.com/axisrow/tg_content_factory.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole axisrow/tg_content_factory collection as a plugin from our marketplace. Git is the plain clone.

README

feature-dev

Codex skill adapted from the Claude feature-dev plugin.

It provides a structured workflow for feature delivery:

  1. Discovery
  2. Codebase exploration
  3. Clarifying questions
  4. Architecture design
  5. Implementation
  6. Quality review
  7. Summary

Primary entrypoint: SKILL.md

Skill manifest

Feature Dev Skill

Use this skill when the user wants to build a new feature and would benefit from a deliberate workflow instead of immediate implementation.

Goal

Drive feature work through seven phases:

  1. Discovery
  2. Codebase exploration
  3. Clarifying questions
  4. Architecture design
  5. Implementation
  6. Quality review
  7. Summary

Operating Rules

  • Do not jump straight into code for ambiguous feature work.
  • Read the codebase before proposing implementation details.
  • Ask clarifying questions after exploration and before architecture selection.
  • Present concrete tradeoffs, not abstract options.
  • Do not start implementation until the user approves an approach.
  • After implementation, run a review pass focused on bugs, regressions, and convention mismatches.

Workflow

1. Discovery

  • Restate the feature request in concrete terms.
  • If the request is underspecified, ask what problem is being solved, required behavior, constraints, and non-goals.
  • Create a task plan that tracks all seven phases.

2. Codebase Exploration

Investigate the codebase from multiple angles. Parallelize local reads and searches when possible.

Cover at least these perspectives:

  • Similar or adjacent features
  • Relevant architecture layers and extension points
  • Existing tests, conventions, and user flows

For each perspective, produce:

  • Key files with path references
  • Relevant control flow and abstractions
  • Constraints that affect implementation

After exploration, read the most important files and summarize patterns that the new feature should follow.

3. Clarifying Questions

Before designing the solution, identify ambiguities such as:

  • Edge cases
  • Error handling
  • Scope boundaries
  • Integration points
  • Backward compatibility
  • Performance or security requirements

Ask the user a concise grouped list of questions and wait for answers. If the user delegates the choice, give a recommendation and get explicit confirmation.

4. Architecture Design

Develop 2-3 implementation approaches with distinct tradeoffs:

  • Minimal changes
  • Clean architecture
  • Pragmatic balance

For each approach, include:

  • Files to change or create
  • Main abstractions
  • Benefits
  • Costs and risks

Recommend one approach and explain why it fits this codebase and request. Ask the user which approach to use.

5. Implementation

Do not begin until the user explicitly approves an approach.

When implementing:

  • Follow existing project patterns
  • Keep changes scoped to the agreed design
  • Update the task plan as work progresses
  • Add tests when the codebase supports them

6. Quality Review

Review the resulting changes from three lenses:

  • Simplicity, DRY, and maintainability
  • Bugs, correctness, and regressions
  • Project conventions and abstraction fit

Report the highest-signal findings first. If issues exist, ask whether to fix now, defer, or proceed as-is.

7. Summary

Close with:

  • What was built
  • Key decisions
  • Main files changed
  • Remaining risks or next steps

Specialist Lenses

Use these role prompts internally when useful:

You do not need separate agents to use this skill. Reuse the lenses as structured thinking modes during exploration, design, and review.

Files (tg_content_factory)
  • references
    • code-architect.md 391 B
      # Code Architect Lens
      
      Use this lens to design a concrete implementation that fits the codebase.
      
      ## Focus
      
      - Reuse established patterns
      - Pick a clear architecture rather than staying vague
      - Map files to create or modify
      - Call out interfaces, data flow, and sequencing
      
      ## Output
      
      - Recommended approach
      - Tradeoffs
      - File-by-file implementation map
      - Build sequence and critical details
      
    • code-explorer.md 381 B
      # Code Explorer Lens
      
      Use this lens to understand how an existing feature works before changing it.
      
      ## Focus
      
      - Find entry points
      - Trace execution flow end to end
      - Identify important abstractions and dependencies
      - Surface existing patterns worth reusing
      
      ## Output
      
      - Key files to read
      - Step-by-step flow
      - Data transformations
      - Notable constraints, risks, or technical debt
      
    • code-reviewer.md 333 B
      # Code Reviewer Lens
      
      Use this lens after implementation to review only meaningful issues.
      
      ## Focus
      
      - Functional correctness
      - Regression risk
      - Convention mismatches
      - Simplicity and maintainability
      
      ## Output
      
      - High-signal findings only
      - Concrete file references
      - Specific fix guidance
      - Residual risks if no issues are found
      
  • README.md 308 B
    # feature-dev
    
    Codex skill adapted from the Claude `feature-dev` plugin.
    
    It provides a structured workflow for feature delivery:
    
    1. Discovery
    2. Codebase exploration
    3. Clarifying questions
    4. Architecture design
    5. Implementation
    6. Quality review
    7. Summary
    
    Primary entrypoint: [`SKILL.md`](./SKILL.md)
    
  • SKILL.md 3.6 KB
    ---
    name: feature-dev
    description: Structured feature development workflow with codebase exploration, architecture tradeoffs, implementation gating, and review
    version: 1.0.0
    metadata:
      source: claude-plugins-official/feature-dev
    ---
    
    # Feature Dev Skill
    
    Use this skill when the user wants to build a new feature and would benefit from a deliberate workflow instead of immediate implementation.
    
    ## Goal
    
    Drive feature work through seven phases:
    
    1. Discovery
    2. Codebase exploration
    3. Clarifying questions
    4. Architecture design
    5. Implementation
    6. Quality review
    7. Summary
    
    ## Operating Rules
    
    - Do not jump straight into code for ambiguous feature work.
    - Read the codebase before proposing implementation details.
    - Ask clarifying questions after exploration and before architecture selection.
    - Present concrete tradeoffs, not abstract options.
    - Do not start implementation until the user approves an approach.
    - After implementation, run a review pass focused on bugs, regressions, and convention mismatches.
    
    ## Workflow
    
    ### 1. Discovery
    
    - Restate the feature request in concrete terms.
    - If the request is underspecified, ask what problem is being solved, required behavior, constraints, and non-goals.
    - Create a task plan that tracks all seven phases.
    
    ### 2. Codebase Exploration
    
    Investigate the codebase from multiple angles. Parallelize local reads and searches when possible.
    
    Cover at least these perspectives:
    - Similar or adjacent features
    - Relevant architecture layers and extension points
    - Existing tests, conventions, and user flows
    
    For each perspective, produce:
    - Key files with path references
    - Relevant control flow and abstractions
    - Constraints that affect implementation
    
    After exploration, read the most important files and summarize patterns that the new feature should follow.
    
    ### 3. Clarifying Questions
    
    Before designing the solution, identify ambiguities such as:
    - Edge cases
    - Error handling
    - Scope boundaries
    - Integration points
    - Backward compatibility
    - Performance or security requirements
    
    Ask the user a concise grouped list of questions and wait for answers. If the user delegates the choice, give a recommendation and get explicit confirmation.
    
    ### 4. Architecture Design
    
    Develop 2-3 implementation approaches with distinct tradeoffs:
    - Minimal changes
    - Clean architecture
    - Pragmatic balance
    
    For each approach, include:
    - Files to change or create
    - Main abstractions
    - Benefits
    - Costs and risks
    
    Recommend one approach and explain why it fits this codebase and request. Ask the user which approach to use.
    
    ### 5. Implementation
    
    Do not begin until the user explicitly approves an approach.
    
    When implementing:
    - Follow existing project patterns
    - Keep changes scoped to the agreed design
    - Update the task plan as work progresses
    - Add tests when the codebase supports them
    
    ### 6. Quality Review
    
    Review the resulting changes from three lenses:
    - Simplicity, DRY, and maintainability
    - Bugs, correctness, and regressions
    - Project conventions and abstraction fit
    
    Report the highest-signal findings first. If issues exist, ask whether to fix now, defer, or proceed as-is.
    
    ### 7. Summary
    
    Close with:
    - What was built
    - Key decisions
    - Main files changed
    - Remaining risks or next steps
    
    ## Specialist Lenses
    
    Use these role prompts internally when useful:
    
    - [code-explorer](references/code-explorer.md): trace feature flows and architecture
    - [code-architect](references/code-architect.md): produce decisive implementation blueprints
    - [code-reviewer](references/code-reviewer.md): review for real bugs and convention drift
    
    You do not need separate agents to use this skill. Reuse the lenses as structured thinking modes during exploration, design, and review.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related