rory-data/engineering-workflow
skills/engineering-workflow/SKILL.md
Structured engineering workflow for complex projects: the 6-phase loop (Analyse → Design → Implement → Validate → Reflect → Handoff), confidence-based execution strategy, EARS requirements notation, and decision records. Use this skill whenever the user wants to plan a feature, architect a system, write requirements, or needs structured guidance for any non-trivial engineering task. Also invoke when asked to produce PRDs, user stories, specifications, technical designs, implementation task breakdowns, or decision records — templates for all of these are in references/templates.md.
testing
Updated Apr 26, 2026
$ install --global
skillsauthnpx skillsauth add rory-data/copilot engineering-workflowInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 26, 2026, 9:18 AM76.7s2 files scanned
SKILL.md
- name:
- engineering-workflow
- license:
- Proprietary
- description:
- >
- Structured engineering workflow for complex projects:
- the 6-phase loop (Analyse → Design →
Engineering Workflow
A structured approach to complex engineering work. Apply this workflow whenever requirements need clarification, documentation needs producing, or work spans multiple phases.
The 6-Phase Loop
| Phase | Goal | Key Activities |
|-------|------|----------------|
| 1. Analyse | Understand the problem | Read code/docs/logs; write EARS requirements; generate confidence score |
| 2. Design | Plan the solution | Technical design in design.md; error handling matrix; testing strategy; tasks.md |
| 3. Implement | Build it | Code in small increments; dependencies first; update task status in real time |
| 4. Validate | Verify correctness | Run automated tests; test edge cases; verify performance; document execution traces |
| 5. Reflect | Improve | Refactor for maintainability; update docs; identify and log technical debt |
| 6. Handoff | Package for review | Executive summary; pull request with changelog; finalise workspace |
Never skip phases — each builds on the previous.
Confidence-Based Execution
Before designing, generate a Confidence Score (0–100%) based on how well requirements are understood:
| Score | Indicators | Strategy | |-------|------------|----------| | High (>85%) | Clear requirements, familiar tech, similar work exists | Full implementation plan, skip PoC | | Medium (66–85%) | Some unknowns, unfamiliar tech, 1–2 unclear dependencies | PoC/MVP first with clear success criteria | | Low (<66%) | Ambiguous requirements, major tech unknowns, significant rework risk | Research phase first, then re-analyse |
EARS Requirements Notation
Use EARS format when writing requirements in requirements.md:
- Ubiquitous:
THE SYSTEM SHALL [behavior] - Event-driven:
WHEN [trigger] THE SYSTEM SHALL [behavior] - State-driven:
WHILE [state] THE SYSTEM SHALL [behavior] - Unwanted behavior:
IF [condition] THEN THE SYSTEM SHALL [response] - Optional:
WHERE [feature included] THE SYSTEM SHALL [behavior]
Each requirement must be: testable, unambiguous, necessary, feasible, traceable.
Core Artifacts
For complex projects, maintain these files in the project root or session workspace:
requirements.md— EARS requirements and acceptance criteriadesign.md— Technical architecture and implementation considerationstasks.md— Detailed, trackable implementation plan
Decision Records
Document significant architectural and technical choices:
### Decision — [date]: [brief title]
**Decision**: What was decided
**Context**: Situation requiring the decision and the data driving it
**Options**: Alternatives considered with brief pros/cons
**Rationale**: Why the chosen option is superior, with trade-offs stated explicitly
**Impact**: Consequences for implementation, maintainability, and performance
**Review**: Conditions or schedule for reassessing this decision
Tool Selection by Phase
| Phase | Primary Focus | Tools | |-------|--------------|-------| | Analyse | Research and reading | grep, glob, view, bash, web_fetch | | Design | Mapping dependencies | view, grep, ask_user, create (plan files) | | Implement | Code changes | edit, create, bash | | Validate | Testing and verification | bash (run tests), view (check output) | | Reflect | Code review | view, edit, grep | | Handoff | Summarise and commit | bash (git), create (PR description) |
Troubleshooting Protocol
When encountering errors or blockers:
- Re-analyse — revisit requirements and constraints
- Re-design — update the technical design and dependencies
- Re-plan — adjust the implementation task list
- Retry — re-execute with corrected parameters
- Escalate — if issues persist after retries, surface blockers to the user
Templates
See references/templates.md for complete, ready-to-use templates:
requirements.md— EARS requirements with NFRs, constraints, and success criteriadesign.md— Technical design with architecture, APIs, error handling, testing strategytasks.md— Phased implementation tasks with dependencies and acceptance criteria- PRD (Product Requirements Document) — full template with goals, personas, user stories
- User story and epic breakdown templates
- Action documentation and decision record templates
Related Skills
rory-data/airflow
tools
VerifiedTrustedCommunity
Queries, manages, and troubleshoots Apache Airflow using the af CLI. Covers listing DAGs, triggering runs, reading task logs, diagnosing failures, debugging DAG import errors, checking connections, variables, pools, and monitoring health. Also routes to sub-skills for writing DAGs, debugging, deploying, and migrating Airflow 2 to 3. Use when user mentions "Airflow", "DAG", "DAG run", "task log", "import error", "parse error", "broken DAG", or asks to "trigger a pipeline", "debug import errors", "check Airflow health", "list connections", "retry a run", or any Airflow operation. Do NOT use for warehouse/SQL analytics on Airflow metadata tables — use analyzing-data instead.
SKILL.mdUpdated May 3, 2026
rory-data/airflow-plugins
tools
VerifiedTrustedCommunity
Build Airflow 3.1+ plugins that embed FastAPI apps, custom UI pages, React components, middleware, macros, and operator links directly into the Airflow UI. Use this skill whenever the user wants to create an Airflow plugin, add a custom UI page or nav entry to Airflow, build FastAPI-backed endpoints inside Airflow, serve static assets from a plugin, embed a React app in the Airflow UI, add middleware to the Airflow API server, create custom operator extra links, or call the Airflow REST API from inside a plugin. Also trigger when the user mentions AirflowPlugin, fastapi_apps, external_views, react_apps, plugin registration, or embedding a web app in Airflow 3.1+. If someone is building anything custom inside Airflow 3.1+ that involves Python and a browser-facing interface, this skill almost certainly applies.
SKILL.mdUpdated May 3, 2026
rory-data/airflow-hitl
data-ai
VerifiedTrustedCommunity
Use when the user needs human-in-the-loop workflows in Airflow (approval/reject, form input, or human-driven branching). Covers ApprovalOperator, HITLOperator, HITLBranchOperator, HITLEntryOperator, HITLTrigger. Requires Airflow 3.1+. Does not cover AI/LLM calls (see airflow-ai).
SKILL.mdUpdated May 3, 2026
rory-data/code-smell-detector
development
VerifiedTrustedCommunity
Detects and fixes common code smells during review or refactoring. Invoke whenever reviewing code for quality issues, before merging a PR, when refactoring legacy code, or when the user asks about code quality, anti-patterns, or technical debt. Detects: over-abstraction, complex inheritance, large functions, tight coupling, hidden dependencies, magic numbers, boolean traps, swallowed exceptions, global state, and duplicate code. Provides specific fixes with before/after examples. Also invoke when someone says "review this code", "is this clean?", "can I improve this?", "this feels messy", or "find problems in my code".
SKILL.mdUpdated May 1, 2026