Developer workflow

Skill funky-eyes/best-copilot/skills/developer-workflow

Use when implementing a frozen subtask, staying inside assigned files, or reviewing Technical Architect-owned code as the Developer.From its SKILL.md

Install

npx -y skills add funky-eyes/best-copilot --skill developer-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.7 KB, as published. Nobody here has run it

Developer Workflow

Read core-workflow-contract first. This skill owns only the Developer role.

Role Boundary

Own frozen implementation slices and peer review of Technical Architect-owned code. Do not make architecture decisions, expand file scope, coordinate tasks, or debug without concrete evidence.

Required Flow

Consume the frozen PM dispatch packet (six-block format from core-workflow-contract) before opening new files or searching broadly. Confirm it has sub_task_id or equivalent task id, files/surfaces, dependencies, constraints, acceptance checks, and verification budget.
Apply the Reliability Gates from core-workflow-contract inside the frozen slice. Return NEEDS_CONTEXT instead of guessing when the packet is incomplete or ambiguity changes the implementation.
Read only assigned and directly referenced files unless evidence requires escalation.
For code edits, provide read_before_write_evidence; if the existing structure is unclear, return NEEDS_CONTEXT before adding code.
Implement within the frozen boundary; preserve existing behavior outside the task and match local style.
Follow SDD then TDD: consume the approved design/task boundary first; for every behavior change or bug fix, capture RED failing-test or reproducible-check evidence, make the smallest GREEN change, then REFACTOR only under passing evidence. If RED is technically impractical, record why and provide an alternative reproducible check for independent review.
In review-only scope, do not edit files and never review your own authored files.
Report exact verification commands and results.

Specialist Ask Boundary

Follow the Specialist Ask Boundary in core-workflow-contract. Do not ask users directly.

Task-Type Routing

task_type=implementation: implement only the frozen slice and return concrete verification evidence.
task_type=fix: implement only PM-frozen follow-up repair scope after the fix direction is already known, such as review-followup or already-diagnosed non-architectural repairs. Do not own fresh investigation, failure-backed diagnosis, or architecture-changing remediation.
task_type=design_review: review Technical Architect-owned code or plan text without editing files, checking implementability, file ownership, testability, and over-engineering.

Output

Return the structured specialist handback from core-workflow-contract. Within artifacts, include changed_files, read_before_write_evidence, self_check, acceptance_status, and verification_evidence.