agentleFS
javiarmestojaviarmesto/ALDC-AL-Development-Collection/skills/skill-estimation/SKILL.md

skill-estimation

Skill115 starsChanged 10 days agoMITView on GitHub

AL project estimation for Business Central. Use when estimating development effort, creating cost models, SWOT analysis, or structuring project proposals.

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 10 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before any estimation, gather these parameters:

    line 25
  2. Distinctive:

    Use the Program Evaluation and Review Technique for each task:

    line 87
  3. Distinctive:

    Ask mandatory intake questions (Pattern 1)

    line 218
  4. Distinctive:

    If reference repositories provided, analyze them for scope comparison

    line 220
  5. Very specific:

    If existing codebase, use al_search_objects to measure current scope

    line 227
  6. Distinctive:

    Use complexity-based hour ranges for object estimation

    line 232
  7. Distinctive:

    Create cost summary with payment milestones (Pattern 5)

    line 248
  8. Distinctive:

    Do NOT estimate without cost parameters (hourly rate, currency) — ask first

    line 277
  9. Distinctive:

    Do NOT build, compile, or deploy code — estimation only

    line 278
  10. Distinctive:

    Do NOT modify production source code — analysis and documentation only

    line 279
  11. Distinctive:

    Do NOT skip the SWOT analysis for any project — risk awareness is mandatory

    line 280

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Skill: AL Project Estimation

Purpose

Estimate AL/Business Central projects: complexity scoring, PERT 3-point estimation, SWOT/DAFO risk analysis, cost breakdown by phase, resource allocation, and structured presales documentation.

When to Load

This skill should be loaded when:

  • A new BC/AL project needs time and cost estimation
  • A feasibility assessment or SWOT analysis is required before commitment
  • A presales proposal or technical assessment document is being created
  • Resource allocation and team composition need to be defined
  • A project plan with milestones and payment schedule is needed

Core Patterns

Pattern 1: Intake Questions (Mandatory)

Before any estimation, gather these parameters:

## Project Intake — Required Information

### 1. Project Identity
- Project name (will be used for folder structure)
- Brief description: What problem does it solve?

### 2. Cost Parameters (MANDATORY)
- Hourly rate (e.g., €75/hour, $100/hour)
- Currency (EUR, USD, GBP)
- Contingency buffer: Yes/No (default 15-20%)
- Risk buffer: Low (10%), Medium (20%), High (30%)

### 3. Technical Context
- Target BC version: SaaS, On-Premise, or both?
- Target delivery date
- Existing codebase? (repository URL or workspace path)
- Reference repositories for similar functionality?

### 4. Team (optional)
- Available developers: Junior, Mid, Senior?
- BC experience level: New, Experienced, Expert?

PAUSE — do NOT proceed without cost parameters. Estimation without rates is meaningless.

Pattern 2: Complexity Scoring

Score each dimension 1-10 to derive overall project complexity:

## Complexity Assessment

| Dimension | Score (1-10) | Criteria |
|---|---|---|
| Data Model | /10 | Tables, relations, migration needs |
| Business Logic | /10 | Codeunits, validations, calculations |
| UI Complexity | /10 | Pages, customizations, RoleCenter |
| Integrations | /10 | External APIs, events, webhooks |
| Reporting | /10 | Reports, queries, analytics |
| Security | /10 | Permissions, data sensitivity, audit |
| Testing | /10 | Test coverage needed, edge cases |
| Migration/Upgrade | /10 | Data migration, version compatibility |

**Overall Complexity**: (sum / 80) × 10 = X/10

Object count estimation:

Object TypeLow ComplexityMediumHigh
Table2-4 hrs4-8 hrs8-16 hrs
Page (Card/List)2-4 hrs4-8 hrs8-16 hrs
Page (Document)4-8 hrs8-16 hrs16-32 hrs
Codeunit2-8 hrs8-16 hrs16-40 hrs
Report4-8 hrs8-16 hrs16-32 hrs
Integration8-16 hrs16-32 hrs32-80 hrs

Pattern 3: PERT 3-Point Estimation

Use the Program Evaluation and Review Technique for each task:

## PERT Formula

E = (O + 4M + P) / 6

Where:
- O = Optimistic (best case, everything goes right)
- M = Most Likely (normal case, typical obstacles)
- P = Pessimistic (worst case, major obstacles)
- E = Expected duration

Apply per development phase:

## Phase Breakdown

### Phase 1: Analysis & Design
| Task | O (hrs) | M (hrs) | P (hrs) | E (hrs) |
|---|---|---|---|---|
| Requirements analysis | 8 | 16 | 24 | 16 |
| Technical design | 8 | 12 | 20 | 13 |
| Architecture review | 4 | 8 | 12 | 8 |
| **Subtotal** | **20** | **36** | **56** | **37** |

### Phase 2: Development
| Task | O (hrs) | M (hrs) | P (hrs) | E (hrs) |
|---|---|---|---|---|
| Tables & data model | X | X | X | X |
| Pages & UI | X | X | X | X |
| Business logic | X | X | X | X |
| Integrations | X | X | X | X |
| **Subtotal** | **X** | **X** | **X** | **X** |

