Minis Coding Success Skills

A practical skill bundle for increasing coding success rate on Minis on iOS.

This bundle focuses on the places where coding tasks most often fail:

1. understanding the shape and risk of a change before coding
2. isolating tasks cleanly
3. diagnosing the real problem
4. implementing changes safely
5. verifying browser-visible behavior when needed
6. finishing the work cleanly
7. improving performance without guesswork
8. deciding whether the result is truly ready to release
9. handling deployment/environment mismatch
10. triaging real incidents
11. planning safe rollback and recovery
12. turning incidents and failed releases into reusable learning
13. using logs, metrics, traces, and telemetry effectively when direct repro is not enough

Included skills

1. software-architecture

Use before non-trivial implementation when structure matters.

Best for:

• clarifying boundaries and responsibilities
• choosing the simplest structure that will hold
• separating UI, state, logic, and side effects
• avoiding overengineering and hard-to-test designs

2. change-risk-review

Use before risky code, config, deployment, or workflow changes.

Best for:

• estimating blast radius before implementation
• identifying shared dependencies and sensitive paths
• checking reversibility early
• deciding what validation and safeguards are needed

3. using-git-worktrees

Use when multiple bugs, features, or experiments in the same repository should stay isolated.

Best for:

• keeping parallel tasks from contaminating each other
• separating experiments from production changes
• reducing branch confusion on Minis
• keeping work physically separated by directory and branch

4. root-cause-tracing

Use when a bug, failure, flaky behavior, or unexpected output appears and the visible symptom may not be the real cause.

Best for:

• debugging strange failures
• tracing upstream from stack traces or wrong output
• avoiding symptom fixes
• narrowing the first bad state or assumption

5. test-driven-development

Use when implementing a feature, fixing a bug, or refactoring code where correctness matters.

Best for:

• writing the smallest failing test first
• fixing bugs with regression tests
• building features with clearer behavioral targets
• making minimal changes with evidence

6. webapp-testing

Use when local web apps, HTML tools, or browser-based UI changes need browser-visible validation.

Best for:

• confirming a page actually loads
• testing UI flows in the browser
• verifying expected vs actual frontend behavior
• validating fixes that are visible only through interaction

7. finishing-a-development-branch

Use when implementation is mostly done and the branch needs to become clean, reviewable, and ready to commit or hand off.

Best for:

• checking tests before commit
• reviewing diffs for residue and scope creep
• removing debug leftovers
• preparing commit or handoff summaries

8. performance-debugging

Use when code is correct but too slow, too heavy, too laggy, or too resource-intensive.

Best for:

• measuring before optimizing
• locating real bottlenecks
• separating CPU, I/O, rendering, and state-churn issues
• making the smallest meaningful optimization

9. release-readiness

Use when implementation is mostly complete and you need a go / no-go judgment for release or handoff.

Best for:

• checking whether validation coverage is enough
• spotting dependency/config surprises
• writing honest caveats
• making a clear release decision

10. deployment-verification

Use when code works locally but may fail after deployment, packaging, or environment changes.

Best for:

• comparing local vs target assumptions
• checking config, assets, and startup paths
• catching deployment-only failures early
• verifying target-like behavior before or after release

11. incident-triage

Use when something is already going wrong and the first job is to assess impact, blast radius, and the next response path.

Best for:

• quick severity assessment
• narrowing blast radius
• gathering minimal useful evidence
• choosing rollback, hotfix, or deeper debugging

12. rollback-planning

Use when rollback may be safer than pushing forward and you need the safest reversal path.

Best for:

• defining rollback triggers
• separating reversible vs irreversible effects
• choosing the smallest effective rollback scope
• verifying recovery without making the incident worse

13. postmortem-writing

Use after incidents, failed releases, rollbacks, or major debugging sessions to capture reusable lessons.

Best for:

• writing compact blame-free postmortems
• separating trigger, root cause, and contributing factors
• preserving useful timelines without noise
• producing actionable follow-up items

14. observability-debugging

Use when logs, metrics, traces, or telemetry are the main evidence source and direct repro or code reading alone is not enough.

Best for:

• narrowing scope through runtime signals
• separating noisy signals from useful indicators
• correlating logs, metrics, traces, and visible symptoms
• identifying instrumentation gaps and next debugging paths

Recommended order

If the task starts with a non-trivial feature or refactor

1. software-architecture
2. change-risk-review
3. using-git-worktrees (if the task should be isolated)
4. test-driven-development
5. webapp-testing (if UI/browser behavior matters)
6. finishing-a-development-branch
7. release-readiness (if the result is being shipped or handed off)
8. deployment-verification (if environment differences matter)

If the task starts with a bug or unexplained failure

1. using-git-worktrees (if isolation helps)
2. root-cause-tracing
3. test-driven-development
4. webapp-testing (if UI/browser behavior matters)
5. finishing-a-development-branch
6. release-readiness (if the result is being shipped or handed off)

If the task starts with a slowdown or lag problem

1. performance-debugging
2. root-cause-tracing (if the slowdown may be a symptom of deeper logic/state issues)
3. test-driven-development (if behavior must be locked down while optimizing)
4. webapp-testing (if UI responsiveness matters)
5. finishing-a-development-branch
6. release-readiness (if the optimized result is being shipped or handed off)

