AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Arch Lens Development

skill-talont-org-autoskillit-arch-lens-development · by TalonT-Org

Create Development architecture diagram showing project structure, build tools, and quality gates. Development lens answering "How is it built and tested?

No reviews yet
0 installs
9 views
0.0% view→install

Install

$ agentstack add skill-talont-org-autoskillit-arch-lens-development

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-talont-org-autoskillit-arch-lens-development)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
20d ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Arch Lens Development? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Development Architecture Lens

Cognitive Mode: Development Primary Question: "How is it built and tested?" Focus: Project Structure, Build Tools, Quality Gates, Test Framework

When to Use

  • Need to understand developer experience
  • Documenting build and test infrastructure
  • Analyzing code quality gates
  • User invokes /autoskillit:arch-lens-development or /autoskillit:make-arch-diag development

Critical Constraints

NEVER:

  • Modify any source code files
  • Include runtime architecture details
  • Show business logic
  • Run subagents in the background (run_in_background: true is prohibited)

ALWAYS:

  • Focus on BUILD and TEST infrastructure
  • Show quality gate pipeline
  • Document test framework setup
  • Include entry points
  • BEFORE creating any diagram, LOAD the /autoskillit:mermaid skill using the Skill tool - this is MANDATORY
  • If the Skill tool cannot be used (disable-model-invocation) or refuses this invocation, do NOT proceed with diagram creation. Abort this step and omit the diagram from output.
  • After writing the diagram file, emit the absolute path as a structured output

token as your final output. Resolve the relative temp/arch-lens-development/... save path to absolute by prepending the full CWD: `` diagram_path = /absolute/cwd/temp/arch-lens-development/{filename}.md `` This token is MANDATORY — the pipeline cannot proceed without it.

Arguments

/autoskillit:arch-lens-development [context_path]

  • context_path (optional) — Absolute path to a PR context file containing new files

(★-prefixed) and modified files (●-prefixed) from the PR diff. When provided, read this file before beginning analysis and focus the diagram on the architectural areas affected by these specific files. When absent, explore the full CWD.


Analysis Workflow

Step 0: Read PR context (when provided)

If a context_path positional argument is present:

  1. Read the file at context_path
  2. Extract: new files list (★-prefixed), modified files list (●-prefixed)
  3. Focus Step 1 exploration on the modules/components these files belong to
  4. Apply ★ prefix on diagram nodes representing new files/components
  5. Apply ● prefix on diagram nodes representing modified files/components

If no context_path is provided, skip this step and explore the full CWD in Step 1.

Step 1: Launch Parallel Exploration Subagents

Spawn Explore subagents to investigate:

Project Structure

  • Find top-level directory organization
  • Identify module/package boundaries
  • Look for: build configs, package definitions, project layout

Build Tooling

  • Find build configuration
  • Identify package manager and build backend
  • Look for: build config files, makefiles, task runners, package managers

Linting & Formatting

  • Find code quality tools
  • Identify pre-commit hooks
  • Look for: linter configs, formatter configs, pre-commit hooks, code quality tools

Type Checking

  • Find type checking configuration
  • Identify strictness level
  • Look for: type checker configs, static analysis tools

Test Framework

  • Find test configuration
  • Identify test patterns and fixtures
  • Look for: test configs, test directories, test runners, test fixtures

CI/CD (if present)

  • Find CI configuration
  • Identify workflow stages
  • Look for: CI/CD configs, workflow definitions, pipeline configs

Entry Points

  • Find CLI entry points
  • Identify console scripts
  • Look for: entry point definitions, command definitions, binary files

Step 2: Map Quality Pipeline

Document the code quality pipeline:

Code -> Format -> Lint -> Type Check -> Test -> Commit

CRITICAL - Analyze Read/Write Direction: For EVERY build/test component:

  • Inputs (reads): What files/config does this tool READ?
  • Outputs (writes): What does this tool WRITE (reports, modified files)?
  • Side effects: Does it modify source files or just report?

Distinguish:

  • Tools that READ and MODIFY code (formatters)
  • Tools that READ and REPORT only (linters, type checkers)
  • Tools that READ code and WRITE artifacts (test output files)
  • Config files (READ by tools, not written by build process)

Step 3: Count Project Metrics

| Metric | Value | |--------|-------| | Source Files | N | | Test Files | N | | Dependencies | N | | Entry Points | N |

Step 4: Create the Diagram

Use flowchart with:

Direction: TB for pipeline flow

Subgraphs:

  • Project Structure (directories)
  • Build Tools (packaging)
  • Quality Gates (linting, types)
  • Test Framework (test runner, etc)
  • Entry Points (CLI commands)

Node Styling:

  • cli class: Project structure, directories
  • phase class: Build configuration
  • detector class: Quality gates (linting, typing)
  • handler class: Test framework
  • output class: Entry points, outputs