### Phase 3: Testing & QA
| Task | O (hrs) | M (hrs) | P (hrs) | E (hrs) |
|---|---|---|---|---|
| Unit tests | X | X | X | X |
| Integration tests | X | X | X | X |
| UAT support | X | X | X | X |
| Bug fixes | X | X | X | X |
| **Subtotal** | **X** | **X** | **X** | **X** |

### Phase 4: Deployment & Documentation
| Task | O (hrs) | M (hrs) | P (hrs) | E (hrs) |
|---|---|---|---|---|
| Technical documentation | X | X | X | X |
| Training materials | X | X | X | X |
| Deployment | X | X | X | X |
| Post-go-live support | X | X | X | X |
| **Subtotal** | **X** | **X** | **X** | **X** |

Pattern 4: SWOT/DAFO Analysis

Structured risk and opportunity assessment:

## SWOT Analysis

### Strengths (Internal Positive)
| ID | Strength | Impact |
|---|---|---|
| S1 | [e.g., Team has BC experience] | High/Medium/Low |

### Opportunities (External Positive)
| ID | Opportunity | Impact |
|---|---|---|
| O1 | [e.g., Standard BC API available] | High/Medium/Low |

### Weaknesses (Internal Negative)
| ID | Weakness | Impact | Mitigation |
|---|---|---|---|
| W1 | [e.g., No existing test suite] | High | Implement TDD from start |

### Threats (External Negative)
| ID | Threat | Probability | Impact | Mitigation |
|---|---|---|---|---|
| T1 | [e.g., BC version upgrade mid-project] | Medium | High | Pin BC version |

## Feasibility Score

| Criterion | Score (1-10) |
|---|---|
| Technical Feasibility | /10 |
| Resource Feasibility | /10 |
| Timeline Feasibility | /10 |
| Economic Feasibility | /10 |
| **Overall** | **/10** |

### Recommendation
- [ ] **GO** — Project viable, proceed
- [ ] **CAUTION** — Viable with conditions
- [ ] **NO-GO** — Not recommended currently

Pattern 5: Cost Summary and Payment Milestones

Consolidate estimation into a financial summary:

## Cost Summary

| Concept | Hours | Rate | Cost |
|---|---|---|---|
| Analysis & Design | X | [RATE] | [TOTAL] |
| Development | X | [RATE] | [TOTAL] |
| Testing & QA | X | [RATE] | [TOTAL] |
| Deployment & Docs | X | [RATE] | [TOTAL] |
| **Subtotal** | **X** | | **[TOTAL]** |
| Contingency ([%]%) | X | | [TOTAL] |
| Risk Buffer ([%]%) | X | | [TOTAL] |
| **TOTAL** | **X** | | **[CURRENCY] [TOTAL]** |

## Payment Milestones

| Milestone | % | Amount | Deliverable |
|---|---|---|---|
| Project Start | 20% | [X] | SOW signed, project plan |
| Design Approved | 20% | [X] | Architecture approved |
| Development Complete | 30% | [X] | Code delivered, tests pass |
| UAT Approved | 20% | [X] | User acceptance sign-off |
| Go-Live | 10% | [X] | Production deployment |

Workflow

Step 1: Intake

  1. Ask mandatory intake questions (Pattern 1)
  2. Confirm cost parameters — do NOT skip this
  3. If reference repositories provided, analyze them for scope comparison

Step 2: Analyze

  1. Score complexity dimensions (Pattern 2)
  2. Count estimated objects (tables, pages, codeunits, reports)
  3. Identify integration points and external dependencies
  4. If existing codebase, use al_search_objects to measure current scope

Step 3: Estimate

  1. Apply PERT 3-point estimation per phase (Pattern 3)
  2. Use complexity-based hour ranges for object estimation
  3. Apply standard ratios:
    • Testing = 30-40% of development
    • Documentation = 10-15% of total
    • Integration = typically underestimated by 50% — adjust accordingly
    • Data migration = 15-20% of total (if applicable)
    • BC version testing = 5-10% for compatibility

Step 4: Risk Assessment

  1. Conduct SWOT analysis (Pattern 4)
  2. Calculate feasibility score
  3. Provide clear GO / CAUTION / NO-GO recommendation

Step 5: Deliver Proposal

  1. Create cost summary with payment milestones (Pattern 5)
  2. Define resource allocation (roles, FTE, duration)
  3. Compile all sections into presales documentation
  4. Store in Technical_PreSales/{project-slug}/ folder structure

PAUSE — present proposal for stakeholder review before commitment.

Estimation Guidelines

RuleGuideline
Testing effortAlways 30-40% of development hours
DocumentationNever skip — 10-15% of total hours
Integration complexityUsually underestimated — add 50% buffer
Data migrationAdd if mentioned — 15-20% of total
BC version testingAdd 5-10% for compatibility verification
Training8-16 hours per user group
Contingency15-20% standard, 25-30% for high uncertainty

References

Constraints

  • This skill covers project estimation, risk analysis, and presales documentation
  • Do NOT estimate without cost parameters (hourly rate, currency) — ask first
  • Do NOT build, compile, or deploy code — estimation only
  • Do NOT modify production source code — analysis and documentation only
  • Do NOT skip the SWOT analysis for any project — risk awareness is mandatory
  • Architecture design → al-architect agent | Technical specifications → al-spec.create workflow | Implementation → al-conductor agent

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.