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.
In this repository55 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- claude-plugin/CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- instructions/copilot-instructions.mdCopilot instructions
- agent-builderSkill
- al-agent-build-instructionsSkill
- al-agent-createSkill
- al-agent-instructionsSkill
- al-agent-taskSkill
- al-agent-testSkill
- al-buildSkill
- al-context-createSkill
- al-initializeSkill
- al-memory-createSkill
- al-pr-prepareSkill
- al-spec-createSkill
- architectSkill
- auditSkill
- conductSkill
- developSkill
- presalesSkill
- reviewSkill
- skill-agent-instructionsSkill
- skill-agent-task-patternsSkill
- skill-agent-toolkitSkill
- skill-al-review-pipelineSkill
- skill-apiSkill
- skill-contribution-assistantSkill
- skill-copilotSkill
- skill-debugSkill
- skill-eventsSkill
- skill-migrateSkill
- skill-pagesSkill
- skill-performanceSkill
- skill-permissionsSkill
- skill-testingSkill
- skill-translateSkill
- specSkill
- triageSkill
- skill-agent-instructionsSkill
- skill-agent-task-patternsSkill
- skill-agent-toolkitSkill
- skill-al-review-pipelineSkill
- skill-apiSkill
- skill-contribution-assistantSkill
- skill-copilotSkill
- skill-debugSkill
- skill-estimationSkill
- skill-eventsSkill
- skill-migrateSkill
- skill-pagesSkill
- skill-performanceSkill
- skill-permissionsSkill
- skill-testingSkill
- skill-translateSkill
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
- Distinctive: line 25
Before any estimation, gather these parameters:
- Distinctive: line 87
Use the Program Evaluation and Review Technique for each task:
- Distinctive: line 218
Ask mandatory intake questions (Pattern 1)
- Distinctive: line 220
If reference repositories provided, analyze them for scope comparison
- Very specific: line 227
If existing codebase, use al_search_objects to measure current scope
- Distinctive: line 232
Use complexity-based hour ranges for object estimation
- Distinctive: line 248
Create cost summary with payment milestones (Pattern 5)
- Distinctive: line 277
Do NOT estimate without cost parameters (hourly rate, currency) — ask first
- Distinctive: line 278
Do NOT build, compile, or deploy code — estimation only
- Distinctive: line 279
Do NOT modify production source code — analysis and documentation only
- Distinctive: line 280
Do NOT skip the SWOT analysis for any project — risk awareness is mandatory
≈ “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.
Files
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/10Object count estimation:
| Object Type | Low Complexity | Medium | High |
| Table | 2-4 hrs | 4-8 hrs | 8-16 hrs |
| Page (Card/List) | 2-4 hrs | 4-8 hrs | 8-16 hrs |
| Page (Document) | 4-8 hrs | 8-16 hrs | 16-32 hrs |
| Codeunit | 2-8 hrs | 8-16 hrs | 16-40 hrs |
| Report | 4-8 hrs | 8-16 hrs | 16-32 hrs |
| Integration | 8-16 hrs | 16-32 hrs | 32-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 durationApply 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 currentlyPattern 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
- Ask mandatory intake questions (Pattern 1)
- Confirm cost parameters — do NOT skip this
- If reference repositories provided, analyze them for scope comparison
Step 2: Analyze
- Score complexity dimensions (Pattern 2)
- Count estimated objects (tables, pages, codeunits, reports)
- Identify integration points and external dependencies
- If existing codebase, use
al_search_objectsto measure current scope
Step 3: Estimate
- Apply PERT 3-point estimation per phase (Pattern 3)
- Use complexity-based hour ranges for object estimation
- 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
- Conduct SWOT analysis (Pattern 4)
- Calculate feasibility score
- Provide clear GO / CAUTION / NO-GO recommendation
Step 5: Deliver Proposal
- Create cost summary with payment milestones (Pattern 5)
- Define resource allocation (roles, FTE, duration)
- Compile all sections into presales documentation
- Store in
Technical_PreSales/{project-slug}/folder structure
PAUSE — present proposal for stakeholder review before commitment.
Estimation Guidelines
| Rule | Guideline |
| Testing effort | Always 30-40% of development hours |
| Documentation | Never skip — 10-15% of total hours |
| Integration complexity | Usually underestimated — add 50% buffer |
| Data migration | Add if mentioned — 15-20% of total |
| BC version testing | Add 5-10% for compatibility verification |
| Training | 8-16 hours per user group |
| Contingency | 15-20% standard, 25-30% for high uncertainty |
References
- PERT Estimation Technique
- BC Extension Development Guide
- AppSource Submission Requirements
- BC Licensing Model
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
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
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.