Show Pipeline Flow:

  • Code through quality gates
  • Build to entry points

Step 5: Write Output

Write the diagram to: {{AUTOSKILLIT_TEMP}}/arch-lens-development/arch_diag_development_{YYYY-MM-DD_HHMMSS}.md (relative to the current working directory)

After writing the diagram file, emit a structured output line:

> IMPORTANT: Emit the structured output tokens as literal plain text with no > markdown formatting on the token names. Do not wrap token names in **bold**, > *italic*, or any other markdown. The adjudicator performs a regex match on the > exact token name — decorators cause match failure.

diagram_path = {absolute_path_to_diagram_file}

Output Template

# Development Diagram: {Project Name}

**Lens:** Development (Build & Test)
**Question:** How is it built and tested?
**Date:** {YYYY-MM-DD}
**Scope:** {What was analyzed}

## Project Metrics

| Metric | Value |
|--------|-------|
| Source Directories | {count} |
| Test Files | {count} |
| Dependencies | {count} |
| Entry Points | {count} |

## Development Diagram

```mermaid
%%{init: {'flowchart': {'nodeSpacing': 50, 'rankSpacing': 60, 'curve': 'basis'}}}%%
flowchart TB
    %% CLASS DEFINITIONS %%
    classDef cli fill:#1a237e,stroke:#7986cb,stroke-width:2px,color:#fff;
    classDef stateNode fill:#004d40,stroke:#4db6ac,stroke-width:2px,color:#fff;
    classDef handler fill:#e65100,stroke:#ffb74d,stroke-width:2px,color:#fff;
    classDef phase fill:#6a1b9a,stroke:#ba68c8,stroke-width:2px,color:#fff;
    classDef output fill:#00695c,stroke:#4db6ac,stroke-width:2px,color:#fff;
    classDef detector fill:#b71c1c,stroke:#ef5350,stroke-width:2px,color:#fff;

    subgraph Structure ["PROJECT STRUCTURE"]
        direction TB
        SRC["src/━━━━━━━━━━Source code"]
        TESTS["tests/━━━━━━━━━━Test suite"]
    end

    subgraph Build ["BUILD TOOLING"]
        direction TB
        CONFIG["Build Config━━━━━━━━━━Build system"]
        TASKFILE["Task Runner━━━━━━━━━━Task automation"]
    end

    subgraph Quality ["CODE QUALITY GATES"]
        direction TB
        FORMAT["Formatter━━━━━━━━━━Code style"]
        LINT["Linter━━━━━━━━━━Code quality"]
        TYPES["Type Checker━━━━━━━━━━Static analysis"]
    end

    subgraph Testing ["TEST FRAMEWORK"]
        direction TB
        TESTRUN["Test Runner━━━━━━━━━━Test execution"]
        FIXTURES["Fixtures━━━━━━━━━━Test setup"]
    end

    subgraph EntryPoints ["ENTRY POINTS"]
        direction LR
        EP1["cli-command"]
    end

    %% FLOW %%
    SRC --> CONFIG
    TESTS --> CONFIG
    CONFIG --> TASKFILE

    CONFIG --> FORMAT
    FORMAT --> LINT
    LINT --> TYPES

    TYPES --> TESTRUN
    TESTRUN --> FIXTURES

    CONFIG --> EP1

    %% CLASS ASSIGNMENTS %%
    class SRC,TESTS cli;
    class CONFIG,TASKFILE phase;
    class FORMAT,LINT,TYPES detector;
    class TESTRUN,FIXTURES handler;
    class EP1 output;

Color Legend: | Color | Category | Description | |-------|----------|-------------| | Dark Blue | Structure | Project directories | | Purple | Build | Configuration and automation | | Red | Quality | Linters and type checkers | | Orange | Testing | Test framework and fixtures | | Dark Teal | Entry Points | CLI commands |

Development Workflow

Code -> format -> lint -> type-check -> test -> commit

Pre-commit Hooks

| Hook | Purpose | |------|---------| | {hook} | {purpose} |

Entry Points

| Command | Module | Purpose | |---------|--------|---------| | {command} | {module} | {purpose} |


---

## Pre-Diagram Checklist

Before creating the diagram, verify:

- [ ] LOADED `/autoskillit:mermaid` skill using the Skill tool
- [ ] Using ONLY classDef styles from the mermaid skill (no invented colors)
- [ ] Diagram will include a color legend table

---

## Related Skills

- `/autoskillit:make-arch-diag` - Parent skill for lens selection
- `/autoskillit:mermaid` - MUST BE LOADED before creating diagram

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [TalonT-Org](https://github.com/TalonT-Org)
- **Source:** [TalonT-Org/AutoSkillit](https://github.com/TalonT-Org/AutoSkillit)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.