If something is already failing in real use

1. incident-triage
2. rollback-planning (if rollback becomes the safest next step)
3. observability-debugging / root-cause-tracing / deployment-verification / performance-debugging depending on the evidence available
4. postmortem-writing after stabilization

Why this bundle works on Minis

Minis has a strong combination for coding work:

• iSH Linux shell for inspection, tests, git, and scripts
• browser automation for web/UI verification
• local file access for direct editing and review
• GitHub access for repo maintenance and handoff

These skills are tuned to that environment:

• shell-first investigation and testing
• minimal repros when no test framework exists
• browser-assisted verification for web work
• git-aware final cleanup before commit
• practical architecture planning for small tools and web apps
• explicit pre-change risk review
• clean task isolation for parallel work
• evidence-backed performance tuning instead of guesswork
• explicit go / no-go release decisions
• structured incident and rollback handling
• reusable learning after failure
• signal-driven debugging when runtime evidence matters most

Design principle

This bundle is built around one idea:

Do not jump straight from idea, risk, symptom, slowness, telemetry, or incident pressure to patch to commit to release in a messy shared workspace.

Instead:

• plan first when structure matters
• review risk before broad changes
• isolate first when tasks may overlap
• trace first when the cause is unclear
• test first when behavior matters
• verify in the browser when the user sees the result there
• measure before optimizing
• use runtime signals when direct repro is weak
• finish cleanly before declaring success
• review release readiness before shipping
• triage incidents before chaotic debugging
• plan rollback before urgent reversal
• write postmortems so failures become future leverage

Current scope

This bundle currently covers:

• architecture planning
• pre-change risk review
• task isolation with worktrees
• debugging discipline
• test-driven implementation discipline
• browser-visible validation for web work
• final branch/handoff discipline
• performance debugging and tuning discipline
• release-readiness checks
• deployment verification
• incident triage
• rollback planning
• postmortem writing
• observability-driven debugging
• reusable reference material for risk, postmortem, observability, and incident/recovery patterns

It does not yet include:

• production incident recovery execution as a dedicated skill
• fuller end-to-end incident walkthroughs from detection to postmortem
• reusable action-item tracking examples across multiple postmortems

Reference packs

Included now

• references/change-risk-review-reference-pack.md
• references/change-risk-review-example-reviews.md
• references/postmortem-writing-reference-pack.md
• references/postmortem-writing-example-postmortems.md
• references/observability-debugging-reference-pack.md
• references/observability-debugging-worked-examples.md
• references/incident-recovery-playbook-examples.md

These reference packs provide:

• blast-radius patterns
• reversibility matrix
• sensitive path checklist
• validation matrix
• recommendation templates
• compact review fragments
• worked risk reviews for shared utilities, startup config, dependency upgrades, and auth/session changes
• postmortem structure and timeline compression patterns
• trigger vs root cause separation guidance
• action-item quality guidance
• blame-free writing patterns
• worked postmortems for failed deployment, shared config incidents, and performance regressions
• signal categories and indicator patterns
• correlation strategies and instrumentation-gap checklists
• next-path templates for observability-heavy debugging
• worked observability examples for latency spikes, blank-page deploy issues, shared-path regressions, noisy telemetry, and frontend-vs-backend lag separation
• triage snapshots, rollback verification fragments, and incident status-update templates

Suggested next additions

Most valuable next candidates:

1. incident/recovery walkthroughs with fuller narrative examples
2. postmortem action-item tracking examples
3. deployment-verification worked examples

Repository structure

minis-coding-success-skills/
├── README.md
├── ROADMAP.md
├── CONTRIBUTING.md
├── .gitignore
├── GITHUB-METADATA.md
├── RELEASE-DRAFT-v0.1.0.md
├── references/
│   ├── change-risk-review-reference-pack.md
│   ├── change-risk-review-example-reviews.md
│   ├── postmortem-writing-reference-pack.md
│   ├── postmortem-writing-example-postmortems.md
│   ├── observability-debugging-reference-pack.md
│   ├── observability-debugging-worked-examples.md
│   └── incident-recovery-playbook-examples.md
└── skills/
    ├── software-architecture/
    │   └── SKILL.md
    ├── change-risk-review/
    │   └── SKILL.md
    ├── using-git-worktrees/
    │   └── SKILL.md
    ├── root-cause-tracing/
    │   └── SKILL.md
    ├── test-driven-development/
    │   └── SKILL.md
    ├── webapp-testing/
    │   └── SKILL.md
    ├── finishing-a-development-branch/
    │   └── SKILL.md
    ├── performance-debugging/
    │   └── SKILL.md
    ├── release-readiness/
    │   └── SKILL.md
    ├── deployment-verification/
    │   └── SKILL.md
    ├── incident-triage/
    │   └── SKILL.md
    ├── rollback-planning/
    │   └── SKILL.md
    ├── postmortem-writing/
    │   └── SKILL.md
    └── observability-debugging/
        └── SKILL.md

Skill links

• software-architecture
• change-risk-review
• using-git-worktrees
• root-cause-tracing
• test-driven-development
• webapp-testing
• finishing-a-development-branch
• performance-debugging
• release-readiness
• deployment-verification
• incident-triage
• rollback-planning
• postmortem-writing
• observability-debugging