skill-estimation
AL project estimation for Business Central. Use when estimating development effort, creating cost models, SWOT analysis, or structuring project proposals.
Works with
---
name: skill-estimation
description: AL project estimation for Business Central. Use when estimating development effort, creating cost models, SWOT analysis, or structuring project proposals.
license: MIT
---
# 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:
```markdown
## 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:
```markdown
## 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 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:
```markdown
## 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:
```markdown
## 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:
```markdown
## 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:
```markdown
## 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
| 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](https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique)
- [BC Extension Development Guide](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-dev-overview)
- [AppSource Submission Requirements](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/readiness/readiness-checklist-marketing)
- [BC Licensing Model](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/deployment/licensing)
## 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 agentMore Project Management skills
firecrawl-build-onboarding
firecrawl/skills
Get Firecrawl credentials and SDK setup into a project. Use when an application needs `FIRECRAWL_API_KEY`, when an agent should add Firecrawl to `.env`, when the user wants to authenticate Firecrawl for app code, or when choosing the first SDK and docs for a new Firecrawl integration. This skill includes its own browser auth flow, so it does not depend on the website onboarding skill.
email-sequence
coreyhaines31/marketingskills
When the user wants to create or optimize an email sequence, drip campaign, automated email flow, or lifecycle email program. Also use when the user mentions "email sequence," "drip campaign," "nurture sequence," "onboarding emails," "welcome sequence," "re-engagement emails," "email automation," "lifecycle emails," "trigger-based emails," "email funnel," "email workflow," "what emails should I send," "welcome series," or "email cadence." Use this for any multi-email automated flow. For cold outreach emails, see cold-email. For in-app onboarding, see onboarding-cro.
onboard
pbakaus/impeccable
Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.

